Fraud Detection

Fraud Detection & Prevention is about stopping fraud in real time — scoring transactions, identifying accounts, attack patterns, and abusers. This page lists the 56 data points Athia uses for this use case, with the definition, type, example, expected source, availability and data class for each.

The field names below are the payments-standard names for each data point. Use this page as a mapping aid: line your own column names up against these, and note anything you cannot supply.

Sub-use cases

• CNP transaction scoring — Risk-scores card-not-present transactions using transaction core attributes, AVS and CVV results, 3DS outcome, IP reputation, amount deviation and analyst or confirmed-fraud labels.
• Chargeback prediction — Anticipates disputes ahead of time from prior dispute counts, network chargeback labels, confirmed-fraud flags, representment outcomes and label latency.
• Marketplace fraud — Attributes risk to the merchant the transaction belongs to, for multi-merchant and marketplace setups.
• Velocity rules — Counts activity per card, email, device and IP across time windows, combined with event timestamps, amount, shipping address and amount deviation.
• Card testing / BIN attacks — Detects enumeration against BINs using entry mode, amount, per-card, per-device and per-IP transaction counts, and distinct cards seen per email, device and IP.
• Account takeover — Flags hijacked accounts using sales channel, IP geolocation, recent SIM-swap signals and recent login counts.
• Consortium reuse signals — Uses BIN and card last four to spot the same instrument reappearing across contexts.
• Refund-to-different-card — Spots refunds routed to an instrument other than the one charged, using card last four and refund history.
• Synthetic / new-account fraud — Identifies fabricated identities from billing address, email and email age, breach count, phone number and how closely the email resembles the cardholder name.
• 3DS step-up decisioning — Decides when to step up to 3DS using the authentication outcome and IP reputation score.
• IP intelligence — Characterises the source IP with ASN, ISP, geolocation, VPN, proxy, Tor, datacenter and residential-proxy flags, a composite reputation score and email velocity per IP.
• Mule detection — Surfaces mule networks from the number of distinct emails seen per IP within a window.
• Email & phone risk — Scores contact identifiers using email, email age and domain, breach count, phone number, line type, carrier and recent SIM-swap signals.
• Refund & promo abuse — Detects serial abusers from distinct cards per email and refund history.
• Subscription fraud — Detects abuse of recurring billing using distinct cards per device, stored payment method age and refund history.
• Friendly / first-party fraud — Separates genuine disputes from first-party abuse using customer lifetime value, prior disputes and representment outcomes.

Data points

Grouped by category. Field names follow the payments standard each data point comes from.

Transaction core

Network / IP

Identity signals

Velocity features

Customer history

Labels & feedback

Availability

Availability describes how dependably Athia can obtain a field in practice, across the integration paths in use. It is a planning signal, not a hard limit: a field marked Partial or Limited today often becomes reliable once the right source is connected.

No field in this use case is marked Not available — every one of the 56 data points is obtainable at Full, Partial or Limited availability. The Limited fields are concentrated in network and IP intelligence and in device-keyed velocity, so where those are missing the gap shows up as weaker IP-based and device-based attack detection rather than an outright blind spot.

Data class

PCI fields are minimized: Athia takes BIN plus last four only — never a full PAN and never a CVV value, only the verification result. PII fields should be delivered hashed, tokenized or generalized wherever the analysis allows it; email, phone and address fields in particular work well as stable hashes. Sensitive fields are never required.

Field-level definitions for the core entities are in Athia Data Dictionary.