The Scoop on Strong Customer Authentication (SCA)

August 24, 2018

Saira Guthrie
Product Marketing Manager

September 2019 Update:

It has been a challenge for many organizations to meet the PSD2 and SCA deadlines. In response, the European Banking Authority recommended that enforcement of SCA should be delayed and that the companies should work with their regulators to achieve compliance. We have added an updated section with details and what it means for your business.

Overview:

SCA: An Essential Ingredient of Digital Transformation
Origin Story of SCA
September 14, 2019: Official Compliance Deadline for Strong Customer Authentication
SCA Extension
Another Important PSD2 Deadline: March 14, 2019
FAQs about RTS and SCA
Strong Customer Authentication Checklist
Ping Identity’s Capabilities for Strong Customer Authentication
Leading the Way with SCA

SCA: An Essential Ingredient of Digital Transformation
If you’re a bank, lender, building society, insurance company, credit card issuer, credit union, asset manager, stock brokerage firm—or any other type of monetary financial institution offering financial accounts—you manage customers’ precious money matters. That’s why you begin every exchange by quickly identifying who you are serving.

In person, a valid ID card will suffice, and digitally, the act of logging in sets the stage. It starts out simple enough, but when interactions are happening remotely through multiple channels, it becomes all the more critical to use multiple factors of authentication (MFA) just to be extra sure, particularly when authorizing high-risk transactions.

A variety of federal or local regulations around the globe ensure financial institutions uphold high standards for data security and access—like PSD2 in the EU. But even if they aren’t an explicit regulatory requirement, strong customer authentication and multi-factor authentication make good business sense for any forward-thinking financial institution that wants to deliver convenient and secure digital customer experiences.

If you are part of an EU monetary financial institution or payment service provider, read on to learn more about strong customer authentication (SCA) and how it came to be an integral PSD2 requirement for all payment service providers effective September 14, 2019.

If your organization falls outside the scope of PSD2, but you are still interested in strong customer authentication as part of a broader digital transformation, you may want to jump ahead to the Strong Customer Authentication Checklist below.

Origin Story of SCA
Since the beginning of this century, the EU banking industry has been highly concentrated and consolidated, due in part to inefficiencies in cross-border payments and a long period of deregulation. Since cashless payments and transactions across Europe weren’t standard previously, money couldn’t easily cross borders and consumers couldn’t take advantage of financial options in other nearby countries.

M&A activity also flourished within member state boundaries, and this resulted in fewer banks holding more money and offering similar services. Without real options, consumers had little incentive to switch account providers, and the lack of competitive forces gave banks little incentive to innovate.

The EU stepped in for the sake of consumers and the collective European economy by adopting the first Payment Services Directive in 2007. This revolutionary regulation:

provides a single market for payments across the EU
establishes more innovative and safer payment services for consumers
encourages competition and new market entrants in the financial services industry

By all accounts, it’s working. An explosion of innovative new financial services has since begun flooding the market and capturing the hearts and wallets of digital-savvy consumers. However, many of the new financial technology (“fintech”) players fall outside the scope of that original directive. As such, they were not previously subject to the same secure payment rules as banks and other traditional account servicing payment service providers (ASPSPs).

Meanwhile, more and more consumers are trusting innovative fintechs with their online banking account credentials, account numbers and card payment numbers. Because they aren’t bound by the original PSD regulation, many of these fintechs are using questionable practices—like storing and using consumers’ logins to “screen scrape” online account data. They’re doing it for the right reasons—to provide convenient digital services, such as account aggregation and personal financial management—but their methodology is flawed.

Screen scraping is the act of using a computer program to copy data from another website. In this case, fintechs log in with the customer’s credentials and “scrape” display data from online banking transaction history.

Banks bound by PSD tried to secure and discourage this risky new flavor of account activity, while some challenger banks deliberately waited to see what would happen. At the same time, fintechs accused banks of a monopoly on customer accounts and data.

Seeing the conflict unfolding, regulators stepped in once again to help reconcile the situation for all stakeholders involved, passing PSD2, the Revised Payment Services Directive, in November 2015. PSD2 entered into force on January 12, 2016, with a two-year deadline for EU member states to transpose it into national law by January 13, 2018.

