How to (better) implement secure APIs in an Open Banking Partnership – Part Two

CEO Suni Munshani’s blog How to (better) secure APIs in an Open Banking partnership – Part One talked about the business advantages of taking a holistic approach to protecting data for compliance with multiple regulations and initiatives and highlighted some great advice from Open Banking consultant, Jon Scheele. In this sequel blog I’ll take a more technical look at how a data-first approach reinforces the architectural responses he advocates, abridged below.

Cybersecurity Reference Architecture

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.

Sponsorships Available

Sponsorships Available

Sponsorships Available

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)

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.

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). 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.

Why Protegrity?

So, financial organisations need strong authentication for PSD2, Open Banking and GDPR, but it is clear from recent headlines that consumers favour brands like Apple with privacy as a brand value. Challenger banks and fintechs have been quick to realise that data sharing initiatives are likely to fail without customer trust and have been agile in their response.

For incumbent financial brands this is harder due to complicated IT estates and sheer volumes of data. Protegrity, however, allows any financial entity sharing data with third-parties for consumer access as encouraged by these initiatives, to make sure that sensitive data is protected at rest, in transit and in use.

Our flagship product, the Data Security Gateway (DSG), allows for the interception of traffic into and out of an organization and to unprotect data as it leaves one bank and is sent to another.

Transport protocols may be HTTPS, SFTP or even email over SMTP and formats may be text, CSV, Office Documents, XML, JSON and others.

At the point of egress, where data leaves the first financial entity, the legal responsibility should be enforced which includes the customers preference for information sharing, and certificates or keys must be presented by the calling bank so there is a secure handshake.

Customers preference determines whether to unprotect their data or leave it protected as in the example below using tokenization.  This can be done by adding customer preferences to the rows in the file and adding just one line to the DSG rules.

This example is an opt-out model, but it is possible to implement an opt-in approach too. Suppose we have a file like this to unprotect and send to a receiving bank:

Table 1: Protected Data

Upstream systems creating files for processing, must inject the customers preference into the file; this is usually done from a database lookup or a join on a table.

One of the powerful features of the DSG, is the ability to scan a line of data quickly, using a regular expression which states the customer has opted-out of allowing sharing of their information. If the string ‘OnlineSecureBankingNoPermission’ is found, then the rest of the line is not processed and protected data, or tokens, are passed to the receiving bank.

Figure 1 Implementing User Preferences on Data Egress

The resulting output file will look like this:

 Table 2: Unprotected Data Respecting User Preferences

By protecting data itself, financial brands can be confident about securely collecting and aggregating it – only to be unprotected by the applications authorised to expose it at the presentation layer to customers. This guarantees the maximum level of security and useability.

If you want to know more about how your brand can protect data and control access to it get in touch.

Linkedin

Facebook

Twitter