A Deep Dive of Transaction Risk Analysis for Open Banking and PSD2

Transaction risk analysis (TRA) is a method that observes the counterparties and attributes involved in a particular transaction in order to prevent, detect and block possible fraudulent behavior. This article will discuss the basics of TRA and how it affects strong customer authentication (SCA) in the second Payment Services Directive (PSD2) accounts/payments flows. Further, this article will discuss the implementation of TRA in WSO2 Open Banking.

The Regulatory Technical Standards (RTS)

RTS was published by the European Banking Authority (EBA) to provide guidance for authentication, authorization, and other security aspects and fill technical gaps in PSD2. RTS was published considering the requirements of PSD2 article 98 to define when and how SCA needs to be applied. The final draft RTS report was released on February 23, 2017.

In the context of PSD2, the following terms are used to describe entities involved in the accounts/payments flows:

• Payment Service User (PSU) - A natural person or bank user
• Third-party Provider (TPP) - An organization or a natural person that consumes APIs developed according to PSD2 standards
• Account Servicing Payment Service Providers (ASPSP) - An entity that provides and maintains payment accounts for payers and publishes APIs to permit TPPs to provide services to the PSUs (the bank)

Strong Customer Authentication (SCA)

SCA is introduced as an attempt to make online transactions, online account access and other online actions more secure by adding an extra layer of authentication during the time of transaction. SCA authenticates users using two or more elements categorized below:

1. Knowledge - Something only the user knows

   A shared secret that only the bank user and the bank are aware of

   E.g. Password, PIN, passphrase, or secret fact

2. Possession - Something only the user possesses

   Ownership proof of a device that uniquely associated with the bank user

   E.g. Mobile phone, wearable device, or smart card

3. Inherence - Something the user is

   A physical characteristic of the bank user that can be used to identify him uniquely

   E.g. Fingerprint, voice patterns, or DNA signature

Requirements that need to be fulfilled by the bank when providing the above elements are defined in the RTS document in articles 6-8. Article 9 emphasizes that the above elements need to be independent of each other in order to make sure a breach of one element does not affect the reliability of others. Risk of using multi-purpose devices such as mobile phones and tablets in the authentication process is identified (as they require special attention due to usage patterns) in this section and measures to mitigate these risks have been defined.

SCA and User Experience

There has always been a constant battle between SCA and user experience. Using SCA for each transaction can lead to user frustration and overuse of resources. SCA always applies some friction to a user’s execution of the transaction flow, therefore it is a barrier in customer experience. For example, a merchant won’t be able to provide a feature such as “one-click shopping” where users are permitted to perform a high amount of transactions without enforcing the friction of SCA. Furthermore, enforcing SCA causes additional use of resources such as SMS and email.

TRA and fraud detection plays an important role in maintaining a balance between security and user experience by defining the right time to apply SCA. But at the same time, TRA can be controversial because some security domain professionals may see it as a security vulnerability.

Transaction Risk Analysis (TRA)

There are a few key elements considered during TRA, which includes

• Transaction amount
• Last SCA applied time
• Payment patterns
• Payment behaviors
• Location of payer/payee
• Devices used
• Time limit

To make this risk analysis based authentication work, risk analysis checks against ongoing transactions need to be performed in real time.

Adaptive Authentication

Adaptive authentication enables adjusting authentication strength based on additional context attributes. It provides flexibility to the authentication framework by giving allowing the system to evaluate the context in real time. Using this, financial service providers can engage different authentication factors based on attributes like geolocation, device, and value of the transaction, instead of enforcing the same set of authentication factors for every transaction.

Fraudulent actions are changing rapidly making it difficult to predict fraud based on the transaction behavior. Therefore application designers in the financial industry need to perform regular security checks such as vulnerability scanning, penetration testing, and static and dynamic application security testing.

TRA Use Cases Defined in the RTS

RTS has mentioned some of the use cases where TRA can be applied to enforce/exempt SCA. The use cases below can be identified as examples where TRA is used to minimize the risks involved in payment/accounts flows.

Payment Account Information

PSUs can avoid the application of SCA if the requesting consent is limited to (either or both of) the actions below for one or more account:

• Accessing balance information
• Accessing executed transactions information for time range within the last 90 days