Giving fintechs the access they want, PSD2 requires banks and other account servicing payment service providers (ASPSPs, such as building societies, credit unions, securities firms, insurance companies, challenger banks, etc.) to grant access to accounts (XS2A) for third party providers (TPP), including fintechs, aggregators, retailers/merchants, charities and others. This access is contingent upon consumers giving their explicit consent for payments or data aggregation.

PSD2 gives banks the security guidance they want by closing some loopholes and expanding the definition of payment services providers. Further, PSD2 mandated the European Banking Association (EBA) with creating “regulatory technical standards (RTS) for strong customer authentication (SCA) and common and secure open standards of communication” within one year.

September 14, 2019: Official Compliance Deadline for Strong Customer Authentication
After collecting responses and consulting with many payment industry stakeholders, the EBA submitted the final RTS draft on February 23, 2017. However, the final draft was not as technically prescriptive as the industry had anticipated. The term “API” doesn’t even officially appear as the vehicle for secure open standards of communication; the idea was to ensure technology neutrality and allow for future innovations.

The European Commission amended the EBA’s RTS draft—adding back the ability for TPPs to resort to controversial “screen scraping” as a contingency mechanism if an ASPSP fails to grant sufficient XS2A—before submitting it on November 27, 2017 to the European Parliament and Council for a three-month review period.

After the review period ended, the final RTS was published in the official Journal of the EU and entered into force on March 14, 2018, with an 18-month implementation window. This means that regulatory technical standards for strong customer authentication and common and secure open standards of communication became mandatory across the EU on September 14, 2019.

SCA Extension

The SCA deadline led to growing concerns that merchants were not adequately prepared for the changes and it could negatively impact commerce across the EU. SCA is applicable to any transaction over €30 initiated within the EU, yet a recent study revealed that only 44% of merchants felt prepared for SCA. The concerns are that poor implementation of SCA could lead to purchase friction (i.e., poor checkout flows and negative customer experiences). In fact, 52% of customers who abandon online carts purchase the same goods through another merchant. In total, the study estimated that checkout friction could impact EU merchants to the tune of €57 billion in abandoned purchase volume.

However, it is not just merchants who were unprepared. In a study of 442 European banks, fewer than 50% were prepared to meet SCA requirements by the deadline. Despite larger and more sophisticated IT operations, these banks have had issues introducing MFA to their customers and developing open APIs strategically because of challenges around modernizing legacy infrastructure and collaborating with outside partners.

In response, the EBA issued an opinion to delay enforcement beyond the deadline for a “limited additional time.” The opinion stipulates that Payment Service Providers (PSPs), which include ASPSPs and TPPs, are to work with merchants and other relevant stakeholders to migrate to solutions compliant with SCA. To put it simply, banks, payment service providers and merchants need to work together on this. In order to receive the extension, PSPs and other stakeholders must submit a migration plan and receive approval from their local regulators, the National Competent Authorities (NCAs).

The timeline appears to be deliberately vague and defers that decision to each national competent authority. The UK’s Financial Conduct Authority (FCA) imposed a deadline of 18 months, to March 2021, as did the CAs of France and Denmark. The extension is an opportunity for PSPs to become strategic partners of merchants, particularly SMBs, who lack the expertise around IT integration and implementation. More importantly, the extension allows PSPs to focus on the security flows not only for SCA but also in regards to customer experience.

While enforcement is delayed, the deadline should trigger companies and PSPs to work together and optimize checkout experiences for their customers. Those that approach SCA right will not only avoid compliance issues but also acquire new customers in the process. And the PSPs and merchants that fail to meet the SCA requirements risk being fined, and even worse, losing out on customer revenues and missing the boat on the massive potential behind the API economy.

Another Important PSD2 Deadline: March 14, 2019
Aside from the implementation deadline for strong customer authentication, an equally important deadline occured six months before, which enabled ASPSPs and TPPs to test and prepare for SCA applications.

From Article 38 of the final RTS:

This Regulation shall enter into force on the day following that of its publication in the Official Journal of the European Union
This Regulation shall apply from 14 September 2019.
However, paragraphs 3 and 5 of Article 30 shall apply from 14 March 2019.

