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 a PSD2 requirement for all payment service providers by 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 inefficiency 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, 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, 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 will become mandatory across the EU on September 14, 2019.
Another Important PSD2 Deadline: March 14, 2019
Aside from the implementation deadline for strong customer authentication, there is an equally important deadline coming six months before that will enable 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.
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
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 them directly with their bank account (e.g., retailers, utilities, charities, etc.).
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.
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
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
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
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
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:
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 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:
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.
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.
Modern multi-factor authentication (e.g., PingID): prompts the user to prove their identity by providing two or more of the necessary security factors.
Identity data store (e.g., PingDirectory): encrypts and stores user credentials, consent records and other attributes, and scales to handle peak access request volume.
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 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.
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, the Ping Identity Platform is comprised of individual solutions that work seamlessly with other technologies in the Ping Identity Platform, as well as with homegrown tools and most major commercial ones. 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. The Ping Identity Platform 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 or “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.