PSD2 and Open Banking – what you need to know - Redscan
Contact Us

Contact Us

Please get in touch using the form below

1000 characters left
View our privacy policy

The revised Payments Services Directive (PSD2) is designed to improve consumer rights and encourage innovation in the payments services industry by facilitating Open Banking.


Open Banking has the potential to revolutionise the payments and fintech industries, but with this tide of change comes a new wave of security risks which financial services firms must be prepared to address.


What is PSD2?


The Payments Services Directive (PSD) was introduced by the European Banking Authority (EBA) in 2007 in order to regulate the payments services industry, improve consumer protection and increase competition across the sector.

A revised Directive, PSD2, took effect on 13th January 2018 and builds on the initial iteration of the legislation by aiming to facilitate Open Banking, enhance consumer rights and reduce financial fraud. In the UK, PSD2’s requirements are enforced by both the Payments Systems Regulator (PSR) and the Financial Conduct Authority (FCA).

The majority of the PSD2’s requirements became law in January 2018. However, requirements for Open Banking and Strong Customer Authentication (SCA) will not come into effect until September 2019.


The rise of Open Banking


Open Banking is a term used in the financial services industry to describe the process of transferring ownership of financial information from banks to customers.

PSD2 includes a set of new rules designed to facilitate open banking by requiring Payment Service Providers (PSPs) to provide approved Third Party Providers (TPPs) with access to customer data via Application Programming Interfaces (APIs).

Open Banking is designed to encourage innovation and competition by allowing TPPs to develop new financial products and applications that give consumers greater visibility and control over their finances. Open Banking is optional for financial institutions in many parts of the world, but PSD2 makes it mandatory for any operating within the EU.

Two categories of TPP are introduced in PSD2; Payment Initiation Service Providers (PISPs), that use APIs to provide payment processing services, and Account Information Services Providers (AISPs), that use APIs to present an aggregated view of individuals’ finances.

With the PSD2 implementation deadline on 14th September 2019, time is running out for PSPs to finalise and secure their API ecosystems.


Open Banking security risks


While Open Banking promises to usher in a new era of flexibility in the banking industry, it also brings with it a wide range of security risks. If not properly secured, the very same APIs designed to open up the banking system to encourage innovation also present new opportunities for cybercriminals to compromise sensitive customer information.

To help protect the integrity of payment systems and data, PSD2 mandates that PSPs comply with the European Banking Authority’s (EBA) Regulatory Technical Standards (RTS) for:

  • Common and Secure Open Standards of Communication (CSC)
  • Strong Customer Authentication (SCA)


Common and Secure Communication


Modern banking applications are typically composed of rich clients that connect to REST APIs over HTTP. Bad coding, implementation and configuration of applications at both PSP and TPP levels could result in critical security vulnerabilities, leading to loss of service availability, plus theft, corruption and destruction of user data.

API and application front-end vulnerabilities, for example, could leave systems susceptible to injection attacks leading to the loss of personal information, man-in-the-middle (MitM) attacks resulting in the interception of transaction data, and Denial-of-Service (DoS) attacks that compromise the quality and availability of service for users.

PSD2’s RTS require PSPs to provide secure API-based communication channels for PSPs, backed up by robust transparency, permissioning and reporting procedures. To achieve PSD2 compliance, it is important for PSPs to regularly test network security controls to identify and address API vulnerabilities before they can be exploited maliciously.


Strong Customer Authentication


PSD2’s new SCA requirements are designed to enhance security and reduce fraud by requiring at least two levels of authentication before transactions can be made. Levels can be based on knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is).

After lobbying from the payments community, these authentication requirements are subject to a range of exemptions to reduce transaction friction, including face-to-face contactless payments under €50, plus recurring and whitelisted payments.

As part of testing programmes, both PSPs and TPPs should also look to review authentication measures on a continuous basis to ensure they comply with PSD2 SCA requirements.


EBA PSD2 security guidelines


To support PSD2’s Regulatory Technical Standards, the EBA has published a range of complementary security measures that PSPs should implement to help manage operational and security risks relating to payment services.

With security threats evolving rapidly, the EBA points out that its guidelines should remain flexible, so that they stay relevant in a changing risk landscape. The first EBA guideline, the General Principle, establishes that PSPs should comply with all provisions, but measures should be proportionate to the PSP’s size and to the nature, scope, complexity and riskiness of its service.

EBA guidelines on the security measures for operational and security risks of payment services under PSD2:

  1. General principle
  2. Governance – operational and security risk management and outsourcing
  3. Risk Assessment – asset discovery, classification and review
  4. Protection – physical security, access control, data system integrity
  5. Detection – continuous monitoring, detection, response and reporting
  6. Business Continuity – Scenario-based continuity management and review
  7. Testing – Independent scanning and testing of security measures
  8. Learning – Continuous situational and security awareness training
  9. Relationship Management – PSP and TPP communication and collaboration


How Redscan supports PSD2 compliance


Redscan is an award-winning provider of managed security, testing and consultancy services. Our experienced team of security experts help organisations of all sizes, including many across the financial services industry, to identify and respond to threats plus achieve compliance with PSD2 and other industry standards.

CREST CCT APP-accredited web application and API penetration testing from Redscan helps organisations to identify security vulnerabilities, such as those affecting authentication and session management, and provides detailed, prioritised remediation guidance to help address them.

A Red Team Operation provides a deeper level of security assessment, rigorously challenging the effectiveness of people, processes and technology to detect and respond to a simulated cyber-attack. A Red Team Operation helps to review risk assessment and scenario-based continuity plans, as well as protection, detection, reporting and training procedures to support PSD2 compliance.

Continuous threat monitoring is also a key requirement of the EBA’S PSD2’s guidelines. ThreatDetect™, Redscan’s flagship MDR service, combines leading CSOC expertise, the latest security technology and aggregated security intelligence to help organisations hunt for, detect and rapidly respond to threats across their hybrid, cloud and on-premise environments, 24/7.

Learn more about our services


Read more:

Redscan shortlisted as finalist at UK Cloud Awards 2019

What is a white hat hacker?

Redscan announced as 2019 SC Awards Europe finalist