Open Banking

Full Title or Meme

Open Banking is both a concept and an actual implementation in the UK.

This page addresses both the UK implementation of the EU banking standards and the concept of Open Banking.

Context

A Chris Michael interview described Open Banking Limited, the brand name of the Open Banking Implementation Entity (OBIE), as a private, non-profit company established in 2016 by the UK’s Competition and Markets Authority (CMA) to create standards and implementation guidelines for United Kingdom retail banking. The organization is funded by major UK banks. Open Banking originally was focused on a subset of PSD2 namely personal and business accounts in UK currency. Now the group is tackling a broader set that covers all PSD2 requirements for payment providers across Europe and includes credit cards and e-wallets, all currencies, and FX International Payments. It sounds more dangerous every day.

“I think the standards will evolve even beyond that, so this is a really interesting space,” Michael said.

Part of that evolution revolves around the fact that while Open Banking is the name of a UK initiative, “open banking” as a concept is spreading globally. In Australia, for example, the Australian Government is pushing forward with Open Banking, recommending adopting the UK’s standards. Japanese banks and financial institutions are registering as payment providers and soon will be required to open their APIs. And here in the United States, Intuit’s Mint now uses OAuth to connect to select banks like Bank of America, Chase Bank, and Capital One with tokens instead of full access with username and password.

“We're also trying to make sure that these standards are true global standards. So we're working with other standards bodies globally, whether it's in Europe or other emerging markets like Australia, to try and make sure that everyone's using the same core standards,” Michael said. “What we're doing now is creating standards and implementation services for not just the CMA order but for the whole of PSD2, and our standard is designed to be one that is a European, if not a global standard, for financial APIs.”

“It's really great to see so many other markets who are adopting open banking and also who are looking to our standards as a kind of gold standard to build on,” he added. “But it's also great to talk to those other markets and talk to the identity professionals who are looking at open banking in those markets because I think there's also quite a lot that we can learn from them as well.”

When it comes to standards creation, the open banking arena is changing rapidly. Open Banking originally was focused on a subset of PSD2, namely personal and business accounts in UK currency. Now the group is tackling a broader set that covers all PSD2 requirements for payment providers across Europe and includes credit cards and e-wallets, all currencies, and FX International Payments — and the landscape continues to shift.

Problems

The following are listed as problems that will be solved.

• The major selling point of this effort by the European bureaucrats is for increased competition.
• The major selling point of this effort by the standards makers is reduction of the risk caused by "screen-scraping" by personal financial consolidation software, which needs user passwords for full access without the new APIs.

There are several areas that will need to be monitored as Open Banking roles out in the EU as exacerbating existing problems in the banking world.

1. Out right fraud https://www.bloomberg.com/news/features/2018-09-11/why-the-eu-is-furious-with-malta
2. Money laundering

The standards are not yet fully tested in the real world with real Users. For example:

• Banks are worried about the bearer tokens introduced with OAuth 2.0.
• Banks and payment initiators are both trying to entice the user's to download apps which have the vulnerability of a User Experience which allows exploitation by attackers. See page Native App Security.
  • Android play store requires Native Apps to be bound to an Enterprise Web Site URL if they use the branding of that Enterprise, but there is no recognized way to bind these 3 concepts securely.
  • Apple's secretive plans are a source of uncertainty in terms of release of any type of secure binding that will encourage safe Behavior by Users.
  • This thread discusses some of the challenges of native-app to native-app interchanges where the apps are supplied by the payment initiator and the bank. The apps are considered to be user agents AND user clients, but are supplied by two organizations that moving user assets from one to the other in the back-ground. What could possibly go wrong?

Threat Models

