Effectively Implementing SCA for UK Open Banking APIs

Eliminating the devil from the details: comprehensive support for UK Open Banking security requirements.

Open banking is gaining momentum across the globe. Initially, PSD2 in the European economic area gave it a welcome regulatory boost. The pan-European initiative was quickly followed-up by the CMA in the UK, resulting in the creation of the UK Open Banking standards that had to be implemented by the nine biggest banks in the UK. These comprehensive standards have become a source of inspiration for open banking initiatives in other geographies like Australia and the US.

An increasingly digitalized consumer playing field calls for a refreshed approach to payment and account handling. Open banking aims to give consumers more control over and access to their financial data and the ways and means to utilize them. This implies an inevitable shift from ‘traditional’ retail banking methods to supporting payment through different channels and devices and facilitated by organizations other than the traditional bank.

Goals of Open Banking

To create a more attractive payment landscape for online consumers in particular, open banking first aims to provide a frictionless payment process, regardless of whether the consumer uses a channel provided through their bank or an alternative one (i.e. direct payment through a merchant’s website). The flipside, however, of opening up additional channels for payment is an increased opportunity for fraud. Thus, open banking also involves a strong focus on consumer protection. In other words, securing channels and processes to minimize the possibility for potentially fraudulent activities that would be harmful to consumers.

What online payment scenarios have in common is the physical absence of the account holder or his/her card (“Card-not-present transactions”). In a typical open banking payment example, the consumer delegates payment to a third-party payment provider (TPP) that becomes responsible for a seamless, direct transfer of the requested amount from consumer account to merchant account.

In general, payment transactions require the explicit consent of the account holder (also referred to as payment user). Such consent is only valid, of course, if the identity of the payment user can be well established. In other words, to avoid payment fraud, it is essential to ensure reliable identification and authentication of the payment user.

Securing Payments With SCA

To guarantee reliability, traditional single-factor authentication is often deemed insufficient. This is why payments under open banking are subject to Strong Customer Authentication (SCA). This is the term adopted in the open banking space to refer to multi-factor authentication or MFA. Essentially, SCA/MFA means that authentication is only regarded as successful when “authentication assertions” are offered through (at least) two independent channels and correspond with distinct “authentication categories”, summarized as:

• Something you know (knowledge)
• Something you have (possession)
• Something you are (inherence)

For example, an initial consumer login using traditional username and password may have to be augmented by confirming the payment through a different channel, using a short-lived token that only applies to this particular payment transaction.

I don’t think it comes as a surprise that SCA – the conditions under which it must be used, as well as the conditions under which exemptions apply – has been made a central requirement under PSD2. As a result, it has also entered the Open Banking UK specifications.

SCA vs. 3DS

Essentially, SCA has to be applied to all payment transactions (unless exempted – see below). This is in contrast to the current banking practice which essentially uses a risk-based approach based on the 3-D Secure (or 3DS) protocol.

The 3DS protocol appeared to be unsuitable to be applied to online open banking payment processes, the major objection being its negative impact on user experience – and remember that a frictionless payment flow is one of the main open banking objectives. Fortunately, version 2.0 of 3DS, commonly known as EMV-3DS, effectively addresses these and other concerns with the earlier version. In fact, it is deemed to increase payment transaction security without being overly restrictive.

Major card issuing companies like VISA and MasterCard are mandating banks to implement EMV-3DS, aiming at successful completion in line with PSD2 implementation timelines. It should be noted that the current PSD2 deadline, set for September 14, 2019, may well be extended to give implementing parties more time to complete.

Nevertheless, banks that aim to claim a leader’s position in the open banking playing field are set to complete implementation in time. Here, adopting software solutions that support essential requirements out-of-the-box has proven to be an effective and cost-efficient strategy.

Akana’s Solution for Open Banking and APIs

APIs being a core element of any open banking implementation, Akana has been actively following the developments in open banking and PSD2. The Akana API Management Platform already offered comprehensive support for the open standards that have been embraced by the emerging specifications, in particular TLS, OAuth and OIDC. The Platform has since been extended with effective support for the security aspects required to ensure message integrity and confidentiality (JOSE Security). All API security aspects are consistently addressed through configurable policies that can easily be reused across APIs.

Recently, the Akana solution has been extended with yet another feature that will enhance the implementation of open banking standards, in particular in the UK. To facilitate UK banks’ implementation of SCA as required under PSD2, a centralized solution is offered based on the RSA Adaptive Authentication for eCommerce interface. Implementing this interface provides banks with an EMV-3DS based SCA capability.

The RSA interface is API-based and comes with specific requirements to ensure message security. The Akana Platform is offering a new policy that specifically addresses these security requirements, in particular:

1. Validate a message sent from RSA to issuer (bank) by verifying the payload (i.e. validate the JOSE signature, check the expiration time);
2. Decrypt the message;
3. Encrypt a message sent from issuer to RSA;
4. Sign this outgoing message.

Having this capability available through an out-of-the-box policy will greatly alleviate the effort required to implement this specific aspect of the open banking/PSD2 interface.

In conclusion, let’s provide a summary overview of the capabilities that Akana provides in any open banking/PSD2 implementation context. Akana allows you to:

• Create an initial API representation (by uploading the Swagger/OAS documents as published by the open banking standards organizations);
• Implement open banking security requirements through configurable, reusable policies: mutual TLS, certificate-based client authentication, OAuth2.0/OIDC-based client authorization, JOSE security;
• Effectively implement the RSA AA security profile to support SCA, again through a configurable, reusable policy;
• Test your API through its built-in Test Client, which allows for configuration of the request message to have it comply with all of the above security policies;
• Implement additional API security requirements not explicitly specified in the open banking standards (but essential to ensure a secure API interface; for example, checking for malicious content in the message, etc.);
• Effective lifecycle management of your APIs (as APIs themselves will be subject to changes as a result of evolving specs, resulting in fresh API versions, etc.).

Ready to see Akana in action? Start your 30-day free trial today. 

Start Trial

👉 Become an Expert

Explore additional resources:

• API Basics
• API Security Best Practices