The real challenge of wealth-tech data integration

Charles Southey
March 4, 2022

The real challenge of wealth-tech data integration

Charles Southey
March 4, 2022
No Comments

News

There has been a great deal of discussion aired recently in the UK Wealth Tech space around the need for much better data integration between the plethora of systems and platforms typically used by advice firms, and the perceived failure of the industry thus far to deliver it. By data integration we mean, quite simply, that systems should be able to share data about clients and their investments automatically between themselves, rather than you having to manually key in the same information multiple times: a so-called “swivel chair” scenario — as in repeatedly swivelling from one keyboard to another (nobody actually still does that, do they?).

A bit behind the times

In an age when our phones can recognize people from their faces, when our kids play games in immersive, 3D virtual environments and our cars are just on the brink of being able to drive themselves around a busy city centre more safely than any human driver, it seems more than a little bit ridiculous that business technology in this sector is still struggling with the basic concept that information can be sent from one computer to another across a wire (or through the air) rather than having to be typed in over and over again. I don’t need to spell out the wasteful effort this represents in countless firms up and down the country, but there are also huge problems associated with having inconsistent and incomplete data everywhere — the much-vaunted “single version of the truth” simply does not exist for the vast majority of firms. The end result is a poor experience for the end clients, and a huge challenge for advice firms struggling to deliver a good service and fulfil their Consumer Duty.

Why hasn't this been fixed?

The way online service providers (wrap platforms, for example), can make their data available to other systems is — almost always — through something called an API (it’s an acronym for “Application Programming Interface” , but that’s not particularly helpful). In truth an API is nothing more than a very simple website: like any website it waits for someone (or something) to come along and ask it for information, which it then sends back.

If the data is confidential in any way, it should only do so when the person or system making the request has verified who they are and that they have a right to access the data (the buzzwords for this are “authentication” and “authorisation”). Traditionally authentication was done just using a username and password — as in when you “log on” to a website (there are much safer and more convenient ways of doing that nowadays — but that’s a topic for another article).

What’s so difficult?

To hear much of the debate around the “challenges of integration”, you would think that the problem is that APIs are really, really hard to build, or really, really hard to use. Nothing could be further from the truth. As websites go, there are none more simple than APIs — they don’t have to worry about looking good on the screen, working with different screen sizes, guiding the user through a logical user journey or any of the hundreds of things that make building websites and online applications for humans difficult. They just have to pick up some data and throw it back down the wire — which is something all websites do anyway. Adding an API to your product offering should be one of the most straightforward of programming tasks for any organization. Most well-designed, modern systems already use APIs internally for the different parts of their application to share data, so adding authentication and exposing it externally should not be much of a stretch.

Likewise, writing a computer program to make use of (“consume”) the API at the other end is one of the most straightforward of programming tasks — and typically fully-worked examples of how to do this are included early on in the Programming 101 tutorials available for just about any programming language. For example, we have a junior developer who is just starting out with a new language, and in her first week she had built and demonstrated working, authenticated integrations with Google, YouTube, Unsplash and several other systems.

Some of the older APIs out there make life a little bit more complicated because they use a horribly over-engineered way of packaging up the data called “SOAP” that was all the rage 10–15 years ago, but modern systems eschew such nonsense and present the data in a very straightforward way so that it can be easily used by the consuming program.

So creating APIs is easy-peasy, using APIs is easy-peasy, and all this talk of “data hubs” and other ways of solving a problem that doesn’t exist in the first place (whilst inevitably creating new problems) is a complete red herring. The wrong kind of solution will just add more cost, risk and complexity — and ultimately the clients will foot the bill.

What problems are we really trying to solve?

OK — so the task of creating or using APIs is not the issue, so what is? Based on over ten years’ experience of building solid integrations with Wrap Platforms, Back-Office providers, Life Companies and various other services, these are what I know the real challenges to be:

1. Motivation

The most obvious point, the providers must actually want to provide a decent API in the first place. And in spite of all the noise made about it, one might reasonably ask: why should they? It’s not as if wealth firms are voting with their feet on this one — I see no obvious correlation between those providers that are finding the most market success and winning all the awards, and those that have the best APIs. Indeed, some platforms that have effectively zero offering in this area still appear to be winning out in the market over others that provide quite decent integration options.

However I personally believe, with the arrival of new API-focused entrants like Seccl, the writing may be on the wall for traditional platforms that pay little more than lip service to this growing need. The smarter platforms will soon start to take note and want to get in ahead of the game on this one.

2. Fear

