Thought Leadership
8 minutes

Twenty-eighteen was a big year for the Second Payment Services Directive, the pan European rule that picks up where PSD1 left off by strengthening consumer payments protections, regulating new market players and, importantly, paving the way for open banking. The bulk of the PSD2’s requirements went into effect on January 13, 2018. The notable exception was the Regulatory Technical Standards (RTS), which define how open banking is to be implemented. The European Commission (EC), which administers the directive, finalized these technical standards in late 2017 and—after some wrangling with industry—the compliance deadline was set for September 14, 2019. 

PSD2 requires banks to grant qualified third parties automated access to customer transaction accounts, covering both retail and corporate customers.1

Most in our business—at least those of us working within the EU—are familiar with the final September 14 PSD2 RTS compliance deadline. Banks must be ready by this date to support open banking and all that it entails, particularly security and secure common communications standards. But, there’s a deadline that’s even closer that might have slipped by you. By March 14, 2019, banks must have their dedicated interface (aka open APIs) ready for testing by account information service providers (AISPs) and payment initiation service providers (PISPs). 

These two 2019 deadlines mean the European payments industry—which is significantly expanded under PSD2—is far from finished with compliance activities to support open banking through APIs. If you need support to meet the deadlines, let’s work together to define a path that will put you not only in compliance but will help your business use PSD2 requirements creatively to expand your market capabilities. Softjourn has deep experience in developing and coding to APIs, including implementing security best practices to help protect your customers’ data.  
Here are some things you should know about 2019 PSD2 compliance requirements, with emphasis on the RTS.  

What if You Can’t Meet the March 14 Testing Deadline? 

Let’s deal first with the biggest gorilla in the room—the looming March 14 deadline. 

If you’re covered by PSD2, you’re required to offer your open APIs to third-party providers (TPPs) for testing and integration. And, as of March 14, you must be ready for external testing for PSD2 open banking, including providing technical specs and support. In addition, you need a contingency plan in the event you’re not ready or your APIs don’t work.

Your contingency plan must offer TPPs an alternative to accessing your customers’ information via APIs, “allowing them to use end-users’ login credentials, while indicating they’re not really the end user.”2  Blogger Marten Nelson, writing in a Finextra post, suggests that—for most—this means formalizing your maintenance of a web-based online or mobile interface for TPP screen scraping.3 

But, don’t jump to screen scraping because it’s a relatively easy option; it’s not what you want to do. First, screen scraping introduces the potential risk of sharing customers’ security credentials with third parties, which—if breached—could compromise customers’ accounts and personal information. Second, it’s preferable to focus from the start on a single, RTS-compliant open API than to take a short-term shortcut to compliance. 

If you’re considering screen scraping as your contingency, talk to us before you go down that path. We’ll discuss your options. 

The September 14, 2019 RTS Compliance Deadline

Security and Strong Customer Authentication (SCA)

According to the EC, all payment service providers (PSPs)—including banks, payment institutions and TPPs—must prove they have certain security measures in place to ensure safe and secure payments. PSPs also must carry out assessments of the operational and security risks at stake and the measures taken yearly.4  The EC notes that a high level of payment security is an important issue, particularly for consumers paying via the Internet. 

Strong customer authentication is an important part of the RTS for higher security, which spells out how SCA is to be applied. These requirements—which apply to all PSPs, including newly regulated ones—include strict security for initiating and processing electronic payments with the goal of ensuring the use of a payment instrument is authorized, thereby reducing fraud risk and protecting users’ confidential financial and personal information.

Generally, providing a password or card details won’t be sufficient to make a payment. In certain cases, says the EC, a code “only valid for a given transaction” is required along with two other independent elements to validate the user or transaction—from something card owners know (e.g., PIN), something they own (e.g., card) and something they are (e.g., fingerprint).5,6  These elements must be independent, meaning the compromise of one doesn’t breach the reliability of the others.     

For remote transaction, such as online payments, the requirements go even further to protect users, requiring a dynamic link to the amount of the transaction and the account of the payee. 

