AML Surveillance Runs on Data: Checking What Your Monitoring Can't See
Updated October 2026. First published April 2024.
Our 2024 version of this post described data analytics against financial crime in general terms: machine learning, blockchain, the history of bookkeeping. This version is narrower and, we think, more useful. A broker-dealer's anti-money laundering (AML) monitoring can only see the data it receives. When a feed is missing, the alerts that depend on it never fire, and nobody may notice until an examiner does.
FINRA now says this in plain terms. Its 2026 Annual Regulatory Oversight Report, published December 9, 2025, lists as an effective practice "Periodically assessing alerts or exception reports to confirm they are functioning as intended," which it describes as detecting the suspicious activity they were built for and "properly ingesting the required data." Among its findings are firms that didn't tailor their AML programs, including monitoring processes and tools, to their business, and firms that didn't investigate red flags their clearing firm raised about an introduced customer.
The Rules the Data Serves
FINRA Rule 3310 requires policies and procedures "that can be reasonably expected to detect and cause the reporting" of suspicious transactions, and independent testing of the program every calendar year for most firms.
The reporting itself is FinCEN's rule for broker-dealers, 31 CFR 1023.320. A firm must file a suspicious activity report (SAR) on a transaction of at least $5,000 that it knows, suspects, or has reason to suspect involves funds from illegal activity, is designed to evade Bank Secrecy Act requirements, has no apparent lawful purpose, or uses the firm to help commit a crime. The SAR is due no later than 30 calendar days after the initial detection of facts that may support a filing. If no suspect has been identified, the firm can take another 30 days, but never more than 60 in total. The firm keeps the SAR and its supporting documents for five years, and the SAR is confidential.
Both rules assume the firm can see the activity. When data is missing, the result usually isn't a late SAR. The facts are never detected at all, and the failure shows up later as a program that wasn't reasonably designed.
Each Red Flag Needs Its Own Data
FINRA's Regulatory Notice 19-18 lists red flags for suspicious activity. Most of them are patterns in data a broker-dealer already holds somewhere. The question is whether all of it reaches the monitoring system on time. A few examples from the notice, with the data each one depends on:
| Red flag (Notice 19-18) | Data the alert needs | What to check |
|---|---|---|
| Wire transfers in small amounts, apparently to avoid triggering identification requirements | Every outgoing and incoming wire, with amounts, dates, and parties | Wires from every platform you use, including any added since the surveillance was set up |
| Excessive journal entries between related or unrelated accounts | Journal entries and the relationships between accounts | Whether journals between your firm's own entities, or through omnibus accounts, reach the feed |
| Frequent changes to the bank account details for redemption proceeds | Account maintenance history for standing instructions | Whether instruction changes are logged as events, or only the current value is stored |
| A deposit followed right away by a request to wire the money out | Deposits and withdrawals, with time stamps | Whether the two arrive in the same feed, or in separate feeds that never get joined |
| An account used for payments or outgoing wires with little or no securities activity | Money movement and trading activity, by account | Whether trade data and cash data share an account key the system can match |
| A dormant account that suddenly becomes active | Activity history long enough to define "dormant" | How many months of history the system actually keeps |
| A customer address associated with multiple other accounts | Customer records across every account system | Whether accounts opened through a second channel or a correspondent show up in the same customer data |
Checks Worth Running
None of these requires new software. They do take time from someone who understands both the data and the alerts.
- Draw the data map. For each surveillance scenario, list the source system, the fields it uses, and how the data gets there. Keep the map with the AML procedures, and update it when a system changes.
- Reconcile volumes. Each month, compare the record counts that left each source system with the counts the surveillance system loaded. A file that silently stops arriving is easy to miss in the alerts and easy to catch in the counts.
- Test scenarios from end to end. Put a known pattern through in a test environment, such as a deposit followed by an immediate wire out, and confirm the alert fires. That is the test behind the FINRA report's phrase "functioning as intended."
- Make new systems part of the AML change process. A new wire platform, a new account type, or a new correspondent relationship should not go live until someone has asked what it means for the feeds.
- Treat inquiries from your clearing firm as data. FINRA's findings include introducing firms that didn't follow up when their clearing firm flagged an introduced customer. Log each inquiry with the date and what you found.
If clients execute trades elsewhere and settle them with your firm, the data problem has another layer, because the execution record sits at another firm. Our post on AML for done-away trades covers that case.