13 Jul 2018

Addressing Cybersecurity in Financial Institutions/Fintech Partnerships

We introduce Jon Scheele, consultant and trainer working with financial institutions on API-based partnerships. He is beginning a series of blogs aimed at financial institutions and FinTech’s to help them cope with the emerging technologies and regulatory-driven landscape of the EU market. For the next in the series, follow the link at the bottom of the article.

Partnerships between financial institutions (FI) and FinTech (financial technology based start-ups) must go beyond the customer value proposition. Strict regulations such as eIDAS for securing electronic transactions, PCI DSS specifying how payment data can be captured, stored and organized and GDPR on customer privacy, require cybersecurity to be embedded into all stages of the customer journey.

To provide end-to-end protection of customer information and financial assets, all partner systems must include authentication and authorization, protection of data, system integrity and proactive detection and response to cybersecurity incidents. As Application Programming Interfaces (APIs) are the key to partner connectivity, implementing high-grade API security is imperative.

So who’s responsible for all of this? Whether you are reading this as an FI or a FinTech company, there is a balancing act to be had. Let’s consider the following:

The Opportunity

A joint report by PwC UK and the Open Data Institute forecasts a £7.2 billion revenue opportunity created by Open Banking by 2022. This includes incremental revenue from new products and services, as well as incumbents’ existing revenue at risk if they fail to adapt.

Opening APIs to FinTech partners in their target market segments extends a bank’s ability to acquire, engage and transact with their customers. PwC’s 2017 survey of 39 leading banks in seventeen countries found that “92 percent of banks state that partnerships with non-banks will be highly important or important in future” and that “71 percent of banks agree or fully agree that partners/collaboration will be required to keep up with the pace of innovation”. Survey respondents described FinTechs’ strengths as bringing new technologies and improved customer experiences, while FIs’ strengths are their secure infrastructure, existing customer base, knowledge of customers, and data availability.

The Risks

But the risks don’t go away, nor does the FI’s responsibility to regulators and customers to keep customers’ sensitive information and funds safe. FIs need to increase their vigilance to protect against the loss or theft of customer information, unauthorized transactions, or their systems or accounts being used for money laundering or breaching sanctions.

Threats

Threats from viruses, malware, man-in-the-middle, phishing and denial-of-service (DOS) attacks are amplified when partner systems are added to the FI’s digital ecosystem.

Two recent incidents point to the increased vulnerability of customer data from FIs’ partners:

The data breach at Ticketmaster UK exposed the personal and payment card details of 40,000 customers. The vulnerability was created when a piece of Javascript code, created by Ticketmaster’s ChatBot provider, Inbenta, was applied to Ticketmaster’s payments page. While it has emerged that hacking group Magecart infected Inbenta’s script, it is the banks who issued the cards that need to deal with affected customers.
The breach of Australia’s new digital real estate exchange service, PEXA, highlights the losses that can be sustained by customers if non-bank partner systems are compromised. In this incident, a hacker siphoned $250,000 from a family’s property settlement by intercepting a password reset email to a conveyancing agent, establishing their own user account, and re-directing funds to their own bank account. In response, PEXA is implementing Multi-Factor Authentication, additional controls in regard to password resets, and a customer guarantee. However, the reputational damage from this breach comes at a time when PEXA, banks and government are trying to build the public’s confidence in a new digital system to replace a 150-year-old paper-based process.

Management

Protecting against threats requires an ecosystem-wide approach to cybersecurity, including:

vetting of partners before granting access to the FI’s production systems;
granular monitoring of API usage by partners;
verifying the identity of partner systems;
tokenization: replacing sensitive customer data with a token or placeholder. This enables the FI to match the customer within their ‘token vault’ without exposing the original data.

The challenge for FIs in fostering a partner ecosystem is to educate the partner’s developers in how to use their APIs without giving away information that could be used to hack the system. To encourage developers to trial APIs, many institutions are publishing developer portals, with guides, sample code, and a ‘sandbox’ environment that enables developers to make simulated API calls. While sandboxes make it easy for developers to develop and test their prototypes, allowing a partner application to call the FI’s production APIs requires more rigorous checks. FI’s must satisfy themselves that both the FI’s and the FinTech’s controls protect customer information and production systems before partner applications access the FI’s live production systems.

The beauty of APIs is that they place a layer of abstraction over the FI’s systems. They don’t have to give out information about the underlying system (and partners don’t have to know how the underlying system works in order to interact with it). Also, by granting just one way in to an FI’s systems, access and usage can be closely monitored.

Incident Response

The responsibility for API security rests squarely on the shoulders of the API provider - the FI itself. Failure to understand inherent vulnerabilities in such business functions can result in massive losses and exposures.

The FinTech partner must be integrated into the FI’s Security Incident and Event Management (SIEM) capability, comprising:

Processes:
- API calls usage.
- By function/activity.
- Volume.
- Errors.
Response:
- Watch.
- Isolate/quarantine/shut down affected areas (API access by a partner’s system).
Notification:
- Partners.
- Customers.
- Regulators.

Authentication Approaches

Changing from a traditional customer-FI interface to a three-way customer-Fintech-FI model increases the “attack surface” (more points to attack and breach). This requires a new cybersecurity trust model, whereby a customer can consent to the FI granting the FinTech access to their account information without exposing the customer’s login credentials. Therefore further governance and information security controls must be adopted in order to protect a client when using intermediary FinTech services.

The European Banking Authority (EBA) has set guidelines for implementing security under the Payment Services Directive (PSD2). These require “Strong Customer Authentication” including the use of Multi-Factor Authentication (e.g. two-factor authentication) based on what a customer has (possession), knows (knowledge), or is (inherence).

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

Implementing EBA security guidelines is a minimum. Firms must go further to ensure controls have been tested and operate as expected. Security must be built into application development practices to ensure there are no vulnerabilities that can be exploited by hackers, malware and API abuse.

Growing Safely

Building FI/FinTech partnerships necessitates taking an ecosystem-wide approach to cybersecurity. This includes developing a robust partner screening and onboarding process, applying OAuth2.0 and OpenID Connect security protocols, methods such as digital certificate-based authentication and tokenization, and integration with the FI’s Security Incident and event management processes.

Building these controls into partnership formation and expansion will ensure that FIs, FinTechs and their customers can (safely) reap the benefits of partnerships.

This blog was written for both FinTechs and Financial Institutions. Stay tuned for the next part of the series: How to Implement Secure APIs in an Open Banking Partnership Part 1 – Strong Customer Authentication.

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.