2019/01/20

Everything you always wanted to know about PSD2 ✻ But were afraid to ask

The new PSD2 regulations are the result of a natural progression in the financial industry. Times are changing, and banks need to adjust their strategy to keep up. Every financial institution in the EU is well aware of PSD2 (the revised Payment Services Directive), but some of the points need more explaining. In this article, we’ll uncover the finer details to help make your bank’s transition easier while introducing new opportunities for profits and innovation.

PSD2 Overview

What is PSD2 all about?

PSD2 is directive meant to regulate payment services and the providers that offer them. 

PSD2 was officially published on November 25th, 2015 by the European Parliament and of the Council. It replaces the old PSD regulation, now called PSD1 - Directive 2007/64/EC. As an official directive, it had to be transposed into national law in every member state.  Certain regulations are different depending on your country of operation.  You can read the full directive here:https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366

While many third party service providers will benefit from this new directive, FinTechs have the most to gain.  Under PSD2, PISPs (Payment Initiation Service Providers), AISPs (Account Information Service Providers) and CBPIIs (Card-based payment instrument issuer) will have the power to access individual client’s bank accounts.   Nothing like this has ever happened in the history of the EU.  PSD2 opens up a huge opportunity for FinTechs to develop new and innovative services to breathe new life into their operations (and bottom line). 

What financial services can FinTech companies access under PSD2?

There are three financial services that will be available for bank customers via Third Party Providers (primarily FinTechs).

Check on the availability of funds (Article 65 of PSD2)

Initiate a payment (Article 66 of PSD2)

Access payment account information (Article 67 of PSD2)

The general rule of PSD2 is that any service or piece of information that is accessible via the bank’s online banking application should also be accessible via third parties, including information related to payments and accounts.  Any type of payment able to be initiated via the banking application must also be accessible via third parties. 

Do FinTechs get unlimited access to customer accounts?

No. Third Party Providers must have explicit consent from the customer of the bank before accessing any of that customer’s accounts. FinTechs may only access accounts for authorized services when the directive calls for it.  Once a customer authorizes access, banks are not allowed to limit FinTech access for PSD2 services.

Can banks access customer accounts held at other banks?

Yes, provided that the client has given authorization.  By default, all banks in the EU have authorization to provide the services mentioned above. 

PSD2 Timing

When does PSD2 go into effect?

PSD2 officially went into effect on January 13th, 2018.  However, bank account access does not go into effect until September 14th, 2019.

Why? Regulation takes time.  This new access must meet regulatory technical standards (RTS) for strong customer authentication, as well as secure and common open standards of communication (officially known as Commission Delegated Regulation [EU] 2018/389). 

Do I need to comply with only the directive?

No.  The directive is simply a goal that the EU set up as guidance.  

Each individual country has created its own laws in accordance with the EU’s overall goal and the referred supplementary regulation.  Supplementary regulations were created based on the PSD2 document prepared by the EBA (European Banking Authority). 

There are two types of regulations: Guidelines and RTS.  Guidelines are not mandatory for the member states, but they must tell have to inform the EBA their stance: either whether they comply, don’t comply or comply with deviations.  RTSs (Regulatory Technical Standards) are more strict — they are obligatory as is, without modification or transposition.  The list of these regulation is available here: https://eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money

So, my development must be ready by September 14th, 2019?

RTS Compliance must be ready by September  14th, but you must deliver full documentation and testing six months before that date. That means all your testing must be complete no later than March 14th, 2019.

There may be other time requirements based on your country’s specific guidelines.

Business Challenges & Opportunities

What’s the real customer benefit for PSD2 if it only allows for retrieving account information and initiating payments?  Banking apps have been doing that for years.

FinTechs won’t have full access until 2019, so they haven’t yet been able to explore everything that they can do. But right now the biggest benefit is array of services FinTechs can develop like alternate payment methods (that don’t require PayPal or a credit card), financial advisory, or even custom account dashboards.  They can also create new service types based on account information, although that type of service may require additional customer consent. 

Also, FinTechs have the opportunity to offer access to multiple banks from one single platform.  PSD2 opens up lots of potential for innovation.

Can banks charge fees for these new services?

No. Banks cannot charge fees for any new service offered, and they cannot require any formal additional contract. 

Without fees, how can PSD2 not be a loss for banks like other regulatory projects? Is there any profit opportunity?

Banks do not need to be concerned about losing money from free PSD2-related services because of all the other profit opportunities built in:

  • Fees for opening up additional services for FinTechs
  • As a bank, offering new FinTech services
  • Partnering with FinTechs to sell services
  • Developing joint services with FinTechs

