An article about the creation of an in-house solution for detecting and preventing fraudulent transactions carried out in Internet banking of one small but very proud bank in Tatarstan. From the article you will learn about why and who needs antifraud, why internal development turned out to be cheaper than buying a ready-made solution, and what a couple of lines of code lead to before the new year.
A few words about myself - an Information Security specialist in an IT company, who accidentally (or maybe not) turned out to be a Product Owner in the team developing an Anti-fraud solution. The IT company itself is developing Internet Banking software.
For me, the story began with a request for help with the formation of functional requirements and the development of integration with the existing remote banking service (hereinafter referred to as RBS). And away we go...
During the study, it turned out:
When analyzing the topic of antifraud, the articles by codezombie helped me a lot . Who 4 years ago wrote about antifraud used in e-commerce, about his experience. In my case, the specifics were different, but the information was very valuable.
Based on these conditions, it was decided to give the project to a development team involved in integration and solving problems of other teams, since this team had the most experienced and cool developers. Unfortunately, in a team of 3 developers, over time there were only two left. I was involved in the backlog, forming requirements, documentation and organizing meetings (we work according to Scrum, but how else). So it turned out that the team had 4 hands writing the code, and 3 heads solving problems.
The main goal of the development team was to create a mechanism for identifying new customer devices and stopping suspicious financial transactions. Why new devices? Analytics showed that most often people access RBS via a smartphone in order to receive confirmation codes through PUSH notifications rather than SMS messages.
In addition, FinCERT began sending lists of details of those involved in fraudulent transactions, that is, they had to be blocked.
In general, there was nothing wrong with integration. The SLA set a limit of 3 seconds for responding to requests. Currently, the average response time is 0.3 seconds. The microservice architecture made it possible to easily integrate with the existing solution by adding three lines for sending a request to the antifraud microservice. The verification occurs until confirmation by SMS or PUSH notification.
At the first stage of development, the goal was set to check two important conditions. Firstly, the device from which the transaction is attempted is new to the client or is trusted. Secondly, whether the props are on the blacklists. These two conditions are enough to block 70% of incidents that arise; for the rest, more information is required, for example, whether the login was by login/password, or by card number, from which country the RBS was logged in, etc.
To apply the check, not much data is needed - a unique client identifier, the identifier of his device (created on the clients themselves - mobile applications and JS libraries on the website), the transfer amount, transfer details. Based on this data, a decision is made to allow or block the operation. Once the entire system was working properly in production operation, the team moved on to the next stage. White lists and automatic downloading of lists from FinCERT have appeared. At the moment, sending incident reports to FinCERT itself via API is being debugged (this is a separate long story).
At the moment, the Antifraud system implements verification of the following payments: P2P payments by card number, replenishment of a phone number, transfer by details, replenishment of electronic wallets. Fraudsters often transfer 2000-3000 rubles to phone numbers or wallets. In the case of cards, the amounts are usually close to the sum of all the client’s available funds. In addition to checks, a page was created for Antifraud operators; the system cannot be made completely autonomous - a person is needed to monitor events, investigate incidents, block/unblock, and create reports on the system. It's difficult to make a website when there are two backend developers on the team. However, it’s never too late to learn (it’s great to have T-shaped specialists on your team!).
At the very beginning, during planning and analysis, there were a lot of thoughts about introducing machine learning, dynamic rules, and antiviruses inside the RBS client. However, judging by the experience of vendors and other banks, more than half of the cases can be closed using static rules. All other methods require more resources and are not as effective. That is why a team of two developers and one analyst (which is what I consider myself to be) is enough to implement the minimum protection measures and regulatory requirements.
It was in the evening, on New Year's Eve. The system implemented checking not only mobile devices, but also client browsers. Using EverCookie . The developers included the feature, but did not test it, since the library was not implemented at the front. Only on the last working day of 2019, the front-end programmer decided to push the branch into production (well, don’t leave it for next year!). Because of this, during the New Year's weekend, Antifraud operators were faced with a lot of work in the form of false positives of the system. We can’t say that this was critical, however, I feel a little sorry for the operators... after all, there was 5 times more work than there was before the changes were made.
If you are interested, I will write more about software solutions, market analytics and how to implement Scrum in a team of 3 people.
A few words about myself - an Information Security specialist in an IT company, who accidentally (or maybe not) turned out to be a Product Owner in the team developing an Anti-fraud solution. The IT company itself is developing Internet Banking software.
Where did it all start?
For the bank itself, it all started with the fact that the Central Bank of the Russian Federation posted a draft of amendments and additions to Regulation No. 382-P, which stated that the bank must prevent funds transfers without the client’s consent. In addition, according to the instructions of the Bank of Russia No. 2831-U, the bank is obliged to report to the Central Bank about all incidents, including the actions of fraudsters.For me, the story began with a request for help with the formation of functional requirements and the development of integration with the existing remote banking service (hereinafter referred to as RBS). And away we go...
Input data
Before development, it is necessary to research the topic, study ready-made developmentsrake, view the market.During the study, it turned out:
- the most common ways to steal money from remote banking services are social engineering and phishing
- using social engineering, they either hack the remote banking system or force the client to voluntarily transfer money
- the amounts stolen by fraudsters per year are not so large, the bank spends about 10% of this amount on investigation and compensation
- the cost of a ready-made antifraud solution exceeds the amount involved in the fraud by 5-10 times (we haven’t talked about the cost of integration yet...)
- it is necessary to report to FinCERT, absolutely
- we can highlight a couple of very frequent and important cases
When analyzing the topic of antifraud, the articles by codezombie helped me a lot . Who 4 years ago wrote about antifraud used in e-commerce, about his experience. In my case, the specifics were different, but the information was very valuable.
Based on these conditions, it was decided to give the project to a development team involved in integration and solving problems of other teams, since this team had the most experienced and cool developers. Unfortunately, in a team of 3 developers, over time there were only two left. I was involved in the backlog, forming requirements, documentation and organizing meetings (we work according to Scrum, but how else). So it turned out that the team had 4 hands writing the code, and 3 heads solving problems.
Cases we struggled with
Don’t think that the bank hasn’t fought beforewith evilwith scammers. We fought with available means. However, there has been a tendency that the number of incidents related to hacking of remote banking services has begun to grow. A popular scheme in 2018 was a scam in the vastness of Avito - fraudulent sellers, using social engineering methods, found out the card number, and in the dialogue they learned an SMS to log into the remote banking system. Thus, we received full access to the Internet banking of a specific client. In 2019, scammers began calling clients on behalf of the bank’s security services, threatening to lose all their money, asking for their login details, or convincing them to transfer all their money to a “safe account.”The main goal of the development team was to create a mechanism for identifying new customer devices and stopping suspicious financial transactions. Why new devices? Analytics showed that most often people access RBS via a smartphone in order to receive confirmation codes through PUSH notifications rather than SMS messages.
In addition, FinCERT began sending lists of details of those involved in fraudulent transactions, that is, they had to be blocked.
Development and integration in Antifraud
In general, there was nothing wrong with integration. The SLA set a limit of 3 seconds for responding to requests. Currently, the average response time is 0.3 seconds. The microservice architecture made it possible to easily integrate with the existing solution by adding three lines for sending a request to the antifraud microservice. The verification occurs until confirmation by SMS or PUSH notification.
At the first stage of development, the goal was set to check two important conditions. Firstly, the device from which the transaction is attempted is new to the client or is trusted. Secondly, whether the props are on the blacklists. These two conditions are enough to block 70% of incidents that arise; for the rest, more information is required, for example, whether the login was by login/password, or by card number, from which country the RBS was logged in, etc.
To apply the check, not much data is needed - a unique client identifier, the identifier of his device (created on the clients themselves - mobile applications and JS libraries on the website), the transfer amount, transfer details. Based on this data, a decision is made to allow or block the operation. Once the entire system was working properly in production operation, the team moved on to the next stage. White lists and automatic downloading of lists from FinCERT have appeared. At the moment, sending incident reports to FinCERT itself via API is being debugged (this is a separate long story).
At the moment, the Antifraud system implements verification of the following payments: P2P payments by card number, replenishment of a phone number, transfer by details, replenishment of electronic wallets. Fraudsters often transfer 2000-3000 rubles to phone numbers or wallets. In the case of cards, the amounts are usually close to the sum of all the client’s available funds. In addition to checks, a page was created for Antifraud operators; the system cannot be made completely autonomous - a person is needed to monitor events, investigate incidents, block/unblock, and create reports on the system. It's difficult to make a website when there are two backend developers on the team. However, it’s never too late to learn (it’s great to have T-shaped specialists on your team!).
At the very beginning, during planning and analysis, there were a lot of thoughts about introducing machine learning, dynamic rules, and antiviruses inside the RBS client. However, judging by the experience of vendors and other banks, more than half of the cases can be closed using static rules. All other methods require more resources and are not as effective. That is why a team of two developers and one analyst (which is what I consider myself to be) is enough to implement the minimum protection measures and regulatory requirements.
Pain
The main rule when developing Antifraud is to do no harm. Any changes and new methods should be tested first in a test, then in a battle in monitoring mode to ensure that they are working properly and there are no problems. In the worst case scenario, mistakes can lead to financial losses and loss of customer loyalty. In our case, the error led to suffering for the operators investigating and managing the Antifraud system.It was in the evening, on New Year's Eve. The system implemented checking not only mobile devices, but also client browsers. Using EverCookie . The developers included the feature, but did not test it, since the library was not implemented at the front. Only on the last working day of 2019, the front-end programmer decided to push the branch into production (well, don’t leave it for next year!). Because of this, during the New Year's weekend, Antifraud operators were faced with a lot of work in the form of false positives of the system. We can’t say that this was critical, however, I feel a little sorry for the operators... after all, there was 5 times more work than there was before the changes were made.
Results
In less than a year, a very small team implemented an Antifraud system for Internet Banking. Unfortunately, there is still a lot of work to do. After talking with representatives of banks and vendors at the Antifraud Russia forum, it became clear that scammers are coming up with new ways every year, and there is no way to relax in this area.If you are interested, I will write more about software solutions, market analytics and how to implement Scrum in a team of 3 people.
