Fraud Build Sheet

How to read this build sheet

The module explains how fraud detection works. This page is the parts list and the assembly instructions.

Every vendor link is there so you can verify what we say, not so you can go and learn it there.

The market splits into three categories

Almost every confused fraud procurement starts by comparing tools from different categories.

A working 2026 stack usually needs one from at least two categories: a scoring layer for the decision, plus a signal source giving evidence the scorer is otherwise blind to.

How to rank vendors — and how not to

Do not rank on claimed model accuracy. No vendor will let you test it independently, the number is produced on their population, and it is the one figure every sales deck leads with.

Rank on four things you can assess:

1. Explainability — can an analyst say why this was blocked, in a sentence a customer could be told?
2. Evidence readiness — does the output stand up in a chargeback dispute?
3. False positive economics — what does a wrongly blocked genuine customer cost you, and how easily can you tune it?
4. Browser-layer visibility — can it see what happens before the request arrives?

Raw materials — signal layers and device intelligence

Raw materials — scoring, graph and infrastructure

How to use each one — device and velocity

Device intelligence, and what the ID actually means

CLIENT
  const {visitorId, requestId} = await fp.get();
  // send requestId to YOUR server, never trust a client-sent visitorId

SERVER
  GET /events/{requestId}   (vendor API, server-to-server)
  -> { visitorId, confidence, incognito, vpn, bot, tampering,
       ipLocation, firstSeenAt, lastSeenAt }

WHAT TO CHECK
[ ] ALWAYS resolve the requestId server-side. A visitorId posted by
    the client is an attacker-supplied string. This is the single
    most common integration error in device intelligence.
[ ] confidence is a property of the IDENTIFICATION, not of risk.
    Low confidence means "we are unsure this is the same device",
    not "this device is suspicious".
[ ] firstSeenAt is the highest-value field and the least used.
    A device first seen 90 seconds ago applying for credit is a
    different proposition from one you have known for two years.
[ ] a shared device is not automatically fraud. Families, shared
    phones and cyber cafes are normal in India. Use device reuse as
    a GRAPH EDGE, not as a rule.
[ ] incognito/VPN are weak signals alone and strong in combination
    with velocity. Never block on either by itself.

Velocity counters — the cheapest real detection you will build

import time, redis
r = redis.Redis(decode_responses=True)

def bump_and_count(key: str, window_s: int, now: float = None) -> int:
    """Sliding window via a sorted set. O(log n), sub-millisecond.
    One round trip per dimension - pipeline them."""
    now = now or time.time()
    pipe = r.pipeline()
    pipe.zremrangebyscore(key, 0, now - window_s)   # drop expired
    pipe.zadd(key, {f"{now}:{id(key)}": now})
    pipe.zcard(key)
    pipe.expire(key, window_s + 60)                 # ALWAYS set a TTL
    return pipe.execute()[2]

def velocity(ev):
    now = time.time()
    dims = {
      "cust_1h":   (f"v:c:{ev['customer_id']}",   3600),
      "cust_24h":  (f"v:c24:{ev['customer_id']}", 86400),
      "device_1h": (f"v:d:{ev['device_id']}",     3600),
      "benef_1h":  (f"v:b:{ev['beneficiary']}",   3600),
      "ip_1h":     (f"v:i:{ev['ip']}",            3600),
    }
    return {k: bump_and_count(key, w, now) for k,(key,w) in dims.items()}

# WHAT TO CHECK
# [ ] TTL on every key. Without it Redis grows until it evicts
#     something you needed, usually at peak.
# [ ] compute velocity in ONE shared module used by training and
#     serving. Two implementations = training-serving skew, and it
#     is invisible until the model quietly degrades.
# [ ] the RATIO matters more than the count. 5 transactions in an
#     hour is normal for one customer and extraordinary for another.
#     Store a per-customer baseline and compare against it.
# [ ] beneficiary velocity across DIFFERENT senders is the mule
#     signal. Most teams only count per-sender and miss it.

The gotcha: velocity features are the highest-value thing you can build in week one and the easiest to get subtly wrong. A counter that resets on deploy, or a window measured in wall-clock rather than event time, produces a feature that looks fine in testing and is meaningless in production.

How to use each one — graph and the national rails

Graph features without a graph database

You do not need Neo4j to start. The highest-value mule signals are computable in SQL.

