Strong Customer Authentication According To PSD2: Summary & Checklist

Posted By Denis Shokotko on Mar 7, 2018 | 0 comments

The changes that are guaranteed to transform the EU financial market have finally arrived. On January 13, 2018, the second Payment Services Directive (commonly known as PSD2) came into force in the European Union.

In this article, we’ve gathered all the information on PSD2 security and strong customer authentication requirements to help the existing and future companies to get ready for these changes. So let’s get started with our comprehensive PSD2 summary!

Note: in case you are afraid of getting lost in all the abbreviations and legal terms, check out our glossary for PSD2 in the knowledge base at the bottom and download PSD2 security requirements checklist here.

How PSD2 Regulation Impacts Fintech

PSD2 is going to influence every bank, consumer and fintech company based within the EU’s borders or even outside the EU (in case they make transactions with banks, companies or consumers that are located in the EU). Thus, if one party that takes part in a transaction is located in the EU, the transaction falls under PSD2 requirements.

Before diving into the understanding of PSD2 impact on fintech industry, we need to be on the same page regarding the directive’s objectives. We can distinguish three main PSD2 objectives pursued by establishing a single standardized payments system:

• enforce equal opportunities to succeed in the market for all payment service providers;
• make the payments system more transparent and more secure against fraud;
• stimulate implementing innovative fintech solutions.

Online payment will continue to play an ever-growing and significant role in the development of e-commerce as well as the stimulation of consumer demand.
Lucy Peng, CEO, Ant Financial Services, Alibaba Group

But how is PSD2 going to influence fintech industry? First and foremost, from now on, third parties that provide payments services are legally recognized as new players in the market and are regulated accordingly by PSD2. Named Third Party Providers (TPPs), they don’t hold any payment accounts or enter into possession of any funds being transferred. There are two types of Third Party Providers (TPPs), as stated in the PSD2 directive:

• Account Information Service Providers (AISPs): these are the companies that accumulate data regarding different consumer accounts in one or several different banks. Their primary task is to provide the users with visualized information about their accounts in a convenient way. A wide range of other features can be implemented here, mainly the ones concerning filtering and analyzing data.
• Payment Initiation Service Providers (PISPs): these are the companies that have a permission to initiate PSD2 payments between the consumer and the bank on the consumer’s behalf. This allows TPPs to facilitate online banking payments.

Image source: wso2.com

The Bright Side. The pros of PSD2 implications for TPPs are obvious: the traditional financial institutions (banks) are required to open their APIs to TPPs, which allows open competition between TPPs and banks on equal terms. Besides, it opens the floor to PSD2 blockchain solutions that can be revolutionary. All the barriers that could be an advantage for traditional financial institutions are now gone. TPPs are no more operating in the ‘gray area’ of the market, now they are protected by this piece of legislation and have certain rights. Besides, by accessing the banks’ APIs, TPPs can use the data produced by banks without having to acquire the needed infrastructure that banks must have or comply with requirements towards banks.

Consumers will be able to take advantage of some pros: now their electronic transactions are legally guaranteed to be secure. Besides security improvements that come with PSD2 banking, with the rise of TPPs consumers will be able to choose the best way to manage their accounts from a wider range of software solutions.

As for the banks, they may be at a disadvantage if they don’t adapt to the changes fast and effectively. If they do, they can win over consumer’s hearts with their brands that are already widely known.

The Dark Side. Yet, all the pros come at a certain cost, so let’s talk about the cons. The PSD2 directive is designed to regulate the market, and regulating means bureaucracy for the better of the market. All companies that want to operate as TPPs and use the pros that PSD2 provides them have to get licensed. Some say, there can be some problems with consumers’ trust towards TPPs mainly because of the fear of fraud. Yet, according to PSD2, required security measures are as fraud-proof as possible, so Payment Service Providers’ only task is to convince their potential clients that the risk of fraud is zero.

Consumers’ only concern may be the fact that it’s still not clear who will hold responsibility in case of fraud or skimming, TPPs or banks.

As for the banks, from now on they’ll have to compete not only with each other but also with TPPs. Adapting their IT framework to PSD2 implementation may turn out to be quite costly, yet, it is necessary to survive the competition.

| Read also: 10 Steps to Eliminate Digital Security Risks in Fintech Project

