Transaction Monitoring and Data Quality: What Every Practitioner Should Understand

WHERE THIS STARTED

Some months ago, I was involved in a conversation with a client undertaking a transaction monitoring implementation. The client had the makings of a good program, committed team and with everyone around the table having a desire to get it right. During a data mapping session, one of their senior compliance people made a statement that we are all very familiar with, almost in passing, "we all know it's garbage in, garbage out."

I have thought about this moment frequently. Not because the statement was wrong; it was not. I kept returning to it because I was not sure everyone around that table meant the same thing when they said it. For some people, "garbage in, garbage out" means you get too many alerts. For others, it means your SAR narratives are thin. A few people, I suspect, were nodding because it sounded right, without being entirely sure what the garbage actually was or where it was going.

The more I spoke to colleagues and contacts across the industry about this, the more I noticed a pattern. Most practitioners understand, at a general level, that data quality matters. What is far less common is a clear picture of how data actually flows through a transaction monitoring environment from one end to the other and what can go wrong at each stage. That awareness gap matters because it is often the compliance practitioner, the BSA officer, the MLRO, or the TM program lead, who is asked by examiners and auditors to speak to data quality. The gap between "we know data quality is important" and "here is exactly how ours affects our program" can be an uncomfortable one to bridge in an exam.

This paper is my attempt to help bridge it. It is not aimed at data architects or system developers. It is aimed at the people who run these programs and need a practical, human understanding of what is happening inside the machine.

WHAT TRANSACTION MONITORING IS ACTUALLY TRYING TO DO

Before getting into data, it is worth being clear about what transaction monitoring is designed to achieve, because that shapes everything about how it works and where it can break down.

At its core, transaction monitoring is an automated, or partly automated, process for reviewing financial activity such as payments, transfers, deposits, withdrawals, and trades, and flagging behavior that might indicate money laundering, terrorist financing, fraud, or other financial crime. It builds on the foundation laid by your Know Your Customer and Customer Due Diligence processes. Once a customer relationship is established and risk-rated, monitoring runs continuously in the background, comparing what that customer is actually doing with what you would reasonably expect given their profile, products, and geography.

When something deviates enough from the expected pattern, the system generates an alert. A human analyst reviews it, gathers context, makes a judgement call, and if the facts support a suspicion of financial crime, a Suspicious Activity Report gets filed with the relevant authority.

That is the theory. And it is a sound theory. But between the theory and the practice sit a lot of moving parts, and data quality is the thing that determines whether those parts work together or undermine each other.

One thing worth noting before moving on is that transaction monitoring does not stop with your own customers. Institutions are expected to monitor activity involving third parties, correspondent banks, payment processors, intermediaries, and other counterparties. Illicit funds rarely travel in a straight line. They move through networks, are layered across jurisdictions, and are often routed deliberately through relationships that are harder to see clearly. That complexity places additional demands on both data completeness and the system's ability to connect the dots across entities.

THE REGULATORY AND SUPERVISORY CONTENT

Regulators on both sides of the Atlantic have firm expectations about what a transaction monitoring program needs to look like, and those expectations have grown more demanding over time.

In the United States, the Bank Secrecy Act and the USA PATRIOT Act require financial institutions to maintain an AML program that includes transaction monitoring and suspicious activity reporting to FinCEN. There is no single prescriptive rule for exactly how to monitor. The requirement is that the system be "reasonably designed" to detect suspicious patterns given the institution's risk profile. The OCC, Federal Reserve, and FDIC have all published supervisory guidance emphasizing calibration, testing, independent validation, and appropriate resourcing. Compliance with OFAC sanctions screening is often handled alongside transaction monitoring, though the two are conceptually distinct.

In the EU, the AML Directives, with the latest iteration further harmonizing requirements across Member States, impose obligations on regulated entities to adopt risk-based programs, conduct ongoing monitoring, and report suspicious transactions. The European Banking Authority issues detailed guidelines covering everything from the use of machine learning in compliance systems to expectations around ICT risk management. Real-time or per-authorization monitoring is increasingly expected in the context of instant payments. In the UK, the FCA and HM Treasury maintain broadly similar expectations post-Brexit, and the Economic Crime Act adds further weight to corporate accountability.

