AML / BSA Transaction Monitoring Data Field Checklist
Transaction monitoring quality is bounded by the data the engine sees. A monitoring system fed only 'amount + date + counterparty' will catch the obvious structuring patterns and miss the typologies that involve cross-account aggregation, third-party-funded purchases, or layered transfers across asset classes. This checklist enumerates the data fields, flags, and event signals your monitoring system needs to evaluate the canonical FinCEN typologies. It's mapped to the typology library in FFIEC's BSA/AML examination manual and recent published consent orders.
Customer profile (the 'expected behavior' baseline)
- Source of funds (account-opening) and source of wealth (lifetime)
Two distinct fields. Source of funds is the origin of the deposit at opening (salary, inheritance, business sale). Source of wealth is the lifetime narrative. Monitoring rules need both to evaluate whether observed activity matches expected.
kyc.source_of_funds, kyc.source_of_wealth - Expected activity profile
Documented expected transaction volume, value, and counterparty mix at opening. Without this baseline, every alert is 'unusual vs. statistical population' instead of 'unusual vs. this customer's stated expectations.'
kyc.expected_activity.{monthly_volume, avg_txn_value, counterparty_categories[]} - Risk rating with revision trail
Customer risk rating (low / medium / high) with the specific factors driving it (geography, occupation, product, PEP status) and a versioned trail of rating changes. High-risk customers get a tighter monitoring threshold.
kyc.risk_rating, kyc.risk_factors[], kyc.risk_rating_history[] - PEP, sanctions, and adverse-media flags
Per OFAC and FinCEN guidance, screening status with refresh date for politically-exposed persons, sanctions matches, and adverse-media hits. Stale screens (>quarterly) are an exam finding.
kyc.pep_status, kyc.sanctions_screen_date, kyc.adverse_media_hits[]
Transaction-level fields (the activity signal)
- Originator and beneficiary identification
Both sides of every transaction with sufficient identification — for wires per Travel Rule, name + account + address. Same-account transfers within the household graph still need both sides.
txn.originator.{name, account, address}, txn.beneficiary.{...} - Counterparty categorization
Categorical tag for the counterparty type (retail payee, wholesale, retail-business-merchant, P2P payment, crypto exchange, money services business). MSB and crypto-exchange counterparties are typology-relevant.
txn.counterparty_category - Funding source and destination type
For each transaction, the funding source (cash deposit, ACH from external account, wire, internal transfer) and destination type. Cash + structuring-amount + retail-payee is the canonical structuring signal.
txn.funding_source, txn.destination_type - Geography fields (originator + beneficiary + intermediary)
Country fields for all three parties. High-risk-jurisdiction routing (per FATF + OFAC) is the canonical layering signal.
txn.originator_country, .beneficiary_country, .intermediary_countries[]
Cross-account & household-level aggregation
- Household graph for related-party rollup
Documented relationship graph between customers — joint accounts, beneficial owners of the same entity, shared address, shared SSN. Structuring detection that misses cross-customer aggregation misses the most common evasion pattern.
household_graph.related_customers[] - Cross-product activity rollup
Customer activity rolled up across deposit accounts, brokerage accounts, lending products, and payment products. Layering that crosses product boundaries within the institution is invisible to product-siloed monitoring.
customer.cross_product_activity_view - Beneficial-owner chain for entity accounts
For entity accounts, the chain from the legal-entity account through to the natural-person beneficial owners (FinCEN CDD rule). Activity must roll up to the natural person for typology evaluation.
entity_account.beneficial_owner_chain[]
Pattern-detection signals (the typology fires)
- Structuring indicators
Per FinCEN Advisory FIN-2014-A005, indicators include multiple sub-CTR-threshold cash deposits in short windows, deposits across multiple branches, and deposits split between related accounts. Each indicator should be a field, not derived ad-hoc by analysts.
monitoring.structuring_indicators[] - Funnel-account indicators
Per FFIEC, deposits from many sources followed by quick wire-out to a single beneficiary. Detecting requires lookback aggregation across deposit sources.
monitoring.funnel_account_score - Rapid-movement indicators
Funds in / funds out within hours-to-days with little or no apparent business purpose. Common in trade-based money laundering and crypto-related layering.
monitoring.rapid_movement_score - Activity inconsistent with stated profile
Aggregate activity that materially exceeds the documented expected profile. Without the expected profile from the customer-profile section, this signal can't fire.
monitoring.profile_inconsistency_flag
Investigative artifacts (the audit trail)
- Alert disposition with documented rationale
Every alert generated by the monitoring system has a disposition (closed-no-action / closed-with-monitoring / SAR-filed / SAR-considered-not-filed) with a documented rationale. 'No-action' alerts must show the analyst's reasoning.
alerts[].id, .disposition, .rationale, .reviewer, .reviewed_at - SAR filing record with continuation flags
Per BSA, SAR filings with timestamp, narrative, and continuation-SAR flags for ongoing activity. Continuation SARs filed every 90 days for ongoing patterns.
sars[].filing_date, .subject_id, .narrative, .continuation_chain[] - Investigation case file links
For SAR-filed alerts, link to the investigation case file with the supporting transaction list, customer interaction log, and reviewer chain. The case file is the artifact regulators request first.
alerts[].case_file_url
Key takeaways
- Monitoring quality is bounded by data quality. A system fed only amount + date + counterparty cannot evaluate FinCEN's published typologies — it can only catch the most obvious structuring.
- The 'expected activity profile' field is the single highest-leverage data input. Without a documented baseline, every alert is statistical-population-relative instead of customer-relative.
- Cross-account and cross-product aggregation is required to catch the most common evasion pattern. Product-siloed monitoring is the modal regulator finding for mid-stage fintechs.
- The audit trail (alert disposition + rationale + case file) is the artifact regulators evaluate first. Without it, having sound alerts is invisible to the examination.