5 Fraud Detection Signals Beyond Transaction Amount
Amount is a threshold wearing a trenchcoat
Transaction amount is the first feature everyone adds and the weakest one alone. A lot of fraud is small and deliberately kept under review thresholds; a lot of large transactions are a regular customer buying a laptop. A model leaning on amount is really leaning on a cutoff, which is a rule in disguise. These five fraud detection signals do more of the actual work — and each one has a way it fails that you need to design around.
1. Velocity and recency aggregates
Counts and sums over sliding windows — last 1 minute, 1 hour, 24 hours, 7 days — per card, device, account, and IP. This is the backbone signal for card testing (dozens of small auths in seconds) and for account-takeover bursts.
Where it fails: "low and slow" fraud that deliberately stays under every window's rate; cold start on entities with no history; shared infrastructure (corporate NAT, mobile carrier IPs) inflating IP-level counts with legitimate traffic.
2. Device and session fingerprint
Device age, emulator and automation flags, browser–OS consistency, timezone versus billing geography, and whether this device has been seen with other accounts. Strong for account takeover and synthetic identity, where the credentials check out but the device doesn't.
Where it fails: privacy tooling and legitimate VPNs generate false positives; fingerprints churn with every browser update; a determined attacker can spoof or farm devices. Treat it as a strong prior, not proof.
3. Entity-linkage and graph features
How many accounts share this device, address, phone, or funding instrument; graph distance to known-fraud entities. This is what catches fraud rings and synthetic identities that look perfectly clean one transaction at a time — the signal only appears when you look at the connections.
Where it fails: needs a graph pipeline you probably don't have yet; legitimate many-to-one sharing (families, shared computers, offices, corporate cards) creates dense-looking clusters; real-time graph queries are expensive and often get pushed to near-real-time.
4. Behavioral and sequence deviation
Does this action fit this account's own history — typical merchant categories, times of day, order composition, navigation path before checkout. A per-entity baseline, not a global rule. This is often the only thing that flags an account takeover where the login is valid and the payment instrument is the real customer's.
Where it fails: thin or no history for new and infrequent users; legitimate behavior change — travel, a life event, holiday shopping — reads as deviation. Needs a fallback for entities without a stable baseline.
5. Unstructured context
Merchant descriptor patterns, the semantics of a shipping-versus-billing name mismatch, free text on the order, chargeback reason narratives, prior support tickets. A tabular model can't read any of this directly. This is where an LLM reasoning layer earns its place — on our fintech fraud-scoring engagement the working shape was a gradient-boosted baseline plus an LLM layer reasoning over transaction narratives and device signals.
Where it fails: latency and cost per call, so you run it selectively rather than on every transaction; it needs grounding in the structured features or it produces confident, wrong rationales; labeled training data for text signals is scarce.
The point is the combination
None of these is a rule, and none is meant to fire alone. The reason to move off amount-as-threshold is that fraud shows up in the interaction: a two-hour-old device, plus an address shared with four other accounts, plus an order that looks nothing like this account's history. Each signal on its own is weak and noisy. A model that learns how they combine is what turns them into a decision.
Which order to add them in
You don't build all five at once. A workable sequence, cheapest and highest-signal first:
- Velocity aggregates. Mostly a streaming-counter problem; no external data, and it immediately kills card testing.
- Behavioral deviation. You already log the events; the work is turning them into per-entity baselines.
- Device fingerprint. Usually a vendor SDK plus your own "seen with other accounts" bookkeeping.
- Unstructured context. Add once you have a model in production and a review queue to feed rationales into.
- Graph features. Highest lift against organized fraud, highest infrastructure cost — a real pipeline, so it comes last.
Each step should earn its place with a measurable drop in either fraud loss or false positives before you move to the next. If velocity plus behavior already gets you where you need to be, stop.
Where this stops being right
- Every signal is a data dependency and a privacy question. Collecting device and graph data has consent and regulatory implications (GDPR and similar regimes) you clear before building features, not after.
- More signals, more drift surface. Each family is something else to monitor and, in a regulated decline, something else to explain.
- Cold start beats you. A brand-new product with no history and no labels can't feed most of these. You start with rules and third-party data and grow into a model as the data accumulates.
FAQ
Is transaction amount useless, then? No — it's useful in combination and in relative terms (amount versus the entity's own 90-day median). It's weak only as a standalone global threshold.
How many features does a real fraud model use? It varies widely, and the raw count matters less than coverage across these families and keeping each contribution explainable.
Do we need an LLM for the unstructured signals? You need something that can read text. An LLM layer is one option — used selectively and grounded in the structured features — not a requirement, and not something to run on every transaction.
ISTRALLEN builds fraud models that combine velocity, device, graph, behavioral, and text signals for fintech teams; the approach is described under AI for Fintech.