Across all of these frameworks, a few expectations stand out as consistently important for practitioners to internalize. First, monitoring must reflect your institution's specific risk profile including its customers, geographies, products, and channels. A generic program that has not been calibrated to the actual risk you carry will not satisfy a supervisor, regardless of how sophisticated the underlying technology is. Second, performance must be tracked and ineffective scenarios must be tuned or retired. Third, there must be explainability. Where AI or machine learning plays a role, regulators expect institutions to be able to show how an alert was generated and why. And fourth, human judgement is not optional. Analysts are still responsible for applying context, escalating concerns, and making final determinations. The technology supports that process. It does not replace it.

HOW A TRANSACTION MONITORING SYSTEM WORKS: THE COMPONENTS

Understanding where data quality issues bite requires a basic map of what a transaction monitoring system actually contains and how the pieces work together. This is not a technical deep dive. Think of it as a guided tour.

Data ingestion is where everything starts. The system pulls in raw transaction data from your core banking systems, customer and KYC data, sanctions and watchlist data, and any external reference data you use. This is the entry point for data quality problems. If source systems are not sending complete records, if feeds are running late, or if formats are inconsistent across business lines or geographies, the problems begin here and flow forward. 

Data cleansing and standardization is the attempt to turn that raw material into something usable. Records are de-duplicated, formats are normalized, and missing fields are flagged. But cleaning has limits. If important fields were never captured upstream, no amount of cleansing will create them. Poor de-duplication at this stage, whether it fails to merge records that belong together or incorrectly merges ones that do not, will cause downstream problems that can be very difficult to trace back to their source.

Profiling is where the system builds a model of normal behavior for each customer. It looks at historical transaction patterns, including how much they typically transact, how often, which channels they use, which counterparts they deal with, and which geographies are involved, and establishes a baseline. Rules and anomaly detection then measure live activity against that baseline. If the historical data used to build the profile is incomplete, biased, or corrupted, the baseline will be wrong. A wrong baseline means genuine anomalies may not breach a threshold, while entirely normal activity might. This is a primary driver of both false positives and, more dangerously, false negatives.

Segmentation determines which rules and thresholds apply to which customers and transactions. High-risk customers should face tighter thresholds than low-risk ones. Commercial customers should be assessed differently from retail. But segmentation is only as good as the attributes feeding it. If a customer's risk rating is stale, if their industry classification is missing, or if the product type on a transaction is incorrectly coded, the wrong rules will apply. In the worst case, no rules will apply, and genuine risk passes through undetected.

The rules/detection engine is where most people think the work of transaction monitoring happens. Rules or other detection algorithms are applied to transactions to detect patterns associated with known financial crime typologies such as structuring, velocity anomalies, geographic red flags, layering patterns. Rules/detection algorithms have thresholds, and thresholds depend on the accuracy of the data being measured. If key values are missing or incorrect, thresholds either fail to fire when they should, or fire constantly when they should not. 

Scoring and ranking takes the outputs of rules/detection algorithms, profiling, and network analysis and combines them into a risk score that determines which alerts get prioritized for review. This is useful precisely because not all alerts carry equal weight. But scoring models are only as reliable as the inputs they receive. Noisy or inaccurate feature inputs produce unreliable scores, which means genuine high-risk alerts can get buried while lower-risk items absorb analyst time. 

Entity resolution and network analytics are capabilities that have become increasingly important as financial crime methods have grown more sophisticated. Entity resolution is the process of correctly linking records that belong to the same real-world entity, for example, the same customer appearing in multiple systems or beneficial owners connected to corporate accounts. Network analytics then maps the relationships between entities and looks for patterns that a flat view of individual transactions would never reveal, such as circular flows, multi-hop layering, and hub-and-spoke structures. Both capabilities depend critically on data completeness and correct linkage. Missing nodes or incorrect relationships do not just degrade the analysis; they can render entire patterns invisible. 

Alert generation, triage, and investigation are the stages most visible to practitioners. Alerts are generated when rules or scoring thresholds are breached, reviewed by analysts who gather additional context, and then either closed as non-suspicious or escalated for potential reporting. What is less visible is how much the quality of that investigation depends on the data environment. If alert metadata is incomplete, if KYC data conflicts with what the TM system shows, or if enrichment data is stale, analysts spend their time filling gaps manually rather than making judgements. That drives up cost, slows decisions, and increases the risk of error. 

Feedback and tuning is the loop that makes monitoring improve over time or fails to. When alert outcomes are captured accurately, that information can feed back into refining rules, algorithms, adjusting thresholds, and re-calibrating models. When outcomes are mislabeled, missing, or not connected back to their source alerts, the system learns the wrong lessons. Models drift. Rules that should have been retired remain active. Performance erodes quietly. 