There is a — largely unfounded — perception in some quarters (and unfortunately that includes some senior decision makers, legal departments and risk officers) that an API is somehow “more risky” than a human-browsable online website. There is absolutely no reason why that should be the case. As pointed out earlier, an API is just a website — the lack of pretty onscreen formatting does not make it less secure.

Of course, if the API is not seen as a core offering, and is starved of resources and attention, it may lead a to poorly designed, built or operated service that is indeed not secure. But that’s not because it’s an API.

Most of the platform websites out there (all those that don’t now enforce some form of 2-factor authentication, for example) aren’t particularly secure either — and believe me, cyber attackers are just as capable of scraping data from your pretty website as your machine-readable API. The solution to this is education: get informed and make evidence-based decisions — don’t be guided or held back by assumptions.

3. Bureaucracy

So let’s say a provider has the motivation, and has overcome the fear, and has built a fairly decent API. Can we, as a solutions provider, just hop onto their developer centre and have a working proof-of-concept integration up and running in less time than it takes to make a bowl of pasta as we can with the APIs from Google, Microsoft, YouTube etc ?

No, sadly not. Instead we have to…

Find the name of the person to contact
Try to set up a meeting (this alone can take weeks)
Demonstrate who we are and what we are trying to do
Complete and exchange forms and agreements (sometimes with paper, ink and snail-mail, sometimes involving lawyers)
Prove that we have an active, mutual customer (e.g. advice firm) waiting in the wings who will be the first beneficiary of this service (they won’t give us time of day otherwise)
Demonstrate that we have the customer’s written consent
Produce and demonstrate a prototype to get sign-off
Ask for the account to be put live, wait for that to happen
Start reverse-engineering the data we finally receive in order to make sense of it (there’s little or no documentation, naturally)

…or various combinations of the above. Finally, get to where we should have been able to get to with a few clicks of a mouse. This whole process can take months, and then we rinse & repeat with the next provider.

Isn’t all this fair enough, however? Shouldn’t we expect a responsible provider to exercise a reasonable degree of due diligence before handing out their customers’ data? Well actually, yes we definitely should — but this ain’t it. It’s another manifestation of fear driving pointless bureaucracy to give the appearance of due diligence (but without achieving the goal).

Above all else it’s a huge amount of friction that represents a barrier to entry to new firms competing in this space and stifles innovation and progress across the board.

Here are some ways that this could be made better:

Developer hub

Firstly, there is no reason we shouldn’t be able to build a complete working integration against a set of test data: this is the norm in most other spheres. Google and Microsoft, for example, host a great deal of highly-secure and confidential data on behalf of their customers — but just because we have built a working API integration doesn’t mean we can access it: for that we need those customers to explicitly give their consent, which they can do, online, e.g. by signing in to authorize it. They can also withdraw it at any time, just as easily. A developer hub like this award-winning one from Visa, with documentation and sample data, is what’s needed.

Who decides?

Secondly, a better arbiter of whether or not we are a sufficiently trustworthy organization to be handling this data is surely the advice firm on whose client’s behalf the data is being held. They cannot generally, of course, make a technical assessment of how we handle things — but they can decide if they trust us to handle their clients’ data. After all, if they chose to they could download it and send it to us anyway: there’s no good reason why the platform or wrapper provider has to be the decision maker on that if they are not the ones making the outsourcing decision. It could even be argued that they are exceeding their mandate and acting anti-competitively if they are seen to be making arbitrary decisions about which suppliers they will or won’t grant access to their API.

Data protection

Thirdly — and this is key — it is indeed right and proper that there should be a proper, independent, technical, procedural and ethical assessment of any provider that is handling sensitive client data, and that the clients themselves should always be aware of all parties who are doing so. As we can see in this timely demonstration from Credit Suisse (my first draft cited the Pandora Papers), the greatest threats to data confidentiality often come from insiders; relatively junior members of staff or even external contractors (e.g. in the IT team) may have extensive access to data by virtue of their role, but probably have not been vetted to the extent you would expect of someone in a more senior position. Furthermore, even if the team are totally trustworthy, their systems may not be watertight — and neither platforms nor advice firms are really able to verify that.

This could be a risk factor for 3rd party data hubs. In general, the fewer hops and staging posts the data has to go through the better. Organisations that handle highly sensitive client data as a data processor surely ought to be regulated and overseen — not in an onerous, bureaucratic way that limits competition and innovation — but in an intelligent and informed way that both helps to establish and maintain trust through the industry and reduces the burden of bureaucracy for small firms (independent accreditation could reduce the need to prove themselves to every supplier they need to integrate with).

4. Data content & taxonomy

