Nowadays, with the ever-evolving financial crimes, there is an increasing demand on the complexity of the tools available to fight this battle against fraud. Thus, the market offers a variety of fraud detection tools. From blocking transactions based on defined rules to complex data analyzes that result in scores representing the risk of a given transaction. The objective is simple: to provide the client a fast and accurate solution that reduces client losses and customer friction. In this article I’ll go through the improvements I applied in the Switch internal fraud prevention tool.

The Challenge

Switch current solution offers a rule-based system to detect fraudulent transactions. The client can define its own set of rules and for each transaction, the Risk application will search for matches with the existing rules based on metadata in the transaction. The actions associated with a rule can be ACCEPT, BLOCK, REVIEW or 3DS ENABLE.

One of the main problems of the current Risk solution was the 100% dependency of the merchant input. Even though some merchants like the possibility of controlling the risk decision rules, many might not want to spend time understanding how these work. Furthermore, these custom rules alone have worse performance than systems that also include advanced data analysis supported in machine learning concepts.

The Solution

The solution encountered consists of a new module capable of supporting multiple security vendors in the already existing workflow without compromising the merchant's ability to add custom rules. Thus, the merchant will be able to add several security vendors and make rules with their resulting parameters. The flow will be the following: when the transaction enters the Risk Application, the chosen risk providers are called and their responses data saved. After this step, the transaction metadata (including the provider’s responses if there are any) goes through the rule engine analysis which will define the final action decisions.

Code Implementation

After understanding the solution concept and the context of its appearance I will go a bit further on the code implementation itself.

Endpoints

In order to configure the merchant account to contain the new features applied to the transaction process, there was a need to represent one more model inside the risk application: a risk channel. The channel is an association of a merchant and a risk provider that can be active or not. Simply put, this model saves all the metadata needed to call a provider with the specific merchant as well as the identification of the risk provider and merchant in question. To interact with this new model, several endpoints were added to the risk application:

Thus, to configure a new provider, a new channel is added to the list of channels by the Switch team. After this, the merchant updates the channel with its authentication metadata so that the merchant can start successfully using the risk provider.

Provider Calls

After completing the new configurations, the next step was the integration of the providers. For this, I used two risk providers that were already available on the Switch product even though they were not implemented in the normal Risk flow.

The main goal of the solution developed was to have a structure where integrations with new providers would happen smoothly and in a short amount of time. This way, I developed an interface that needs to be implemented by all the providers to abstract the behaviors inside each provider and enforce a common pattern to implement new risk providers.

Rule Engine

The changes applied to the rule engine were essential to complete the provider integration since it’s responsible to determine the actions to apply to the transaction based on the data accumulated in the risk flow process. This way, the last step for the risk providers integration was adding parameters coming from the risk providers to the rule engine. For example, the obtained parameters for a risk provider could be:

Thus, it became possible to create new rules associated with the risk provider’s results:

Conclusion

Personally, this experience was a success because I came up with a complete concept and a simple solution for the problem at hand. I believe my implementation was a good starting point for this new feature and will enable new enhancements to the fraud management tool in the Switch platform.

Risk Rule Engine