APIs and your data

Just because an API can access and share your data – should it?

An Open API ecosystem could transform banking, introducing new banking apps across a range of services. But at what cost to consumer privacy and data ownership?

Change is coming. Particularly regarding open access to user’s financial accounts through Open APIs as enabled by the Competition and Markets Authority, (the CMA). The method to access accounts has just been specified to enable developers to build applications for enhanced comparison tools allowing customers to search and select financial services products. These standards and specifications (which are currently in pre-release beta), can be accessed on the developers page of the Open Banking website. The service provider will therefore have access to a limited non-sensitive set of personal data, depending on contractual agreements. It is within these contractual details, that the devil may be found.

What happens to your data after it is exposed via APIs to third-parties, or if it is stored by third-parties? What control and / or ownership do you have over the usage of your data after an initial enrolment into the service? The answer is worryingly vague.

Through third-party API’s, consented for but hidden in terms & conditions, your data can and will be shared with a range of external third-parties, beyond your control or knowledge. These include financial services employees, insurance companies, marketing services and even health providers. Account aggregation technology then pools and contextualise highly personal data. This data cannot be kept secure through regulation alone. It must be protected by technology.

There are two types of Account Aggregation: “Server-Side” where customer’s financial accounts and personal information is aggregated by a server owned and managed by a third-party service provider, and “Client-Side” where customer accounts and information is aggregated on the customer’s own device. In the widely used, “Server-Side” model, customers, having accepted terms & conditions provide ‘agency’ coverage to the service provider and disclose their online login and password to the provider. These credentials are stored on the server and used by the provider to perform aggregation. The security risks associated with disclosing online credentials to a third-party and the personal financial information stored by the provider, even if encrypted, are obvious.

Conversely, the “Client-Side” model never requires the customer to disclose their online credentials to a third-party. Aggregation is performed on the customer’s chosen device. Data is encrypted and stored on their own device in a Personal Data Vault, where the customer can choose to share their data (or not) with a third-party.

Once consent has been proactively given by the end consumer to upload and enhance their data, including categorisation, transactions, or geo locations, a plethora of financial services can be provided against that data set. These services all rely on a complete understanding of the consumer’s entire financial position across multiple institutions, including offline assets and liabilities. Above all, data security is embedded into the data aggregation from the start. That’s the good news, the bad news is that “Client-Side” data aggregation is still rarely implemented, and it is not implemented at all in the US.

API Data Access Architecture, two models:

APIs and regulation: building security into the heart of the process.

PSD2 Access 2 accounts (XS2A) proposals exist to open up APIs to empower businesses and enhance services. Open APIs have the potential to enable companies within the payments space to work off each other’s platforms, driving innovation. Yet the question of what happens to your data once the back-end is opened is pertinent. It must be addressed with permission-based software, supplying ultimate control over who sees your data and credentials, affording you, the end-user, the power to revoke access.

Although third-party access to credentials may change depending on what verification mechanism is implemented for PSD2 and Open Bank APIs in Europe, a security challenge still persists in “Server-Side” aggregation models, and regulatory grey areas still exist. PSD2 requires security and access controls for customer and employee data – but not necessarily for authentication credentials. Europe’s General Data Protection Regulation coming into force in May 2018 mandates that organisations comply with aspects of data handling, putting the onus on organisations to demonstrate compliance. Yet until then, the impetus is on data processors and data controllers to carry out due diligence and ensure their data handling processes are reactive enough to defend individual rights. The argument has been that legacy banks will not have the technology to be reactive enough to protect the back-end, but my argument is that new entrants joining the financial services ecosystem may not always be as security proficient as the legacy players.

Safe data aggregation technology is needed to work across all platforms. Organisations of all sizes need to consider a ‘data re-sharing’ strategy, accounting for how their customers consent for the safe sharing and storage of their data. This consideration needs to be backed by technology, not just regulation. This security must be insured at exactly the point computers interact; the API.

Without permission schema determining the use of your data after it is sent to an API the financial transactions and data you share can be retained by the technology provider and shared at will, enabled through most aggregation contractual terms and conditions. It is therefore my hope that “Client-Side” data aggregation becomes the norm rather than the exception. Your data must remain yours only.