Note: Only if they have authenticated with SCA within the last 90 days.

Contactless Payments at Point of Sales

PSUs can avoid application of SCA where the payer initiates a contactless payment at the point of sale only if both of the following conditions are met.

• The ongoing transaction value does not exceed 50 euros
• Total number of transactions since the last SCA applied transaction does not exceed 5 and cumulative sum of those transactions does not exceed 150 euros

Transport and Parking Fees

PSUs can avoid application of SCA where the payer initiates an electronic payment transaction at an unattended payment terminal for the purpose of paying a transport or parking fare.

Trusted Beneficiaries and Recurring Transactions

PSUs can avoid application of SCA only if the payee is in the payer’s trusted beneficiary list. However, exemption of SCA is not permitted if the payer gives consent, creates, confirms or subsequently amends the list of trusted beneficiaries.

PSUs can avoid application of SCA when the payer initiates a series of payments for the same amount, for the same payee, unless it is the first time. However, exemption of SCA is not permitted if the payer subsequently amends the series of payments.

Payment to Self

PSUs can avoid application of SCA when

• The payer initiates a credit transfer to another account that belongs to themselves (same natural or legal person)
• Both the creditor account and the debtor account belongs to the same bank (same ASPSP)

Low Value Transactions

PSUs can avoid application of SCA where the payer initiates an electronic payment and only if both of the following conditions are met:

• The ongoing transaction value does not exceed 30 euros
• The total number of transactions since the last SCA applied transaction does not exceed 5 and the cumulative sum of those transactions does not exceed 100 euros

Apart from these articles, article 16 (titled as Transaction Risk Analysis) also contain a set of rules that defines scenarios to exempt SCA. A reference fraud rate is defined in this article and SCA exemptions are allowed only for low fraud rated banks. In other words, SCA is mandated for the identified possible fraudulent actions from this article. More information regarding fraud detection aspect of RTS and PSD2 is discussed in this article.

WSO2 Open Banking Capabilities for TRA

WSO2 Open Banking has a TRA module, which like its other features is extensible and configurable. This allows users to customize the functionality to cater to the contrasting needs of financial institutes.

Figure 1 below depicts the overall authorization flow when the TRA module is activated in WSO2 Open Banking.

Figure 1 - PSU Authentication flow with TRA enabled

Once the basic authentication is completed, the TRA module is called from the flow. The TRA module provides a response with the decision on whether to proceed with SCA or not.

WSO2 Open Banking employs WSO2 Identity and Access Management capabilities such as adaptive authentication. This allows the WSO2 Open Banking solution to call on external modules during the authentication process, take decisions based on the current context (and historical data), and adapt the authentication process based on the results.

Figure 2 below is an abstract view of the TRA component in WSO2 Open Banking.

Figure 2 - TRA Module

The TRA module consists of a set of validators that will be executed according to the configurable order. If any of the validators return true (suggesting TRA can be exempted), the response will be sent to the authorization flow immediately, indicating the possibility of exempting SCA. If all the validators return false, the module will send a response back to the authorization flow indicating the result.

The TRA module is implemented in a way such that these validators can be added or removed by changing the configurations easily. Moreover, it is implemented in such a manner that anybody can easily implement a new custom validator, add it to the solution, update the configuration and use it in the authorization flow.

These validators use the TRA database to store related data such as last SCA applied time for a particular user and transaction value. These are used again by the same validators when making the decision. A consent management database is also used to read data during the validation process.

These validators process large amounts of data in real time in order to produce accurate results. This can slow down the authorization flow resulting in bad user experience. To minimize this effect, WSO2 Stream Processor — designed to be a SQL-based, high performant, lightweight, open source stream processing platform that facilitates real-time data processing — is used for processing this data in real time.

Conclusion

PSD2 has additional requirements for minimizing the threats of fraudulent actions that have been on the rise with the advent of new technology. In order to maintain the balance between user experience and strong customer authentication, some additional measures have been introduced via real-time TRA and fraud detection during the authorization flow. State-of-the-art identity and access management capabilities such as adaptive authentication have made this process easy by enabling the system to adapt to changing behaviors of fraud. WSO2 Open Banking, which delivers PSD2 compliance, and is easily configurable and extensible, makes use of WSO2 IAM and real-time data processing to enable this.