Paragraph 3 is the requirement for ASPSPs to provide interfaces (i.e., open APIs) that meet the common and secure open communication standards, with technical specifications documented and publicly available.

Paragraph 5 is the requirement that ASPSPs provide a testing facility and support for TPPs to be able to connect and test authorizing payment services through the interface.

However, 41% of banks failed the March deadline to get their test environments ready. This was a precursor to the SCA extension as it delayed the amount of time that TPPs would have to create integrations. Even among ASPSPs that did meet the deadline, there were issues with API accessibility, documentation and functionality. A silver lining was that banks and technology companies began collaborating on creating test environments, including us. We created a Quickstart Private Sandbox for Open Banking & PSD2.

FAQs about RTS and SCA
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.

Strong Customer Authentication Checklist
For banks and other account servicing financial institutions in the process of implementing open APIs, here is your recommended strong customer authentication technology checklist:

Modern multi-factor authentication (e.g., PingID): prompts the user to prove their identity by providing two or more of the necessary security factors.
OAuth authorization server (e.g., PingFederate): serves as a token endpoint and grants scoped access tokens after validating user credentials and attributes against the directory.
Identity data store (e.g., PingDirectory): encrypts and stores user credentials, consent records and other attributes, and scales to handle peak access request volume.
OAuth resource server (e.g., PingAccess): sits in front of your exposed financial APIs and redirects API calls to an authorization server, enforces policy for requiring at least two of the three required SCA-compliant authentication factors, and validates access tokens once they are issued by the authorization server.
Customer data governance (e.g., PingDataGovernance): enforces customer consent records and offers REST APIs for managing identity and authorization data—a must-have in a post-GDPR environment.
API intelligence (e.g., PingIntelligence for APIs): analyzes API request data to automatically learn normal/abnormal activity patterns, detect threats and block suspicious requests

Ping Identity’s Capabilities for Strong Customer Authentication
The Ping Intelligent Identity platform is a modern IAM (identity and access management) platform. It provides a broad spectrum of PSD2 and open banking capabilities to handle a variety of SCA use cases and the requirements of the overall open banking movement, and includes support for the most common API vulnerabilities as defined by OWASP.

Ping also provides the IAM technology that underpins the Open Banking Directory, the trusted framework where ASPSPs and TPPs in the UK register to participate in Open Banking. Open banking in the UK is the most widely known flavor of PSD2 in execution, setting an example other member states will likely follow. It has specified OAuth 2.0 and OpenID Connect (OIDC) as technical standards for secure system integration in an open, financial-grade API (FAPI) environment.

Since you’re a proactive organization, it’s likely that you already have some of these capabilities in place already. If this is the case, you have a couple choices:

If you’re planning to keep some of the pieces you already have in place, the Ping Identity Platform supports your ability to pick and choose only the functionality you need. Built in an extensible fashion, using open standards, our platform is composed of individual solutions that work seamlessly with other technologies, including homegrown tools and most major commercial technologies. You can integrate your existing enterprise applications, directories and most other pieces of an IAM infrastructure using cloud identity provider connections, data store integrations, password credential validators and proprietary integration kits. Our solution has the just-right combination of turnkey integrations, edge use cases and “last mile” integrations to meet the complex needs of even the largest enterprises.

If you already have some of these capabilities, but they’re outdated and unable to keep up with the scale and demands of open banking, you might be dreading a disruptive transition. We understand the nature of infrastructure technology, and we understand that a “rip & replace” approach is never an option. We support your need for new technologies that coexist alongside legacy ones, whether indefinitely or temporarily. With the Ping Identity Platform, you can roll out a gently-phased transition where you “flip the switch” seamlessly in the background.

Leading the Way with SCA
Strong customer authentication is becoming the standard across financial services in every geography. Even when it isn’t being mandated, SCA is being proactively adopted by innovators looking to deliver the right balance of security and convenience for customers. Many of the world’s largest financial institutions are turning to Ping Identity for our expertise in identity and access management technology, and our leadership in open standards and the global open banking movement.

Get the Technical Solution Guide for PSD2 and Open Banking to learn more.