Last, but not least, we come to one of the biggest issues, namely the accuracy, consistency, completeness and interpretability of the data that is available from today’s APIs. For, in spite of all the issues above, most platforms and providers do already offer some form of API, and it is possible to fill in the forms and go through their processes and integrate with them.

Having done so, what do you actually get out of it? I recently saw a tweet from another start-up in this space saying it was quite easy to get valuations from many providers, and they didn’t see what the fuss was about. Well, yes, that isn’t so hard: basic on-the-day valuations are generally available. They say a journey of 1,000 miles begins with a single step — and I guess that’s the first step. Here are just a few reasons, though, why that is a very, very long way from being sufficient:

Investors generally want to know about the performance of their investments. Not entirely unreasonably, given that achieving some form of return is the very purpose of investing. In order to show performance for a single stock holding, you need to know the average original purchase (aka “book cost”). This is seldom provided via valuation APIs.
You also need to know (or be able to calculate) the book cost in order to calculate your potential Capital Gains Tax liability on sale, or to manage your investments so as to reduce that. The definition of “book cost” for CGT purposes may not be the same as that provided for investment performance purposes (because of the treatment of reinvested dividends, for example). I don’t know of any platform API that supplies both versions of book cost. Surely this, if nothing else, should be mandatory. How can anyone accurately report their capital gains to HMRC?
In order to correctly show performance over time for a wrapper as a whole you absolutely need transaction data: you need to know the quantum and timing of every “external flow” (e.g. cash deposit, cash withdrawal, transfer etc.) transaction over the period in question, and you need to be able to distinguish between “external flows” and other transactions (distributions, interest payments, tax rebates etc. etc.).
You also need to know the previous value of the wrapper at the start of the period in question. There are very few platform or provider APIs that provide all these things. How should we know if a “Journal Debit” or a “Cash Adjustment” is an external flow or not? Even when transaction data is available, it sometimes includes unhelpful transaction types like that.
As an aside, the only correct way to show wrapper performance for an investor portfolio (and the reason you need those transaction dates ) is by using Money Weighted Rate of Return (XIRR in Excel). That takes account of both the value and the timing of flows. A “Time Weighted” return, which I have often been asked to produce, is completely the wrong metric for individual investors — it’s just for Fund Managers. If you don’t agree, have fun explaining to a client why their £5,000 loss is actually a 10% gain in Time Weighted terms. This can, and will, happen. A topic for another article.
If you want to know how much of a client’s annual ISA allowance or Pension Annual or Lifetime Allowances remain, it would be nice to know (assuming you can get transaction data at all) which of those transactions should be counted towards the limit and which are exempt. If you’re just transferring a SIPP or an ISA in-specie from one provider to another, for example, that doesn’t use up your allowance. This kind of information is almost never available.
If you have two Mr John Smiths, and one of them also has a joint account with his wife, it would be helpful to be able tell who is who — especially if you’re also trying to match against data from other platforms or back-offices. Just the name won’t cut it. Sometimes you don’t even get that.

Both ways

Absolutely everything we’ve talked about so far is one-way (aka “ready only”). Imagine if your client has moved address, or changed their name, or you want to rebalance their portfolio, or open a new wrapper for them, or process a withdrawal instruction, and you want to be able to process those changes and instructions across multiple platforms with a few clicks from within your own Practice Management System (“Back Office” or ”CRM” system if you must, but it really ought to be a Practice Management System).

OK, now I’m just dreaming. It could save a huge amount of time, cost, manual effort and reduce processing errors for both providers and Wealth Firms. If only there was an API-first platform-like offering out there…

In summary

To wrap things up: the problem of data integration is absolutely not about the difficulty of creating, or consuming, APIs. That stuff is dead easy. And it will absolutely not be solved by adding yet another layer of technology — and staging post for the data — into the mix.

We need platforms and other providers to choose to lead the charge, or be left behind. We need, as an industry, to establish and adopt best practices, drawing from what’s happening in other, more advanced, sectors, not making up our own from scratch. We need standards around how data is recorded, and what data must be made available. This latter point may be one for the regulators — it’s surely not OK that we can tell a client how much their portfolio is currently worth but we have no idea how it got to that point. We need providers to overcome their fear and encourage integration and healthy competition by creating clear, simple, documented developer hubs, like this one, for example. Oh yes, if HMRC are happy and able to do it, maybe it’s not so dangerous, scary or difficult after all?

Seccl has thrown down the gauntlet with their API. Who else is brave enough, and visionary enough, to pick it up?

Charles Southey

Charles Southey is a Cambridge-educated Computer Scientist with over 30 years experience leading IT solutions delivery in some of the world’s most successful organisations, including 10 years delivering award-winning commercial solutions in the Financial Services sector.