Transaction Monitoring Data Completeness Testing: Counts, Values, Rejects, and Alert Coverage

TL;DR

• Transaction monitoring data completeness testing must prove the full chain: source population → extract → transform → ingest → scenario execution → alert/no-alert result → reject repair.
• Reconcile record count, monetary value, and risk segments at every handoff. Do not net missing transactions against duplicates.
• A zero-alert transaction may be fine. A transaction that never reached the rule engine is not. Preserve a result or approved exclusion for every in-scope source record.
• The final workpaper needs record-level exceptions, rerun evidence, an impact conclusion, owners, dates, and independent review—not a screenshot showing two totals match.

A transaction-monitoring system can run every night, produce thousands of alerts, and still miss the transactions that matter. The dashboard proves the engine ran. It does not prove the complete population reached it.

That is the job of transaction monitoring data completeness testing: define the in-scope source population, follow it through every handoff, reconcile counts and values, account for rejects and transformations, and prove each record reached applicable scenario logic or a documented exclusion.

FinCEN’s August 3, 2026 UBS Financial Services consent order is unusually concrete. FinCEN found that UBS failed to appropriately monitor more than 61,500 foreign-currency wires with an aggregate value above $10.5 billion. The order describes incomplete data, error-prone manual work, implementation and testing deficiencies, and records that did not reach effective monitoring. The lesson is bigger than UBS: “system implemented” is not a population-completeness conclusion.

The existing UBS enforcement breakdown covers what failed. This article builds the reusable workpaper a tester should run next.

Transaction monitoring data completeness testing: prove coverage, not alert volume

Use a precise objective:

Determine whether all risk-relevant transactions in the defined source population were completely and accurately extracted, transformed, ingested, evaluated by applicable transaction-monitoring scenarios, and routed to a traceable alert, no-alert result, approved exclusion, or resolved exception.

That wording prevents two common testing errors.

First, it does not assume every transaction should alert. Rules apply based on scenario criteria. A legitimate result can be “evaluated; criteria not met.”

Second, it does not let the tester stop at ingestion. A record can load successfully and still be excluded from scenario execution because a product code changed, a currency field is blank, a customer relationship failed to match, or a rule was disabled for that segment.

The FFIEC BSA/AML Examination Manual’s suspicious activity reporting section is the regulatory context for systems used to identify, research, and report suspicious activity. The workpaper remains institution-specific: scope should follow the products, services, customers, geographies, transaction types, and monitoring design in the institution’s risk assessment.

Keep the authority levels straight: 31 CFR 1020.210 is a binding AML-program rule for banks; the FFIEC manual is interagency examination guidance. The six-sheet workpaper below is RiskTemplates suggested practice, not a regulator-prescribed form or universal testing threshold.

Sheet 1: lock the population definition

Write the scope before pulling totals. Otherwise, every break can be explained away later as an “out-of-scope” item.

Do not write “all transactions” when the extract is a report generated after operational filters. Identify the rawest authoritative population available and reconcile the report back to it.

Where this gets messy: Finance may own the ledger, Payments may own message-level data, and AML Technology may monitor an enriched event assembled from both. The workpaper should not pretend one table is universally authoritative. It should define which source proves occurrence and value, which source supplies monitoring attributes, and how their records join.

Sheet 2: build the handoff reconciliation

Set one row per handoff, feed, transaction type, and test period. Aggregate totals are useful only if they can be drilled to record-level differences.

Use signed differences, but never conclude from a net zero variance. Ten missing records plus ten duplicates equals zero in an arithmetic reconciliation and twenty defects in a control test.

Compute separate break populations:

• source IDs missing from extract;
• extract IDs missing after transformation;
• accepted IDs absent from scenario execution;
• executed IDs with no traceable result;
• duplicate IDs at any stage;
• rejects not repaired within the defined service level;
• late records crossing the test-period boundary;
• unexplained value differences; and
• records included despite an approved exclusion—or excluded without one.

A useful workpaper also reconciles by day or batch. A monthly total can hide a failed weekend file that was offset by a duplicate Monday load.

Sheet 3: compare count, value, and risk segments

FinCEN’s UBS order shows why count-only testing is weak. The affected foreign-currency wires exceeded $10.5 billion in aggregate. The FinCEN announcement says the action involved willful BSA violations and a $125 million civil money penalty. The control failure was consequential because the missing population carried financial-crime risk, not merely because rows failed to move between systems.

Segment the reconciliation using the institution’s own risk assessment and scenario design:

Do not invent a universal acceptable variance. A practical control objective is zero unexplained missing in-scope records. Timing breaks may be legitimate if the design intentionally monitors late records in the next cycle, but the tester should prove that next-cycle execution and assess whether delay remains consistent with the risk and program design.

Sheet 4: test fields and transformations that control eligibility

