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.
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.
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:
From Part 1, the key cybersecurity activities that financial institutions (FIs) need to take when implementing Open Banking Initiative are:
There are three main approaches to carrying out authentication and authorization of a customer through a dedicated interface. These are:
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.
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.
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:
The financial institution provides access to the FinTech by:
The Qualified Trust Service Provider (QTSP) provides security for the financial institution and FinTech partnership through:
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:
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
|Csuj oadg||Jhydg sgst||OnlineSecureBankingNoPermission|
|Hgdg jhdg||Hgs gwjth as|
|Khwer hswet||1 jAydw jYswop|
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
|Csuj oadg||Jhydg sgst||OnlineSecureBankingNoPermission|
|Joe Bloggs||One Frith St|
|Fred Smith||1 Maple Street|
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.