PSD2 Security Changes

PSD2 contains a large number of different guidelines and requirements. So, if you want to carve a niche and corner the new-born market, you need to have a clear understanding of what requirements you would be obliged to comply with.

First and foremost, under PSD2 fintech regulations, all Payment Service Providers have to meet Strong Customer Authentication (SCA) requirements. From now on, they have clear guidelines and demands regarding authentication their software products require from users to authorize PSD2 payments. You will find more details on those requirements in the next section of this article.

Should you get licensed as an AISP or PISP, or adapt to the changes as a bank, you will be obliged to:

• establish a suitable framework for dealing with operational and security risks;
• report annually to a competent authority (report will have to include risk assessments, current risk mitigation measures that are used, and statistics regarding fraudulent transactions);
• inform a competent authority if fraud occurs;
• comply with Strong Customer Authentication requirements (as mentioned above).

All the requirements may seem overwhelming. Regulation comes with bureaucracy, yet, in this particular case, it opens the door for open competition between startup TPPs and traditional financial institutions on equal terms. So, let’s take a closer look at requirements for customer authentication methods and how Transaction Risk Analysis can help you improve the software’s user experience.

| Read also: 10 Basic BYOD Security Rules

PSD2 Directive Requirements For Strong Customer Authentication

Basically, SCA’s main purpose to secure the transaction from fraud. In order to achieve that, the user is required to authorize payments, the access to the account or its modification using two out of three elements:

• something that the user has (a credit card, a mobile phone etc.);
• something that only the user knows (passwords, PINs etc.);
• something that the user possesses inherently (fingerprints, facial recognition etc.).

It is up to TPPs or banks which elements they will require to authorize a transaction. The elements must comply with the following requirements:

• they can’t be disclosed (even accidentally, meaning that passwords that are being entered must be hidden behind symbols);
• they can’t be replicated (the data from the device or application can’t be replicated on another device);
• they must have a low level of false positives (facial or fingerprints recognition must function well);
• they must be independent (thus, if one element gets compromised, the others must remain reliable).

There is one more requirement for the authentication codes: dynamic linking, i.e. the authentication code must be linked to a certain amount of funds transferred and to a certain payee, as stated by the payer.

Looking through all the requirements may make your head spin, which is quite natural. So, in order to simplify the requirements regarding SCA, there are 6 cases when SCA is mandatory and can’t be avoided:

• accessing the account details (balance, transaction history), in case SCA occurred more than 90 days ago;
• contactless payments above €50 or €150 cumulatively;
• online electronic payments above €30 or €100 cumulatively;
• editing the list of trusted payees;
• setting up a recurring transaction of the same amount to the same recipient;
• initiating a credit transfer (except for the cases when the transfer is addressed to another payer’s account in the same bank).

Surely, requiring users to go through authentication process every time they make a purchase can spoil user experience. That’s why we should take a closer look at when customer authentication can be omitted:

• accessing the account data (balances, transaction history) in case if the user accessed this information within the 90-days period using SCA;
• making contactless payments for the amount of less than €50 (for one purchase), or less than €150 cumulatively (for several purchases). Besides, SCA must be applied after five consecutive contactless payments;
• making payments in public transport or in parking terminals;
• transactions to trusted recipients;
• recurring payments of the same amount to the same recipient;
• payments between the payer’s accounts (only if they are open in the same bank);
• making remote electronic payments for the amount less than €30, or €100 cumulatively. As in case with contactless payments, SCA must be applied after 5 consecutive payments;
• remote electronic payments that are flagged as ‘low-risk’ after a thorough transaction risk analysis.

The last point seems to be the most interesting one because if you comply with it your product’s user experience can be quite more pleasant than your competitors’. You’ll find more details on transaction risk analysis in the next section of this article.

The list above may seem as overwhelming to you as the opportunities that PSD2 present you with. So, you may wonder: why bother? The answer is, the more exemptions from SCA you can implement into your software products, the better user experience will be delivered to your clients. Users are not ready to completely sacrifice seamless and easy user experience for security. Thus, you need to learn to deliver the best balance between user-friendliness and security checks (all while complying with the PSD2 legislation).

You have some time to introduce SCA in full power until November 2018. From November 2018 SCA becomes obligatory, and lack of PSD2 compliance can get you into a legal trouble.

