Fraud Detection: Making Open Banking a Safer Place

Objective

The Regulatory Technical Standards(RTS) specification, published by the European Banking Authority (EBA), takes into consideration the requirements of PSD2 article 98 to define when and how SCA needs to be applied. The final report of the draft RTS document[1] was released on February 23, 2017.

This article provides an overview of the fraud detection aspect of RTS and PSD2 directive. We also explore in detail the implementation of the Open Banking Fraud Detection component in the WSO2 Open Banking solution.

Fraud Detection

Article 2 of the RTS mandates the ability to incorporate transaction monitoring mechanisms to detect unauthorized or fraudulent transactions. It also exempts the security requirements of strong customer authentication based on the identified level of risk and recurrence of the payment transaction. In order to exempt strong customer authentication, the spec has mandated various exemptions in Chapter 3. The exemptions specified until article 15 are straight forward scenarios where Strong Customer Authentication (SCA) can be exempted. These are discussed fully in this article.

Article 16 discusses that SCA exemptions can be provided if the transaction monitoring systems identify a low-risk transaction. A transaction can be identified as posing a low risk only if it satisfies the guidelines mandated in Article 2(I) and Article 16(2). The low-risk exemption provides Account Servicing Payment Service Providers (ASPSP) the ability to exempt strong customer authentication in the case of low-risk transactions. This will help the ASPSP to reduce the number of times SCA is applied. The reliability of this exemption is protected by the conditions put in place in order to make use of this exemption which are listed from Article 16(2)(d) to Article 16(2)(g) of the RTS.

Conditions for SCA Exception

In order to provide the SCA exception, Article 2(3), Article 2(4), and Article 16(2)(c) of the RTS mandate a set of minimum rules. These aspects should be considered in a rule-based scoring mechanism to grade transactions based on their risk levels. (Please note that these are the minimum mandated requirements. Based on the requirement of the payment service provider, more rules can be introduced).

Fraud Rules Currently Supported by WSO2 Open Banking

By analyzing the requirements and guidelines provided by the specification, we provide the following rules for risk analysis. We also provide other rules to further ensure the transaction risk is measured appropriately.

WSO2 Open Banking Fraud Detection Implementation

The WSO2 Open Banking Fraud Detection implementation is done in such a way that it can run independently of the Open Banking solution. Based on the transaction data published to it, the fraud detection module will provide the number of rules passed/failed and a fraud score based on the different rules. When the fraud detection module is integrated to the open banking risk analysis validator, it will exempt transactions from SCA if the transaction is identified as low risk (low transaction risk score).

The diagram below provides a brief explanation of the WSO2 fraud detection implementation.

The fraud detection implementation consists of four components:

• EOD (End of Day) Trigger Apps
• Business Rules
• Fraud Detector App
• Fraud Result Analyzer App

The functionality of these components are as follows:

EOD Triggers

EOD triggers are apps that run at the end of each day in order to aggregate and summarize the data recorded within that day.

• FrequencyAggregator - Calculates, and stores usual transaction frequency (per day) of each user.
• VolumeRateAggregator - Calculates, and stores transaction amount per day of each user.
• AmountAggregator - Calculates, and stores average transaction amount and the standard deviation.
• UsualDayAggregator - Calculates and stores the usual day of user transactions and the deviation of the days.
• UsualTimeAggregator - Calculates and stores the usual time of user transactions and the deviation of the time.
• FraudRateCalculator - Calculates and stores the fraud rate(RTS[3] Article 19) of the bank by the end of the day.

FraudDetector

Gathers previously stored data of the current transaction, adds it to the stream, and then validates if the fraud rate of the bank is within the RTS[3] Article 19 guidelines. If the fraud rate is within the given values, the transaction data is forwarded to the fraud detection rules.

Fraud Detection Rules

Fraud rules are the different rules that will be run in real time on the transaction data, in order to determine the risk of the transaction.

