Guest blog written by Chris Michael, Head of Technology, Open Banking; speaker at IDENTIFY 2017 Europe.

Open Banking is a global concept

Open Banking can be summarised as the introduction of APIs which allow developers to build products and services on top of core banking platforms.

This is a global concept with far-reaching implications. It promises to give banking customers a new and secure way to take control of their financial data, and make payments directly from their bank accounts. It should also help level the playing field between large players, small players and new entrants. And, in turn, this should give consumers new, innovative financial products and better value for money.

That's all very good, but there are some conflicting challenges as follows:

• There's a tricky balance between frictionless e-commerce scenarios (e.g., Amazon OneClick) and secure multi-factor authentication (MFA) (e.g., using a hardware key fob or card to login to your bank account).
• We've trained consumers to be careful about sharing sensitive data with third parties, and now we appear to be saying it is OK to share your data.
• Organisations who can access Open Banking APIs will need to be able to navigate a complex regulatory and banking landscape. How will smaller fintechs and third parties be able to participate and compete against the bigger players?

As explained below, these don't have to be contradictions at all.

The UK is leading the way

In 2018, the second Payment Services Directive (PSD2) and the General Data Protection Regulation (GDPR) both come into force across the European Union, including the United Kingdom. These regulations will define and govern the use of Open Banking APIs.

In 2016, the Competition and Markets Authority (CMA) ordered the CMA9 (the nine largest current account providers in the UK, including AIBG, Bank of Ireland, Barclays, Danske, HSBC, Lloyds Banking Group, Nationwide, RBS and Santander) to set up and fund the Open Banking Implementation Entity (OBIE), an independent not-for-profit limited company.

The remit of the OBIE is to deliver fully open API standards and a security framework for banking in the UK. While this is aligned to PSD2 and GDPR, it goes a step further. It requires each of the CMA9 to adopt the same tightly defined standard. This consistency should be good for developers as it leaves less open to interpretation, eliminating the need to build a different integration into each bank. The same consistent standards and security framework are also open to any non-CMA9 current account providers (e.g., challenger banks) to use if they wish.

This is a very smart move, which should give financial services in the UK a head start compared with the rest of Europe and indeed the rest of the world.

Standards designed to protect the consumer

Security, privacy and express consent are the pillars of Open Banking. The OBIE's API standards fall into three groups:

Open Data APIs

These APIs cover data that is (or should be) in the public domain and that doesn't contain any personal or sensitive information. They include location information on ATMs and branches, and most importantly standardised (and so more easily comparable) product information on personal current accounts, business current accounts, SME unsecured lending and SME credit cards. Each of the CMA9 must make this information available to developers without the requirement for any registration or access controls.

Closed (Read/Write) Data APIs

These APIs cover the data relating to an individual Payment Service User's (PSUs) account. The Read API consists of:

• Account and Transaction API, which allows the retrieval of account details, balances, lists of trusted beneficiaries, direct debits and standing orders.
• Transaction History API, which allows the retrieval of transaction records for a defined period.

The Write API allows for the submission of a single immediate payment. The initial version of the specifications (v1) is limited to UK PCA and BCA accounts in GBP. However, the APIs have been designed so that they can be further extended to cover additional use cases, for example the fuller set of requirements defined by PSD2.

Security Profile

The Read/Write APIs are protected resources, and access is controlled by the OBIE Security Profile. This is based on OAuth2 and allows for the PSU to be redirected to the ASPSP website (or mobile app) to authenticate and authorize. This is further enhanced using OpenID Connect (OIDC), based closely on the OpenID Foundation's Financial API (FAPI) profile. Crucially, the profile mandates the use of TLS MA and JWS for signing.

Creating a secure ecosystem

The OBIE have gone a step further in creating the Open Banking Directory. This is a core platform for banking in the UK and will provide trusted participants (i.e., FCA-regulated banks and third parties) with credentials, software statements and digital certificates, so that they can transact securely.

The Directory also introduces the concept of Dynamic Client Registration, whereby a TPP can onboard their apps with multiple banks automatically using a single set of credentials. The Directory can be likened to an App Store or Marketplace for Open Banking, which makes it easy for trusted parties to connect and transact.

Driving developer adoption and customer benefits

The OBIE approach tackles head on some of the apparent contradictions I listed above and delivers many significant benefits:

• By keeping the Open Data standard completely open, we have removed any potential barriers for third parties to access this data for the benefit of their customers.
• The Read/Write standards are based on an OAuth redirect which ensures the customer is giving their banking credentials only to their bank and not sharing them with third parties. This positive friction is a good thing for one-off access, as it reassures the customer they are dealing with their bank.
• Furthermore, the standards can be extended to allow the trusted third party to have longer lived access to the customer's account, which will remove unnecessary friction for repeat access scenarios (e.g., giving accounting software repeat access to transaction history without the customer present).
• The granularity in the scopes and permission codes give the customer full control of what data they share and with whom.
• The OB Directory provides a secure environment for FCA-regulated entities to connect and transact.
• And finally, Dynamic Client Registration will significantly reduce the manual overhead of developers having to manage different credentials and onboarding processes with multiple banks. This should lower barriers to entry and speed up adoption.

Next steps

The Open Data APIs went live in March 2017. Earlier this month, the Open Banking Directory opened for enrollment. PSD2 comes into effect on 13 January 13 2018, coinciding with the launch of the Read/Write APIs.

There are a number of significant enhancements and extensions being considered for 2018, so we are just at the beginning of a very exciting new phase for banking.

This has been a large and complex program, which wouldn't be possible without the dedication and collaboration of so many people across the OBIE, the CMA9 and many stakeholder groups.

Banking really is becoming Open.

More Information:

• Please contact enquiries@openbanking.org.uk
• Join us at IDENTIFY Europe on 25 October 2017 to hear Chris Michael speak or visit www.pingidentity.com/PSD2