-- 1. PASS-THROUGH: money in, money out, almost all of it, fast
SELECT account_id,
       SUM(credit_amt)                        AS in_amt,
       SUM(debit_amt)                         AS out_amt,
       SUM(debit_amt)/NULLIF(SUM(credit_amt),0) AS pass_ratio,
       AVG(EXTRACT(EPOCH FROM (debit_ts - credit_ts))/60) AS hold_mins
FROM matched_in_out
WHERE ts > now() - interval '7 days'
GROUP BY account_id
HAVING SUM(debit_amt)/NULLIF(SUM(credit_amt),0) > 0.90
   AND AVG(EXTRACT(EPOCH FROM (debit_ts - credit_ts))/60) < 30;

-- 2. DORMANT THEN BURST: the strongest single Indian mule signal
SELECT a.account_id, a.last_active_before, COUNT(t.*) AS burst_txns
FROM accounts a JOIN txns t ON t.account_id = a.account_id
WHERE a.last_active_before < now() - interval '90 days'
  AND t.ts > now() - interval '48 hours'
GROUP BY 1,2 HAVING COUNT(t.*) >= 5;

-- 3. SHARED DEVICE ACROSS UNRELATED ACCOUNTS
SELECT device_id, COUNT(DISTINCT account_id) AS n_accounts,
       ARRAY_AGG(DISTINCT account_id) AS accounts
FROM sessions WHERE ts > now() - interval '30 days'
GROUP BY device_id HAVING COUNT(DISTINCT account_id) >= 4;

-- WHAT TO CHECK
-- [ ] tune thresholds on YOUR data. 0.90 and 30 minutes are
--     starting points, not findings.
-- [ ] shared device >= 4 will surface families and shared phones.
--     It is a REVIEW trigger, not a block.
-- [ ] run these as batch features feeding the real-time model,
--     not inside the request path. They are too slow for <50ms.

The national rails

MuleHunter.AI, DPIP, the I4C Suspect Registry and CPFIR are all indirect. You reach them through your sponsor bank or regulated partner, not through an API you sign up for.

What to ask your sponsor bank, specifically:

• Which national signals do you consume, and can any of them reach us as a feature?
• What is the latency on a suspect-registry match — real time, or overnight batch?
• When you flag one of our accounts, how do we hear, and how fast?
• What is the unfreeze path, and how long does it take?

Cost per unit

Best combinations

Combinations that conflict

• Two scoring platforms. You are paying twice for one decision and will trust neither.
• Graph queries inside the request path. Blows the latency budget; precompute.
• Trusting a client-supplied device ID. Resolve server-side or the signal is attacker-controlled.
• Blocking on device sharing. Normal in India. Review trigger, not a rule.
• Buying a guarantee model to avoid building anything. It caps loss; it does not give you the data or the judgement.

Three recommended builds

Strong and expensive

Build: Enterprise scoring platform with case management, plus a browser-layer signal provider, plus a guarantee model on the highest-risk segment.

Use when: volume is high, losses are material, and you need a defensible answer for a regulator or a board tomorrow.
Cost shape: $50k/year floor plus signal layer plus a percentage of protected volume.
Trade: the model is theirs. You will struggle to explain a specific block, and tuning goes through their team.

Strong and reasonable — the default

Build: Device signal layer → your own velocity counters in Redis → your own rules → a gradient-boosted model on your labels → batch graph features → step-up ladder rather than block/allow.

Use when: you have engineers and fraud is a core risk rather than a checkbox.
Cost shape: a few hundred dollars a month for signals, plus infrastructure.
Trade: you own detection quality — which is the point, because the labels you accumulate are the asset.

Strong and lean

Build: Open FingerprintJS or a per-call signal API → Redis velocity → explicit rules → manual review queue → SQL graph queries nightly.

Use when: pre-scale, low volume, proving what your fraud actually looks like before buying against a guess.
Cost shape: near zero beyond infrastructure and review time.
Trade: higher analyst load and no consortium view. Acceptable at low volume; it stops scaling once review hours exceed the cost of a platform.

What next

• AML — a mule account is both a fraud case and an AML case. Same data, different obligation, and the two teams need one shared view of the account.
• Payments — a dispute is where a fraud decision meets money movement, and the evidence pack you assemble comes from here.
• Customer operations — a blocked genuine customer becomes a support contact within minutes. Design that conversation before you turn the rules on.
• Governance — the fraud model, the vendor score and the rules engine are all models under the RBI draft. Inventory, tier, kill switch, fallback.

Sources

Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which numbers are primary-sourced and which are industry reporting — they are not equivalent, and treating them as if they were is how a confident wrong number gets repeated.