Open Banking consultant and trainer Jon Scheele continues a series of articles on how financial institutions and FinTechs can implement new technologies in the European Union (EU) regulatory landscape. 

Jon’s first article explained what approaches are needed to incorporate cybersecurity into partnerships between Financial Institutions and FinTechs. His second article focused on the cybersecurity implications of the EU’s regulatory landscape post-Open Banking era and how to address them with secure APIs.

In this post, I take a closer look at the reference architecture of APIs for Open Banking and how financial institutions and FinTechs can safely share data under this architecture. Married with the authorization workflow described in my previous article, financial institutions and FinTechs can safely and in compliance with EU regulations, send and share data to improve their services.

The aim of the reference architecture is to show the building blocks that financial institutions can use to strengthen the resilience of their infrastructure in order to:

• reduce the odds of a successful cyber-attack,
• facilitate smooth and rapid recovery and
• ensure a coordinated response and resolution of an attack between partners, regulators and other stakeholders.

Cybersecurity Requirements

From Part 1, the key cybersecurity activities that financial institutions (FIs) need to take when implementing Open Banking Initiative are:

• authenticating customers,
• gaining consent (authorization) from customers to share data with Third Party Provider (TPP) partners,
• recording consent for audit purposes,
• allowing customers to revoke consent,
• vetting partners and their cybersecurity capability,
• granting partners secure access to customer information (and only the information that the customer has consented to share).

Regulatory Technical Standards on Strong Customer Authentication (RTS SCA)

Part 1 also described the authentication and authorization workflow for financial institutions to gain consent from customers before sharing their data with third-party payment service providers (TPPs). It showed the components needed to deliver this workflow using OAuth2.0 and OpenID Connect.

In addition, and applicable in September 2019, the Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Open Standards of Communication (often referred to as just RTS SCA), specifies that Account Servicing Payment Service Providers (ASPSPs) can implement authentication using either a dedicated interface to the third-party provider, or an adaptation of their online banking application.

There are three main approaches to carrying out authentication and authorization of a customer through a dedicated interface. These are:

• Redirection: the customer is redirected from the FinTech or third-party payment provider's app to the bank’s authorisation server, and returned to the FinTech's client on completion.
• Embedded approach: the customer’s authentication data are exchanged between the FinTech and the financial institution through the interface, allowing the customer to consent to a transaction through the FinTech's client.
• Decoupled approach (or a combination thereof): the bank asks the customer to authorize the payment, for example via a dedicated mobile app or any other application or device which is independent from the online banking front-end.

The financial institution should choose the method that aligns best with the authentication procedures it offers to its customers through its own online customer interface.

Securing the Application and Transport Layers to Meet PSD2 RTS SCA

Underpinning the authentication and authorization of the customer (a 'payment service user' or PSU in PSD2 parlance) is a deeper level of security to ensure that the FinTech or third-party payment provider, financial institution (an account servicing payment service provider or ASPSP in PSD2) and messages between them are what they purport to be.

The Berlin Group’s NextGen PSD2 Framework describes an API-enabled access-to-accounts (XS2A) interface. The framework comprises an application layer and a transport layer.

• The Application Layer comprises account service definitions and data models for core and extended services.
• The Transport Layer covers the composition of messages and the mechanism for message exchange.

At the Application Layer, for the purpose of identification, qualified certificates for electronic seals are used for securing data and documents originating from the payment service provider (could be the FinTech or financial institution). A seal guarantees the authenticity of the document or data – confirming that it actually came from the payment service provider and that it hasn’t been altered.  Qualified certificates are issued by a Qualified Trust Service Provider (QTSP) according to the eIDAS regulation. The certificate has to indicate all roles the FinTech is authorized to use as well as its authorization number issued by a National Competent Authority (NCA).

At the transport layer, the communication between the FinTech and the financial institution is secured by a TLS connection. Per PSD2 regulatory technical standards (RTS), this requires a qualified certificate for website authentication issued by a QTSP, again in accordance with the eIDAS regulation.  

A Reference Architecture for ASPSPs and TPPs

Successful integration requires components provided by both the financial institutions and the FinTech:

The customer uses a web interface or client app provided by the FinTech.

The FinTech delivers services through:

• a web server that hosts the client application that the customer uses,
• an identity server to authenticate its customer and
• a signing server to request a Qualified PSD2 certificate from the qualified trust service provider.

The financial institution provides access to the FinTech by:

• exposing its services through the access-to-accounts (XS2A) interface via the API gateway,
• verifying the identity and integrity of the FinTech and its messages by means of qualified PSD2 certificate,
• obtaining customer consent to share information via the authorization server and
• providing access to the customer information contained in its resource server.

The Qualified Trust Service Provider (QTSP) provides security for the financial institution and FinTech partnership through:

• confirmation that the FinTech has registered with the competent authority in the FinTech's EU member state,
• providing qualified certificates when requested by the FinTech,
• provision of qualified certificates containing all necessary PSD2 data and
• revoking certificates upon request that can originate from the certificate subject (FinTech) or from the National Competent Authority.

Applying the Reference Architecture to building Open Banking Partnerships

The above reference architecture provides a guide to building secure interoperability to enable financial services (FinTechs and financial institutions combined) to extend their value proposition to customers. Success will rely on the ability to:

• attract partners and provide more choice that will enhance the customer’s journey;
• make it easy for customers to securely provide (or revoke) their consent to sharing sensitive information with partners and third party providers and
• ensure that all entities have strong cybersecurity capabilities for protecting the customer information that is shared.

In my next post, I will look at the implementation options for each of the reference architecture components, in order to meet the cybersecurity requirements of PSD2 Regulatory Technical Standards (RTS).

For more information about PSD2 and SCA, including timelines, check out this infographic from the European Payments Council – PSD2 Explained.

About the Author

Jon Scheele is a consultant and trainer, helping financial institutions and FinTechs build new customer value propositions through API-enabled partnerships. Jon trains financial services professionals in the strategy, design, implementation and product management of APIs in his course in Building Financial Services Open APIs.

Note: this blog article was written by a guest contributor for the purpose of offering a wider variety of content for our readers. The opinions expressed in this guest author article are solely those of the contributor and do not necessarily reflect those of GlobalSign.