Open Banking APIs under PSD2: How to Mitigate Risk

In recent years, open banking has received a lot of attention in the financial services sector. Open banking means that banks open their systems to authorized third-party financial service providers, so these companies can initiate and process payments and financial transactions at the request of the bank’s customers.

Open banking promises to unlock innovation that will profoundly improve the banking experience and introduce new financial services. For example, Third Party Providers (TPPs) can provide applications that enable consumers to consult multiple bank accounts from a single application, or apps that make it easier for businesses to share data with their accountants.

Under PSD2, banks must offer an interface allowing TPPs to communicate with them. That way, if the consumer wants to use financial service providers other than the bank, these providers can gain access to the bank’s systems and serve the bank’s customers via the open communication interface.

This is not without risk. According to McKinsey & Company, “Most banks report that they do not expect security to become a problem under PSD2; however, they also recognize that they must invest in fraud management. Banks are responsible for mitigating fraud risk and will need to implement advanced controls, including advanced analytics (for example, to validate the origin of inbound calls to the API) and strong tools to detect fraud attacks. The [McKinsey Global Payments Practice PSD2 Survey 2017] survey respondents indicated that the risk of fraud arising from third-party access to accounts is a serious concern and that fraud prevention is a top priority.”

Risks to Banks

The introduction of open APIs makes banks dependent on the security of the TPPs using these APIs. Possible threat scenarios include:

• A data breach at a TPP exposes the bank’s customers
  • TPPs will store consumers’ financial data. If a TPP is breached, that could expose the bank’s customer data, which in turn could affect the reputation of the bank. In light of the European General Data Protection Regulation (GDPR), banks need to make sure TPPs implement appropriate technical and organizational measures to protect customer data.

• Fraudulent requests from a compromised TPP
  • If a TPP is hacked, that could result in fraudulent requests for information about a bank’s customers – or fraudulent payment requests from the TPP to the bank. Such an incident could happen through vulnerabilities in the TPP’s mobile app or web application. Since banks are the first party to be held liable for unauthorized financial transactions from a user’s bank account, a security breach at a TPP may have serious consequences for banks.

• Fraudulent requests from TPP employees
  • A disgruntled employee at a TPP could issue fraudulent requests for information about a bank’s customers or initiate fraudulent payments.

Banks should adopt a number of technical and organizational security measures to address these and other threats. In the context of open banking, banks can mitigate risk in multiple ways:

1. Use transaction risk analysis
Banks can use transaction risk analysis to:

• Detect fraudulent transactions and user behavior. The PSD2 Regulatory Technical Standards (RTS) mandates that payment service providers (PSPs), including banks, perform a risk analysis of all the financial transactions they process. This way, PSPs can detect payment fraud, such as card-not-present fraud.
• Detect security incidents at TPPs. Transaction risk analysis can be used to detect abnormal behavior in requests originating from TPPs, identify suspicious transactions from TPPs, detect atypical sequences of API calls, and all of this in real time.
• Detect API implementation vulnerabilities. Weaknesses in the implementation of APIs might give rise to fraudulent transactions and unusual user behavior, which can be detected using advanced fraud monitoring.

2. Choose the right authentication model
Strong Customer Authentication is critical, whether that’s two-factor authentication, multi-factor authentication, biometric authentication, or other. However, different authentication models each have their own characteristics and security implications. For the bank, it is usually best to use a model that places the authentication process with the bank itself or with an external security provider. This means that the bank will continue to communicate directly with the user instead of through the TPP. In doing so, more information becomes available to the bank for transaction risk analysis, including proof of authentication events, which is relevant for handling disputes about the liability of a fraudulent transaction.

3. Protect the communication channel with TPPs
Banks must protect the data exchange with their TPPs. Think of mutual authentication between a bank and TPP using, for example, SSL/TSL protocols.

4. Request independent security audit reports from TPPs
The European Commission has anticipated security risks under PSD2 and therefore requires PSPs and TPPs to manage operational and security risks. More specifically, Article 95(1) of PSD2 requires PSPs to establish a framework with appropriate mitigation measures to manage operational and security risks relating to the financial services they provide. The establishment, implementation, and monitoring of security measures should cover the following:

• Governance, including the operational and security risk management framework, the risk management and control models, and outsourcing
• Risk assessment, including the identification, classification and risk assessment of functions, processes, and assets
• Protection of the integrity of data, systems, and confidentiality, physical security, and asset control
• Monitoring, detection, and reporting of security incidents
• Business continuity management, including testing of business continuity plans, incident management, and crisis communication
• Independent testing of security measures

Banks should request that TPPs provide independent security testing reports in order to verify the maturity of their security practices.

5. Avoid security vulnerabilities in the API implementation
To protect against injection attacks, ensure that whatever data format the API uses, the API software component parsing the data structures is hardened against attack. Also, banks should protect input sanitization to prevent injection of all forms. The security analysis and testing should cover all APIs and tools so banks can discover and analyze them effectively.

Open Banking APIs and How to Protect Them

The open APIs required by PSD2 will undoubtedly lead to new, innovative banking services and apps. At the same time, however, banks must prevent criminals from accessing customer data and transactions. Banks and TPPs must therefore be aware of the risks and offer sufficient protection. To learn more, download this white paper:

Open Banking APIs Under PSD2: Security Threats and Solutions

This blog was inspired by an article by Frederik Mennes that first appeared on Techzine.