Q&A with Simon Clare, CTO Bravura Solutions and David Tonge, Co-Founder and CTO Moneyhub

In our research into the advice tech stack we repeatedly find that lack of integration poses a substantial challenge for adviser businesses. Firms have invested in the various elements they need to build a tech proposition that suits the firm and their clients, often on the promise that those elements will seamlessly stitch together, only to find the reality does not deliver an integrated experience and data has to be manually re-entered.

The finger is frequently pointed at APIs, but what actually is an API? Why do they sometimes not work? What should advisers ask and expect of their technology partners?

We spoke with Simon Clare, Chief Technology Officer at Bravura Solutions and Dave Tonge, CTO at Moneyhub, to answer some these questions and find out if we can look forward to a brighter, more connected future.

What is an API?

Simon Clare [SC]: It stands for Application Programming Interface. Basically APIs are ways for computer systems to speak to each other. It’s a contract – that word is important – a contract or a promise one computer system makes to another. If a computer system publishes an API, it promises that if you talk to it in this particular way and tell it what to do on a thing it knows about, then it promises to do that certain thing.

Dave Tonge [DT]: Now, when people talk about APIs they’re generally talking about a way for cloud-based services to talk to each other.

For example, let’s say you want to take payments on your website, you can use a company called Stripe and they provide an API so that your web developer can look at their documentation and then create the process for information to be collected on your website, sent to Stripe and processed back to you.

APIs are also used to transfer data. Let’s look at open banking: all of my financial transaction data is at my bank with my current account. Maybe I want to use another tool to analyse that data and aggregate it. Before APIs, I would have to log in to my bank account, hope they had the ability for me to export a file, or I’d have to manually copy down all the bits of data, then I’d need to go to another tool, try and import the data or manually copy things in. With an API, the tools can be connected. I can simply authorise a tool to go to my bank transactions and analyse them.

Aside from data transfer, what else is good about APIs?

DT: The good thing about APIs is that they unleash a bit of creativity. Take the example of Google; there are loads of add-ons for their Office suite. If they had to do technical work for each and every one of those, there would be far less integrations. Whereas they can say this is our API and anyone with a good idea can create an extension or an add-on that works with Google.

SC: I think it’s really important to be able to run open systems, and for clients to be able to participate in new emerging ways in which platforms are communicating. It’s a rapidly evolving world and the more we can maximise the connectivity and interoperability of our systems the more we can participate in a connected future, where we can plug and play with other people’s technology.

Are all APIs ‘open APIs’?

People talk about Stripe’s APIs as being open, because you can just access their website and all the APIs are publicly available. So are there two types of APIs – open and not?

DT: There’s probably a bit of a scale; it’s not so much one thing or the other. A better way to differentiate would be ‘standardsbased APIs’ and ‘proprietary APIs’. Standards-based APIs are what people think of as ‘open’. For example, again with open banking, the banks use standards-based APIs, so a tool like Moneyhub can write code once for Barclays and use the same code to connect with HSBC and the same code for Nationwide. If they all had proprietary APIs we would have to do extra work to connect to each one separately. Sometimes there’s no choice but to do a proprietary API, if there aren’t common standards agreed between businesses.

How can advisers figure out the costs involved with APIs?

DT: Something like a payment tool for your website can be quite clear in the pricing model, for example some fee based on each payment. In other cases the cost models can be tricky, especially if it’s based on usage and it can be difficult to estimate what your usage costs will be. What I would recommend, and what quite a few companies offer, is more like a per user based pricing because it’s a lot easier to understand and often you might be paying for existing systems like that already. For example you might be paying for a back office system on some level of per a number of users.

The other thing I would say is nowadays, providers shouldn’t be charging extra for an API. If you’re already paying them for some service, the API should be part of that service. Google don’t charge extra for their API. The API is just another way of accessing that same service.

Why don’t they always work? And why do they sometimes work and then stop working?!

SC: Every API is a promise, and if a provider promises to keep this API up to date, they promise that this API works. If I change my software from one version to another, that promise still stands. If I change that and I break it, then that breaks it for everyone who is using my API, so I have to change my API in a controlled process. That effectively is why it might go wrong sometimes. Whoever is maintaining those APIs has to do a good job of it. They have to maintain them formally.

DT: Fundamentally, some of the problems are down to a mismatch in the different services. If you have a system that is geared for US 401(k)s and you’re trying to get that system to display UK-based tax wrappers, the problem there is above the level of the API.

The other problem in the investment world is that a lot of the firms might not have as much technical experience in building and maintaining high quality APIs. That I think is part of the problem, and the lack of standards. Sometimes there are these different proprietary APIs and it’s quite easy for one company to blame the other.

Often things go wrong in the consent and authentication stage that is necessary in financial services, for example an open banking tool has to go to my bank, and the bank has to ask if I’m happy to share my data with the tool, and that pattern is sometimes where it falls down. The most complex part of the whole pension dashboard system is identifying the user, taking the user through the authentication and making sure you capture their permissions. And then especially in the adviser world, you’ve got all these intermediated connections and multiple users.

What should advisers ask their prospective tech partners?

SC: There are two key questions around APIs. The first is, do they have their own APIs that they maintain and manage? They should be able to give you documentation that describes what those APIs are and what they do. The second thing is, we’re in a maturing world where API standards are coming into place now as well. So question two is ‘do they use any open API standards’? You can’t apply that one across the board yet because we’re not quite at the place where there’s a formal fully open set of API standards for the industry.

DT: If an advice firm doesn’t have access to large amounts of technical expertise, then ideally what you’re looking for is existing integrations between the parties. Taking a step back from APIs, what we want to get to is solution A, B and C work together. So that everything is in sync and we’re not having to manually export data from one place and import it in another. The way in which that happens nowadays is often through API-based integrations. So you can just ask what are the APIs and what companies have integrated to it. If the systems aren’t already integrated, then there are tools like Zapier that mean you might be able to do some of your own integration work. That can be really useful for creating customised workflows. You can be a little bit less at the mercy of say, a back office provider if there’s a new feature you want to implement. If they provide a good API, then you might be able to add in logic like, for example, when there’s a new client onboarded, using Zapier you can say ‘send this email here’ or ‘update this record’. There are all sorts of things you can do.

What does the future look like?

DT: In an ideal world all of this stuff would just speak together. In another five years, not much longer than that, there’s this whole ‘no code’ movement, things will start speaking together a lot more. There are a lot of people now, especially a little bit outside financial services, who are moving away from the old way of doing software, where you have something very specific built for a specific industry to solve a specific problem. Now people are realising a lot of companies actually have similar problems that need to be solved and the requirements are actually very similar. I think where things are going is that you have these cloud-based services that maybe do fewer things but do them really well and can speak with other systems. In the short term that could make things even more complicated for a financial advice firm, and maybe there will be consultancy fees to pay if you don’t have the experience to hook that all up, but in the long run that is likely to be a far lower cost than paying a big bill to a proprietary piece of software that is only targeting your niche.

Right now for advisers, my advice would be to get their data in order, use a cloud-based system, wherever possible one that has an API. That won’t fully futureproof you but it will make it a lot easier.

This article first appeared in our Spectrum of Adviser Platforms and the rise of White Labelling report – You can download a free copy here.

Would you like to share your views and influence our research agenda? Employees of financial advice firms can join the NextWealth Research Panel and get free access to NextWealth research by sharing their views.