• FrequencyRule - Validates whether the transaction frequency of the past 24 hours is higher than the average transaction frequency.
• VolumeRateRule - Validates whether the transaction amount per day of the past 24 hours is higher than the average transaction amount per day.
• AmountRule - Validates whether the transaction amount is within twice the standard deviation of the average transaction amount of the user.
• UsualDayRule - Validates whether the transaction day of the user is regular if the deviation of transaction days is less than or equal to 2 days.
• UsualTimeRule - Validates whether the transaction time of the user is regular if the deviation of transaction time is less than or equal to 2 hours.
• UserBlacklistedRule - Validates whether the user is recorded as a blacklisted user.
• ApplicationBlacklistedRule - Validates whether the application is recorded as a blacklisted application.
• UserFlaglistedRule - Validates whether the user is recorded as a flagged user (potential fraudster flagged by the system).
• ApplicationFlaglistedRule - Validates whether the application is recorded as a flagged application (potential fraudulent application flagged by the system).

FraudResultAnalyzer

Gathers result data of all fraud detection rules and when a potential fraud is identified, adds the transaction to the flagged list and then sends a response stating whether the transaction is a potential fraud or not.

Deploying Fraud Rules

Deploying an available fraud rule

The fraud rules are available as Siddhi app templates in the Open Banking Business Insights component of the Open Banking solution. In order to deploy a Siddhi app to run in real time, the required rule could be deployed from the business rules manager [2]. The diagram below depicts the business rules manager once several apps are deployed.

Creating a new fraud rule

In order to create a new fraud detection rule, a new Siddhi app needs to be added to the business rule set and then deployed similar to deploying any other fraud rule. This follows 2 steps as listed out below:

Step 1: Create the Siddhi app for the fraud rule

The Siddhi application can be created and tested using the Siddhi development environment (editor) [3].

Step 2: Add the new rule as an app template

The developed Siddhi app can be added to the fraud detection ruleset using the business rules template editor [4]. The diagram below depicts how the different rules are shown in the business rules template editor.

Step 3: Deploy the rule in the business rules manager

This can be done similar to adding another rule since the template will be available with the other fraud rules.

Transaction History Analyzer

When a transaction becomes flagged as fraudulent by the fraud detection solution, based on the rule, either the PSU or the Application(TPP) gets flagged (Will not get the SCA exemption). In this scenario, introduce a dashboard to handle false positives and false negatives. Transactions can be updated to be marked as fraudulent or not fraudulent.

Features provided by the Transaction History Analyzer are:

• A 90-day transaction history
• Transaction filter and sorting
• Ability to mark transactions as fraudulent/not fraudulent
• Add fraudulent users and applications to the blacklist

The image below shows an example usage of the Transaction History Analyzer:

Monitoring

Article 17 of the RTS mandates that payment service providers that provide SCA exemptions shall record and monitor transaction data at least on a quarterly basis (90 days). In order to fulfill this requirement, the WSO2 Open Banking solution provides a monitoring dashboard.

Functionalities supported by the fraud detection dashboard are as follows:

• Display the total value of unauthorized/fraudulent payment transactions
• Display the total value of all payment transactions with the resulting fraud rate
• Display the total value of all payment transactions through SCA with the resulting fraud rate
• Display the total value of all payment transactions under each of the exemptions with the resulting fraud rate
• Display the average transaction value
• Display the average transaction value through SCA
• Display the average transaction value under each of the exemptions
• Display the number of payment transactions where each of the exemptions was applied
• Display the percentage of the number of payment transactions where each of the exemptions was applied in respect of the total number of payment transactions

The following images show the different insights displayed in the monitoring dashboard. Though the dashboard shows the transactions of the past 90 days, the date range can be filtered as you prefer.

Conclusion

The fraud detection solution has been created and included in WSO2 Open Banking to provide the ASPSPs with the ability to enhance user experiences by reducing the use of SCA and reduce the risk of transaction fraud. WSO2 is committed to continuously introduce different fraud rules and enhance the fraud detection module based on different spec updates. More information on WSO2 Open Banking is available here.

References

[1] Draft Regulatory Technical Standards on Strong Customer Authentication and common and secure communication under Article 98 of Directive 2015/2366 (PSD2)

[2] Documentation: Managing Business Rules

[3] Documentation: Creating a Siddhi Application

[4] Documentation: WSO2 Open Banking