How to (better) Secure APIs in an Open Banking Partnership – Part One

by protegrity on March 8, 2019

March 8, 2019

Author : protegrity

European financial institutions are increasingly asking us about protecting their customers’ personally identifiable information for sharing purposes in-line with UK and European initiatives and directives. There is lots of great advice out there including this from, Jon Scheele, written for Global Sign, and abridged for this blog with kind permission from the author, find the full version at globalsign.com.

The tactics advocated here, when built on a foundation of Privacy by Design – or data-centric audit and protection – offer those in the financial industry a strategy for confidently embracing these changes, without fear of breach or business compromise.

Sponsorships Available

“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

Electronic Identification and Authentication Services (eIDAS)

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.

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

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.

Financial institutions must apply Multi-Factor Authentication, using two or more customer attributes.

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

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.

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

Why Protegrity?

Offering customers personalized services in digitally convenient ways via open APIs in compliance with these UK and European data sharing initiatives gives financial institutions an opportunity to increase competitive advantage and customer loyalty but according to the UK’s Competition and Market Authority (CMA), customers will not give consent to share their information without comprehensive safeguards in place.

This poses a problem for the established banks and FinTechs who see balancing the need to protect personal information with their plans to transform by innovating with data and disruptive technologies, as difficult.

“The overarching challenge for everyone in the industry is in securing consumer trust by adopting an exemplary approach to privacy and data security.” Chris Scott, The Bunker

By going one step further than authentication and verification to find and protect private information itself – at rest, in transit and in use – financial institutions can be data-first in their approach to both customer privacy and business growth.

Protegrity supports financial organizations with the data-centric discovery, protection, authentication and authorization critical for compliantly protecting their customers from fraud

Look out for the next part of this blog or contact us directly to find out more about how Protegrity can help your brand ensure customer trust, as well as prevent the financial and reputational damage of data loss and cyberattacks that may be caused by the vulnerabilities associated with the integration of internal systems with third-party service-oriented architecture and microservices-based system.