Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 913
- Points
- 113
Hello!
Not long ago we wrote on our blog about antifraud and its structure. In this post, I would like to touch on the criteria for an ideal antifraud that would make life easier for clients, without blocking payments and at the same time protecting their funds, and saving the payment system time and resources. We will talk about how payment systems treat fraud and what can come from them towards the company, how it is common to fight fraud now and how well it can be done in the future.
There are such indicators as fraud to sale and chargeback to translation ratio. Visa's fraud to sale limit is 0.9% of total turnover or $75,000). That is, if you have 90 cases of fraud per 1000 sales, this is a very, very loud bell. The advantage is that Visa sets such a limit specifically for cross-border transactions, ignoring cases in which all payment participants are located in the same region. The downside is that in our case, to reach the limit of sending two bytes, we have a lot of cross-border operations.
MasterCard has stricter rules; it counts all transactions; it makes no difference to it whether it is a cross-border transaction or domestic (in one region). Fraud is fraud. Sanctions in the case of MC represent the arrival of auditors who will personally closely monitor how the company is fighting fraud. Of course, the company can refuse the auditors’ visit, saying, no, sorry, we won’t let you in. In response, MC representatives will shrug their shoulders and simply disconnect the company from their system.
In general, when the fraud to sale or chargeback to translation ratio begins to exceed the established limit, the payment system slowly begins to turn its heavy, tired gaze on you, promising little pleasant things. You start receiving notifications, fines arrive, you are given the opportunity (that very case when opportunity = obligation) to fix this state of affairs, you have to fill out a bunch of papers, documentation and remediation plans. Little pleasant and much difficult.
And in addition to all this official red tape, there are also financial losses - the company pays fines for this. The so-called “chargeback window” may open, into which all the chargebacks declared in the payment system monitoring system begin to quickly arrive. The acquiring bank cannot challenge such transactions, so it shifts responsibility to its payment facilitator (that is, to us). We are trying to fight off this by collecting funds from our merchants, accounts receivable arise, and this again is stressful and time-consuming.
In general, if you can avoid it, you should avoid it. This is why you need a well-functioning antifraud. With metrics, their detailed recording, display and monitoring.
An interface is necessary here, despite the fact that antifraud in the minds of citizens is most often a backend thing that thinks it is something and takes action. In fact, without an interface, a person working with antifraud will be forced to write selects into the database, upload data, and consult various tables. That means wasting a lot of time. Because analyzing data arrays in tabular format is fundamentally wrong.
There should also be a full-fledged sandbox. Antifraud works on rules (on a huge number of rules), and you need to understand how correctly certain new rules will work, whether they will conflict with existing ones or not. It is in the Sandbox that this can be tested. Many antifraud systems are based on standard IF THEN logic, which is also not entirely correct. Already now there are many additional parameters that allow you to significantly upgrade the usual anti-fraud rules. For example, you can make an adaptive 3DS. You can collect the payer’s data and store it, after which you can carry out full authentication and receive the payment result from the acquirers. Such payments will be divided into successful and unsuccessful, and historical data will be collected for each of them, as I already wrote about above.
De facto, it becomes possible to create the character and behavior model of a reliable payer, and during the next authorization requests, simply check with this data and not burden the payer with unnecessary checks, as now - require a bunch of confirmation codes or tests in a matchbox. Yes, all these checks help a little, but in essence they are quite often redundant. You can collect all these confirmations during the first authentication and save this fingerprint. Almost a digital signature, it saves a lot of time. To all participants in the process.
In principle, the functionality itself for processing existing payment characteristics is quite simple. You feed input data, based on it 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 immediately taking and cutting off payments based on the usual signs for a classic antifraud is also not very correct. Let's say the payer has a card issued by a bank in Latin America. And he is trying to make a payment from a Russian IP. And then the bell immediately rang - yeah, hold the carder, there he is.
Yes, it's suspicious. But you shouldn’t immediately record such a payment in the “left” section, because situations can be different. For example, this is an employee on a business trip who pays for something with a business card. And even a 3DS won’t help much here, because business cards are not always linked to the phone number of the employee who currently has it with him. And what should you do if a person tries to pay with such a card, the system sends him for additional verification, and the SMS with the code happily goes somewhere to the employee’s corporate phone? This kind of thing bothers business clients more than it seems.
This is where historical data comes in handy. We will be able to understand whether such a payment is in principle typical or not, whether there was such a payer before, whether we saw this card in the system before, maybe there have already been authentications. Or, on the contrary, it was from this card that we once assessed such actions as fraud, and the transaction was marked in processing so that they would definitely pay attention to it, because the “FROD” marker is noticeable. Further, based on a combination of signs, we may not authorize such a transaction, but first “pre-authorize” it and send it to a specially trained person for processing, who will look at everything manually and make a decision.
In addition, such operations can be batched, collected into a single group, which is then sent en masse to hold or for manual verification. Merchants who have the opportunity to further enrich our data using their systems can also play a role.
We have already started moving in this direction, and now I can say that the things described in this post will take at least a year, this is all quite large-scale.
Since the last post we have completed the readme, now it is easier to assemble. Microservices are located in the following repositories:
(c) For any questions on this topic, you can write to me in telegram https://t.me/anton_lva
Not long ago we wrote on our blog about antifraud and its structure. In this post, I would like to touch on the criteria for an ideal antifraud that would make life easier for clients, without blocking payments and at the same time protecting their funds, and saving the payment system time and resources. We will talk about how payment systems treat fraud and what can come from them towards the company, how it is common to fight fraud now and how well it can be done in the future.
From the payment system side
The most obvious evil from fraud is the loss of funds through fraudulent transfers. But there are also problems that can arise from the company itself, in which the number of chargebacks (bw - a procedure for challenging a payment, which is launched by the issuing bank) and fraud begin to exceed the established norm. And this immediately leads to reputational losses, both financial and regulatory. By regulatory, I mean the non-illusory opportunity to get monitored by payment systems in relation to each terminal of our company (the level of fraud and chargeback is monitored separately for each of them, and not based on the indicators of the company as a whole).There are such indicators as fraud to sale and chargeback to translation ratio. Visa's fraud to sale limit is 0.9% of total turnover or $75,000). That is, if you have 90 cases of fraud per 1000 sales, this is a very, very loud bell. The advantage is that Visa sets such a limit specifically for cross-border transactions, ignoring cases in which all payment participants are located in the same region. The downside is that in our case, to reach the limit of sending two bytes, we have a lot of cross-border operations.
MasterCard has stricter rules; it counts all transactions; it makes no difference to it whether it is a cross-border transaction or domestic (in one region). Fraud is fraud. Sanctions in the case of MC represent the arrival of auditors who will personally closely monitor how the company is fighting fraud. Of course, the company can refuse the auditors’ visit, saying, no, sorry, we won’t let you in. In response, MC representatives will shrug their shoulders and simply disconnect the company from their system.
In general, when the fraud to sale or chargeback to translation ratio begins to exceed the established limit, the payment system slowly begins to turn its heavy, tired gaze on you, promising little pleasant things. You start receiving notifications, fines arrive, you are given the opportunity (that very case when opportunity = obligation) to fix this state of affairs, you have to fill out a bunch of papers, documentation and remediation plans. Little pleasant and much difficult.
And in addition to all this official red tape, there are also financial losses - the company pays fines for this. The so-called “chargeback window” may open, into which all the chargebacks declared in the payment system monitoring system begin to quickly arrive. The acquiring bank cannot challenge such transactions, so it shifts responsibility to its payment facilitator (that is, to us). We are trying to fight off this by collecting funds from our merchants, accounts receivable arise, and this again is stressful and time-consuming.
In general, if you can avoid it, you should avoid it. This is why you need a well-functioning antifraud. With metrics, their detailed recording, display and monitoring.
Ideal antifraud
First of all, it is necessary to take into account all fraud operations during processing and store a history of them. Firstly, this will be the same historical data on the basis of which it will be possible to improve the model. Secondly, this 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 visual and human-readable form.An interface is necessary here, despite the fact that antifraud in the minds of citizens is most often a backend thing that thinks it is something and takes action. In fact, without an interface, a person working with antifraud will be forced to write selects into the database, upload data, and consult various tables. That means wasting a lot of time. Because analyzing data arrays in tabular format is fundamentally wrong.
There should also be a full-fledged sandbox. Antifraud works on rules (on a huge number of rules), and you need to understand how correctly certain new rules will work, whether they will conflict with existing ones or not. It is in the Sandbox that this can be tested. Many antifraud systems are based on standard IF THEN logic, which is also not entirely correct. Already now there are many additional parameters that allow you to significantly upgrade the usual anti-fraud rules. For example, you can make an adaptive 3DS. You can collect the payer’s data and store it, after which you can carry out full authentication and receive the payment result from the acquirers. Such payments will be divided into successful and unsuccessful, and historical data will be collected for each of them, as I already wrote about above.
De facto, it becomes possible to create the character and behavior model of a reliable payer, and during the next authorization requests, simply check with this data and not burden the payer with unnecessary checks, as now - require a bunch of confirmation codes or tests in a matchbox. Yes, all these checks help a little, but in essence they are quite often redundant. You can collect all these confirmations during the first authentication and save this fingerprint. Almost a 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 character of each payer, and not just mindlessly run through a list of conditional operators.In principle, the functionality itself for processing existing payment characteristics is quite simple. You feed input data, based on it 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 immediately taking and cutting off payments based on the usual signs for a classic antifraud is also not very correct. Let's say the payer has a card issued by a bank in Latin America. And he is trying to make a payment from a Russian IP. And then the bell immediately rang - yeah, hold the carder, there he is.
Yes, it's suspicious. But you shouldn’t immediately record such a payment in the “left” section, because situations can be different. For example, this is an employee on a business trip who pays for something with a business card. And even a 3DS won’t help much here, because business cards are not always linked to the phone number of the employee who currently has it with him. And what should you do if a person tries to pay with such a card, the system sends him for additional verification, and the SMS with the code happily goes somewhere to the employee’s corporate phone? This kind of thing bothers business clients more than it seems.
This is where historical data comes in handy. We will be able to understand whether such a payment is in principle typical or not, whether there was such a payer before, whether we saw this card in the system before, maybe there have already been authentications. Or, on the contrary, it was from this card that we once assessed such actions as fraud, and the transaction was marked in processing so that they would definitely pay attention to it, because the “FROD” marker is noticeable. Further, based on a combination of signs, we may not authorize such a transaction, but first “pre-authorize” it and send it to a specially trained person for processing, who will look at everything manually and make a decision.
In addition, such operations can be batched, collected into a single group, which is then sent en masse to hold or for manual verification. Merchants who have the opportunity to further enrich our data using their systems can also play a role.
Is such an ideal achievable in principle?
Like everything ideal, most likely, building such an antifraud system will become a process rather than an end goal. Because appetite comes while eating, and as soon as we finish one thing, we immediately figure out how to pump it up to an even more useful level.We have already started moving in this direction, and now I can say that the things described in this post will take at least a year, this is all quite large-scale.
RBKmoney Public Contributions
Let me remind you that RBKmoney Fraudbusters is one of the first (or even the first?) products of this level in the world, made publicly available as open source. You can use it freely under the Apache 2.0 license.Since the last post we have completed the readme, now it is easier to assemble. Microservices are located in the following repositories:
- https://github.com/rbkmoney/fraudbusters - the antifraud machine itself
- https://github.com/rbkmoney/fraudo - DSL rules
- https://github.com/rbkmoney/fraudbusters-management - management interface API
(c) For any questions on this topic, you can write to me in telegram https://t.me/anton_lva
