INNOPAY
Innopay logo
INNOPAY
INNOPAY

Sharing transaction risk data leads to Open Banking success

This article was first published by the Paypers in the Open Banking Report 2018.

The revised Payment Service Directive Regulatory Technical Standards (PSD2 RTS) will come into effect in September 2019. It will require every bank (Account Service Payment Service Provider, ASPSP) to apply Strong Customer Authentication for almost every transaction. Although this increases security, it also introduces unwanted friction in the payment process. Fortunately, there are exemptions where SCA is not required. However, this requires an AS-PSP to perform Transaction Risk Analysis (TRA).

And therein lies the problem. 

For TRA to be effective, the data about the transaction, the customer and the context needs to be available and analysed, in real-time by the bank (ASPSP). However, with new service providers or Third-Party Providers (TPPs) joining the payment chain, the data is fragmented and distributed across multiple parties. Moreover, although there are several initiatives to standardise the exchange of payment information (through APIs), there is very limited mentioning of standardising context and risk data.

In this article, we elaborate on three key points that need to happen in order for banks to make TRA more effective under PSD2.

1. Security and risk data should be shared through open and common APIs.

Security and risk data consist of contextual data that can be gathered during the entire process of the transaction. Collecting data starts when a customer performs a transaction at a TPP. The TPP can read various data points based on the device the customer uses and his behaviour. After that, at the ASPSP, various data points can also be gathered based on attributes of the transaction and of the account.

During this process, the TPP should use the API call to the bank to provide contextual data, which will be assessed within the bank’s fraud engine.

This does require parties to use the same protocols and standards for communicating context data.

 

Only when the transaction poses a “low level of risk”, then the payment service provider is allowed exemption from SCA. PSD2 requires the risk assessment to include:

  • Abnormal transaction behaviour
  • Lists of compromised or stolen authentication elements
  • Unusual information about the device or software
  • Historic transactions of the user
  • Amount of transactions
  • Location of payer and payee
  • Known fraud scenarios
  • Signs of malware infection

Multiple standardisation initiatives are aiming to decrease communication complexity between banks and TPPs. In Europe, several initiatives have been launched to create an open and common API standard for PSD2:

  • “NextGenPSD2” is the standard developed by the Berlin Group — consisting of almost 40 banks, associations and PSPs from across the EU;
  • Also, in Poland (PolishAPI) and France (STET) initiatives were launched by consortia of banks in their respective countries;
  • In the UK, the Open Banking Implementation Entity (OBIE) is also working on a common API standard, an initiative mandated by the UK’s Competition and Markets Authority in 2016, ahead of PSD2.

However, there is a complication. These standards only marginally discuss the sharing of risk and authentication data. They also differ in their requirements: 

  • The Berlin Group standard specifies only the IP-address as mandatory (from 1.0 version);
  • STET and PolishAPI also add UserAgent as mandatory (information about the device and browser), besides IP-address;
  • UK’s OBIE refers to the OpenID Foundation Financial-Grade API which prescribes just the “UserAgent” as mandatory;
  • The API of OBIE talks about sharing of ‘Additional fields identified by the industry as business logic security concerns’, but that does not give clarity on which data must be shared mandatorily.

With increased coordination and convergence between different standards, more risk data and authentication data could be added to the APIs. Already, the scope of UK Open Banking has been aligned with PSD2, while STET and the Berlin Group are working together to ensure convergence between standards. Moving forward, these standards could include application and device details, time since credentials change (i.e. change of phone number, e- mail, rebinding of app etc.), time since onboarding of customer.

In addition, aspects of behaviour could also be shared. Think of properties of transactions like the moment of the day when they are usually performed, the receivers and the value of the transactions. Also, through the speed of typing, tilt of the device, and the order of pressed buttons. This behaviour is strongly attached to a device and a person, a combination that is hard to imitate.

In figure 1 a non-exhaustive overview of properties is listed to give insight on what can be used as risk data as input for a risk engine.

Various risk data that can be used as input for a risk engine

2. Machine learning becomes the new normal for fraud detection engines.

In open banking, the value chain is less vertically integrated. Without control over the end-to-end process, the AS-PSP needs to be able to gather risk data through additional sources. So, how can banks maintain their ability to detect fraud?

Besides exchanging information with TPPs, banks could also exchange modus operandi (MO) with other banks through an API call. Firstly, this requires banks to develop this capability into their “open” fraud engines so that they can consume external sources of data. Secondly, engines need to be able to analyse and process larger volumes of data in real-time.

For years, rule-based engines have proven to be effective in uncovering fraud for known patterns. However, rule-based processing has an inverse relationship with the size of datasets. By getting input from TPPs and other banks, the amount of risk data grows significantly. Machine learning techniques are faster and more efficient at processing large datasets and can maintain a high level of detection capability while working with large datasets. For discovering unknown fraud patterns out of large datasets, the application of machine learning is therefore recommended. For machine learning to add value, a large dataset is needed, so it might be worthwhile to start-off with a rule-based engine and then later improve by adding machine learning. 

3. Use customer involvement as detection mechanism.

In open banking, customers need to have control over their personal data. Without control, customers will be reluctant to share data, or transact with TPPs. Risk engines are able to learn from actions that are initiated by customers. For instance, they are able to detect a security aware customer or a customer that is likely to become malicious. Therefore, giving control to the customer will improve risk-profiling, and therefore transaction risk analysis (TRA) for banks.

A solution that gives the customer a convenient way to manage access to his account would be beneficiary to all parties in open banking. The customer should be able to determine access restrictions for devices and users, and/or provide limits to spending and withdrawals. Based upon the customers’ own insight, he could revoke access, or adapt access requests. Through the same system the customer can also administer which of his own devices are to be trusted, which means that in case of loss he can act upon that immediately. 

To conclude 

It goes without saying that any data sharing initiative should adhere to the applicable privacy laws. GDPR requires a lawful basis for processing personal data. Legal obligation is one of them. The PSD2 RTS on Strong Customer Authentication states in Article 2 that payment service providers shall have transaction monitoring mechanisms in place. Our solution mentions risk data sharing from TPPs towards banks. Part of that risk data is data on behaviour, which is personal data. Therefore, it is important that only the banks risk engine can make use of that data. This can be ensured by using a bank-controlled software development kit (SDK) for gathering behavioural data and sending that data over a secure connection. 

Being able to do transaction risk analysis has its benefits for TPPs, banks and customers, but requires ongoing cooperation of the three parties involved. TPPs need to collect and share risk data with banks; banks need to share risk data amongst other banks and delve into the possibilities of machine learning, and customers can contribute by monitoring and controling the access others have to their data. By combining these perspectives, Open Banking finds layered support aiming to lower risk and set friction to a minimum.

The future will show to which extent transaction risk analysis (TRA) will be adopted for payment services, and a trusted infrastructure will undoubtedly be fundamental to its success.

INNOPAY consultants are innovation experts in digital transactions and active in, amongst other, the banking industry and payments business. To discuss how we can help define or execute your Open Banking Cybersecurity strategy, please get in touch.

Let's get in touch

Ready to do business with the experts at INNOPAY?