RBKmoney's open-source Antifraud - on the road to the ideal

Hello!

Not so long ago we wrote in our blog about antifraud and its device. In this post, I would like to touch on the criteria of an ideal antifraud, which would simplify life for clients without blocking payments and at the same time protecting their funds, and save time and resources for the payment system. We will talk about how payment systems relate to fraud and what can fly from them towards the company, how it is customary to deal with fraud now and how good it is to do it in the future.

From the payment system

The most obvious evil from the fraud is the loss of funds in fraudulent transfers. But there are also problems that can come to the company itself, in which the value of the chargeback (the procedure for protesting the payment, which is launched by the issuing bank) and the fraud begin to exceed the established norm. And this is already a jackpot and reputational losses, both financial and regulatory. By regulatory, I mean the unlucky opportunity to get on the monitoring of payment systems in relation to each terminal of our company (for each of them the fraud and chargeback levels are separately monitored, and not by the performance of the company as a whole).

There are indicators such as fraud to sale and chargeback to translation ratio. Visa’s fraud to sale limit is 0.9% of the total turnover or $ 75,000). That is, if for 1000 sales you have 90 cases of fraud, this is a very, very loud bell. The plus is that Visa sets such a limit specifically for crossborder transactions, ignoring cases in which all payment participants are in the same region. And the minus is that in our case, to reach such a limit as two bytes to send, we have a lot of cross-border operations.

MasterCard’s rules are more stringent, it considers all operations, it doesn’t matter whether it is a crossborder or domestic (in one region). Fraud is fraud. The sanctions in the case of MC represent the arrival of auditors who will personally closely monitor how the company is dealing with fraud. Of course, the company can refuse the visit of auditors, they say no, I’m sorry, we will not let go. In response, MC representatives shrug their shoulders and simply disconnect the company from their system.

In general, when a fraud to sale or chargeback to translation ratio begins to step over the set limit, the payment system begins to slowly turn its heavy tired look on you, promising little pleasant. You begin to receive notifications, fines arrive, you are given the opportunity (the very case when opportunity = obligation) to fix this state of affairs, you have to fill out a bunch of papers, documentation and remediation plans. A little pleasant and a lot of complex.

And besides all this bureaucratic red tape there are financial losses – the company pays fines for it. The so-called “chargeback window” may open, into which all chargebacks declared in the payment system monitoring system will flaunt. An acquiring bank cannot dispute such transactions, so it transfers responsibility to its payment facilitator (that is, to us). We are trying to fight back from this, collecting funds from our merchants, accounts receivable arise, and this again is stress and time.

In general, if there is a possibility to avoid this, it is necessary to avoid. For this, you need a well-tuned antifraud. With metrics, their detailed accounting, display and monitoring.

Perfect antifraud

First of all, it is necessary to take into account all fraud operations in processing and keep a history of them. Firstly, it will be the very historical data on the basis of which it will be possible to improve the model. Secondly, these data must be labeled so that the final product, that is, a convenient and functional antifraud, can build detailed statistics and display them in a clear and human-readable form.

An interface is necessary here, despite the fact that antifraud in the minds of citizens is most often such a backend thing, which it considers itself something and takes action. In fact, without an interface, a person working with antifraud will be forced to write selects to the database, upload data, and check against various tables. That is to spend a lot of time. Because analyzing data arrays in a tabular format is basically wrong.

And there must also be a full sandbox. Antifraud, on the other hand, works on the rules (on a huge number of rules), and you need to understand how well these or other new rules will work, whether they will conflict with existing ones, or not. It is in the Sandbox that this can be run in. Many antifrauds are based on the standard IF THEN logic, which is also not entirely correct. Already, there are many additional parameters that make it possible to pump through the familiar antifraud rules. For example, you can make adaptive 3DS. You can collect the payer data and store it at your own place, after which complete authentication and receive the payment result from acquirers. Such payments will be divided into successful and unsuccessful, historical data will be collected for each of them, as I wrote above.

De facto, it is possible to create the character and behavior model of a reliable payer, and with the following authorization requests, just check this data and not load the payer with unnecessary checks, as now – require a bunch of confirmation codes or analyzes in a matchbox. Yes, all these checks help a little, but in essence they are quite often redundant. You can collect all these confirmations at the first authentication and keep such a fingerprint. Almost digital signature, it saves a lot of time. To all participants in the process.

About adaptability

Antifraud should work on adaptive functions that will adapt to the nature of each payer, and not just mindlessly run through a list of conditional operators.

In principle, the functionality for processing already existing payment features is quite simple. You feed the input data, on the basis of which you build an algorithm that will make this or that decision in accordance with this data. In addition to this, a scoring model is definitely needed. Because it’s not very right to take and cut off payments according to usual signs for the classic antifraud. Suppose a payer has a card issued by a bank from Latin America. And he is trying to make a payment from the Russian IP. And then the bell immediately – yeah, hold the carder, there he is.

Yes, suspiciously. But immediately write down such a payment in the “left” is not worth it, because the situations can be different. For example, this is an employee on a business trip who pays for something with a business card. And here even 3DS will not save much, because business cards are not always tied to the phone number of the employee with whom she is now with her. And what should I do if a person tries to pay with such a card, the system sends it for additional verification, and an SMS with a code joyfully leaves somewhere on the employee’s corporate phone? Such things interfere with business customers more than they seem.

This is where the historical data comes in handy. We will be able to understand whether such a payment is characteristic in principle or not, whether such a payer was previously, whether we saw this card in the system earlier, maybe there have already been authentications. Or vice versa, it was from this card that we had once evaluated such actions as fraud, and the transaction was marked up in processing so that it would be precisely paid attention to, because the “FROD” marker is noticeable. Further, according to the totality of signs, we can not authorize such a transaction, but first “preauthorize” and send for processing to a specially trained person who will look at everything with pens and make a decision.

In addition, such operations can be batched, collecting in a single group, which then massively send to the hold or for manual verification. Merchants, who have the opportunity to enrich our data with the help of their systems, can also play their role.

Is such an ideal achievable in principle?

Like everything ideal, most likely, the construction of such an antifraud will become a process, rather than an ultimate goal. Because the appetite comes with eating, and as soon as we finish one thing, we will immediately figure out how to pump it to an even more useful level.

We have already begun moving in this direction, and now I can say that the pieces described in this post will require a minimum of a year, this is all quite large-scale.

RBKmoney Public Contributions

I remind you that RBKmoney Fraudbusters is one of the first in the world (or the first?) Products of this level, which is posted in public access in the form of open source. You can use it freely, under the Apache 2.0 license.

From the moment of the last post we dopied the readme, now it is easier to assemble it. Microservices are located in the following repositories: