2019/01/20
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 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).
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.
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.
Yes, provided that the client has given authorization. By default, all banks in the EU have authorization to provide the services mentioned above.
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).
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
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.
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.
No. Banks cannot charge fees for any new service offered, and they cannot require any formal additional contract.
Banks do not need to be concerned about losing money from free PSD2-related services because of all the other profit opportunities built in:
And these are just the opportunities we have now. More and more will be developed as full access rolls out.
There are two ways to provide compliant access: dedicated interfaces (APIs) or screen scraping, where the FinTech uses the bank’s existing online interface.
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.
Under law, FinTech must identify themselves before accessing your online interface. As the bank providing access, it is your responsibility to properly identify them.
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.
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.
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).
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)
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.
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.
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.
No. Because PSD2 applies to all online channels, most requirements (including SCA) apply to every one of the bank’s e-channels.
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).
According to the directive, there are 3 situations where SCA is necessary:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 .
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.
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.
Every bank must publish its APIs for testing with documentation. This deadline is six months before the live start, meaning March 14th, 2019.
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.
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.
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.)
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.
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.
