Open Banking is Nearly Here and it is Going to Change Everything

In 2016 the Competition and Markets Authority (CMA) concluded its investigation into the UK banking sector by mandating that the nine largest banks in the UK must enable customers to share their data securely with other banks and third parties in order to accelerate digital change, enable new types of banking services and increase competitiveness across the entire sector.

In 2013 the European Commission proposed an amendment to the existing EU payment services directive. This amendment is commonly referred to as PSD2 and is similarly concerned with increasing digital competitiveness, increasing consumer choice and promoting the adoption of online and mobile payments. PSD2 has significant overlap with Open Banking, and many believe PSD2 can largely be achieved through the use of Open Banking APIs. As such the UK’s open banking efforts have been aligned to PSD2.

In 2018 both the CMA Open Banking recommendations and PSD2 legislation are due to come into effect, and they will have big impacts on customer trust relationships. Customers will be able to:

• Move banks, and take all of their transaction history and data along with them in an automated, seamless and secure way.
• Utilise services to aggregate all of their banking history in one place.
• Enable accountants to directly access their transaction data.
• Pay for purchases directly by choosing to pay with a bank account rather than a debit or credit card.
• Do numerous other things that have not even been thought of yet.

At the very heart of open banking is the issue of user consent. With open banking, for the first time, the customer controls their banking data. And they choose who gets to access it and what they can do with it. Banks must ensure customer data is secure and must adhere to customer access instructions in a consent-driven way, and third-party service providers such as retailers and account aggregators must become identity enabled to partake of the benefits of this new world. The imminent arrival of the General Data Protection Regulation (GDPR) adds further challenges, for example you will also have to ensure that users can revoke their open banking consent at any time.

ForgeRock has been working with Payments UK and the Open Banking implementation entity to define the technical standards for open banking. One of the most important challenges to solve has been that of consent. How can users consent to the sharing of their data and the execution of their payments? And how can this actually be implemented in time for the early 2018 open banking deadline? As always, we look to open standards.

The OAuth 2.0 standard is a leading solution for delegated authorization. Using OAuth, a user can consent to (authorize) an application doing something on their behalf. A typical example of this is enabling one of the many third-party Google Drive-related applications to connect to your Drive account without that client app needing to see your Google credentials, or accessing certain Drive functions it shouldn’t have or can’t handle. You can even go into Drive later and disconnect the app if you ever want stop using that app. This is OAuth’s great set of strengths. The functions that the app is constrained to perform are called scopes, and they are typically predefined items such as being able to read Drive items, viewing their activity history, etc.

OAuth is potentially a great solution for authorizing access to your account data, but it has some missing pieces. For example, OAuth scopes are, in practice, not set up to be defined dynamically, but in Open Banking a user may wish to make a single payment to a retailer that includes an amount that would differ every time. You can’t predefine what a payment will look like and still have OAuth’s user authorization flow work correctly, so the OAuth scope mechanism is insufficient for capturing these dynamic payment details.

Enter OpenID Connect (colloquially called OIDC), which builds on top of the OAuth standard and enhances it in a number of key ways. OIDC is typically used for federated authentication. When you “Login with your Google account” to a third-party site you are using OIDC to do so. In effect what you are doing here is authorizing Google to share your identity with a third party.

But OIDC is more than just an identity layer. Importantly for Open Banking, OIDC not only defines a variety of standardized security tuning features on top of OAuth, it also defines a mechanism for dynamically defining scopes. The use of OIDC enables users to set up a consented custom payment with one of these whizzy new apps without having to reveal their identity to this as-yet untrusted app, and then be redirected to their own trusted bank to authorize the payment in a secure and identified fashion. The mechanism being used is called the request parameter, and it enables a signed and/or encrypted JSON Web Token (JWT, pronounced “jot”) to be included in the app’s OIDC authorization request sent to the bank.

Quite clever, really. With the request parameter we now have a mechanism to securely enable both payment initiation and account sharing, two of the key use cases PSD2 and Open Banking are designed to enable. The Open Banking Work Group has formally recommended the use of the request parameter for implementing open banking in the UK. This means that anyone who wishes to enter the open banking ecosystem must be OIDC enabled.

The ForgeRock Identity Platform supports OAuth and OpenID Connect out of the box, so you can implement open banking compliance consent flows. However, that is just one piece of the puzzle.

You also need to secure the APIs that return open banking data. With OIDC, the way you do this is by enabling them as resource servers. The ForgeRock platform can act as an authorisation server, issuing OIDC tokens that can be validated by any OIDC-compliant API gateway such as Apigee. Alternatively, if you do not have your own API gateway you can deploy the ForgeRock Identity Gateway component in front of your existing APIs to identity-enable them.

So now you have a secure way of collecting bank customer consent and a means by which to protect their data, but how do you authenticate the user securely? The ForgeRock Identity Platform offers a large collection of different authentication mechanisms including push notification with touch ID, device fingerprinting, adaptive risk and many more. PSD2 mandates Strong Customer Authentication (SCA) as a requirement and the ForgeRock Identity Platform is SCA ready out of the box.

Finally you need all of this to be scalable, highly available and up and running in time for the deadline of January 2018. Open Banking really is coming and it really is going to change everything. ForgeRock is ready to help you on that journey.

Download our Open Banking white paper to learn more.