Card vetting, known in fraud circles as card testing or carding, is how criminals confirm a stolen card number is still active and has spending room before they commit to a large purchase. They do this with small transactions and automated checker tools, not by trusting whatever a marketplace listing claims.
- Card testing runs stolen numbers through small transactions or checker APIs before the real fraud starts
- CVV and AVS checks catch careless attempts, not the ones built on phished or breached CVV data
- EMV 3DS2 and velocity rules on the acquiring side stop far more traffic than card level checks alone
- A sudden run of small declines across one BIN range is usually a breach signal, not noise
How card testing actually works
A stolen card number is worth nothing until someone confirms it works. A criminal will usually run it through a Luhn check to rule out a mistyped number, then group it by BIN, the first six to eight digits, to work out the issuing bank and product tier. Grouping matters commercially: a corporate BIN sells for more on a card shop than a standard debit BIN, because the assumed limit is higher.
The live test comes next, usually against merchants known for weak fraud screening: subscription sign ups, browser extensions, small SaaS trials, donation pages, anywhere a low value charge can clear without manual review. Checker tools, sold on the same forums as the card data, run this at volume, rotating through residential proxy networks so attempts do not cluster on one IP.
CVV and AVS: necessary, not sufficient
CVV is meant to prove the person transacting holds the physical card, but a CVV obtained through phishing or a breached e-commerce database defeats that assumption. Address Verification checks are similarly easy to satisfy once billing details ride along with the stolen record, which they usually do when the source was a full data breach rather than a skimmer. Neither control was built to stop testing traffic; both were built to stop opportunistic fraud. Treating a passed CVV and AVS check as proof of a legitimate cardholder is the most common gap in merchant and issuer fraud logic.
Why testing traffic is hard to catch
A single test transaction looks unremarkable: a small amount, a plausible address, a card that passes CVV. The signal only shows up in aggregate, across a merchant, a BIN range, or a device fingerprint pool, which is why single transaction rules underperform against carding. Testing operations spread attempts across many merchants rather than one, keep amounts under common review thresholds, and rotate IP and device fingerprints faster than most legacy fraud engines refresh their block lists.
Controls that actually cut testing success
EMV 3D Secure 2 is the biggest structural change: it shifts liability toward the issuer and adds a risk based authentication step most checker scripts cannot complete. Velocity rules at the acquirer and network level, transaction count and value per card, BIN, device and IP within a rolling window, catch the volume pattern that per transaction rules miss. Network tokenization removes the static card number from the merchant environment, shrinking the pool of raw numbers available to test. On the merchant side, rate limiting, device fingerprinting and blocking known checker user agents on checkout pages closes off the low friction targets testing operations prefer.
What regulators and card schemes actually expect
UAE banks operate under the CBUAE cybersecurity requirements, which increasingly expect issuers to demonstrate a working fraud monitoring capability, not describe one on paper. PCI DSS requirements around the cardholder data environment apply regardless of where the bank sits, and assessors ask for evidence of monitoring tuning, not a policy document. Entities regulated out of DIFC and ADGM face the same underlying expectation: evidence that fraud monitoring works in practice, not a policy document describing how it should.
Reading a testing wave as a breach signal
A spike in small value declines concentrated on one BIN range is rarely random. It usually means a batch of cards from a single merchant breach has reached a card shop and is being validated in bulk before resale. Correlating blocked BIN ranges against breach disclosures, and against threat intelligence platforms that monitor card shops and carding forums, closes the gap between noticing odd transaction activity and knowing which breach it came from. That correlation belongs inside a bank's wider fraud mitigation programme, since the same stolen data often surfaces alongside phishing kits built to harvest the CVV in the first place.
A short checklist for fraud and SOC teams
Confirm 3DS2 is enforced on card not present transactions above a sensible threshold, not just switched on at default. Check velocity rules key off BIN and device fingerprint, not card number alone, since a tested number rarely gets reused twice. Verify someone owns the link between blocked transaction spikes and breach intelligence feeds; it is usually manual and gets lost in a reorganisation. Track CVV and AVS pass rates as their own fraud metric, separate from overall approvals: a rising pass rate on declined then approved retries is often the first sign of an active testing run against your BIN.
