Integrating Fraud detection systems with Open Banking

8 min readMay 16, 2020

It has been several years since European authorities first announced the initiatives for Open Banking. World has now begun to see how fintech companies, businesses, and consumers are adopting for this new era of banking. While Open Banking is opening up potential opportunities for businesses, fraudsters are looking at this as an opportunity to gain access to valuable consumer data.

In the meantime, digital adaptation has increased its pace due to the current COVID-19 situation . Therefore, more bank users are looking for convenient banking applications provided by third-party providers(TPPs). It has been observed that fraudulent activities have also increased with this digital adaptation.

Identifying possible frauds and preventing them has become a vital concern not only for financial institutes (Banks) but also for TPPs. Even though most regional open banking specifications have defined measures and strategies for identifying financial frauds, banks and third-party providers are seeking additional technologies to prevent fraud.

This blog will focus on selecting and integrating a fraud detection system with an Open Banking solution.

Fraud Detection as a separate Component

Open Banking solutions are often implemented to cater to requirements of a particular regional specification. Since fraud prevention requirements also can come with the specification, it is possible that an Open Banking solution itself contains a fraud detection component. Since most of the banks are looking for more than regulatory compliance, it is worth evaluating the capabilities of such an embedded component.

On the other hand, fraud detection systems were introduced way before Open Banking and they have evolved since then. Most of these fraud detection systems are advanced and are now using machine learning and data mining techniques to identify fraudulent behaviors.

Fraud detection styles can be identified in three levels.

1.Rule-based fraud detection

A defined set of rules are used to identify possible frauds. If a particular action breaks a rule, it will be considered as a fraudulent action. As an example, it is possible to define a rule as below.

If a payment amount is over $500 and the creditor is not in the debtor’s trusted beneficiary list, mark this as a possible fraudulent payment.

2. Score-based fraud detection

A set of rules is defined to evaluate an action and each rule will assign a score to the action. In the end, if the cumulative sum of the score is higher than a defined threshold, it will be considered as a fraudulent action. Refer to the example below.

If a payment amount is over $500 — Add 10 points to the fraud score.
If a payment creditor is not in debtor’s beneficiary list add 5 to the fraud score.

3. Machine learning-based fraud detection

A set of supervised machine learning models can be developed based on labelled historical datasets. The fraud detection component can update the datasets based on the feedback provided from the Open Banking system in order to increase the accuracy of each model.

Requirements can come as a combination of these styles. As an example, the requirements of RTS ( Regulatory technical standards that provide technical guidelines for PSD2) contain rule-based and score-based fraud detection requirements.

Adding an external component for fraud detection will be an extra cost in finance and resources to the banks. This should be done after careful evaluation of the exact fraud prevention requirements of the bank.

Selecting a Fraud detection component

Below guidelines will be helpful when selecting the proper fraud detection component for a bank.

Depth of supported techniques and styles

Fraud detection components that are tailor-made to cater to open banking regulations usually come with rule-based and score based support as they are mandated by many regional regulators. If a bank has a requirement to have self-learning fraud detection capabilities, it is better to check whether those tailor-made components support machine learning-based fraud detection. On the other hand, if a bank chooses a multi-purpose fraud detection component, there is a possibility that it no longer supports rule-based fraud detection. If the regional specification mandated a set of rules for fraud prevention, it is worth checking the possibility of achieving those requirements using the multi-purpose fraud detection component.

Fraud detection components support a vast variety of techniques ( such as IP-based address filtering, user blacklisting/whitelisting, etc). If there is an infrequent requirement among the bank’s fraud prevention checklist, authorities must be mindful when evaluating the fraud detection components.

Ability to customise or extend

Since a bank’s requirements can be very unique, it is possible that each of the requirements is not supported by default. On the other hand, requirement change is inevitable. Having the flexibility to add/change existing rules or models is a huge advantage in a fraud detection model.

Cost of Integration and deployment

Deployment time and effort can be costly in terms of resources and money. Due to the size, state, and infrastructure of the bank, different banks may prefer different deployment environments and deployment patterns.

Integration with Open Banking can also be costly. Having external components with standard interfaces to connect will always be an advantage. Apart from the integration with the open banking system, the fraud detection component may also need to integrate with external entities such as threat intelligence services.

Compliance to standards

A Fraud detection component that is certified by multiple security authorities is a sign of a better component. Apart from the regular security certifications, financial authorities also provide certifications for applications.

Customer Support

A bank should evaluate the software provider regarding the level of technical support they are willing to provide under the service level agreement.

