Part three of this epic on Open Finance, right up there with the guitar solo at the end of ‘Free Bird’ by Skynyrd.

I will now cover the boring and deeply unsexy part of Open Finance: all the work that product providers and platforms will have to do to make it a reality. By which I mean, deal with the huge demand to release the data they hold on customers’ long term savings products.

Really it’s all about data. Data availability, data quality, data storage, data protection and, um, APIs.

Data Quality
People get pretty obsessed with this one, and to be fair they aren’t wrong. Data quality is an issue. People tend to forget to tell financial institutions when they move house or change their name. But it’s not just that.

Hidden away in financial service firms, all sorts of skeletons exist. Firms know they have some shonky calculations processes and rely on some people running a calculation on a spreadsheet when a request comes in. That won’t fly in a world where the customer expects that data to be available and correct in seconds.

Now I have a wee bit of sympathy on this. Data quality is hard (see aforementioned lack of updates from customers) but some of the decisions made to just live with manual process are likely to lead to a lot of work at some point.

Data Availability / Usability
It’s possible that a firm has all their data in tip top shape but that’s not the end of the things they will need to consider. The data probably sits on an admin system, designed to run the product. That system’s job is to assign payments, buy and sell funds, etc. But most are simply not designed to allow access 24/7 in the volume that Open Finance will demand.

Nor is it necessarily held in a way that’s easily usable. We know from Pensions Dashboard for example that calculations may be run but not stored, other than in a PDF or Word document. Or held in tables on databases that are really only designed to be read by super expert users. For example, a column might have “3” meaning it’s a single premium. Perfectly useful when running an internal process, no use at all to a customer.

Then of course the issue for big firms that have a heritage back book is that they don’t have one admin system, they have a couple, several or even many. All with their own wonderful idiosyncrasies.

For these and other reasons, it’s likely that firms will need to consider a data store.

Data Storage
Now if all the products are on a single super modern platform it may be that a firm won’t need a data store. But we know from Dashboard that, one way or another, most firms are going to go the data store way, be it in house or via an ISP.

But what is a data store in this context?

Essentially, somewhere that all the data a customer might expect to be able to access or share is held so that it is instantly available, 24/7, and in a format that the customer understands.

Building and maintaining such a store is no small task, but they can have a lot of secondary benefits within the business itself. Firms actually find it hard to access this data for their own internal needs such as MI, business reporting or even marketing. It’s possible they have wanted to do this for years but never had the business case to get it prioritized. With Open Finance likely to be a regulatory requirement, that will change.

Data Protection
The data needs to be secure. Non-negotiable. Simple as that.

OK a bit more on this. Identifying the customer is a key part of open data, and one that is extra tricky in the UK as we don’t have a national ID system. I would expect Open Finance will have to follow the route of Pensions Dashboard, so there is going to be a lot of reliance on the UK financial service sector and government sorting out Digital IDs. Without a secure and trusted framework that a firm can rely on, it will not be able to release data.

APIs
An API, or Application Program Interface, is how the data gets moved between the different parties. They are a standard way to request and receive the data. Like a virtual USB port if you will.

Firms will need to have the APIs in place, built to the agreed standards. These will handle the requests which then go to the data store. It will also handle security and other aspects.

A key question is the volume of demand that may go through the APIs and the need to respond quickly. They also need to resilient enough to stay available 24/7/365 and not fall over.

We have already seen in the Pensions Dashboard space that a lot of firms have no interest in building these in house and are using ISPs like Altus, ORIGO or Bravura to do this for them. I expect this will be very much the same with Open Finance. But that will not mean there is no work for the end provider firm. They will ultimately have to be the ones demonstrating to whomever is in charge that they have met their obligations.

Next we will move on to the rather more exciting world of how we might use Open Finance to help people.