Our article answering the question What is PSD2? provides an overview of PSD2 security requirements. In this article we will provide further details on an approach for meeting these requirements, for Open Banking solutions.
The PSD2 directive has led to a ‘Banking as a Service’ API platform in the UK, and in simplified terms this involves the following parties:
- Banks act as ‘Account Servicing Payment Service Providers’ (ASPSPs) and host API endpoints
- Merchants and Fintechs act as ‘Third Party Providers’ (TPPs) by building apps that call the above APIs
- Consumers act as ‘Payment Service Users’ (PSUs) and use apps that access their bank accounts
The platform is designed to be dynamic, so that a consumer can use many merchant apps, and qualifying merchants can call the APIs of many banks.
In order to establish a concrete best practice on meeting regulations and achieving interoperability, financial working groups have published guidance such as the Open Banking UK Implementer’s Draft.
This involves adapting the OAuth and OpenID Connect frameworks into a ‘profile’ that conforms to PSD2 and deals securely with threats. The profile is used both by banks implementing APIs, and by businesses who call those APIs.
Financial security profiles usually require Level of Assurance (LoA) 3 for payment transactions, which in turn requires Multi Factor Authentication. It is also recommended to be able to dynamically change factors used by apps, as part of an Authentication Policy.
In order to participate in Open Banking, apps call bank APIs over a Mutual TLS tunnel, within a restricted Public Key Infrastructure (PKI). Businesses calling the APIs must present a valid eIDAS client certificate both during authentication and when accessing data.
After approval by eIDAS, PSD2 mandates that a merchant must be able to begin interoperating with bank APIs without delay. Traditionally however, mutual TLS clients are cumbersome to manage, requiring both OAuth clients and certificates to be configured.
OpenID Connect has a mechanism for Dynamic Client Registration which should be used in this case, so that any approved company can sign up quickly and reliably via HTTPS calls. This is done by sending the eIDAS client certificate to the Authorization Server, to create an OAuth client, whose details can then be used to call the API.
This registration endpoint is protected by mutual TLS and allows any client in possession of a client key signed by an eIDAS authority to connect. This allows for immediate on boarding to take place without delay.
The Dynamic Client Registration Management article provides further details on how DCR can be used with client certificates, and the below video provides details on the Curity Identity Server’s implementation.
Before taking payment from a customer in an app that uses Open Banking, the PSD2 requirement of user consent must be satisfied. This involves asking the user to confirm the runtime amount of money and merchant being paid.
Consent must also be non-repudiable, audited and linked to access token claims, so that banking APIs have clear proof of the user’s intent and can authorize the request.
The built in OAuth consent mechanism does not fully meet these requirements, and a complete solution may involve asking the customer to use an additional app, which makes an out of band call to a third party signing service.
Since Open Banking involves highly sensitive data, its best practice will evolve further over time, to deal better with threats. The article on Financial Grade Security highlights some of the newer OAuth and OpenID Connect standards related to financial systems.
Open banking implementations require you to meet difficult PSD2 regulations. This is best managed by implementing a financial security profile designed by experts, based on OAuth and OpenID Connect. You will then need an Authorization Server that supports up to date standards.
One of the key goals of the Curity Identity Server is to enable banking grade security and we continually improve our support for related standards. This provides a toolbox that banks and other businesses can use to build and maintain Open Banking services and clients.