• Traditional Threat Modeling involve an expensive simulation of the total network and use of common models to turn that into a risk profile. That is hard to do without a specific implementation architecture to model. So none have been published in Open Banking even though it is likely that the banks have run them.
• Fraud is by far the most likely source of costs from Open Banking standards. Several studies have addressed the issue in general terms and an attack model has been included in the OpenID FAPI standards. Open Banking is Creating New Fraud Challenges for the Banking Industry was published on 2020-02-17 where the cost to customer acceptance was address in general terms based on a PwC study that showed that on 18% of UK customers understand the actual impact of Open Banking on their experience.
• Like all enterprise, banks like to privatize profits and socialize loss. Socialization can mean pushing the costs on to governments or insurance companies, and more recently directly on to the customer. There is some hope that the banks will make customer whole in fraud when it happens, but the most common experience is for the customer to be blamed for the fraud. This is not going to help with acceptance of Open Banking.
• Threat Models traditionally only consider costs born by the bank. While that might include reputational or Conduct Risk it is not likely to consider the risk to the customer. Clearly this approach is not customer friendly and may run afoul of some government's regulations.

Solutions

• The UK open banking specs are kept on an open source repository.
• The Berlin Group is looking at an EU wide deployment.
• The Swift Standards are the basis a Global Network that enable efficient communications among banks world wide. It is manipulated by the larger Western countries for their own purposes and has not been interested in in protecting customers.

Dual Mode and Wallet

• Dual Mode - Extending the Reach of Open Banking APIs

  In theory Open Banking APIs can support Consumer Payments. However, the server centric OAuth security concept makes UX quite challenging compared to schemes like Apple Pay where SCA and account selection are integral parts of the “Wallet”. This presentation outlines an open, light-weight, synchronous API dedicated for Consumer Payments

• Dual Mode Open Banking API.

  Current Open Banking APIs do not specify a matching "Open Wallet", they have rather left this part to the market to figure out. This is likely to lead to a fragmented payment landscape unless a few and very dominant vendors set their own "standards". This is the sole motivation behind the Dual Mode Open Banking API proposal. In addition, current Open Banking APIs introduce a security and user interaction model which significantly departs from already established and well-functioning national mobile payment systems as well as from Apple Pay. The described scheme heavily builds on experiences with such systems.

Banking APIs Deployed

• Open API Banking Examples / Use Cases Thriving: After ING Bank, Deutsche Bank Looks For Partners For API

Definitions of interest from the UK Open Banking effort. These acronyms are used through-out the already jargon-heavy industry and will cause lots of head scratching. The major issue is whether Trusted Third Party access to the Users account are read-only (for consolidated reporting - aka screen scraping), or read/write (for payment initiation).

Entity Name	Type	Cat	Description	Access
Payment Service User (PSU)	Real World Entity	N/A	a natural or legal person making use of a payment service as a payee, payer or both	No
Payment Service Provider (PSP)	Legal Entity	N/A	A legal entity (and some natural persons) that provide payment services as defined by PSD2 Article 4(11)	Yes
Account Servicing Payment Service Provider (ASPSP)	Legal Entity	PSP	provides and maintain a payment account for a payer as defined by the PSRs and, in the context of the Open Banking Ecosystem are entities that publish Read/Write APIs to permit, with customer consent, payments initiated by third party providers and/or make their customers’ account transaction data available to third party providers via their API end points.	the bank or its agent
Third Party Provider / Trusted Third Party (TPP)	Legal Entity	PSP	organisation or natural person that use APIs developed to Standards to access customer’s accounts, in order to provide account information services and/or to initiate payments. Third Party Providers are PISPs or AISPs.	see PISP and AISP below
Payment Initiation Service Provider (PISP)	Legal Entity	TPP	provide an online service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider.	read write
Account Information Service Provider (AISP)	Legal Entity	TPP	provide account information services to consolidated information on one or more payment accounts held by a payment service user with one or more payment service provider(s).	read only
Financial Conduct Authority	Legal Entity	Federation Owner	The FCA is the competent authority for the UK	No

References

External Sites

• The API page on this wiki helps put the banking apis in context.
• CEF: Opening a Bank Account Across Borders with an EU National Digital Identity for OIX Europe