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
Why hasn't this been fixed?
What’s so difficult?
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:
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.
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.
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:
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.
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.
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.
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…