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. This next article focuses on the cybersecurity implications of the EU’s regulatory landscape post-Open Banking era and how to address them with secure APIs.

Regulatory mandates such as the UK’s Open Banking initiative and Europe’s revised Directive on Payment Services (PSD2) aim to promote innovation, competition and financial inclusion.

Forward-looking financial institutions see this as an opportunity to extend their value proposition to customers through partnerships with new, non-bank parties, collectively known as FinTechs, using Open APIs (Application Programming Interfaces).

But how can financial institutions, like banks, expect to improve their partner relationships and customer offering through APIs while remaining compliant with new cybersecurity mandates around data sharing? We aim to explore this idea in today’s post, but first, let’s have a recap of the regulations affecting open banking partnerships – all of which have a part to play.

Regulations Affecting Open Banking Partnerships

eIDAS

As GlobalSign have said in a previous blog on ‘The Road to eIDAS’ :

“In order to achieve the goal of a transforming digital single market, the European Union's regulation on Electronic Identification and Authentication Services (eIDAS) was created. eIDAS sets an electronic identification standard to achieve safe and streamlined online transactions across Europe. And for this purpose, the regulation relies on electronic trust services.”

Before eIDAS, Digital identity services in the UK appear to have been a low priority for financial institutions in comparison to other areas, such as payment initiation and account aggregation services. However, in other European states, digital identity has been seen as a priority. For example, the Italian government launched SPID (Sistema Pubblico Identita Digitale), a national identity system allowing public services to be accessed by a single digital identity, boosting efficiency and economy development for Italy.

France, The Netherlands and Germany are now beginning to prioritize their focus on this area, moving forwards, and Nordics have been ahead of the game for quite some time.

Therefore, as financial institutions begin to develop partnerships with APIs with FinTechs, consideration will need to be given to building a single agile framework to deliver the required reporting services across multiple business areas and at times, across borders and between disparate infrastructures.

PSD2

PSD2 mandates that financial institutions (such as banks) must open access to their customer information and payment networks to third-party providers. Financial institutions must provide this access through a secure and standardized set of APIs offering account information and payment initiation services to customers.

To do this securely, financial institutions are mandated to first identify their customers through ‘strong customer authentication’. Simple username/password combinations are insufficient. Financial institutions must apply Multi-Factor Authentication, using two or more customer attributes.

These can be selected from what the customer knows (‘knowledge’), a digital certificate embedded in a mobile phone that the customer has (‘possession’), or biometric data such as fingerprint or iris scans to prove who the customer is (‘inherence’).

This new regulatory landscape aims to accomplish the following.

• Extending the cybersecurity ecosystem beyond a financial institutions own infrastructure and apps. Financial institutions are still responsible for the security and privacy of customer information and funds, so must carefully verify partners’ cybersecurity and privacy processes and controls.
• Scaling the cybersecurity capabilities of financial institutions to accommodate the increased number and range of partnerships and protect and monitor their increased attack surface (the result of increased data collection and sharing).
• Setting policies and standards by which financial institutions will partner with FinTechs. FinTechs may not know how to integrate securely, so banks need to provide guidance.
• Balancing security with a positive customer experience.

(PSD2) allows these FinTechs, such as third-party payment services providers, to enter the European payment market and access consumers’ sensitive data, with the aim to offer new, convenient and secure payment services. And with this added convenience, there must also be additional safeguards for all the sensitive data that is moving around this ecosystem.

Regulatory Technical Standards on Strong Customer Authentication (RTS SCA)

In addition, and applicable in September 2019, the Regulatory Technical Standards on Strong Customer Authentication (RTS SCA), specify various elements to ensure strong customer authentication and common and secure open standards of communication under PSD2. This includes defining in detail the elements requiring SCA, including the use of Multi-Factor Authentication (defined above). 

The General Data Privacy Regulation (GDPR)

Furthermore, the General Data Privacy Regulation (GDPR) necessitates embedding customer consent into partnering strategy. Customers must be allowed to decide what data can be shared, with whom, and to what purpose. They must also be allowed to revoke their consent and request removal of their data at any time.

Putting The Requirements Together

When it comes to adopting a secure Open Banking Initiative, financial institutions should be:

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

How Do We Gain Consent and Authenticate Customers in Open Banking Partnerships?

The regulations and requirements above work together to create an opportunity for all 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 partners and third-party providers have strong cybersecurity capabilities for protecting the customer information that is shared.

Developers working in financial institutions must begin implementing measures to identify their customers and gain consent before data sharing with FinTechs. We outline a recommended workflow for this below.

Recommended Workflow for API Authentication

Open standard protocols for authorization such as OAuth and OpenID Connect are current best practice for granting third-party access to account information while maintaining the privacy of the customer’s login credentials. Re-authentication is also required depending on the activity being invoked such as funds transfer or payment.

The steps in the authorization flow are:

1. The customer uses a partner’s end-user application. The application is attempting to get access to the user’s account and needs permission from the user before it can do so.
2. The app is directed to the financial institution’s authorization server. This is the server that presents the interface where the user approves or denies the request.
3. The customer is authenticated according to OpenID Connect using multi-factor authentication (e.g. use of a digital certificate embedded into the customer’s device).  
4. The customer is asked to authorize (consent to) the sharing of data with the end-user application. The actual data to be shared is defined by the “scope of consent”.
5. The customer is redirected back to the end-user app and consent is approved with an authorization code.
6. The end-user application requests the authorization server to exchange its authorization code for an authorization token. This extra step enables the authorization server to conduct an extra check to ensure that the end-user application is who it is expected to be.
7. The end-user application provides its authorization token to the financial institution’s resource server to gain access to the information for which the customer has provided consent.

The regulatory requirements we mentioned above ensure that best practices are being laid out for identification and authentication to ensure a pre-required level of cybersecurity aimed at a more trusted transactional market in the EU. Financial institutions and FinTechs alike need to start incorporating these standards and tools into their services and partnerships sooner rather than later.

In my next post, I will 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 above authorization workflow, financial institutions and FinTechs can safely and in compliance with the new EU regulations, send and share data to improve their services.

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.