Matching totals do not prove correct monitoring. A transaction can survive every row-count comparison while its country becomes null, its amount is scaled incorrectly, or its product code maps to an excluded category.

Select fields that determine scenario eligibility, risk segmentation, aggregation, or investigator context. Typical examples include:

• unique transaction and source IDs;
• account, customer, household, and counterparty identifiers;
• transaction type, subtype, channel, and status;
• original amount, currency, converted amount, and exchange rate;
• originator and beneficiary details;
• origin, destination, and counterparty country;
• timestamps and business date;
• product/program code;
• debit/credit direction;
• customer risk rating; and
• rule-relevant reference or free-text fields.

For each field, document source value, transformation rule and version, monitoring value, expected result, actual result, and exception ID. Include boundary and negative tests: nulls, unsupported codes, malformed references, daylight-saving transitions, weekend files, very large values, reversals, and records arriving after the nominal cutoff.

A transformation can be technically valid and still defeat monitoring. For example, collapsing multiple source transaction types into “other” may preserve count and value while removing the attribute a scenario needs. That is why AML Compliance must approve semantic mappings; Data Engineering cannot own the risk interpretation alone.

Sheet 5: prove scenario execution and alert coverage

Create a record-level join from each in-scope source transaction to one of four terminal states:

1. Evaluated and no alert: applicable scenarios ran; criteria were not met.
2. Evaluated and alerted: retain scenario/run ID and alert/case linkage.
3. Approved exclusion: retain rule, rationale, approver, effective dates, and evidence the exclusion worked as designed.
4. Exception: rejected, unmatched, not evaluated, or missing a terminal result; retain the repair path.

Then reconcile those states back to the source population:

source population = evaluated/no alert + evaluated/alert + valid exclusions + open exceptions

That formula is a control design, not a regulatory equation. Adapt it to the architecture, but do not allow an unclassified remainder.

Also test many-to-many behavior. One transaction may run through multiple scenarios and generate multiple alerts; one alert may aggregate many transactions. Preserve a bridge table with transaction ID, scenario ID, run ID, alert ID, case ID, and disposition. Counting alert rows as transaction coverage will produce false assurance.

Sheet 6: make the reject queue auditable

A reject file is not an exception-management process. For each rejected or unmatched record, retain:

The UBS order describes an error-prone process involving multiple systems, manual copying, incomplete data, and flawed implementation testing. It is exactly the environment where a reject can disappear between operational teams. A queue needs aging, escalation, and a final monitoring result—not just a “fixed” status.

For ongoing indicators after the workpaper is established, connect exceptions to the BSA/AML transaction-monitoring KRI guide. Track unexplained missing records, unresolved reject age, late-feed frequency, replay completion, and reopened defects using thresholds calibrated to internal history and risk. Do not use alert count as a proxy for completeness.

Write a conclusion that states what was—and was not—proved

Avoid “no exceptions noted” unless the workpaper actually reconciled the complete population and tested field accuracy, scenario execution, and rejects.

A useful conclusion includes:

• period, products, channels, systems, feeds, and scenarios tested;
• source-population basis and known limitations;
• counts and values at each stage;
• differences by risk segment;
• field/transformation tests performed;
• number and value of missing, duplicate, late, rejected, and unrepaired records;
• whether all in-scope records reached a terminal state;
• scenario and alert-coverage results;
• impact on prior alerts, cases, and SAR decisions;
• required lookback or replay scope;
• open issues, owners, dates, interim controls, and escalation; and
• independent reviewer and sign-off date.

Example conclusion language:

For the defined test period and covered wire feeds, the tester reconciled source records through extraction, transformation, monitoring ingestion, applicable scenario execution, and terminal results. Three records were rejected because of an unmapped currency code; they were not included in the original scenario run. The records were repaired and replayed under Run ID [ID], producing [results]. Issue [ID] remains open for the mapping defect and preventive control. The conclusion does not cover ACH, card, or internal-transfer feeds, which were outside the approved scope.

That example is intentionally a hypothetical form, not a real institutional result. Its strength is the boundary: it says exactly what the tester proved, what failed, how records were handled, and what remains open.

So what?

Take one recent monitoring day and ask Data Engineering for the authoritative source extract, AML Technology for accepted/rejected IDs and scenario-run records, and Operations for alert/case links. If those teams return three unrelated totals with no common record identifier, the first issue is not rule tuning. It is traceability.

Build the six-sheet workpaper, start with the highest-risk transaction feed, and force every source record into an evaluated, alerted, excluded, or exception state. Then have Independent Testing reproduce a sample without relying on screenshots prepared by the control owner.

When the reconciliation produces defects, the Issues Management Tracker & Template gives each break a root cause, owner, due date, remediation plan, validation record, and closure-evidence trail.

Primary sources: FinCEN UBS announcement, August 3, 2026 · FinCEN Consent Order No. 2026-02 · FFIEC BSA/AML Examination Manual · 31 CFR 1020.210