Anti-fraud system architecture
An anti-fraud system is not a monolithic application, but a set of interconnected modules, each of which performs a specific function in the chain of detecting and preventing fraud. To process thousands of transactions per second and make decisions in milliseconds, the architecture must be thought through down to the smallest detail.
The classic design includes four key components: the data collection and enrichment module, the analytics engine, the decision engine and the data storage. Let’s take a closer look at each of them.
Data collection and enrichment module
At the entry point of the anti-fraud system there is a module that aggregates information from many sources and prepares it for analysis. The raw transaction data — amount, currency, sender and recipient details — makes up only a small part of the overall picture.
| Category | Description |
|---|---|
| Data is collected through several channels: | The first channel is transactional systems: processing centers, payment gateways, remote banking systems. The second is client applications that transmit information about the device, browser, geolocation and user behavior. The third is external sources: blacklists, sanctions databases, services for verifying IP addresses and phone numbers. |
| The key task of this module is data enrichment: | The system supplements each transaction with context: it determines the MCC code (the merchant category), matches the IP address to a geographic region, checks the card number against lists of compromised data. If a customer makes a purchase in an unfamiliar country an hour after an operation in their home city, this is “impossible travel”, one of the clear markers of fraud. |
| A separate area is building the device fingerprint: | The module collects browser characteristics, screen resolution, installed fonts and plugins, time zone. Even if an attacker changes their IP address and creates a new account, the system recognizes the familiar device. For mobile applications, SDK libraries are used that collect similar parameters without affecting performance. |
Behavioral analytics complements the static data. The module records typing speed, cursor movement trajectory, the time between clicks. Automated attacks differ from the actions of a living person: bots move the mouse along straight lines and fill in forms at an inhuman speed.
Analytics engine
The collected data feeds into the analytics engine — the intelligent core of the system. This is where the transaction risk is assessed based on rules, statistical models and machine learning algorithms.
| Category | Description |
|---|---|
| Rules (rules engine) — the first line of defense: | They describe specific scenarios: “block an operation over 100,000 rubles from a new device at night” or “send a transfer to a country on the elevated-risk list for review”. Rules are easy to configure and update, but they are unable to detect complex patterns. |
| Statistical models work at the second level: | The system builds a profile of each customer: typical operation amounts, activity times, purchase geography, spending categories. Any deviation from the profile raises the risk score. If a person usually spends 5,000 rubles in grocery stores, but today transfers 200,000 rubles to an unfamiliar card, this is an anomaly. |
| Machine learning takes the analysis to a new level: | Algorithms (gradient boosting, neural networks) are trained on historical data and reveal non-obvious relationships that an expert would not notice. Modern systems use models based on CatBoost, XGBoost or PyTorch. This raises the problem of class imbalance: for every million legitimate transactions there are only a few fraudulent ones. To solve it, methods of sample balancing, filtering and additional data labeling by experts are applied. |
The engine’s output is a numeric risk score from 0 to 100 (or another scale). The higher the score, the greater the probability of fraud. The score is formed as a weighted sum of individual factors: each attribute — a new device, an unusual amount, a suspicious IP — adds a certain number of points.
Decision engine
Based on the risk score, the system must make a concrete decision: allow the operation, decline it or send it for additional review. This is handled by the decision engine.
| Category | Description |
|---|---|
| The typical logic works with three options: | At low risk (roughly, a score below 20) the transaction goes through automatically — the customer does not notice the system at work. At medium risk (a score of 20–50) “soft” measures are applied: a request for an SMS code, a push notification asking to confirm the operation, additional authentication. At high risk (a score above 50) the operation is blocked or passed to a fraud analyst for manual review. |
| The thresholds are not a constant: | They are configured to fit the specifics of the business and are adjusted regularly. A bank can afford strict limits: an extra confirmation request is annoying but does not scare off the customer. An online store risks losing an impulsive buyer, so its thresholds are usually softer. |
| The module integrates with external systems: | It sends SMS through carrier gateways, initiates a call from a voice bot, passes the case to a Case Management system for investigation. If a fraud analyst manually flags a transaction as a false positive, this information is fed back into the analytics engine to train the models. |
An important principle is the graduated response. A good system does not work on the binary logic of “block or let through”. It adapts the level of protection to the level of threat: the higher the risk, the tighter the check. This makes it possible to strike a balance between security and convenience for the customer.
Data and log storage
All operations, decisions, rule triggers and model results are recorded in the data storage. This component solves several tasks: it enables the system to work in real time, accumulates history for training the models, and stores logs for investigations and audits.
For real-time access, in-memory databases are used. The response time to a query is measured in milliseconds — otherwise the customer would wait too long at the checkout. In large systems the load reaches hundreds of thousands of requests per second, and classic relational DBMS cannot cope with such volumes. That is why specialized solutions are used: in-memory DBMS, columnar stores for analytical queries, distributed systems with horizontal scaling.
The historical storage (Data Warehouse or Data Lake) accumulates data over months and years. ML models are trained on these arrays, hypotheses are tested, and fraud trends are analyzed. Here speed is not critical — completeness and integrity of the data matter more.
A separate layer is event logging. Every action of the system is documented: which rule fired, what score was assigned, what decision was made, which analyst reviewed the case. Logs are needed to investigate incidents, respond to customer complaints and meet regulatory requirements. In the financial sector, the retention period for logs is set by law — usually no less than five years.
The storage architecture must ensure high availability and fault tolerance. Losing data during a fraud investigation is unacceptable. That is why replication, backups and geographically distributed clusters are used.
A well-designed architecture allows the anti-fraud system to process enormous data streams, instantly detect suspicious activity and at the same time avoid creating inconvenience for legitimate users. Each module performs its own function, and their coordinated work ensures reliable protection against fraud in real time.
Real-time fraud monitoring
The speed of fraud detection directly determines the size of the losses. A transaction goes through in fractions of a second, and if the system analyzes the data after the fact, the money has already been transferred to the attackers’ accounts. This is exactly why modern anti-fraud solutions are built on the principle of real-time detection: each operation is assessed at the moment it is made, before the funds are actually debited.
Real-time fraud monitoring is the process of continuously analyzing an incoming stream of events in order to instantly detect suspicious activity. Unlike batch processing, where data is accumulated and analyzed with a delay of hours or days, a streaming architecture provides a detection latency on the order of tens of milliseconds. At such speed the system has time to block a fraudulent transaction before it is completed.
Event stream processing
At the core of real-time anti-fraud lies an event-driven architecture. Every user action — logging into the application, entering card details, confirming a payment — generates an event that instantly enters the processing stream. The system does not wait for a batch of data to accumulate: it analyzes each event as it arrives.
The key components of stream processing include the message broker, the stream processor and the state store. The message broker receives events from many sources and guarantees their delivery without loss even under peak loads. The stream processor applies rules and models to each event, querying the state store for historical context — the user’s previous transactions, their devices, typical behavior patterns.
The system’s ability to process time windows is critically important. Anti-fraud analyzes not only the current transaction in isolation, but also its connection to preceding events. The system tracks sliding time windows: how many transactions were made in the last five minutes, hour, day; how amounts and geographies changed; whether these details were used before. This approach makes it possible to detect complex fraud schemes that cannot be spotted by analyzing a single operation.
To process millions of events per second, horizontal scaling is used: the data stream is split by keys (for example, by user ID), and each segment is processed in parallel. At the same time, all events of a single user are guaranteed to land on the same processor, which ensures the correct calculation of aggregates and profiles.
Transaction risk score calculation
Each operation receives a numeric risk assessment — a score reflecting the probability of fraud. Calculating the score happens in several stages: first deterministic rules are applied, then machine learning models, and finally the results are combined into a final assessment.
Deterministic rules trigger on obvious anomalies. A transaction from a country that does not match the card’s country of issue receives a certain number of points. An amount exceeding the typical threshold for a given user adds more points. Using a new device, connecting through an anonymizing service, a mismatch between the browser’s time zone and the IP address — each factor makes its contribution. Rules are set by experts based on accumulated experience and quickly adapt to new attack schemes.
Machine learning models reveal patterns that are hard to describe with rules. The algorithms analyze hundreds of attributes: behavioral patterns, data entry speed, cursor movement trajectory, the sequence of actions in the application. A model trained on historical data recognizes deviations from the normal behavior of a specific user and the typical behavior of their segment.
Modern systems use model ensembles. One model specializes in detecting credential theft, another in detecting compromised cards, a third in recognizing bots. Their results are aggregated with weighting coefficients, which improves the accuracy of the final assessment and reduces the probability of false positives.
An important aspect is data enrichment at the moment of calculation. The system requests additional information from external sources: the reputation of the IP address, the status of the phone number in databases of compromised details, the results of the device check. All requests are executed in parallel and fit within a common time budget — usually no more than 100–200 milliseconds for a full assessment cycle.
Automated response and escalation
Based on the calculated score, the system makes a decision about the fate of the transaction. A graduated set of response measures is applied: from a transparent pass-through to a full block with a notification to the security team.
Low-risk operations go through without additional checks. The user does not notice the anti-fraud at work — the transaction completes in the standard time. A medium level of risk triggers step-up authentication mechanisms: the system requests confirmation via a push notification, an SMS code or biometrics. This creates an additional barrier for the fraudster but has minimal impact on the legitimate user.
High risk leads to a temporary block of the operation and its escalation to manual review. The fraud analyst receives the full context: transaction details, user history, the rules that fired and the models’ predictions. Based on this information, they make the final decision — approve, decline or contact the customer for verification.
A critical level of risk means an immediate block with no possibility of automatic approval. Such cases include attempts to make transactions with known-compromised details, operations with signs of automated attacks, or transfers to accounts on sanctions lists.
The automated response system takes the business context into account. For an online store with a low average order value, the blocking threshold can be lower than for a premium service where customers expect a minimum of obstacles. Thresholds are configured separately for each user segment, service channel and operation type.
Feedback closes the loop of the system’s operation. Every decision — confirmed fraud, a false positive, a successful transaction — is recorded and used to retrain the models. This ensures the anti-fraud continuously adapts to the changing tactics of attackers and reduces the share of erroneous blocks over time.
An anti-fraud system works effectively when the architecture links data collection and enrichment, analysis and decision-making into a single loop that assesses risk before the operation is completed. The coordinated work of the modules makes it possible not only to detect anomalies in the event stream, but also to capture the full context of each decision, preserving transparency for investigations, audits and model development.
Real-time fraud monitoring relies on stream processing, risk score calculation and a graduated response — from an invisible pass-through to additional authentication and escalation to manual review. When the system closes the feedback loop and uses accumulated decisions and logs to retrain, it adapts faster to changing fraud scenarios and helps protect operations without unnecessary obstacles for the customer.
