The Question at Hand
You're planning to replace your manual transaction monitoring process with an automated system. The vendor demos look impressive, and the business case is approved. But here's the uncomfortable question: should you clean up your data feeds and customer risk profiles first, or let the new system inherit what you have and fix things later?
UBS Financial Services chose the second path. Between January 2019 and June 2023, the firm failed to monitor more than 60,000 foreign-currency wires worth over $10 billion. About 33% of foreign-currency wires in retail customer accounts never reached the monitoring system. FinCEN imposed a $125 million civil penalty, the largest ever against a broker-dealer under the Bank Secrecy Act. FINRA, the SEC, and the CFTC added another $48 million in coordinated enforcement actions.
The automation didn't create the problem. UBS's manual quarterly report already omitted relevant geographic information and couldn't identify suspicious patterns. But the new system inherited those gaps, and the firm treated deployment as completion rather than as the start of validation work.
This isn't a rare edge case. It's a fundamental choice every compliance program faces when modernizing surveillance infrastructure.
The Case for Automating First
Deploying your new monitoring platform before addressing every data quality issue has practical merit.
You can't fully understand your data problems until you try to use the data. Manual processes hide gaps because humans compensate for missing fields, inconsistent formats, and incomplete records without documenting what they're doing. An automated system forces you to define every field mapping, every exclusion rule, and every transformation. The failures become visible and measurable.
Delaying automation to "get the data ready" often means the project never launches. Data remediation expands to fill available time. Business units resist changing how they capture information. IT priorities shift. Meanwhile, you're still running the inadequate manual process that prompted the automation project in the first place.
There's also a resource reality. You need the new system's reporting capabilities to identify what's missing. Your current infrastructure probably can't produce the reconciliation reports, coverage metrics, and gap analyses you need to scope the remediation work properly. Deploy first, measure the delta, then fix what matters most.
Regulatory pressure adds urgency. Examiners expect you to have automated monitoring appropriate to your risk profile and transaction volume. Explaining that you've delayed implementation to perfect your data sounds better than it reads in an exam report. At least with a system in place, you can demonstrate forward progress and show a remediation roadmap.
The Case for Fixing Data First
The counterargument is equally compelling: automation locks in whatever you feed it.
Transaction monitoring systems process every record they receive correctly while missing material activity that never arrives. If your data feeds exclude 33% of in-scope transactions, your new platform will monitor 67% very efficiently and create a compliance record that looks complete. Unlike humans, the system won't notice what's absent.
UBS had already faced regulatory action over foreign-currency wire monitoring in 2018. The firm deployed a new automated system in 2021. The same data gaps persisted. That's not a technology failure. That's a remediation failure disguised as a technology upgrade.
Customer risk ratings determine alert thresholds, scenario sensitivity, and review prioritization. If your customer due diligence process still carries stale domicile information, missing political exposure flags, or outdated risk classifications, your monitoring rules will make decisions based on wrong assumptions. Automating bad inputs produces bad outputs at scale.
The technical debt compounds quickly. Once your monitoring system is live, changing field mappings or data sources requires regression testing, scenario revalidation, and documentation updates. Every downstream report and investigation workflow depends on the current structure. What seemed like a temporary workaround becomes permanent infrastructure because the cost of changing it keeps rising.
There's also an evidentiary problem. Regulators expect you to demonstrate which transactions entered your system, how the system treated them, and whether cases reached investigation and reporting within required timeframes. If you can't reconcile your source population with your monitored population, you can't answer the first question. That gap undermines every control downstream.
Where Practitioners Actually Land
Most compliance programs end up in the middle, though not by design.
They deploy the new monitoring system with known data limitations, document those limitations formally, and commit to remediation within defined timeframes. The documentation matters. UBS's problem wasn't just the data gaps. It was treating system deployment as project completion rather than as the start of validation work.
Effective implementations include end-to-end reconciliation before go-live. You don't need perfect data, but you need to know what you're missing. Count transactions at the source system. Count transactions in the staging layer. Count transactions that reach the monitoring platform. Document exclusions with business justification and review dates. If 15% of wires drop out during transformation, that's a control finding that needs escalation and remediation tracking, not a configuration note buried in technical documentation.
Customer risk data requires separate attention. You can phase transaction types into monitoring gradually, but you can't phase customer risk. Either your platform uses accurate risk ratings to set thresholds or it doesn't. Firms that succeed typically freeze new customer onboarding into the automated system until risk profiles meet minimum data quality standards, then backfill existing customers in risk-ranked order.
The regression testing discipline separates programs that maintain control from programs that drift. Every field mapping change, every new transaction type, every scenario modification needs testing that proves previously monitored activity still reaches the system. Configuration changes are where automation breaks silently.
Our Take
Fix enough to know what you're not fixing, then automate with formal remediation commitments.
The UBS enforcement action doesn't prove that automation is risky. It proves that migration without reconciliation is risky. Installing a new analytical engine while ignoring incomplete source data and weak customer risk controls just moves the failure point from a manual process to an automated one.
But waiting for perfect data before deploying monitoring technology isn't realistic either. You need the system's capabilities to measure the gaps properly and to demonstrate regulatory progress.
The control that matters is reconciliation: source population to monitored population, with documented exclusions, approved risk acceptance for temporary gaps, and measurable remediation timelines. If you can produce that evidence, you can automate with confidence. If you can't, you're building on a foundation you don't understand.
FINRA's head of enforcement said firms must design AML programs "tailored to their business model and capable of reasonably monitoring transactions for potentially suspicious activity." Reasonable monitoring requires knowing what you're monitoring. Count first, automate second, validate continuously.