WHERE DATA QUALITY ACTUALLY GOES WRONG: THE PRACTICAL PICTURE

It is one thing to describe the components and note that data quality matters at each stage. It is more useful to put some flesh on what that actually looks like in practice. Missing counterparty information is a common and consequential example. Many financial crime typologies depend on understanding who is on the other end of a transaction. If the counterparty field is consistently absent or incomplete in a particular payment channel's data feed, any rules that rely on counterparty characteristics simply cannot fire. The detection gap is not a model problem. It is a data problem, and it may not be visible at the rule level at all.

Stale customer risk ratings create a subtler but equally serious issue. If a customer was risk-rated at on-boarding two years ago and their profile or behavior has changed significantly since, the risk rating may no longer reflect reality. Rules and thresholds calibrated to that stale rating apply the wrong level of scrutiny. This is particularly common in programs that have invested heavily in on-boarding but have not kept the same discipline around periodic review.

Duplicate customer records are another area where the consequences are often underappreciated. When the same customer appears as two different records in the TM environment, their transaction history is split. Neither half looks as unusual as the whole. Thresholds designed to detect velocity or volume anomalies will never be reached because the activity that would trigger them is distributed across two identities.

Late or incomplete data feeds create timing problems that are easy to miss. A transaction monitoring run scheduled at the end of the day relies on having received all transactions from that day. If certain feeds run late, which is common in environments with multiple source systems, some transactions simply are not included in that day's analysis. In a batch processing environment, those transactions may be picked up in the next run. In a near-real-time environment, they may be assessed out of context. Either way, the system's picture of the day's activity is incomplete. 

Inconsistent data formats across product lines or geographies are a persistent challenge in larger institutions. When currency, date, amount, and identifier fields are not standardized across systems, the aggregation and normalization steps have to work much harder and the risk of errors introduced during transformation increases significantly.

WHAT THIS MEANS FOR REGULATORY AND AUDIT EXPOSURE

Data quality issues in transaction monitoring are not just an operational headache. They carry regulatory and legal weight. 

Missed detections and false negatives are the most serious consequence. If a genuine suspicious activity pattern fails to generate an alert because of a data gap, the institution may fail to file a required report. Depending on the circumstances, that can constitute a regulatory breach. The fact that the failure traced back to a technical data feed issue rather than a deliberate decision provides limited protection if the institution could reasonably have identified and corrected the problem.

Alert overload is the more visible problem. When data quality drives excessive false positives, analysts become overwhelmed. When analysts are overwhelmed, the probability that a genuine alert is missed in the noise increases. This is not hypothetical; supervisory commentary has noted this dynamic explicitly in the context of consent orders and enforcement actions. 

Explainability failures are a growing concern as AI and machine learning become more common in TM environments. Regulators expect institutions to be able to explain how an alert was generated, what data drove it, and why a particular threshold was applied. Where data lineage is poor or where intermediate steps in a model's logic are not logged, that explanation becomes impossible to provide. In an audit, that is a finding waiting to happen. 

Inconsistent outcomes where the same customer looks different in the TM system and the KYC system can create credibility problems with examiners, lead to confused or contradictory analyst decisions, and can result in SAR narratives that are difficult to defend. 

WHAT GOOD LOOKS LIKE: PRACTICAL GUIDANCE FOR PRACTITIONERS

The good news is that none of this requires a technology transformation to start addressing. Much of what makes a transaction monitoring program data-resilient is discipline and governance rather than additional tooling.

Strong data governance means having clear ownership of data quality within the program. Someone needs to be responsible for knowing what fields are critical, what the acceptable null rate is for each of them, and what the process is when a feed degrades. Data stewardship is not a role that lives only in the technology team, compliance and operations need a seat at that table. 

Regular data quality monitoring means checking, on a scheduled basis, for null rates, duplicate rates, timeliness of feeds, and schema consistency. Problems caught close to their source are far easier and cheaper to fix than problems discovered at the alert or investigation stage. Most institutions have the capability to do this. Fewer have made it a routine. 

Periodic tuning is not optional. Rules and models built on last year's customer base and product mix will drift from relevance. Scenarios that are generating noise without producing quality alerts should be reviewed and, where warranted, retired. Thresholds should be revisited against actual outcome data. The frequency of tuning should be proportionate to the rate of change in the business, with more frequent reviews where products or channels are evolving quickly. 

