Transactional Fraud: Types, Signals and Controls

What transactional fraud covers, and what it does not

The term is used loosely, so it helps to set a boundary. Transactional fraud is fraud that happens at the moment of a payment or a money movement: the purchase, the top-up, the refund, the payout. It is judged one transaction at a time, usually in the few hundred milliseconds between "pay" and "approve".

That framing matters because it limits what you can know. At checkout you often have a card number, a billing address, an IP address, a device and an email address, and nothing else. You do not have a verified identity, a relationship history or a document. Good transaction controls are therefore about consistency: do the pieces of data you do have agree with each other, and do they look like a real customer's behaviour?

Two further distinctions are useful for operations teams:

• Third-party fraud: someone other than the account or cardholder makes the payment (stolen cards, takeover, synthetic identities).
• First-party fraud: the genuine customer makes or benefits from the payment and then disputes it, or abuses a refund or promotion policy.

The two need different controls. Device and BIN signals are strong against the first; evidence and policy design matter more for the second.

Types of transaction fraud

Two neighbouring problems are covered separately. Account compromise after sign-up is in our guide to account takeover fraud, and bulk testing of stolen card numbers has its own article, "How to Stop Card Testing Attacks with BIN Data".

The checkout signals worth collecting

Most fraud tooling reduces to a handful of signal families. The value comes from comparing them, not from any single one.

Geography agreement

Compare three locations: the country of the card issuer (from the BIN), the country of the IP address, and the billing and shipping address. Agreement across all three is reassuring but not proof. Disagreement is a prompt to look closer, because many genuine customers disagree with themselves (travel, expats, gifts).

Velocity

Count events over short windows: attempts per card, per device, per IP, per email and per shipping address. A single card used on several accounts, or one device trying many cards, is more telling than any absolute volume. Choose windows to match your business: minutes for digital goods, hours or days for physical goods.

Device and network

Device fingerprints, browser consistency, and signs of proxies, VPNs, hosting-provider IP ranges or emulators help link sessions that look unrelated. IP and device intelligence is useful here because it ties a payment to prior behaviour from the same device.

Email and phone

Age and format of the email address, disposable-domain use, and whether a phone number is valid and plausible for the billing country all carry signal. Email validation and phone validation are cheap to run before the payment is attempted.

Order behaviour

Unusual basket composition (many units of a resaleable item), express shipping to a new address, a billing address different from shipping, and very fast form completion often separate scripted from human behaviour. Treat these as modifiers to the score, not as stand-alone reasons to decline.

Using BIN data at checkout

The BIN (bank identification number) is the first six to eight digits of a card number. It identifies the issuer and typically returns attributes such as card brand, credit, debit or prepaid type, and issuing country. If you are new to it, start with what a BIN number is; for hands-on checks see how to check BIN numbers, or try the BIN checker.

Practical uses on a checkout:

• Country comparison. A card issued in one country, an IP in another and a billing address in a third is the classic mismatch. Weight it by what you sell and where you ship.
• Card type. Prepaid cards are not fraudulent by nature, but anonymous prepaid cards on high-resale goods deserve different treatment from a domestic credit card.
• Routing and authentication. Issuer data helps decide whether to request 3-D Secure, which payment method to offer, or whether to expect a particular decline pattern.
• Consistency over time. If several different cards in one session share a BIN range from an unusual issuer, that is worth a rule.

The caveat is false positives. Travellers, students abroad, people buying gifts for relatives overseas, and customers on corporate VPNs all produce legitimate mismatches. Use BIN mismatch to route a transaction (to step-up or review), and reserve automatic decline for combinations of strong signals. The ScreenlyyID BIN lookup returns this issuer data through an API so it can be part of the same decision as your other checks.

3-D Secure and liability shift

3-D Secure (3DS) adds issuer authentication to an online card payment, either silently (frictionless) or with a challenge such as a one-time code or app approval. For merchants the attraction is liability shift: where a payment is successfully authenticated, responsibility for certain fraud-coded chargebacks generally moves from the merchant to the issuer.

Several points are easy to miss:

• Liability rules are set by each card network and acquirer agreement, and they differ by region, transaction type and exemption used. Read your own acquiring terms rather than assuming.
• Liability shift covers specific fraud disputes. It does not cover "item not received" or "not as described" disputes.
• Challenging every customer can reduce conversion. Many merchants apply 3DS selectively: to transactions flagged by their own risk rules, or where regulation requires strong customer authentication.
• Where regulation requires authentication, exemptions and their conditions are a compliance question, so confirm them with your acquirer or counsel.

A sound pattern is to let risk signals decide who sees a challenge. Low-risk orders go through frictionlessly, high-risk ones get authenticated or are declined, and the middle goes to review.

Chargebacks: what they tell you

A chargeback is a dispute raised by the cardholder through their issuer. For fraud operations, treat the chargeback feed as labelled data, because it is the only confirmation you get that a transaction you approved was bad. Three habits help:

1. Separate the causes. Fraud-coded disputes, service disputes and suspected friendly fraud need different responses. Mixing them hides which control is failing.
2. Feed outcomes back into rules. If a pattern of device, BIN and address appears in lost disputes, turn it into a rule or a review trigger.
3. Keep evidence ready. Order records, delivery confirmation, IP and device logs and customer communication are what you submit when contesting. Reason codes and time limits are defined by the card networks, so check your acquirer's guidance.

Also remember data security: merchants that store, process or transmit card data have obligations under PCI DSS. The PCI Security Standards Council publishes the standard. Fraud signals should be stored and used without keeping card data you do not need.

Card testing, where criminals probe many card numbers with small payments, tends to precede larger fraud and is documented in Stripe's card testing guide. Our separate article on it covers the defence in detail.

Example rules to adapt

These are starting points, not recommended thresholds. Test every rule against your own approved-and-disputed history before it declines anyone.

Note the last row. Allow-rules for trusted behaviour are as important as block-rules, because they protect conversion and keep reviewers focused on the real grey area.

Putting it together

A workable operating model for a merchant looks like this: collect signals before authorisation, score them together, apply 3DS and review selectively, and feed dispute outcomes back into the rules. ScreenlyyID offers BIN lookup, IP and device intelligence, and email and phone validation behind a single API, described on the fraud detection and compliance page, with decisioning and case review to act on the results. For programme-level topics such as KPIs, tooling mix and ownership, see the article "Payment Fraud Risk Management". More guides are in the fraud detection hub.

Card networks and regulators change their rules periodically. Check current requirements with your acquirer, the relevant regulator or legal counsel. This page is general information, not legal advice.