4 ways to ensure Open Banking doesn't become the next Cambridge Analytica

"Plenty of risks to learn from API driven industries," says cybersecurity expert

by | October 18, 2018 | bobsguide

The Open Banking Initiative, brought in by PSD2 on January 13, heralded the start of a new dawn.

A key proponent of European Banking Authority (EBA), Financial Conduct Authority (FCA) and Competitions & Market Authority (CMA) policy, the permissioned release of customer data to third parties (TTP) from the incumbent custodians has already seen an explosion of best of breed fintech propositions anticipating the impact of the initiative.

But, as bobsguide recently reported, Open Banking still has some way to go to convert public sentiment: according to a YouGov poll, 77% of the UK public is concerned about data sharing. The marketplace and ecosystem model that the regulators envision for the industry relies upon customer trust. For the custodian banks, fomenting trust is a security exercise, and for the fintech third parties, a marketing exercise, according to John Sheehy, director of strategy at cybersecurity firm IOActive.

And both exercises are interlinked. A breach of financial data now not only comes with hefty fines thanks to GDPR, it can also be disastrous for the PR image; in a crowded market, customers desert services en masse, and is often fatal for the service providers. The primary example for Sheehy, the effect the Cambridge Analytica scandal has had on Facebook’s user numbers.

As incumbents look to shore up their own API infrastructure for Open Banking, Sheehy believes they should be ready to wholly embrace Open Banking while keeping aware of the unique security risks posed by an API culture.

“Why would the banks want to promote customers to use external services?,” asks Sheehy. “The answer is, if you don’t cannibalise your own business, somebody else will. If banks want to retain market share or continue to serve a large pool of customers, they have to provide the services at the costs the consumers want.

“Open banking brings with it a set of risks. If we look at some of the industries based around significant API sets we can see very recent lessons in the threat posed, even on the scale of the Cambridge Analytica scandal.”

Here Sheehy lays out the top 4 risks banks should understand for the next five years of API driven Open Banking:

Exploiting permissions

A main risk is that consumers do not totally understand the permissions inherent with PSD2.

If we look at the current app market there are apps that abuse permission access to collect sensitive data. This isn't just garage job, nefarious apps but well-known companies who may wish to know what other apps are running at the same time for competitive intelligence purposes rather than customer experience; for instance, a car sharing app does not need to know what other apps are running.

Trust is the currency of APIs

Likewise, there has to be a very clear, transparent and concise communication of what a permission can and cannot do to ensure the customer understands. The obvious example of that done poorly are the reams of terms and conditions when accepting software.

Data privacy is inherent to the new era of consumer trust. While legacy banks may have hundreds of years of experience managing that trust, new fintechs and challengers do not. The question becomes how do you strike a balance between the optimal API driven world of customer experience and customer trust? I don’t know and can’t say if this implementation of Open Banking will do that, but what I do know is that it will bring a lot of unintended consequences and risks.

Understand how an API ecosystem generates innovation

With an ecosystem surrounding a set of APIs, market participants recognise that there is no single architect with all the good ideas. What drives innovation is diversity of people, organisation structures and market placement; in effect a mix of companies trying different things will generate ideas, concepts and innovations.

This is where innovation comes from, they can use the API in an unintended way and it can have good consequences or bad consequences. For the team behind Cambridge Analytica, it was a bad consequence.

This is the dual line that is needed between unintended consequences that have innovative effects and unintended consequences that are strongly negative.


This of course down to a bit of self-governance, where the supervisors of the marketplace/app store regulate the providers accessing their APIs. Here the banks can accredit and approve each third party by ensuring they have the right intentions and are handling data responsibly.



Data matching & reconciliations: not spreadsheet native

Best Practice | Banking Data matching & reconciliations: not spreadsheet native


Data matching & reconciliations: not spreadsheet native

Here is a summary of the top 6 reasons why commonplace spreadsheet technology can no longer meet the advancing reconciliation… Continue Reading

View resource
Reza Simchi, Graviton Global Investments Pte Ltd - ETRM systems (Best Practices)

Best Practice | Banking Reza Simchi, Graviton Global Investments Pte Ltd - ETRM systems (Best Practices)

Enuit llc

Reza Simchi, Graviton Global Investments Pte Ltd - ETRM systems (Best Practices)

This presentation was created by Reza Simchi of Graviton Global Investments Pte Ltd in September 2021 for Enuit LLC in… Continue Reading

View resource
Profile Software eNewsletter Summer 2021 edition

Banking Profile Software eNewsletter Summer 2021 edition

Profile Software

Profile Software eNewsletter Summer 2021 edition

Profile’s quarterly eNewsletter Summer 2021 edition presents the company’s recent implementations in banks like Optima bank with the new Digital… Continue Reading

View resource
Customer Experience in Banking - ViewPoint

Best Practice | Banking Customer Experience in Banking - ViewPoint

Maveric Systems Ltd

Customer Experience in Banking - ViewPoint

Onboarding a customer, familiarizing them with the bank, and retaining them is largely dependent on the bank’s ability to create… Continue Reading

View resource