Blueprint: transaction monitoring
Follow the money trail across multiple hops.
Model TRANSACTION, ACCOUNT, DEVICE, MERCHANT, COUNTERPARTY, ALERT, and KYC_PROFILE records as connected data so an investigation can traverse from a single ALERT through shared deviceId or accountId values across several hops. Instead of rebuilding joins per case, the graph already holds the paths between transfers, accounts, and the devices or counterparties they share.
Transaction monitoring on RushDB is a blueprint for fraud and AML investigation graphs that connect TRANSACTION, ACCOUNT, DEVICE, MERCHANT, COUNTERPARTY, ALERT, and KYC_PROFILE records so investigators can traverse shared identifiers across multiple hops instead of rebuilding joins by hand.
Suspicious activity rarely stays inside one table.
Fraud and AML teams start with one ALERT, like aml-778 on account acct-901, then need to pivot through shared devices such as dev-22, mule accounts like acct-417, beneficiary identifiers, merchants, IPs, and KYC_PROFILE data. In flat feeds, every one of those pivots is a new SQL join, and any relationship nobody thought to join in advance becomes a blind spot the investigator never sees, letting a laundering ring stay split across accounts that look unrelated.
Before
- Rules fire on isolated transactions
- Investigators pivot manually across accounts, devices, merchants, and counterparties
- Shared identifiers arrive as flat fields without durable relationships
- Multi-hop investigations require ad hoc SQL joins or graph exports
With RushDB
- Transactions, accounts, devices, merchants, counterparties, alerts, and KYC profiles stay connected
- Multi-hop traversal exposes mule paths, shared-device clusters, and circular flows
- Suggested relationship patterns surface likely joins such as accountId, deviceId, merchantId, and beneficiaryId
- Investigators review and approve relationship patterns before future writes depend on them
Graph intelligence on ingest
Incoming data becomes queryable graph context.
TRANSACTION records carrying fromAccountId, toAccountId, deviceId, amount, and riskScore arrive alongside ALERT and DEVICE payloads referencing the same identifiers. RushDB types riskScore and amount as numeric on ingest and treats accountId, deviceId, and merchantId as candidate relationship keys rather than opaque flat strings.
01
Normalize as data arrives
TRANSACTION, ALERT, and DEVICE records are typed on arrival so riskScore, amount, and fingerprint are immediately filterable without preprocessing.
02
Auto-link nested structure
When a TRANSACTION payload nests ACCOUNT and DEVICE details, those become traversable relationships instead of duplicated flat fields on import.
03
Enrich scattered sources
Suggested relationship analysis surfaces repeated accountId, deviceId, merchantId, and beneficiaryId keys across feeds so analysts can approve durable joins for future alerts.
Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.
Review suggested relationship patternsData model
One flexible graph for the workflow.
Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.
Flat transaction feeds, device events, and KYC records can become reviewed relationship patterns before future writes rely on them.
{
"alertId": "aml-778",
"reason": "rapid movement after incoming transfer",
"TRANSACTION": {
"transactionId": "txn-4481",
"fromAccountId": "acct-901",
"toAccountId": "acct-417",
"deviceId": "dev-22",
"merchantId": "remittance-12",
"amount": 9800,
"riskScore": 84
},
"ACCOUNT": {
"accountId": "acct-901",
"KYC_PROFILE": { "kycId": "kyc-901", "country": "GB", "riskTier": "high" }
},
"DEVICE": { "deviceId": "dev-22", "fingerprint": "ios-7f3" },
"MERCHANT": { "merchantId": "remittance-12", "category": "money_transfer" }
}Working example
Start from one alert. Traverse the ring.
A rapid-movement alert points to one transfer. From there, the investigation follows the account to a shared device, then to other accounts and transactions that may belong to the same fraud or laundering pattern.
ALERT aml-778
accountId: acct-901
transactionId: txn-4481
reason: rapid movement after incoming transfer
TRANSACTION txn-4481
fromAccountId: acct-901
toAccountId: acct-417
deviceId: dev-22
amount: 9800
riskScore: 84
DEVICE dev-22
fingerprint: ios-7f3{
"labels": ["TRANSACTION"],
"where": {
"riskScore": { "$gte": 70 },
"ACCOUNT": {
"accountId": "acct-901",
"DEVICE": { "fingerprint": "ios-7f3" }
}
},
"limit": 25
}[
{
"transactionId": "txn-4481",
"path": "acct-901 -> txn-4481 -> acct-417",
"sharedDevice": "dev-22",
"riskScore": 84
},
{
"transactionId": "txn-4510",
"path": "acct-377 -> txn-4510 -> acct-417",
"sharedDevice": "dev-22",
"riskScore": 79
}
]TypeScript SDK
Traverse reviewed relationships, not one-off joins.
Keep alert-driven investigation queries label-scoped and capped. Let suggested relationship patterns help analysts find repeatable joins, then approve only the patterns that match the data dictionary and compliance policy.
from rushdb import RushDB
db = RushDB('RUSHDB_API_KEY')
paths = db.records.find({
'labels': ['TRANSACTION'],
'where': {
'riskScore': {'$gte': 70},
'ACCOUNT': {
'accountId': 'acct-901',
'DEVICE': {'fingerprint': 'ios-7f3'}
}
},
'limit': 25,
})Implementation blueprint
Build the investigation graph.
Use this sequence to move from flat transaction feeds to reviewable relationship patterns and repeatable fraud or AML investigation paths.
- 01Import ACCOUNT, TRANSACTION, DEVICE, MERCHANT, ALERT, and KYC_PROFILE records
- 02Review suggested relationship patterns for accountId, deviceId, merchantId, and beneficiaryId
- 03Approve patterns that match your data dictionary and investigation policy
- 04Run label-scoped multi-hop traversals from alerts
- 05Store investigator decisions, evidence, SAR references, and false-positive outcomes as records
Build path
- Use TRANSACTION records for transfers, card events, payouts, deposits, and withdrawals.
- Connect ACCOUNT, DEVICE, MERCHANT, COUNTERPARTY, and KYC_PROFILE records through reviewed relationships.
- Keep traversal depth, time windows, and result limits explicit in investigator-facing endpoints.
- Store investigation outcomes as evidence. Do not treat graph proximity as a fraud verdict.
Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
Suggested relationship patterns
Surface candidate joins from repeated identifiers such as accountId, deviceId, merchantId, and beneficiaryId.
Open docsRelationships API
Attach reviewed relationships between accounts, transactions, devices, merchants, alerts, and case evidence.
Open docsRelationships
Use graph traversal to move from one alert to connected records across multiple investigation hops.
Open docsRelated guides
Read the concept before implementation.
These guides explain the category, tradeoffs, and related RushDB features behind this workflow.
How it works
Build the smallest useful workflow first.
01
Ingest operational records
Store transactions, accounts, devices, merchants, KYC profiles, sanctions-screening hits, and rule alerts as typed records.
02
Review suggested relationships
Use recurring identifiers to find candidate relationship patterns, then approve only the joins that are valid for your data model.
03
Run multi-hop investigations
Start from an alert and traverse through accounts, devices, counterparties, merchants, and prior decisions with strict limits.
Know where it fits.
Traversal reduces pivot cost
The practical win is not magic detection. It is faster evidence gathering when the third or fourth hop matters to the case.
Suggestions stay reviewable
Suggested relationship patterns are useful because fraud feeds are full of repeated IDs, but approved relationships should still reflect policy and domain review.
Questions developers ask.
Next step
Start with one focused workflow.
Related use cases
Explore all use cases