Integrating fraud detection component with Open Banking

Elements of fraud detection

Fraud detection solutions available today can be quite complex. But we can depict essential elements in an abstract manner as follows( Figure 1). Here, we have considered only the elements that are relevant when we look at these in an Open Banking solution perspective.

The data interface is the element that is directly connected to the open banking solution. Here, it has separated into two sub-elements.
The publishing interface is responsible for receiving datasets for updating the base datasets.
Querying interface is responsible for receiving inputs about an event and providing a response indicating the fraud risk of the event.
The fraud detection engine is the central element of the component, which is responsible for producing outputs. ( Risk-score or boolean value)
The Data processor is responsible for receiving raw data from the publishing interface, processing data, and updating the dataset accordingly.

How to integrate external fraud detection component to an Open Banking solution

The main integration point for fraud detection in Open banking is the end-user authorization flow. Open Banking solutions usually provide the capability to dynamically decide the authentication options based on the event ( Adaptive authentication capabilities). The basic requirement of having an external fraud detection solution is to use its insights during this decision-making point.

Open banking solutions should provide an extension point to communicate with the querying interface of a fraud detection system after successful basic authentication. ( Since it is the first point in the flow where the end-user is correctly identified). The request should be sent with essential information about the event. Fraud detection systems then evaluate the event based on the dataset and produce an output to send back. Open banking solution then decides the authentication option based on this output and other factors as required.

The complexity of output from the fraud detection system can vary from a boolean value, score to a composite payload.

Refer to the pseudocode example below for a scenario where the fraud detection component returns the output from 0 to 1 indicating the risk of the event.

Inputs expected by the fraud detection system can be varied and some of them can be critical for the evaluation process. Extracting them inside this extension point can be challenging in some situations. As an example, if the fraud detection system expects user’s(PSU’s) IP address as an input, there is a possibility that it is not available at this point in authentication flow.

One of the critical things about this integration is the time taken for the fraud detection component to respond. Since this is a real-time process, any delay in connection or evaluation can affect negatively in user experience

Other integration points for fraud detection in open banking are the data publishing points. In order to produce accurate predictions about an event, a considerable amount of data needs to be stored in the dataset of the fraud detection component. Not only machine learning-based systems but also rule-based systems also require historical data to detect fraudulent actions. ( As an example RTS[2] article 15 rule request the sum of recent transactions. ) Data publishing points can vary based on the data requirements of the fraud detection component. Advanced fraud detection systems require more data elements to make accurate predictions. Most commonly, the following points in open banking flows are more likely to have data publishing requirements:

End of successful/unsuccessful authorisation
End of consent initiation ( UK and NextGenPSD2 specifications)
End of Payment submission (UK specification)
End of Account information retrieval (UK, NextGenPSD2 and Australian CDR specifications)
End of Dynamic client registration (UK and Australian CDR specifications

Since there can be multiple integration points for data publishing, it can slow down the whole process. It is better if the open banking solution can provide an asynchronous method to publish data since they are not needed to be published in real-time.

Things to consider when integrating with Fraud detection systems

Integrating with multiple fraud detection components

As mentioned above, different types of fraud detection components provide different advantages. It is possible to integrate with more than one fraud detection component if the open banking extension points are flexible enough. But the tradeoff here is the evaluation time. Multiple fraud detection systems can take more time to process the event. One solution is calling multiple systems in parallel ( If the Open Banking component is flexible to do that).

Size of the dataset

The size of the dataset can have a huge impact on the performance of the fraud detection system. While machine learning-based systems can make more accurate predictions using a large dataset, model building time will be a bottleneck. Rule-based systems also can be slowed down when retrieving from a large dataset if the database operations are not optimized well enough.

On the other hand, having a small dataset will not be much effective for machine learning-based systems. To cover most of the fraudulent scenarios, it is better to have a mix of rule-based and machine learning-based systems.

Conclusion

Detecting and preventing fraudulent actions have become a huge concern for financial institutes due to the prevailing conditions in the world. Different fraud detection systems in the world can be classified according to the techniques they are using. Both financial purpose and general-purpose fraud detection systems are available in the market. Selecting and integrating open banking solutions with a fraud detection system need to be done after a careful evaluation of fraud prevention requirements, capabilities, and extensibility of both systems.

I would love to hear any comments about the above things discussed here. Please feel free to leave a comment or reach out to me if you have any questions or concerns. I am hoping to discuss more interesting topics in the Open Banking domain. So Keep it touch with this blog.

If you are interested in Transaction Risk Analysis, read my article about it on WSO2 Library.