There are many nuances to PSD2 requirements, specifically as they relate to the regulatory technical standards and strong customer authentication. To follow are some FAQs that break down several aspects of the regulation.
What are the regulatory technical standards?
The PSD2 regulatory technical standards specify:
- requirements for strong customer authentication
- situations that are low risk enough to be exempt from requiring SCA
- security measures that help protect the confidentiality and integrity of personalised security credentials
- requirements for common and secure open standards of communication (CSC) between ASPSPs, TPPs, payers and payees
What types of financial companies are included in PSD2?
ASPSPs are usually banks, but can be any monetary financial institution that offers financial accounts. The two most common types of TPPs are payment initiation service providers (PISPs) and account information service providers (AISPs).
- PISPs are any third party that wants to let consumers pay directly with their bank account (e.g., retailers, utilities, charities, etc. and third-party payment service providers that enable organizations to accept a wide variety of payments through a single channel).
- AISPs are any third party that wants to let consumers aggregate all of their account information from multiple banks in one place to create a complete picture of their finances.
What is strong customer authentication?
Strong customer authentication, or SCA, means certain security measures need to be in place in order for a customer to prove their identity before they can grant a third party access to their account.
What are the required security measures for the application of SCA?
Requirement: Authentication Code
Customers will have to provide at least two independent elements out of the following three security factors to generate an authentication code:
- Knowledge: Something they know (e.g., password or PIN)
- Possession: Something they own/have (e.g., token or mobile device)
- Inference: Something they are (e.g., fingerprint or facial recognition)
Security measures about the authentication code itself:
- Must be one-time-use only
- No information about the elements can be derived from it
- Not possible to generate a new code based on previous ones
- Cannot be forged
Security measures for generating an authentication code:
- When an authentication fails, it shouldn’t be revealed which of the elements were incorrect
- Five (5) failed authentication attempts should result in a temporary block, and the duration of the block and number of retries should be based on a risk score
- Maximum of five (5) minutes of idle time without activity
- Authentication sessions must be protected according to common and secure standards of open communication (see Chapter V of the full RTS)
Requirement: Dynamic Linking
The EBA added this requirement to prevent “man-in-the-middle” attacks, where bad actors try to hijack an authentication code to authorize fraudulent payments or access. The “dynamic linking” aspect means that the authentication code should dynamically fail if a middleman tries to use it for the wrong payee or amount. The SCA dynamic linking requirement includes the following:
- Payer must be made aware of the payment amount and payee
- Authentication code must be specific to the amount and payee agreed to by the payer when initiating the transaction
- Banks (or other ASPSPs) must only accept authentication codes that match the original information
- Any change to the amount or payee should make the authentication code invalid
- ASPSPs must maintain the integrity, confidentiality and authenticity of the transaction information and what is displayed to the payer throughout all phases of the authentication
Are there situations that are exempt from SCA?
Payment service providers won’t have to ask customers to perform strong customer authentication for the following:
Payment Account Information
AISPs will be able to gather account balances and 90 days of transaction history, UNLESS:
- It’s the first time information is being retrieved
- It’s been over 90 days since last SCA
Contactless Payments Below €50
Customers can initiate a contactless electronic payment without fuss at point of sale, UNLESS:
- Cumulative total since the last SCA is over €150
- It’s been five (5) payments since the last SCA
Trusted Beneficiaries
ASPSPs can allow customers to set up a “whitelist” of beneficiaries that don’t require SCA for payments, UNLESS:
- It’s the first time the payer is adding that payee to the whitelist
Recurring Transactions
Subsequent payments for the same payee and amount, UNLESS:
- It’s the first time the payer is setting up the recurring transaction
Low-value Transactions Below €30, UNLESS:
- Cumulative total since the last SCA is over €100
- It’s been five (5) payments since the last SCA
Low-risk Payments
ASPSPs can use risk scoring to determine that a payment is low enough risk not to require SCA, UNLESS:
- Transaction risk analysis detects an abnormal spending or behavior pattern, unusual device information, malware infection, known fraud scenarios or abnormal / high-risk payee location
Unattended Terminals for Transport Fares and Parking Fees
Electronic payments can be seamless and convenient without holding up traffic.
Credit Transfers Between Accounts Held by the Same Natural or Legal Person
Transferring money between your own accounts doesn’t require SCA.
Secure Corporate Payments
Corporate payments through dedicated payment processes and protocols that have a high level of security don’t require SCA (e.g., payroll).
Are there monitoring and reviewing requirements?
Yes, banks (and other ASPSPs) must conduct independent audit/reviews of SCA procedures, SCA exemptions, as well as confidentiality and integrity of users’ credentials and APIs at least every three (3) years.
They must have mechanisms in place for detecting potential fraud, including monitoring:
- Lists of compromised or stolen devices
- Payment amounts
- Known payment fraud scenarios
- Signs of malware at any stage of the authentication
- Usage logs of access devices or software
ASPSPs are expected to analyze transaction risk, plus calculate overall fraud rates for each transaction type and risk scores for each transaction. ASPSPs must maintain a fraud rate below the thresholds as described in the RTS Annex:
Card Payments | Credit Transfers |
0.01% for transactions up to €500 | 0.005% for transactions up to €500 |
0.06% for transactions up to €250 | 0.01% for transactions up to €250 |
0.13% for transactions up to €100 | 0.015% for transactions up to €100 |
They are also expected to monitor and adequately document the following information about all payment transactions:
- total fraud amount and rate
- average transaction value
- total number of payments
Reports should include a breakdown % of payments with and without SCA, and breakdown of remote and non-remote payment transactions. These records should be fully available to competent authorities and the EBA upon request.
Why is multi-factor authentication (MFA) essential for SCA?
On the surface, multi-factor authentication is the most obvious piece of technology you’ll need in order to meet the SCA requirements. PSD2’s RTS defines strong customer authentication as a requirement to have two or more factors of authentication in place to be absolutely certain that the person trying to access an account is an authorized customer. A username/password is just one factor, and sadly isn’t enough to verify identity because credentials are stolen through big and small data breaches every day. Even worse, pre-PSD2 fintech customers may still be accustomed to eagerly handing over their banking credentials and account information to third parties in exchange for money management tools and other services.
Modern MFA, like PingID, lets banks serve up a variety of authentication methods and devices that customers can use to authenticate who they are before you grant access to their online or mobile banking accounts. It also ensures that fintechs can no longer access customer accounts without their real-time authentication and authorization/consent. And with MFA in place, your customers’ usernames and passwords are useless without a second factor. Even if these credentials are still sitting in a fintech’s directory vault somewhere, they pose less of a threat to your bank’s security, so you can sleep better at night.
What if you already have MFA in place?
Many financial institutions already have an MFA solution in place to secure online and mobile banking access, often with a one-time passcode through SMS text messaging or email. But first-generation solutions that rely on SMS or email aren’t designed for financial-grade security. While any MFA is better than nothing, bad actors have caught up to older MFA technology, which means one-time passcodes can be intercepted over email and text. Modern multi-factor authentication, like PingID, is secure because it can use more doesn’t rely on hard tokens or require servers to be on premises, and it can look and feel like it’s part of your existing mobile app or branding.
So is modern MFA the answer to SCA?
The simple answer is not by itself. SCA is much broader than just MFA. SCA is about creating a sole digital authentication platform for all customer journeys. To accomplish that, you need a powerful, flexible standards-based authentication authority architecture that has the capability to enforce MFA only when required and support a broad variety of context and authentication factors. And more than just technology is needed. Becoming SCA compliant will involve reworking processes and change management for employees, third-parties and customers. But it is critical that you get the technology right. In the next section, let’s dive a little deeper into the technologies that will help support your SCA compliance by September 14, 2019.