And these are just the opportunities we have now.  More and more will be developed as full access rolls out.

Access to Accounts

What kind of technical access must be provided to third parties? 

There are two ways to provide compliant access: dedicated interfaces (APIs) or screen scraping, where the FinTech uses the bank’s existing online interface.

Tell me more about screen scraping.

With screen scraping, the client provides the FinTech with security credentials to login. The FinTech software will then log into the online banking system (just as a normal customer would) to make a query or payment transaction. 

Will I know when a FinTech is accessing our online banking application?

Under law, FinTech must identify themselves before accessing your online interface. As the bank providing access,  it is your responsibility to properly identify them.

Isn’t sharing security credentials risky?

While there is some level of risk associated with sharing security credentials, there have not been any reported cases of fraud to this point. Keep in mind: even though this access method is compliant, it was NOT proposed by the Commission.

That said, you still have an obligation to offer screen scraping as a fallback in case the APIs fail. 

Does screen scraping always need to be the fallback for APIs?

This is where it gets interesting.

Anytime a bank uses a dedicated interface (APIs), they MUST provide a non-dedicated interface (screen scraping) as a fallback.  Plus, the bank must prove that the dedicated interface is equally and readily available as the APIs.

However, there is no requirement that APIs must be the primary interface.  If a bank chooses a non-dedicated interface as its “official” interface, there is no legal requirement for a fallback. 

Is there any risk to using non-dedicated interfaces as the primary interface?

While there are advantages to using non-dedicated interfaces as the primary mode of access (a lower administrative burden), there is more risk on both sides since they cannot be standardized.  This could make it more difficult to get FinTechs on board with your services.

However, it is possible for banks to get an exemption from having a non-dedicated interface as fallback if there is another type of fallback in place (e.g. disaster recovery).

How do banks get these exemptions?

Local regulators can give exemptions from the fallback requirement if your bank can build a good API that uses some of the widely used and respected standards.

The EBA published guidelines for these exemptions, although each member state can handle them differently. (EBA/GL/2018/07)

What is a good API in terms of these technical standards?

Good APIs ARE dedicated interfaces with fallback facilities in place. The overall regulation is technology-neutral, but there are still technical standards that must be followed.

The Commission created the API Evaluation Group to check extensiveness and compliance of five standards: the Slovak Standard, the Polish Standard, Open Banking UK, STET, and NextGenPSD2.

The API EG also created  a list of standard recommendations to allow for easier improvement of service levels. These recommended functionalities can be found on the website of the European Payments Council.

If a bank uses at least one of these five standards in developing its APIs, the APIs are more likely to be compliant.  However, you must still  pay close attention to implementation.  If an account query takes 2 minutes, you made some mistakes.

What is the best technical standard for APIs?

While there is no single “best” option of those five technical standards, right now NextGenPSD2 is the most popular and may be on its way to becoming a standard across Europe. 

Is it enough to just have my IT developers program these standards?

No. The standards describe the APIs, including available content and message formats for FinTechs, but they do not include specifications for important features like transaction monitoring and authentication.

You will also need to ensure your IT team is aware of the PSD2 IT requirements during development.

IT Requirements to Meet

What are the general IT requirements?

  • Establish interfaces and ensure secure communication
  • Provide access to core PSD2 services
  • Identify TPPs, check TPP’s authorization and permissions
  • Use SCA (Strong customer authentication) & manage exemptions
  • Monitor transactions and prepare monitoring reports
  • Have a fallback mechanism readily available
  • Provide full testing facilities (developer portal, sandbox)

So do I just need to complete the APIs and the related items?

No. Because PSD2 applies to all online channels, most requirements (including SCA) apply to every one of the bank’s e-channels. 

Strong Customer Authentication

What does Strong Customer Authentication (SCA) mean?

According to the PSD2 directive, SCA means requiring a minimum of two factors/elements that show knowledge, possession, or inherence for authenticating the customer’s identity.

These elements include information that only the user would know (e.g. a password), something that only the user would have (e.g. a security token), and a feature unique to the user (e.g. a fingerprint).

When do I need to perform SCA?

According to the directive, there are 3 situations where SCA is necessary:

  • When the payer accesses its payment account online
  • When the payer initiates an electronic payment transaction
  • When the payer carries out any action through a remote channel that may imply a risk of payment fraud or other abuses

What does that third situation really mean?

In truth, it covers a wide range of cases.

An example would be requiring SCA in order to change the mobile contact number where clients receive a one-time password.  That situation would apply because that number change could later be used to engage in fraud. 

Who performs SCA? Are banks responsible, or should I just accept the FinTech’s SCA?

