AML transaction network monitoring

Transaction-network monitoring exists to surface coordinated money-flow that single-leg rules miss: accounts that look ordinary in isolation, yet move value through the same counterparties, in the same windows, along the same corridors. The output is a quality alert. It names the accounts (nodes) and the payment relationships (edges) that made the pattern unusual. An analyst still dispositions it.

This is not a filing engine. Graph scores and community labels are investigation prompts. They are not a finding of layering, not a typology match, and not a reason to auto-file. If the model cannot point to which accounts and which booked transfers drove the score, the alert is not ready for the queue.

Production systems in this class (Google AML AI, NICE Actimize, and comparable graph AML platforms) sit on booked payment history and entity graphs. Treat them as a family of approaches, not a ranking. No platform detects a ring as a finished fact. The bank still owns typology mapping, thresholds, and the human decision.

Network monitoring is not the same job as real-time transaction fraud scoring. Fraud scoring asks whether this payment should be held or released now. AML network monitoring asks whether already-booked movements, read together, look coordinated enough to investigate. Mixing those clocks produces the wrong queue and the wrong evidence pack.

Start from the ledger, not from a narrative. Nodes are accounts you can identify in core: customer accounts, internal nostro/vostro, known merchants, and counterparties with a stable identifier (account number plus bank, or a legal entity you already KYC'd). Edges are booked payments: amount, currency, value date, origination and destination, channel, and payment message fields you actually persist (purpose codes, correspondent chain, originator and beneficiary names as recorded).

Build the graph after posting, or from a posting-complete extract with a known lag. In-flight authorizations, declined attempts, and reversed holds do not belong on the AML graph until they become booked (or booked-then-reversed) events with an auditable id. If you mix pre-posting fraud telemetry into the same graph, you will cite edges that never existed on the books.

Keep attributes that explain concentration without implying guilt: payroll indicators, product type, onboarding date, and KYC risk band. Those attributes exist so you can suppress ordinary fan-outs later. They are not evidence of a network.

Each edge needs a stable payment id so an investigator can pull the original message or internal transfer. When an account is new or thinly documented, do not invent missing counterparties. Leave the node sparse and let perpetual KYC refresh and onboarding files supply identity later. Graph models that impute hidden members from a shared device or address manufacture a ring you cannot defend.

The signal is coordination: multiple accounts moving as if they share a plan, on a timescale and topology that is rare for their product and corridor. Score the subgraph, not the loudest account. A graph model should name which edges, among which accounts, in which window, drove the alert. If the explanation collapses to one node, you have a customer-level hit, not a network hit.

Use these ingredients together, not as single rules. Burst timing: many first-time counterparties in a short window, then a rapid onward hop. Shared bottleneck: unrelated originators concentrating into one newly active account, then dispersing. Corridor reuse: the same correspondent or beneficiary cluster across accounts with no stated reason to share it. Role flip: an account that mostly received now mostly sends, still tied to the same subgraph.

Illustrative example, not a confirmed typology: several recently opened retail accounts each book same-day credits into one operating account at your bank, in amounts that sit just under a local reporting comfort line. That operating account then books two outward payments via the same correspondent to beneficiaries you have not seen from this product set. The alert should list those originators, the operating account, the two outward legs, value dates, and amounts as booked. It should not name a criminal organization, assign a mule-ring label, or claim the beneficiaries are shells. The investigator first asks whether this is a collection arrangement, a family pooling remittances, a marketplace settlement, or activity that still looks unexplained after those hypotheses.

That is also where mule account detection at top-up belongs as a sibling control, not a substitute. Mule detection often fires on funding or top-up of a pass-through account. Network monitoring fires when pass-through behavior is distributed across many booked legs. One score for both jobs will miss the distributed pattern or double-alert the same customers.

Payroll fan-out will burn the queue if you ignore product. A corporate salary account paying employees on payday is a star: coordinated in the graph sense and ordinary in the business sense. Encode payroll product, batch channel, and repeating payees, then suppress or re-route those subgraphs with evidence (batch id, employer flag, repeating beneficiary list). Do not leave them in the AML queue to be explained after the fact.

Shared address is not a ring. Students, multi-tenant buildings, registered-office providers, and households share addresses. Treating same address or same device as laundering membership cites edges that are not payments. Keep identity overlays as analyst context. You did not discover a ring. You discovered co-location.

Every alert must carry cites the way a rule alert carries transaction ids.

Node list: account ids, customer ids, product, open date, KYC status, and whether the node is a bank customer or an external counterparty. Edge list: payment ids, booked amounts and currencies, value dates, direction, channel, and correspondent identifiers on the message. Why-this-subgraph: a short statement such as first-time concentration into a named account from multiple originators, then outward legs on the same value date, not a bare risk score. Negative context: payroll-like batch flags, repeating legitimate payees, known merchants, so the analyst does not rediscover the obvious.

The investigator should go from a node to the account, from an edge to the payment, and from the subgraph to a timeline. Connected dots plus a numeric score are a visualization, not a quality alert.

Do not pre-label the subgraph as a ring, a layering cell, or a numbered typology. Those words belong in the case narrative after disposition, if supported. Putting them on the alert trains staff to file what the model appeared to know.

When the same customers already sit in an open case, attach the new subgraph rather than opening a parallel network alert.

Route the cited subgraph to AML investigations with the same ownership rules you use for other quality alerts: dual control on filing decisions, documented alternative explanations, and an explicit close reason when the pattern is explained (payroll, household, marketplace, correspondent cover). The graph does not file. The analyst files, or the analyst closes.

Filing from the graph score alone will not survive a regulatory sample. A score without cited legs cannot show why this activity was unusual, what you collected, and why you discounted the legitimate story. A score with cites is still not a suspicious activity report. It is the starting exhibit. Disposition may still conclude the pattern is a known collection, or pass-through consistent with the customer's stated business, after invoices, a relationship-manager conversation, or KYC refresh.

If the subgraph involves accounts that were just funded, hand the evidence pack to AML case disposition at funding rather than treating network monitoring as a second, unsupervised filer. Funding-stage disposition and transact-stage network alerts should share case ids and payment cites so the bank tells one story.

Every disposition should tag whether the cites were sufficient, whether the subgraph was a payroll or address artifact, and whether the model should have been suppressed. That feedback keeps graph AML in the quality-alert class instead of an un-triageable firehose.