The rules do, however, allow other ways to achieve acceptable SCA security, such as assessing transaction risk and identifying fraudulent transactions. And, exemptions are available for contactless and small-value payments, and certain types of payments such as for transportation and parking.7 

The McKinsey Global Payments Practice PSD2 Survey 2017 suggests banks recognize that the risk of fraud arising from third-party access to accounts is a serious concern and they must invest in fraud management to fulfill their PSD2 obligations to mitigate fraud risk. They also recognize the need for “advanced controls, including advanced analytics (for example, to validate the origin of inbound calls to the API) and strong tools to detect fraud.”1

Common and Secure Communication Standards (CSC)

In support of open banking, PSD2 addresses the obligations of banks and other providers of innovative payment solutions and account information tools. In short, consumers who want to use innovative nonbank services that require access to their financial data housed at banks cannot be prevented by their banks from doing so. A bank that offers online access to its accounts is obliged to cooperate with fintechs or others (including other banks) to provide these services and appropriate tools to those providing such new services. To accomplish this, banks must establish secure communication channels to transmit data and initiate payments.5 

The RTS defines how access to customers’ accounts is handled between banks and the other parties that may be involved in offering services. 

According to the EC, banks must put in place a communication channel—adapting their customer online banking interface or developing a dedicated interface—that enables banks and TPPs to identify each other when accessing the customer data and communicate through secure messaging at all times.8

The EC goes on to emphasize that a quality dedicated communication interface should offer—again, at all times—the same level of availability and performance as the interfaces made available to consumers or companies for directly accessing their payment account online. And, they should not create obstacles to providing payment initiation or account information services. PSPs also must define transparent KPIs and service level targets for their dedicated communication interfaces, if used.8

Regarding specific communications standards, the RTS only specifies that the interfaces must follow communications standards issued by international or European standardization organizations. And, while acknowledging that the lack of more detailed standards may be challenging, the EC indicates that it’s the responsibility of market participants to work together to create solutions that work for all parties.4


So, what does this all mean? First determine if you’re covered by PSD2. That sounds basic, but we’ve often found that companies that don’t consider themselves traditional banking or payments businesses incorrectly believe regulation doesn’t apply to them. If you have anything to do with facilitating payments, verify with appropriate counsel whether you’re covered or not. You don’t want to get caught flatfooted on compliance issues. 

And, if you are covered, you need a plan—if you don’t have one already. That plan must be put in place and executed immediately to address the March 14 deadline to have available your test interface (and all the trimmings). Then, you need to focus on September 14. 

We encourage all PSPs—our clients and others—to be mindful of the following as they work towards the March and September deadlines:9    

  1. Employ transaction risk analysis to detect (a) fraudulent transactions and user behavior, (b) security incidents at TPPs and (c) API implementation vulnerabilities. 
  2. Examine your SCA choices and select the model that’s right for your organization—multifactor authentication, biometric authentication or other.
  3. Protect the communication channel with TPPs. 
  4. Request independent security audit reports from TPPs, covering governance; risk assessment, protection of the integrity of data, systems, physical security and asset control; security incident monitoring, detecting and reporting; and business continuing management.  
  5. Avoid security vulnerabilities during API implementation vulnerabilities. 

Common and Secure Communication seeks to promote competition and innovation among payment service providers.10


There are many who say that PSD2 will revolutionize banking, ushering in new players and completing the transition to a digital economy. Time will tell whether that prediction is true. But, what we know today is that this potential revolution has created the need for all players in payments to reevaluate the way they do business and introduce significant changes to how they manage customer data, communicate with third parties and manage risk and security. We also know that many will need support to manage the huge obligations of PSD2, and we want you to know that Softjourn can help you implement the PSD2 requirements you may be facing and accelerate your ability to comply with those requirements and use them to expand the success of your business. 

We’re here when you need us and ready to hit the deck running to support you. 

The Journey from PSD to PSD2
The Journey from PSD to PSD2
Folcia M. et al, PwC (2016). PSD2 in a nutshell.