The bank defines the method of SCA and is therefore accountable.

There are several models for SCA, including redirected, decoupled, embedded, or a combination.

With a redirected model, the bank is in charge of all of the related processes. With the other models, the authentication takes place at least partially via the FinTech. Anytime you offer an SCA method through your online banking module, you must also offer it via the API. 

SCA seems like a hassle for customers. Will they always need to use it?

It is very possible to make SCA customer friendly.  One example is the ability to exempt customers from SCA requirements for low-risk transactions. In the case of a redirect approach, developing a seamless experience will improve the user experience.

What SCA Exemptions are available?

The most common SCA exemptions are for small-volume payments  and customers  who are simply retrieving account information.  There are 6 other  situations for exemption, based on Articles 10-17 of the RTS.

Banks with strong risk methodologies that identify low-risk transactions can also get exemptions, provided they continuously monitor fraud rates. 

Who decides how to use the exemptions?

The service provider (banks) determines whether an exemption applies. That provider bears responsibility for any obligations of reimbursement.

You may also shift the burden of responsibility to the FinTech via signed agreement.

Who is responsible for PSD2 transactions?

The bank.

In the case of fraud, as a general rule the customer should receive an unconditional refund. In the case of SCA being used, the banks can make a claim against the FinTech. Without SCA, the bank bears the full responsibility. 

In that case, should I just always use SCA?

Requiring SCA for everything is an option, but it could become an inconvenience for your clients.  It’s up to you to find a balance between convenience and security. 

Security

Isn’t it a big operational risk to give third parties access to my database? Are there security measures in place to guarantee customer safety?

Extensive security measures were built into PSD2 to protect all parties involved.

Third parties MUST get authorization from national authorities for any services provided. FinTechs are required to use eIDAS (Electronic Identification, Authentication and Trust Services) certificates for added safety and security.  All bank communications must remain secure.  Requiring SCA bolsters security as well. In general it is the purpose of the RTS to lay down the rules for the security issues.

How do I check a third party’s authorization for the service? What are eIDAS certificates?

You can check whether a given FinTech has authorization with your local regulator, who will have a list.  The authorized parties will also have eIDAS certificates that allow for the creation of secure communication channels and identification.

Monitoring & Reporting

What should we be monitoring and reporting?

For PSD2 compliance, you must be able to prove that your online banking module and dedicated PSD2 APIs are equally accessible.  (Read the earlier section about dedicated vs non-dedicated interfaces).

While you should monitor payment transactions and prepare regular reports on fraud monitoring (just as you would with card payments), you must also have a transaction monitoring mechanism in place .

What are transaction monitoring mechanisms?

A transaction monitoring mechanism is a specific safety precaution that takes into account several risk-based factors of account transactions.  This is a requirement of the RTS that applies to both dedicated and non-dedicated interfaces.  A minimum list of these mechanisms is provided in Article 2 of the RTS. 

Should this transaction monitoring be real time?

The EBA recently confirmed that real-time monitoring is not required by the RTS. Certain risk calculations for SCA exemption do require real-time monitoring, but that is a different issue.

Testing Facility

What testing facilities do I need to make available for FinTechs? Is there a deadline? 

Every bank must publish its APIs for testing with documentation. This deadline is six months before the live start, meaning March 14th, 2019. 

Is there a specific way to publish our APIs?

There is no explicit regulation or obligation for how you publish your APIs. There is a wide range of API definition standards to choose from.

One of the most popular APIs for payment and banking is OpenAPI.  Be sure to research your options before committing to a certain standard.

Most banks will launch a developer portal that lets FinTechs register and then access test environments, but you can offer another solution. 

Should this testing environment be open to any developer?

No. You’re only required to give testing access to FinTechs with authorization for PSD2.  You can give access to other FinTechs at your discretion. 

Do I need to have everything ready by March 14th?

You do not need to have a real software environment in place or SCA by this date, but the API must be available for testing messages.  (Note: some of these requirements from the directive are not 100% clear.  We recommend doing additional research specific to your member state.)

Will most banks be ready by March 14th?

It’s very unlikely.

The API Evaluation Group’s final recommendations and the EBA’s final opinions were only published in November and December 2018, respectively. Because of this late release, it is almost a given that most banks will experience delays, not necessarily from their own fault.

Local authorities still have not published central registers, which will likely cause further delays. It is unlikely that everything will be ready to go by September 2019. 

What are the central registers?

Central registers are where national authorities list the payment service providers and their licenses in relation to the PSD2 services. Payment service licenses can apply to payment services listed in Annex I of PSD2.

Quite much information to process? We are always here to help you solve the PSD2 challange and more.