Strong Customer Authentication and Dynamic Linking for PSD2
- Divya Premanantha
- Senior Software Engineer - WSO2
The Payment Services Directive 2 (PSD2) policy aims to open payment ecosystems to simplify online payments and reduce fraud by mandating strong customer authentication (SCA) for third-party providers (TPPs). SCA enforces the use of two-factor authentication (2FA), which requires users to verify their identities in two unique ways before giving access.
Dynamic linking is the most discussed topic under the Regulatory Technical Standards (RTS) on SCA and Common and Secure Communication (CSC). It has three segments. First, it requires a payer to verify an online transaction by generating an authentication code with some transaction data (at least the amount and any information identifying the beneficiary) to link the authentication code with the provided data. Second, it aims to protect the confidentiality and integrity of transaction data throughout the authentication process. Third, the users should be aware of the online transaction data that they authenticate. This requirement is often referred to as What You See Is What You Sign (WYSIWYS). This implies that the detailed transaction data and session identifier information should be given to the user.
This article mainly covers the concept of SCA, in which 2FA pays a major role. We also discuss the importance of dynamic linking in SCA.
RTS Specifics of Online Payments
The RTS requires an authentication code each time a payer accesses a payment account online or carries out any action through a remote channel to initiate an electronic transaction. The code is accepted only once by the payment service provider. The authentication procedure must ensure that the payer is made aware of the transaction details and of the payee at all times. The authentication code should be specific to the amount of the transaction and the payee (any change to the amount or payee shall result in a change of the authentication code).
It is also necessary to define interdependencies for the elements in SCA so that a breach does not compromise the reliability of other parts. Dynamic linking ensures this by linking the payer and payee. Security protections are required for the elements of SCA, in particular, to mitigate the risk that those elements are uncovered, disclosed to, and used by unauthorized parties.
Strong Customer Authentication
Figure 1: SCA authentication flow
One of the major aspects of PSD2 is the focus on improving security in the payment space by emphasizing SCA. The RTS for SCA is a mandatory requirement for authenticating online payments. It will be mandated across the Europian Union (EU) from September 2019. SCA means certain security measures need to be in place in order for customers to prove their identities before they can grant third parties access to their accounts.
PSD2 has mandated service providers to facilitate SCA when the following situations arise:
- Access online payment accounts
- Initiate electronic transactions
- Action carried out through a remote channel that presents a risk of payment fraud
- Provision of information through a service provider
2FA, which focuses on instances where entering a username and password are not secure enough, is an important element of SCA. Transactions that use 2FA need to be authenticated using at least two of the following three factors: something that the customer knows (e.g. a password, PIN, or response to a security question), something that the customer has (e.g. a mobile phone), and something that the customer is (e.g. a biometric such as a fingerprint).
Figure 2: 2FA categories
With the general shift towards online services, there is a greater need to authenticate the identity of users during transactions and banking activities to:
- Reduce the potential for online fraud
- Reduce the cost of processing fraudulent transactions
- Increase cardholder confidence in using online services
- Comply with international regulations such as PSD2 and the Payment Card Industry Data Security Standard (PCI-DSS)
An independent authentication element should be used and the authentication mechanism must generate an authentication code, which is only valid once. The following conditions need to be met when generating the code:
- No information regarding the knowledge, possession, and inheritance can be derived from the disclosure of the authentication code
- A new authentication code should not be generated based on the knowledge of any other authentication code previously generated
- The authentication code cannot be forged
Specific types of low-risk transactions may be exempted from SCA according to the regulation. When a payment request is initiated, the bank analyzes the risk level of the transaction and ultimately decides on whether to approve the exemption or if 2FA is needed. An exemption will decrease the number of times a customer needs to authenticate and will reduce the friction for low-risk transactions, which will lessen customer drop-offs.
SCA Approaches
When banks implement SCA there are popular approaches that different banks can follow. Redirect is one of the most used and easiest to implement SCA approaches. When the Payment Service User (PSU) starts the interaction with the TPP it is redirected to a web interface of an Account Servicing Payment Service Provider (ASPSP) for authentication. It means in a payment scenario when a user is shopping online and wants to make a payment they are redirected to their bank website to authenticate themselves by entering their credentials. A great advantage of a redirect approach is that no additional detailed information about the user is shared with the TPP. To complete the authorization process a pre-populated credit transfer screen is presented for the user’s confirmation. The redirect approach is therefore considered a half automated methodology i.e. the flow is controlled by the user and the payment is essentially initiated by themselves.
The decoupled SCA approach is very similar to the redirect approach. The main difference is that the PSU will not redirect to the ASPSP’s authentication website. This authentication needs to be done through an independent application or a device from the ASPSP’s end (e.g. a mobile application). It means that the PSU should authenticate itself through a methodology that should be decoupled from the main authentication flow. Similar to the redirect approach it’s easy to implement and an effective approach as the interaction is between ASPSP and PSU.
An embedded SCA approach means that the process is fully automated and the payment is initiated on behalf of the PSU by the TPP. The user shares the credentials with the TPP who authenticates and initiates the payment in the background and embeds the interaction with the ASPSP. A service provider should be registered and licensed in order to perform this action as the entire approach is carried out by the TPP who is not allowed to store any shared credentials by the PSU. To increase the secure factor of this approach the PSU may be required to complete an SCA such as a one-time-password to reduce fraud.
Dynamic Linking
To prevent man-in-the-middle attacks, European legislators introduced the requirement of dynamic linking between the payer and payee. A man-in-the-middle attack is performed by attackers who try to interrupt the connection established between the two parties and 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:
- The payer should be made aware of the amount of the payment transaction and payee
- The generated authentication code must be specific to the payment transaction amount that the payee agreed to with the payer when initiating the transaction
- An ASPSP or a bank must validate the original information, regarding the transaction and the payee, and accept only if the details match the authentication code
- The authentication code should be invalidated if any modifications are encountered in the amount or payee
- The integrity, confidentiality, and authenticity of the transaction information should be maintained by the ASPSP and the displayed information to the payer should be accurate throughout all authentication phases
WSO2 Implementation of SCA and Dynamic Linking
WSO2 Open Banking supports multi-factor authentication (MFA) with the integration of WSO2 Identity Server, which provides identity and access management capabilities. It not only complies with PSD2 SCA but also helps users perform secure online transactions by providing a robust implementation to ensure only trusted parties authorize APIs. The solution also provides seamless integration with legacy user stores. To comply with dynamic linking, WSO2 provides a consent management console and authentication flow to generate unique authorization codes.
The flow starts with a user request for a TPP to utilize account services relating to an information service provider (AISP), a payment initiation service provider (PISP), or a card-based payment instrument issuer (CBPII). To provide the required services for the user, the TPP initiates the consent request and redirects the user to the bank to authenticate. Following the successful initial authentication, the user is requested to complete an SCA based on the selected approach. The user then follows the consent management flow and gives consent to the TPP to access private data.
After the user completes the process, the bank issues an authorization code, which can be exchanged for an access token by the TPP application. To ensure the secure transaction of the required access token, it’s signed as a JSON Web Token (JWT). This access token is then linked with the data store, which can be used by the TPP to invoke APIs.
The user can now retrieve services from the TPP application in which the required TPP application accesses resources from the bank through an API. The implementation checks the validity of the access token and only allows the tokens that are active and dynamically linked to the payer and payee.
WSO2 Identity Server enhances the authentication and authorization mechanisms. The configuration of a one-time password through SMS (SMS OTP), time-based one-time password (TOTP), one-time-password through email (email OTP), and many other first- and second-factor authentication can be configured through WSO2 Identity Server.
Conclusion
Complying with PSD2 has become a key priority for EU-based financial institutions. Dynamic linking, which is a key part of SCA, has created a new set of requirements for 2FA implementations. This involves dynamically linking authentication tokens to the specific payment amount and the specific payee of the transaction. These regulations aim to protect the confidentiality and integrity of transaction data.
WSO2 Open Banking with PSD2 compliance provides an overall solution for security breaches and ensures a secure transaction for the user with dynamic linking capabilities for authenticity and confidentiality, with an authentication code throughout the authorization flow.