For companies doing business in the EU, whether that’s accepting payments or transferring funds into or out of Europe, following the second EU Payments Services Directive (PSD2) and complying with Strong Customer Authentication (SCA) isn’t a choice––it’s a requirement.

So, it’s no surprise that more payment service providers and financial services companies are coming up with innovative ways to meet the specific details outlined in SCA. Companies that make a user’s experience more seamless and delightful as they toggle through a necessary but perhaps clunky part of the payment process will boast happier customers.

Let’s explore the details of PSD2 and SCA, and how you can use a legal requirement as an opportunity to provide a better customer experience and rise above the competition.

As an EU-wide initiative, PSD2 provides increased security for online shopping through the proposed process known as Strong Customer Authentication. 

As PSD2 goes into effect, shoppers with European Union credit cards, financial institutions, or digital payment services may be asked to confirm their identity before checking out with a Europe-based merchant. 

While only certain transactions are eligible for PSD2, merchants and financial services companies would be smart to follow the SCA guidelines to protect their users—regardless of transaction type. 

Here are some key considerations for eligible transactions:

• SCA only applies to access of a payment account online and to a customer-initiated electronic payment initiation (transaction), unless an exemption under the Regulatory Technical Standards (RTS) applies. 
• The buyer and merchant must both be based in the European Economic Area (EEA). This means that issuing banks and acquiring banks are both EEA-based.
• Purchases under €30 are exempt. This exemption is for small-dollar amount purchases unless there are five or more consecutive attempts that sum over €100.

SCA is a specific form of two-factor authentication (2FA) that must include two or more elements, categorized as:

• Knowledge: something only the user knows
• Possession: something only the user possesses
• Inherence: something the user is

 Payment service providers (PSPs) must employ an authentication method that uses elements from two different categories. One of these elements must be dynamically linked to the transaction, and the authentication elements and the transaction must happen within five minutes of each other. 

Inherence

Any biometric — whether it’s facial recognition, a fingerprint, or a retina scan — is a possible inherence element. 

Possession

Here are some examples of SCA-compliant possession elements:

• Possession of a device evidenced by an OTP generated by (or received on) a device (hardware or software token generator, SMS OTP)
• Possession of a device evidenced by a signature generated by a device (hardware or software token)

Knowledge

Also in the document are SCA-complaint elements that constitute a knowledge factor. These include: 

• Password 
• PIN 
• Knowledge-based challenge questions
• Passphrase
• Memorized swiping path

Knowledge factors that are not compliant with Strong Customer Authentication guidelines include:

• Email address or user name 
• Card details (printed on the card) 
• OTP generated by (or received on) a device (hardware or software token generator, SMS OTP)

While multiple authentication methods satisfy SCA requirements, Authy App Unlock + Push Auth is worth examining in detail because it satisfies both factors at the end-user’s device.

A business using the Authy API for two-factor authentication can now get data about whether a user had enabled an unlock method to open their Authy mobile app, when it was last unlocked, and the method used. 

This information allows Authy customers to use the Authy App Unlock process as an additional authentication factor for PSD2 SCA compliance, as well as for account takeover prevention.

With Authy App Unlock + Push Auth, App Unlock functions as either the “knowledge” or “inherence” element, depending on whether a PIN, fingerprint, or Face ID is used to unlock the user’s device. Once the knowledge or inherence factor is satisfied by unlocking the app, Push Authentication is used as the dynamically linked “possession” element. 

Here are some tips on adding a second factor of authentication to your web application, with a smart user enrollment and communications flow to make the most out of this security process. 

In the following scenarios, here’s how we define business and users:

• Business: The PSP entity that is looking to use Twilio Authy to perform SCA
• User: The end-user that needs to be authenticated by the business via SCA
  
  Business setup with Twilio Authy

1. The business developer user creates a customer account to start using Twilio Authy.
2. The business then integrates the Authy API, specifically a User Status endpoint for the unlock method data and Push Auth endpoint. This “Getting Started” document is a great one to bookmark.
   
   Enrolling a user into Twilio Authy security 

1. During the sign-up process, the business asks their user for a phone number and email address to be used for receiving Authy messages.
2. The Business adds the User via the Authy API.
3. The Business asks the User to install the Authy App; the user will receive an SMS download link from Authy. In some instances, users will already have downloaded the Authy app here.
4. The business directs the user to enable the Unlock method for its Authy App. This is accomplished in the Authy iOS app by navigating to Settings > Security > App Protection: Enable > Protect Entire App. In Authy Android, users can navigate to Settings > Security > App Protection: Enable. 
5. The business confirms the user has enabled the unlock method by checking that enabled_unlock_methods is either “pin,” “faceid,” or “fingerprint.” Note that the action of a user enabling the unlock method does not set the “last_unlock_method” or “last_unlock_date” properties.
   
   User authentication challenge to approve a transaction

1. The business sends an Authy Push Authentication request to the user.
2. The Push Auth request appears to the User as an app notification on the device on which the Authy App is installed.
3. The user taps on the notification, which attempts to open the Authy App.
4. To allow Authy to be opened, the user is requested to unlock the app with either their PIN, Face ID, or fingerprint.
5. The user successfully unlocks the Authy App.
6. The user sees the Push Auth request and accepts it.
7. The business checks that Push Auth verification has been approved and records the updated_at timestamp of the approval. 
8. The business determines whether the last_unlock_method was “pin,” “faceid,” or “fingerprint,” and verifies that the last_unlock_date is within 5 minutes of the Push Auth approval. This data is available in the approval_request response. This check assumes that the transaction will be executed immediately after the Push Auth approval because the RTS specifies that the two authentication elements and the transaction should happen within five minutes of each other.
9. If the last_unlock_date can not be verified as occurring within the five-minute window, then the business requests that the user close and re-open the Authy App (e.g., Go to phone’s home screen) to retrigger the unlock authentication. 

Building better SCA-compliant security

Twilio’s Authy API can help payment providers meet dynamic linking requirements by making it simple to add 2FA to their services. But remember, when deciding how to implement SCA, consider the impact on the consumer. Get it wrong, and you’ll adversely impact customer purchase flow. 

In addition to push authentication, Authy supports OTP delivered via SMS and voice, and TOTP generated in the free Authy app. Authy 2FA via an SDK is also available.

If you’d like to discuss your current authentication strategy and how Twilio can help, click here to talk to an expert.

Meanwhile:

• Download our e-book to review what financial organizations must know about PSD2 rules.
• Discover the critical user events in financial services that demand 2FA protection.
• Learn how to secure payment actions using Python, Flask, Javascript, and the Authy API.
• Read our blog about the requirements of dynamic linking as it relates to PSD2 & SCA.