How fraudsters prepare their attack infrastructure

In this blog post we will look at how fraudsters prepare infrastructure for a fraud attack and what you can do today to be better prepared. For professional scammers, not opportunists, defrauding a financial institution is a highly sophisticated operation. As the defences of companies become more sophisticated, so do the fraudsters.

What fraudsters are trying to manufacture

The goal is not just to get one transaction through. The goal is to make an account, a payment method, or a set of identities look ordinary enough that the first serious fraud attempt is not treated as the first suspicious event. Fraudsters are trying to manufacture age, activity, verification, and distance from known bad behaviour.

Normally, preparing attack infrastructure includes, but is not limited to:

1. buying stolen card details (aka fullz)
2. buying or renting accounts with the targeted companies (e.g. TapTapSend, or WorldRemit)
3. potentially buying stolen identities for account verification
4. making several small transactions

How trust is built before the attack

While buying stolen card details is done mostly for payment facilitation, the other steps are about building up trust with the companies. Any fraud detection system at any payment company looks at how long the user has been known to the company - one way or another. There are multiple angles this can be assessed from. The first and most obvious one is how long the user has been on the books.

There is often increased attention and separate checks for new accounts or accounts making their first ever transaction. That means buying older accounts is preferable to opening new ones, which is why there is a large market for older accounts with payment companies. Not just that, but people often voluntarily advertise those accounts for sale/rent.

Buying stolen identities can be an important step in preparing fraud infrastructure. This is mostly done to open new accounts and immediately verify them with a stolen ID. In many markets ID verification is not mandatory and is often considered a "safety" signal by the companies. However, since the competition between remittance companies is fierce, they tend to lower barriers to transactions and ID verification is introduced only in the markets with high fraud rates and/or strict regulations.

With any sort of account, especially with new ones, fraudsters tend to make a few small transactions. This works because they know that payment companies are overly suspicious of dormant accounts that suddenly start transacting large amounts. Small transactions are cheap probes. They test whether the account, card, recipient, device, and behavioural pattern can pass through controls. They also create recent benign-looking history, which can weaken simple dormancy and velocity rules if those rules are not designed carefully.

Small transactions like this reset companies' internal aggregation features (amount sent last 3 days, number of transactions last X days, etc), thus lowering the probability of such accounts being flagged.

So to sum it up, an ideal account for a fraud attack is an old account that was verified by the previous owner and either has recent transaction history, or a recent history created with small transactions performed with a stolen card.

What can you do to help yourself?

Firstly, treat new customers with a stricter set of rules and/or separate ML models. There are a lot of conversations about how the customer mass should be sliced for analysis and control. My experience is that separating first/non-first time transacting customers is often enough and a good first step.

Secondly, make sure that among the features/fields you check on a transaction the dormancy-related features are present. Make sure you track the cadence and frequency of transactions, as well as how much time has passed since the last transaction. A dormant account that suddenly starts moving money is not the same as an account with a stable recent history, even if the last transaction amount is the same.

Do not overweight the verification flag. It is not foolproof. When analysing your machine learning models, make sure to do counterfactual analysis to see how the prediction changes when the flag is flipped. If you see a dramatic score drop - this might be a bad signal and needs readjusting. Verification should help you understand the customer, not suppress every other signal.

Use the customer graph

There is also one specific method that I found extremely useful in the past: look at the evolution of the customer graph. Count connected components and track the size of the largest one. If it spikes - alert, pay attention to the market slice where it appears.

Let's get into a bit more detail here. Imagine a graph where nodes are transactions and their details. For example, a transaction with id1 is related to this phone number and that card hash, as well as this name and that town. Now look at the last 90 days in a market slice, pull all the data available for that slice and build that graph.

The next step is to calculate connected components - isolated segments of the graph that share some details in common. What you are looking for is connected components that are relatively large compared to the market size. Say, if the CC size you normally see in that market is 5 and you see 50 - that's your first clue to investigate it. It means that a lot of transactions share a lot of details in common: same card hashes, same phone numbers, same names, same devices, same recipients, or other repeated details.

For example, imagine 40 accounts that look unrelated at the account level. When you build the graph, you discover that they share 3 card hashes, 6 phone numbers, 2 device fingerprints, and a repeating set of recipients. None of those links may be decisive alone. Together, they start to look like infrastructure.

It might be a false positive, of course. Some large connected components are normal: families, shared devices, agents, payroll flows, or community patterns can all create legitimate connections. The useful signal is usually the combination of size, growth rate, newness, market context, and the type of shared identifiers.

However, one large connected component means nothing on its own - you want its temporal dynamics. So what you do is rewind your data back in time and start building the same connected components as of one week ago, 6 days ago, 5 days ago, etc, until today. If a component is persistent and keeps growing in size - it has every chance of being a coordinated fraud attack. Dig into it. This is the infrastructure we talked about - bought card details are shared between accounts, same phone numbers can be used for verification, etc.

Spot the preparation, not just the spike

The main idea is simple: fraud infrastructure often appears before the fraud spike. If you only look at individual transactions, you may see normal-looking activity. If you look at how accounts, cards, phones, identities, recipients, and devices connect over time, the preparation phase becomes much easier to spot.

This is also the kind of problem ezrules is built for: turning those observations into testable rules, graph-derived signals, and investigation workflows that fraud teams can adjust quickly when the pattern changes.