Card testing — also called card cracking or a BIN attack — is fraud in which criminals validate stolen card details using very low-value transactions before attempting a larger drain. Machine learning detects it by scoring the pattern of attempts across merchants and customers, rather than waiting for a single transaction to breach a threshold.
Card testing is a velocity problem before it becomes a loss problem. The early signs are often small: a low-value authorisation, a strange merchant pattern, or a handful of failed attempts that look harmless on their own.
Traditional rule-based systems can miss that build-up because they usually respond only after a threshold is crossed. By then, the attacker may already know which card details work. Card testing detection through machine learning gives fraud teams a way to spot the movement before the larger drain begins.
Bank Identification Number (BIN) attacks are not just a ‘more rules’ problem; it’s a timing problem.
How BIN attacks work
BIN attacks, often associated with card testing, typically begins with validation. Criminals may have stolen or purchased card details through phishing, malware, data breaches, or criminal marketplaces.
What they do not always know is whether the credit card is still active, whether the security checks will pass, or which merchant will approve the payment.
So they test.
The first payments are often tiny. A few pence. A pound. A small donation. A low-value digital purchase.
Some fail, but the successful ones reveal what the attacker needs to know.
Once a card works, the next stage can move quickly.
Higher-value purchases, wallet loading, resale of goods, or attacks on linked accounts may follow.
The problem for legacy systems is that the early activity does not always look serious.
A £0.05 transaction does not scream danger in the same way a £900 purchase does. A single failed payment may look like ordinary customer friction. A merchant name may appear slightly differently each time.
That is exactly why card cracking works.
Why do legacy systems often see it too late?
Many older fraud platforms rely on fixed logic. If a transaction is over £500, flag it. If five transactions happen in ten minutes, block the card. If the country is on a high-risk list, step up the check.
Those rules still have a place, no serious enumeration stack throws them away. But card crackers know how to sit underneath them:
- keeping payments small
- spreading attempts across merchants
- using bots to test at scale (this is why velocity limits are important)
They move before the pattern becomes obvious at customer level.
The European Payments Council’s 2025 Payment Threats and Fraud Trends Report identifies botnets, malware, social engineering, and third-party vendor risks as key threats in the current payments space, and we’re seeing the same across the UK.
That matters because card testing rarely manifests as a single suspicious transaction. It behaves like a coordinated pattern made up of small, easy-to-miss signals: a rule may see noise pollution, but a trained model can spot the attack’s shape.
Why do fraud models need enriched transaction data first?
Raw transaction data is messy. Merchant names can be shortened, duplicated, misspelt, routed through payment processors, or presented differently across internal systems.
The same merchant may appear under several labels. Different merchants may look almost identical.
That makes precise and fast fraud detection harder than it needs to be.
Before an authorisation request reaches the risk engine, it needs context. That means cleaning the merchant name, identifying the merchant, assigning the right category, and comparing the transaction with the customer’s usual behaviour.
A simple flow looks like this:
- A card authorisation request enters the system
- The transaction is categorised and enriched
- Merchant, channel, location, and behavioural context are clarified
- The model scores the activity
- The system approves, monitors, steps up, blocks, or routes the case for review
This is where merchant identification becomes important. If the system cannot identify the merchant, it will struggle to determine whether that merchant is part of a broader testing pattern. If the merchant name is slightly obscured in the raw data, the system can still cluster related attempts and spot the broader trend.
Watch the merchant, not only the customer
Watching out for card testing is often approached too narrowly. A single customer transaction of £0.01 may not seem urgent. But one merchant receiving hundreds of tiny authorisations across unrelated customers is a different picture.
That merchant-level view is where useful detection often starts.
A model can monitor whether a merchant suddenly shows:
- A sharp rise in £0.01 or £1 transactions
- Higher decline rates than normal
- Attempts across unrelated customers
- A move from card-present to card-not-present activity
- Unusual international gateway activity
- Repeated low-value authorisations with no clear customer relationship
That last point matters. Criminals often rely on the fact that each attempt looks small in isolation. The pattern only becomes clear when customer, merchant, channel, and amount are read together through intentional limits like decline rate thresholds, velocity limits and more. Legacy systems operate in silos but Moneyhub uses cross-network Smart Data intelligence to cluster anomalous behaviour across entirely unrelated accounts.
Treat tiny transactions as signals, not noise
A low-value payment is not always low risk.
In enumeration attacks, the small payment is often the warning shot. The attacker is not trying to steal 5p. They are checking whether the card works.
That means the amount needs to be judged against the customer’s normal behaviour. If someone uses public transport regularly, a £0.10 authorisation on a local bus should not cause alarm, but a £0.10 authorisation at an unfamiliar international gateway deserves attention. It may not need an instant block, but it can justify a silent flag for the next 60 minutes.
The model can then watch for:
- A second attempt at the same merchant
- A sudden move to a higher-value transaction
- A new device or location
- Several failed attempts in a short period
- Similar activity across other customers
- Merchant behaviour that looks unusual
This gives the fraud platform room to act without creating unnecessary friction too early.
Use risk scores to apply the right friction
Fraud prevention is not just about saying yes or no. Sometimes the right action is to approve and watch. Sometimes it is necessary to ask the customer a simple question. Sometimes the card needs to be blocked immediately.
A risk score can help decide which route makes sense
Approve and continue monitoring
Send an in-app check
Ask the customer to confirm the transaction
Block or route to manual review
This is where nudges in financial services can help. A well-timed ‘was this you?’ message can confirm genuine activity without turning every small payment into a frustrating customer journey.
The FCA’s work on digital design and Consumer Duty also puts pressure on firms to design journeys that reflect customer needs, alongside foreseeable harm and internal risk controls.
That balance matters – fraud checks need to protect people without making everyday banking harder than it should be.
Feed confirmed attacks back into the model
Card cracking changes quickly. A merchant category that looks normal today can become a testing ground next week.
A payment gateway that rarely caused concern can suddenly appear across hundreds of small authorisations. A botnet can switch between merchant types before a manual rule is updated.
When a card cracking attempt is confirmed, the enriched details should be returned to the training set. Not just the amount and timestamp, but the merchant identity, category, payment channel, location, customer context, decline pattern, and linked behaviour.
Over time, this helps the model recognise which combinations are becoming risky.
For example, it may learn that a certain merchant category is being targeted for low-value validation attempts. Or that a cluster of international gateway transactions is appearing across customers with no normal reason to use those merchants.
Cut false positives without missing the quiet signals
Fraud teams are not short of alerts – false positives are common. They are short of useful ones.
If every tiny payment becomes an alert, teams drown. Yet, if all tiny payments are ignored, attackers get space to test.
The answer sits between those two extremes.
A £1 payment to a known subscription provider is not the same as a £1 authorisation through a merchant linked to a sudden spike across unrelated customers. The amount may be similar but the risk is not.
The Office for National Statistics estimated that there were 4.4 million fraud incidents in England and Wales in the year ending December 2025. It also reported a 19% rise in bank and credit account fraud in the year ending September 2025, reaching around 2.6 million incidents.
That volume makes accuracy important. Not just accuracy in spotting fraud, but accuracy in deciding what is a false positive and when not to interrupt.
Spot the build-up before the drain
Card cracking rarely starts with the large drain. It usually starts with small tests that tell the attacker whether the card is worth using.
Machine learning can help fraud teams spot those signs earlier, but it needs clean transaction context to work properly. Categorisation and enrichment in real-time, not batch processed, helps clarify the merchant, payment type, channel, customer behaviour, and network pattern behind each authorisation.
That is how firms move from reacting to the drain to spotting the build-up.
About Matt Barr
Matt Barr is a Product Director here at Moneyhub. He’s been working either with or for banks since the mid-00s, solving all manner of problems. From ISA transfers to corporate actions, Matt now focuses on transaction categorisation and enrichment. When he’s not solving client problems, you can find Matt buried under his children’s laundry or stomping through the Peak District.
FAQs
Card cracking is a type of credit card fraud in which criminals test stolen card details with small transactions before attempting larger payments or engaging in account abuse.
Machine learning can help detect card cracking by learning which patterns are risky, such as repeated low-value payments, unusual merchant spikes, failed attempts, or transactions that fall outside a customer’s normal behaviour. These signals can trigger silent flags, closer monitoring, customer nudges, or step-up checks before the fraud escalates into a larger drain.
Transaction enrichment provides fraud systems with clearer merchant, category, channel, and behavioural context, making it easier to distinguish genuine low-value payments from early fraud signals.
share
