Ongoing Customer Wallet Monitoring: Setting the Right Alerts

This is part 3 of our "Tools for Compliance" series. Part 1, Travel Rule, End-to-End, covered the originator/beneficiary workflow; part 2, Real-Time Sanctions Screening, covered the per-transaction check. This one moves from the point-in-time check to the thing that runs in between every check — continuous monitoring of customer wallets, and the alert calibration that decides whether your analyst queue is a control or a graveyard.

Sanctions screening fires at a moment: a deposit lands, a withdrawal is requested, a list updates. Ongoing monitoring is the control that watches the customer between those moments. The AMLR makes it an explicit, standalone obligation — a CASP must monitor the business relationship throughout its lifetime, not just clear it at the gate. The hard part is not deciding to monitor. It is deciding what to alert on, at what threshold, so that the signals an examiner expects you to catch surface above the noise of normal customer behaviour.

A monitoring programme that alerts on everything alerts on nothing: the analyst queue fills with false positives, real signals get closed in bulk, and the audit trail shows alerts generated but not meaningfully reviewed. Below is the obligation, the alert categories, the calibration logic NCAs ask about, and the investigation path from alert to SAR.

Why Monitoring Is Its Own Control

Onboarding diligence and per-transaction screening are point-in-time controls. The AMLR's ongoing-monitoring obligation (Art. 21) is a duration control: the CASP must scrutinise transactions undertaken throughout the relationship to ensure they are consistent with the customer's risk profile and known source of funds, and must keep that profile up to date. MiCA reinforces this for CASPs through its governance and risk-management requirements — the monitoring system is part of the internal control framework an NCA expects to see operating.

The distinction matters operationally. A customer who screened clean at onboarding and clean on every individual deposit can still be the subject of a SAR — because the pattern across those clean transactions is what triggers suspicion. Structuring, sudden volume changes, new exposure to a high-risk counterparty, dormancy followed by a burst — none of these is a single bad transaction. They are only visible if something is watching the relationship over time.

The Alert Categories You Have to Run

A defensible monitoring programme runs a set of rule categories, each mapped to a recognised typology. The categories below are the floor, not the ceiling — a risk-based programme adds rules specific to its customer base and product mix:

• Threshold & structuring — transactions above a value threshold, and patterns of transactions just below a reporting threshold designed to avoid it (smurfing)
• Velocity & volume anomalies — a sudden change in transaction frequency or value relative to the customer's established baseline, including dormancy-then-burst
• Counterparty risk exposure — funds moving to or from addresses linked to sanctioned entities, mixers, darknet markets, high-risk exchanges, or known fraud clusters — including newly-designated entities the customer touched before the designation
• Behavioural inconsistency — activity that doesn't fit the declared profile: a retail customer moving institutional volume, a stated long-term holder making rapid round-trip transfers
• Cross-chain & obfuscation patterns — bridge-hopping, chain-peeling, conversion to privacy assets, or rapid movement designed to break the transaction graph
• Geographic & jurisdictional triggers — exposure to high-risk jurisdictions or to VASPs in non-cooperative regimes

Each rule must have a documented rationale — the typology it targets, the threshold, and why that threshold is set where it is. "We alert on transfers over EUR 10,000" is a rule; "we alert on transfers over EUR 10,000 because [risk rationale], reviewed quarterly against our SAR conversion data" is a control.

Calibration: The Difference Between a Queue and a Graveyard

Calibration is where most monitoring programmes quietly fail. Set thresholds too tight and the queue floods with false positives; analysts close them in bulk, and the one real alert dies in the batch. Set them too loose and the system never fires on the activity it was built to catch. NCA examiners probe this directly, and the questions are specific:

• What is your false-positive rate, and how do you know? A programme that can't state its FP rate can't demonstrate it tuned anything.
• How are thresholds derived? Risk-based and documented, or inherited from a vendor default nobody revisited?
• How often are rules back-tested? Against actual SAR outcomes — do the rules that fire most also convert to SARs, or are they pure noise?
• Is there segmentation? A single threshold across retail and institutional customers is a calibration failure by construction.
• Who can change a threshold, and is it logged? A loosened threshold with no change record is an audit finding waiting to happen.

What You Actually Monitor: Data & Touchpoints

Monitoring a customer wallet is not a single feed. A complete picture requires several data sources kept continuously in sync:

1. On-chain activity, in near-real-time

Every inbound and outbound transfer on every chain the wallet uses. A customer's ETH activity tells you nothing about their TRON or Solana exposure — monitoring has to be cross-chain or it has a hole the size of whatever chain you didn't watch. This means subscribing to address activity across chains and reconciling it against the customer record.

2. Risk-graph re-evaluation

A counterparty that was unlabelled last week can be attributed to a sanctioned cluster this week. Monitoring isn't just "did the customer transact" — it's "did the risk of anything the customer has already touched change." This is the same continuous-re-screening logic from the sanctions piece, applied to the customer's whole transaction graph rather than a single check.

3. Profile & behavioural baseline

The expected-activity profile captured at onboarding — volumes, counterparty types, geographies — is the baseline every anomaly rule measures against. A monitoring system without a baseline can flag "large transfer" but not "large transfer for this customer," which is the only version that's useful.

4. List & designation feeds

Sanctions and high-risk-entity updates feed monitoring the same way they feed screening — a new designation should retroactively light up every customer with prior exposure.

From Alert to SAR: The Investigation Path

An alert is the start of a workflow, not the end of one. The path examiners walk:

1. Triage & enrichment — the alert is enriched with customer context (profile, KYC, history) and on-chain context (counterparty labels, hop analysis, cluster attribution) so the analyst isn't starting from a bare address
2. Analyst review — a trained analyst dispositions the alert: false positive, monitor-and-continue, or escalate — with a documented rationale in every case, including the closed ones
3. Enhanced due diligence — for escalations, deeper review: source-of-funds enquiry, customer outreach where appropriate, expanded transaction tracing
4. MLRO decision — the MLRO determines whether the suspicion meets the threshold to file a SAR with the FIU, and whether any freeze or restriction applies
5. SAR filing & tipping-off — filed within the jurisdiction's deadline; the customer must not be informed (AMLR Art. 54), and front-line staff must be trained on that prohibition

The deficiency auditors find most often is not a missed alert — it is an alert that fired, was closed as no-action, and has no recorded reason why. An alert with no disposition rationale is indistinguishable, on the record, from an alert nobody looked at.

How BA Does It

BA's wallet monitoring watches customer addresses continuously across 80+ chains. Each monitored wallet is subscribed to on-chain activity through a multi-provider feed, so a single provider outage doesn't create a blind spot — the system fails loud, not silent. Inbound and outbound transfers are evaluated in near-real-time against the BA risk graph of 1B+ labelled addresses, including the clusters attached to sanctioned and high-risk entities, so a counterparty re-attributed this week lights up every wallet that touched it — including exposure that predates the designation.

Alerts carry the enrichment an analyst needs to disposition them: the counterparty label, the hop distance, the cluster, and the customer's own baseline — not a bare address. Thresholds and rule categories are configurable per customer segment, and every alert, disposition, and rationale is recorded for the AMLR's 5-year retention window. The point isn't more alerts; it's alerts you can action and defend.

Next in the series: Tools for Compliance #4 — KYT for Stablecoin Issuers, where we move from watching customer wallets to the issuer's side of the glass: what BA sees when USDT or USDC freezes an address, and how a stablecoin issuer runs Know-Your-Transaction at the contract level.