A transaction is not just an authorization payload. It is the end result of a user journey.
If you own the checkout surface, you have access to context that issuing banks do not. This applies to platforms like Shopify, payment service providers like Stripe or Adyen running hosted checkout, and enterprise merchants building their own. Issuers operate primarily on the authorization message: ISO 8583 fields plus a handful of extensions, received only after the user clicks “Submit.” You see everything that happens before and around that moment, plus everything your platform has ever known about this customer, this device, and this card.
That context is the raw material for a fraud model that outperforms what an issuer can build alone. The five features below are widely used across modern fraud systems and cover the main signal categories a checkout-owner fraud model can draw on.
§01 · Platform-exclusive
Five signals unique to platforms
and checkout owners.
These are the data points that are dropped, generalized, or never collected before the final authorization message reaches the bank. Adding them as features in your fraud model lets you stop bad actors earlier in the funnel.
Identity linkage & email metadata
The signal
Compare the billing name against the email local part for
linguistic correlation. A single mismatch between
Bob Smith and
sarah.clark@gmail.com is
unremarkable — gift-buying is common. But layered with
other email features, the signal sharpens. Useful sub-signals:
domain age (registered last week vs. last decade),
disposable-email detection (mailinator, tempmail, and thousands
of variants), Gmail dot/plus aliasing where one underlying
address (bob.smith+1@,
bob.smith+2@) appears across
many accounts, catch-all MX records, and prior appearance of
this exact email on your platform. A rolling merchant-level
surge — say 500 transactions in an hour where billing name
and email have near-zero correlation — is a strong
indicator of an automated attack, though not by itself
definitive.
The enrichment
Pass these fields to identity vendors like Ekata (now Mastercard), Experian, Telesign, or synthetic-identity specialists like Socure or SentiLink. Note the limits: most identity APIs verify that a person matching the provided PII exists, which means they confirm real-name-real-address combinations but struggle with synthetic identities (a real SSN paired with fabricated PII) and with fully stolen identity packages where every field is real but taken from one real person.
How it is retrieved
Server-side API call to a vendor before or during authorization, plus internal queries against your own user table for prior-appearance signals.
Cart composition & SKU-level risk
The signal
The liquidity of the items in the cart. Fraudsters don't steal credit cards to buy niche products — they target goods they can resell immediately. High-risk SKUs include digital gift cards, gaming currency and skins, prepaid cards, in-demand sneakers, popular electronics, and high-end cosmetics. Custom-printed apparel, made-to-order furniture, and personalized items are much lower risk because they have no resale market. Calibrate the SKU weights against your own chargeback data — universal liquidity rankings vary by region and channel.
How it is retrieved
Server-side access to the storefront catalog and the session cart payload, joined against historical chargeback rates by SKU or category.
Spatial & network-layer risk
The signal
A two-layer feature. The first layer is geographic: the
distance between the request IP, the billing address, and the
shipping address. A connection from London with a Texas billing
zip shipping electronics to a Miami reshipper is a classic
mismatch. The second, harder-to-spoof layer is below HTTP. TLS
fingerprints (JA3/JA4) and HTTP/2 settings reveal the client
library actually making the request. A user agent claiming to
be Chrome 130 but presenting a Python
requests or
curl TLS signature is almost
certainly a script. Layer in ASN reputation: datacenter ranges
(AWS, GCP, Hetzner, OVH), residential-proxy networks (Bright
Data, Oxylabs), Tor exits, and known VPN providers each carry
different risk weights. IP geolocation is noisy on its own
(mobile-carrier IPs, corporate VPNs, satellite ISPs), so always
pair it with the lower-layer fingerprint.
How it is retrieved
Server-side comparison of the HTTP request IP against the shipping form and AVS payload. TLS fingerprint capture at the edge (CDN, WAF, load balancer) before TLS termination. IP enrichment via MaxMind, IPQualityScore, or Spur.
“The graph and identity gap between a single legitimate buyer and a fraud ring operating dozens of accounts is where checkout owners produce signal that issuers cannot reproduce.”
Account tenure & entity-graph linkage
The signal
Two of the most predictive features in any modern fraud system — and both entirely unavailable to the issuer. Tenure sub-signals: time since account creation, time between account creation and card-on-file, time between card-on-file and first attempted charge, count of prior successful purchases, email-verified status, and recent password or shipping-address changes. A fraud-ring account is often created, has a card added, and attempts a high-value purchase within minutes. The entity graph links accounts across your platform via shared device fingerprints, cookies, payment instruments, shipping addresses, phone numbers, and IP/ASN. A “first-time” account sharing a device fingerprint with three accounts already on your chargeback blacklist is high risk before it does anything else. This is the kind of cross-merchant context the issuer has on the cardholder side — your equivalent is cross-account context on the merchant side.
How it is retrieved
Direct queries against your user, session, and order tables for tenure features. Offline graph computation (Neo4j, Spark GraphX, or a feature store with adjacency queries) materialized into features available at scoring time.
Payment-instrument behavior on your platform
The signal
Card-level features built from your own platform's history, distinct from generic transaction velocity. Useful features: number of cards added to this account in the last hour or day, time between card-add and first attempted charge, ratio of declined to successful attempts on this card (card cycling), use of low-trust BIN ranges (prepaid cards, virtual-card issuers like Privacy.com, certain neobanks), whether this BIN has appeared on your platform before, and how many distinct accounts have used this same card. Card testing typically shows up here long before it shows up in conversion ratios. Fraudsters often hit the payment API directly, bypassing the checkout page entirely.
How it is retrieved
Internal aggregations over your tokenized-card store and authorization-attempt logs, surfaced as features at scoring time.
§02 · Overlap Signals shared by gateways and issuers.
These are the standard data points required to move money. Both you and the banking entities evaluate them, though often with different weights.
- Core transaction data
- Amount, time of day, currency, MCC.
- Card verification data
- AVS (largely a US/Canada/UK construct — outside those markets billing-address verification is weak or absent), CVV match, BIN country.
- Basic velocity metrics
- Transactions attempted on a specific card within a short window — though the bank sees this across all merchants while you see only your own.
- 3DS 2.x authentication data
- Roughly 100 fields of contextual data now flow between merchant and issuer through 3DS 2.x. Both sides see and can score on this.
§03 · Issuer-exclusive
Signals unique to card networks
and issuing banks.
Understanding what the banks can see that a single platform cannot helps you map your blind spots.
- Cross-merchant velocity
- The issuer sees the fraudster testing a card across Stripe, PayPal, and Adyen simultaneously. A single platform sees only its own isolated attempts. Some cross-merchant signal sharing exists on the merchant side (Sift, SEON, Forter consortium data), but it is narrower than the issuer's view.
- True account state
- The issuer knows available credit, historical spending averages, travel patterns, recent in-app activity such as logins and password changes from the banking app, and whether the card has been recently reported lost or stolen but not yet propagated to networks.
- Global chargeback & auth history
- How many chargebacks this cardholder has filed across their lifetime, and how prior 3DS challenges resolved. Both are strong features unavailable to any single merchant.
- Cross-card account relationships
- The issuer can link multiple cards held by the same accountholder, including activity on accounts where one card is fraud-flagged and another is not.
The strategic takeaway.
Your most predictive machine-learning features will rarely be the basic transactional data. Issuers already analyze that heavily, and so does every other merchant. The features that move your model are the ones drawn from your own platform's funnel and history: email and identity linkage, network-layer fingerprints, account tenure, entity-graph linkage, and payment-instrument behavior. The graph and identity gap between a single legitimate buyer and a fraud ring operating dozens of accounts is where checkout owners produce signal that issuers cannot reproduce.
Two things to keep in mind when operationalizing these signals.
First
False positives are the dominant cost.
False-positive declines typically cost merchants substantially more revenue than actual fraud losses. Every signal in this article needs to be calibrated against its false-positive rate, not just its fraud-catch rate. Aggressive blocking on any single feature — a disposable email, a VPN IP, an unusual cart — will reject many legitimate customers. These features earn their keep only in combination, weighted by a trained model against real outcome data.
Second
Pre-authorization blocking is a strategic choice.
Blocking before auth saves interchange and processing fees but discards the issuer's risk assessment as a feature in your model. Mature fraud platforms often let authorization happen, treat the issuer's response as input, and decide capture-versus-void downstream. The right cut point depends on your auth costs, your chargeback rates, and how strong your pre-auth features are.
Done well, this contextual data improves the entire ecosystem. It reduces false positives so legitimate customers aren't wrongly declined. It lowers chargeback rates. And it builds the kind of merchant track record — low fraud, high authentication completion, clean 3DS data — that issuers reward with higher approval rates on legitimate transactions. The compounding effect on conversion is often larger than the direct fraud savings.