| Read also: The Pros and Cons of Different Two-Factor Authentication Types and Methods

Transaction Risk Analysis In PSD2 Explained

We’ve mentioned Transaction Risk Analysis (TRA) above, in the list of exemptions from SCA. So, what is it?

TRA is not innovative or totally new to those who have been in this industry long enough. In simple terms, TRA is a method that is used to determine whether the transaction is potentially fraudulent or not. This is achieved by analyzing the usual behavior of all the parties involved in the transaction and flagging the unusual behavior as potential fraud.

Yet, TRA-based exemptions from SCA are applicable only for payments up to a certain amount (up to €500 maximum). It depends on your overall Reference Fraud Rate (RFR). RFR is calculated as the value of successful fraudulent transaction within the past 90 days divided by the total value of all transactions via the payment system within the same period:

Under the PSD2 legislation, if the transaction is flagged as a low-risk one, it can be exempt from SCA, depending on the overall fraud rate:

What factors must be analyzed?

According to PSD2 regulation, the following factors have to be monitored and analyzed for a qualitative TRA:

• user’s behavioral patterns (in terms of spending money);
• payment history (both personal and of the same demographic group);
• locations of the user and the recipient’s account;
• payment amounts;
• information about the device used and its software (in order to track changes in its software, malware etc.);
• known fraud schemes;
• compromised and stolen SCA elements.

Surely, this list is far from final. These are only the basic guidelines for a truly good TRA. It is up to you and your cybersecurity professionals to expand this list and to lower your fraud rate as much as possible.

Why is it needed?

Apart from obvious security reasons, there’s one interesting perk of having low fraud rates due to qualitative TRA: a better user experience. Users want the apps to be easy, they want to make as fewer clicks as possible. That’s why, if your fraud rates are low, more transactions can be exempt from requiring SCA.

| Read also: Smart Identification or How to Make 2FA More Convenient for Users

Conclusions

PSD2 compliance is compelling and challenging, no doubt. You need to set up a Strong Customer Authentication system that complies with the legal requirements, build a Transaction Risk Analysis framework or improve the existing one, deal with the EU’s bureaucratic mechanisms. Keep in mind the pros of doing all of that: you’ll be able to compete in the EU market while providing your customers with highly secured services. Now, a short recap:

1. PSD2 is bound to change the EU fintech market. Now, Third Party Providers are legally recognized as payment providers, and banks are obliged to open their APIs to them to endorse a level playing field. There are two categories of TPPs recognized by PSD2: Account Information Service Providers (AISPs) that can gather and analyze account data and Payment Initiation Service Providers (PISPs) that can initiate payments on the client’s behalf. In order to become a TPP, the company needs to get licensed by a competent authority.
2. PSD2 regulates payments security quite heavily. All Payment Service Providers have to establish a framework for managing security and operational risks and react to fraud, as well as report to competent authorities regarding issues involving fraud.
3. Strong Customer Authentication is regulated by PSD2 in details. It must require either two of three authentication elements (knowledge, possessions, inherence). After authorization is done, a one-time dynamically linked code is generated. We have detailed lists of when SCA is mandatory and when transactions can be exempt from it above. The balance between security measures and customer convenience is what’s going to determine which fintech software solutions will succeed and which ones will fail.
4. Transaction Risk Analysis is your ticket to maximizing SCA exemptions. TRA determines the fraud risk of a transaction by analyzing the user’s usual behavioral patterns and other factors, e.g. location. The lower your Reference Fraud Rate is, the more transactions can be exempt from SCA: the maximum amount of the payment that can be exempt from SCA is determined by your fraud rate.

Are you ready to seize all the opportunities made possible with PSD2? Choosing a solution provider for setting up Strong Customer Authentication is a challenging task. You can make it easier by using our checklist.

Read more:

• Two-Factor Authentication in the PCI DSS Standard
• One-Time Passwords: Generation Algorithms and Overview of the Main Types of Tokens
• 10 Most Popular Two-Factor Authentication Apps on Google Play Compared
• How to Backup Google Authenticator or Transfer It to a New Phone
• Top 7 Tips How to Protect Yourself from Phishing Scams
• Social Engineering: What It Is and Why It Works
• Ransomware – to Pay or Not to Pay
• Panama Papers Leak – Evil or Good?