A transaction score sees one payment. A fraud graph sees that the new account, reused document, recently swapped phone, familiar device, shared beneficiary, and rapid transfer chain already belong to the same story. The graph is the context layer; rules, models, investigators, and payment controls still make the decision.
Regional fintech systems rarely lack signals. They lack a consistent way to connect onboarding, authentication, devices, telecom, accounts, merchants, payment keys, beneficiaries, disputes, and confirmed cases. A graph makes those relationships explicit, but every edge needs time, provenance, and confidence. “Used device” is incomplete; “used device between these timestamps, observed by this SDK, with this confidence” is evidence.
Nodes should represent durable things: person, legal entity, account, device, document, phone, email, address, IP/ASN, payment key, merchant, beneficiary, and case. Transfers, logins, enrollments, password resets, SIM changes, consent grants, and disputes are events. Do not flatten events into timeless links; otherwise the graph cannot answer whether a relationship existed before the decision.
Fraud graphs fail quietly when identity resolution merges two legitimate people or leaves one actor split across dozens of aliases. Start with deterministic identifiers that have clear provenance. Add probabilistic links as separate, scored hypotheses. Never turn the same address, NAT IP, family phone, shared POS, or recycled number into automatic ownership.
| Relationship | Evidence | Useful feature | Decision use | Failure mode |
|---|---|---|---|---|
| Device used by many new accounts | Attested device/app ID, first/last seen, session history. | Distinct accounts in 1h/24h/30d. | Step-up, limit, or review. | Shared retail device or unstable fingerprint. |
| Document image reused | Verified document ID plus image/perceptual fingerprint. | Accounts and legal names per evidence cluster. | Block onboarding pending verification. | Vendor retry or template collision. |
| Recent SIM change before recovery | Carrier signal with observation time and API result. | Hours since SIM swap plus authenticator reset. | Delay sensitive actions; use stronger proof. | Treating SIM change alone as fraud. |
| Beneficiary receives from many fresh accounts | Confirmed transfers ordered by event time. | Fan-in, source tenure, burst, amount distribution. | Hold or investigate cash-out path. | Legitimate marketplace or payroll aggregator. |
| Rapid multi-hop transfer chain | Transfers with settlement status and participant IDs. | Path length, elapsed time, retained amount. | Trace, block available funds, open case. | Ignoring reversals, pending states, or clock order. |
| Known fraud community proximity | Confirmed labels with case provenance and expiry. | Shortest path, weighted neighbors, community overlap. | Add evidence to a decision. | Contaminating neighbors with permanent guilt. |
Compute features as they were knowable at decision time. Backfilled labels, later disputes, corrected identities, and future edges cannot leak into training or replay. Store event_time, observed_at, valid_from, valid_to, source, confidence, schema version, and ingestion ID. This lets teams reconstruct the graph used for a payment decision and explain it months later.
Online checks should be small and explicit: one- or two-hop neighborhoods, recent degree, fan-in/fan-out, account age, shared identifiers, path to confirmed fraud, community risk, cycles, and velocity windows. Heavy community detection, embeddings, label propagation, and historical simulations belong in offline jobs. Materialize approved features into a low-latency store instead of running an unbounded traversal in the payment path.
Brazil's Pix MED 2.0 documentation explicitly addresses tracing subsequent transactions and blocking suspicious funds beyond the original recipient. That is a graph-shaped operational problem: settled transfer edges, participant accounts, available balances, event ordering, case status, and return actions must remain consistent. The graph can reveal the path, but recovery still follows scheme rules and institution authority.
GSMA Open Gateway and CAMARA expose standardized SIM Swap and Number Verification capabilities. A recent SIM change combined with password recovery, a new device, changed beneficiary, and unusual transfer is more informative than any signal alone. Carrier availability, consent, latency, portability, recycled numbers, and regional coverage must be explicit in the feature contract.
An analyst should see why a node or edge exists, when it was valid, which system produced it, and whether it is confirmed or inferred. Case views need timeline, transaction path, shared identifiers, prior decisions, evidence quality, notes, and permitted actions. W3C PROV offers useful concepts for representing entities, activities, agents, and derivation; the exact storage engine matters less than defensible lineage.
Graph convenience can become surveillance sprawl. Define purpose, lawful basis, data minimization, retention, geographic boundaries, tokenization, role-based access, query audit, export controls, and deletion propagation. Separate raw PII from pseudonymous graph identifiers. Sensitive attributes should not become proxy features merely because they improve a retrospective metric.
Measure prevented loss, recovered funds, precision by action, false-positive friction, challenge completion, review time, analyst agreement, label delay, feature freshness, entity-resolution errors, appeal overturns, and impact by customer segment. Offline AUC does not reveal whether the system blocked the right transfer in time or created avoidable exclusion.
An immutable event log; identity and payment adapters; a versioned entity-resolution service; a temporal graph projection; offline graph jobs; a low-latency feature store; a policy engine combining rules, models, and graph evidence; a case workspace; an explanation record; and a label pipeline. Graph storage could be native or projected from relational/event data. The contract and reproducibility matter more than the logo.
A fraud graph is valuable when it converts scattered facts into time-aware, reviewable evidence. It should help a fintech make a proportional decision, reconstruct that decision, investigate connected behavior, and learn from the outcome without turning correlation into guilt.
Article about temporal anti-fraud graphs for regional fintech, entity resolution, instant payments, device and telecom signals, explainable decisions, investigation, privacy, and feedback.