Fraud Data Architecture
The data foundation for transaction fraud: event logging, decision logs, entity resolution, feature stores with point-in-time correctness, graph data, label stores, and retention.
Core components
1. Event logging: the money path as events
Log every state change on the money path, not just transactions. Minimum event families:
| Family | Example events | Why |
|---|---|---|
| Identity and access | sign-up, login success/fail, MFA challenge/result, session created, device enrolled | ATO and farming precursors |
| Account changes | email/phone/address change, password reset, payout destination added/changed, trusted contact change | Highest-signal precursors to payout loss (see Account Change Events) |
| Funding | bank link, ACH debit initiated, card load, check deposit, ACATS in, crypto deposit | Where reversible value enters |
| Value movement | purchase, P2P send, trade, transfer between accounts, reward earned | Where value moves |
| Money-out | withdrawal, payout, redemption, gift card issue, ACATS out | Where loss is realized |
| Settlement and reversal | settle, return (with code), dispute (with reason), chargeback outcome, recall | Labels and exposure |
| Decisions | every rule/model evaluation, score, action, reason codes, versions | Reproducibility and audit |
| Ops | queue assignment, review decision, case notes (coded), enforcement, appeals | Labels, QA, investigations |
| Customer contact | support contact, channel, verification outcome, complaint | Social engineering and scam signals (see Customer Contact Signals) |
Event design rules:
- Make events immutable and append-only, with two timestamps:
event_time(when it happened) andingest_time(when you knew). - Use stable IDs for account, customer, device, instrument, payee, session and transaction, consistent across systems.
- Set up a schema registry and data contracts with product teams. A renamed field silently breaks a fraud rule.
- Capture attempts and failures as well as successes. Failed logins, declined payments and abandoned step-ups are signals.
- Log the raw vendor response (or its hash plus key fields) with the vendor's version. Vendors change scoring under you.
2. The decision log
The decision log is the single most valuable fraud table. It holds one record for every decision point:
| Field | Purpose |
|---|---|
| decision_id, txn/event id, timestamp | Join keys |
| decision point | e.g., payout_request, ach_link, receipt_submit |
| inputs as served | Feature values actually used (or a pointer to a snapshot) |
| rules evaluated / fired, with versions | Rule governance (see Rule Governance and Change Management) |
| model id, version, score, top reasons | Model Risk Management and explainability |
| vendor calls: latency, status, response | Fallback analysis |
| action and reason code | Approve, decline, hold, step-up, review |
| treatment group | Holdout / champion-challenger assignment and propensity |
| latency breakdown | See Real-Time Decisioning Architecture |
Without "inputs as served", you can't reproduce a decision. You can't defend it to a customer, a regulator or a court, and you can't detect training-serving skew.
3. Entity resolution and graph
Fraud rarely stays inside one account. Entity resolution links records that refer to the same real-world thing: person, household, device, bank account, card, address, payee.
- Deterministic links: same instrument fingerprint, same verified bank account, same device ID, same normalized email.
- Probabilistic links: similar names and addresses, shared IP ranges in time windows, behavioral similarity.
- Graph store: nodes (accounts, devices, instruments, payees, addresses, emails, phones) and timestamped edges. It serves real-time features ("accounts sharing this payout destination in 30 days") and investigation views. See Graph Analytics, Entity Link Analysis, Device Reputation and Linkage.
- Edge provenance and expiry: record why two entities were linked and when. Shared IPs in a campus or a mobile carrier's NAT pool create false rings.
4. Features: online, offline and point-in-time correctness
| Layer | Serves | Requirements |
|---|---|---|
| Streaming aggregates | Velocity counters (count/sum by entity over windows) | Exactly-once or idempotent updates; late-event handling |
| Online feature store | Low-latency key lookups at decision time | Single-digit-ms reads; freshness SLAs per feature |
| Offline feature store | Training and backtests | Point-in-time joins: values as they were at the decision timestamp, never later |
| Feature registry | Definitions, owners, lineage | One definition used both online and offline, to avoid training-serving skew |
Useful feature families for transaction fraud (public overview; detailed feature lists live in members playbooks):
| Family | Examples | See |
|---|---|---|
| Tenure and history | Account age, time since last change, prior successful payouts to this destination | Customer Tenure and History |
| Velocity | By account, device, instrument, payee and IP, over multiple windows | Velocity Signals |
| Change-to-money-out timing | Time since contact or payout-destination change | Account Change Events |
| Funding quality | Share of balance from unsettled or reversible funds | Funding Source Signals, Fast In Fast Out Patterns |
| Graph | Degree, shared attributes with known-bad entities, cluster size | Graph Analytics |
| Device and network | Device and IP attributes | Device Fingerprinting, IP Reputation and Proxy Detection |
5. Label store
Covered in Fraud Labeling and Feedback Loops. Architecturally, it's a versioned table keyed by transaction and entity, with event_time and label_time, label source, and supersession. It's joined to the offline store with time-aware logic.
6. Investigation and case data
Case Management Systems need read access to the event log, decision log and graph, and write-back of coded outcomes. Free-text-only case notes are a data dead end.
7. Retention, access and privacy
| Data | Retention driver | Notes |
|---|---|---|
| SAR and supporting documentation | 5 years from filing (BSA) | See BSA-AML and SAR Filing; restricted access |
| CIP records | 5 years after account closure (banks, broker-dealers) | See KYC and Customer Identification Program (CIP) |
| Broker-dealer customer account records | SEC/FINRA books-and-records requirements (e.g., FINRA 4512 retention of prior versions) | See Broker-Dealer Obligations (FINRA and SEC) |
| Decision logs | Dispute windows, regulatory exams, model validation, litigation holds | Usually measured in years |
| Raw device and behavioral telemetry | Model training, privacy minimization | Shorter retention, aggregated features kept longer |
| Stored bank account numbers | Nacha data security: unreadable at rest for covered non-FI parties | Tokenize or encrypt (see Nacha Rules and ACH Risk) |
Apply purpose limitation, role-based access, and pseudonymized analytics views. Fraud-prevention exemptions in privacy laws don't mean "keep everything forever". See Privacy and Data Use in Fraud Prevention.
How to build it
| Stage | What to build |
|---|---|
| Crawl | Centralize money-path events in a warehouse; stable IDs; a basic decision log (decision, score, rules fired) |
| Walk | Event stream; streaming velocity counters; online key-value feature lookups; label table with two timestamps; vendor responses logged |
| Run | Feature registry with shared online/offline definitions; point-in-time training sets; entity resolution and graph features; data contracts with product teams |
| Fly | Real-time graph features; automated freshness and skew monitoring; replay of any decision from logs; privacy-aware access tiers |
Build vs buy. Many fraud platforms bundle a feature store, rules engine and case manager. That's fast to start, but check you can export decision logs and features into your own lake, and that velocity windows and graph features are configurable. See Vendor Selection and Evaluation and Vendor Landscape. Open-source building blocks exist for streaming, feature stores and graph (see Open Source Tools for Fraud Teams).
Artifacts and templates
Data readiness checklist for a new money path
- Every state change on the path emits an event with stable IDs and two timestamps
- Attempts and failures are logged, not just successes
- Decision point writes to the decision log, including inputs as served and versions
- Velocity counters exist for account, device, instrument and destination
- Reversal and settlement events (returns, disputes, recalls) are joined back to the originating event
- Labels for this path have a defined source and maturity window
- Retention and access set with compliance and privacy
- Product schema changes require a fraud data-contract review
Data quality monitors
| Monitor | Alert when |
|---|---|
| Event volume per type | Drops or spikes vs seasonal baseline (often a logging break with no fraud behind it) |
| Null/default rate per feature | Rises above baseline |
| Feature freshness | Online values older than SLA |
| Online/offline skew | Distribution distance between served and recomputed values |
| ID join rate | Events failing to join to account/device/instrument |
| Vendor response rate and latency | Timeouts or empty responses rise |
Metrics
- Decision reproducibility rate: share of sampled decisions that can be exactly replayed from logs
- Feature freshness SLA attainment and skew incidents per quarter
- Event coverage: money-path state changes with events / total known state changes
- Join coverage: losses and labels successfully joined to originating decisions
- Time to new feature: idea to production, in days
Pitfalls
- Logging only approved transactions. You lose attempts, declines and attack shape.
- Recomputing training features from current tables. This causes point-in-time leakage.
- Separate online and offline feature code. Training-serving skew is guaranteed.
- No stable device or payee IDs. Linkage collapses and graph features become noise.
- Treating vendor scores as immutable. Log versions; vendors retrain.
- Retention by default. Keeping raw telemetry indefinitely raises privacy and breach exposure. Keeping decision logs for too short a time loses defensibility.
Related
- Real-Time Decisioning Architecture · Fraud Labeling and Feedback Loops · Fraud Metrics and KPIs
- Rules Engine · Machine Learning Models · Graph Analytics · Case Management Systems · Entity Resolution
- Privacy and Data Use in Fraud Prevention · BSA-AML and SAR Filing
- Vendor Selection and Evaluation · Open Source Tools for Fraud Teams
Sources and further reading
- Federal Reserve SR 26-2 attachment, Revised Guidance on Model Risk Management (Apr 2026): data and documentation expectations underpinning model validation and outcomes analysis
- FFIEC BSA/AML Manual, Suspicious Activity Reporting: five-year SAR and supporting-documentation retention
- FFIEC BSA/AML Manual, Customer Identification Program: CIP record retention (five years after account closure)
- Nacha, Supplementing Data Security Requirements: stored account numbers must be unreadable at rest for covered parties
- FINRA Rule 4512: retention of prior versions of customer account information
- COSO/ACFE Fraud Risk Management Guide, 2nd ed., Executive Summary (2023): data analytics as a cross-cutting point of focus