Entity resolution deserves more attention than it typically gets outside of technology circles. Investing in the quality of your customer master record and ensuring that the same customer is consistently identified across systems, pays dividends across the entire monitoring chain, not just in the network analytics module. 

Human oversight of automated processes is a regulatory expectation, but it is also a genuinely useful check on system performance. Analysts who are well-trained and well-supported are not just reviewing alerts; they also serve as a feedback mechanism, catching patterns that rules and models have not accounted for and feeding that insight back into tuning and model refinement. 

Audit logging and data lineage need to be treated as first-order requirements, not afterthoughts. The ability to trace an alert back through the logic and data that generated it is what makes a program defensible under scrutiny. If that traceability is weak, the program is exposed, not because the detection was wrong, but because it cannot be shown to be right. 

A NOTE ON AI AND AGENTIC TOOLS 

AI-assisted investigation tools and agentic AI capabilities are attracting significant attention in the financial crime space, and for understandable reasons. If well implemented, they can reduce the time analysts spend on routine data gathering, draft initial case narratives, surface contextually relevant information, and help prioritize review queues more effectively. 

But the same data quality principles apply with even greater force in an AI-assisted environment. These tools depend on the quality, completeness, and accuracy of the data they are given. If profiles are incomplete, relationships are incorrectly mapped, or transaction data lacks key context, an AI tool does not fill those gaps creatively. Instead, it generates outputs that reflect those gaps, often with more confidence than a human analyst would show. A poorly drafted narrative presented to an analyst as a starting point can anchor their thinking in the wrong direction just as effectively as a correct one can anchor it in the right direction.

The sensible approach is to deploy these tools in an assistive, recommendation-only capacity initially, with human review and sign-off required on outputs. Every action taken by an automated or AI-assisted process should be logged and auditable. And the quality of the underlying data environment should be treated as a prerequisite, not something to be resolved later. 

QUESTIONS EVERY TM PROGRAM LEAD SHOULD BE ABLE TO ANSWER 

As a practical close, here are some questions worth putting to yourself or your program. They are not meant as a checklist or an assessment framework. They are meant as prompts for honest reflection. 

• Do you know, specifically, which source systems feed your transaction monitoring platform, how frequently, and what happens to your monitoring runs when a feed is delayed or drops fields? 

• When were your customer risk ratings last reviewed? Are customers who have been in your book for several years being monitored against a risk profile that reflects who they are today? 

• Can you explain your false positive rate and the trend over the past twelve months, not just the number, but what is driving it? 

• If your TM system generated an alert today that turned out to be a genuine case, could you trace the logic and data behind that alert from the SAR narrative back to the source transaction, clearly and without gaps? 

• When did you last tune your detection scenarios based on outcome data, not because something broke, but as a scheduled review? 

• If an examiner asked you tomorrow to describe your program's data quality controls, would your answer be confident and specific, or would you be reaching? 

These are not trick questions. Most programs have credible answers to most of them. But the gaps are worth knowing before someone else finds them. 

CLOSING THOUGHTS

Transaction monitoring is a serious compliance obligation. It is also, if we are honest about it, a genuinely difficult operational challenge. It is one that sits at the intersection of technology, process, data governance, and human judgement in ways that make it hard to get entirely right, particularly in complex or fast-growing institutions. 

The point of this paper is not to suggest that most programs are failing. Most are doing a reasonable job under real constraints. The point is that the data quality conversation in this space tends to be shallower than the subject deserves. "Garbage in, garbage out" is true.

But it captures only a fraction of what that actually means in practice. 

When institutions treat data quality as a peripheral concern, something the technology team manages rather than as a central pillar of the compliance program, the consequences compound quietly. More alerts, more analyst time, more rework, weaker narratives, less defensible outcomes, and greater exposure when a supervisor comes knocking. 

When institutions treat data quality seriously, the benefits run in the other direction. Fewer false positives, more focused investigations, stronger documentation, and a program that can withstand scrutiny not just because it is technically functional but because the people running it genuinely understand what it is doing and why. 

That understanding is what this paper is trying to support. If it prompts a conversation, or gives a practitioner a clearer vocabulary for talking about their program, it has done its job.

---------------------------------------------------------------

Dan Buckingham is the Managing Director of Financial Services at the Apollo Group, as well a financial crime compliance practitioner with over 20 years of relevant experience. This paper is for informational and discussion purposes and does not constitute legal or regulatory advice.