The AML Implementation Gaps That Only Show Up After Go-Live

AML transaction monitoring implementations share a specific failure mode. The system goes live. Rules fire correctly on the scenarios tested in UAT. The compliance team begins operations — and within the first quarter, two problems emerge simultaneously: the alert volume is far higher than anticipated because the rules are generating false positives at a rate that was never tested, and the investigation team finds that structuring patterns are not being detected because the test cases never covered them.

Neither problem was invisible during the implementation. Both were present in the configuration. What was missing was the test coverage to surface them before go-live.

Rule Calibration: Detection Is Not Enough

The standard AML UAT approach tests that a rule fires. A large cash deposit above the threshold triggers an alert — the test passes. What this approach does not test is how often the same rule fires against legitimate, normal customer behaviour in the bank's actual portfolio.

False-positive rate is not a concern for the IT delivery team. It becomes the compliance team's operational problem from day one of go-live. An AML rule tuned to fire at a threshold appropriate for a corporate client portfolio will generate an unmanageable volume of alerts if the same threshold is applied to a retail portfolio where large transactions are routine for certain customer segments. The delivery team never sees this because UAT runs against a small, controlled test dataset, not against a realistic customer transaction population.

The fix is straightforward but requires domain knowledge to specify: negative testing scenarios must be included in the UAT register alongside positive detection scenarios. For every rule, there should be at least one test case that confirms the rule does not fire on a transaction that falls within normal behaviour parameters for the relevant customer segment.

Structuring: The Pattern Nobody Tests

Structuring — the practice of breaking up a large transaction into multiple smaller ones to avoid detection thresholds — is one of the most common money laundering techniques. It is also one of the most consistently undertested scenarios in AML implementations.

The reason is straightforward: structuring is a multi-transaction pattern, not a single-transaction event. UAT test cases are almost always written as individual transactions. A test case that processes one large deposit above the threshold is easy to specify. A test case that processes seven deposits over three days, each one below the threshold, all from the same customer, all followed by a single large outgoing wire — that requires building a scenario, not just a transaction, and it requires understanding what the detection rule is actually supposed to catch.

What structuring test coverage actually requires

• Pattern definition — the rule must specify the time window, the transaction count threshold, the cumulative amount threshold, and the customer scope (same account vs same customer across accounts)
• Multi-step test execution — the test must process all transactions in sequence, not just check the alert after a single transaction
• Negative scenario — multiple transactions by the same customer that are genuinely unrelated to structuring (a customer making several legitimate payments in a week) should not trigger the pattern rule
• Alert aggregation — where the system is expected to aggregate multiple transactions into a single alert rather than generating one alert per transaction, this behaviour must be explicitly tested

STR Filing and Tipping-Off: Two Requirements, One Regulatory Obligation

The Suspicious Transaction Report filing workflow and the tipping-off prohibition are two distinct regulatory requirements that are operationally linked. Filing an STR on a customer without triggering any system action or customer communication that could alert the customer to the investigation is not just good practice — it is a legal requirement in most jurisdictions. In India, it is a requirement under the PMLA and the RBI's AML/CFT master directions.

In UAT, these two requirements are almost always tested independently. There is a test case for STR filing: the analyst raises a case, completes the investigation, submits the report. There is a separate test case or configuration check for the tipping-off prohibition: the customer-facing system does not display any alert or notification when an STR is filed. What is rarely tested is the interaction: that completing the STR filing workflow does not inadvertently trigger any system event — email, SMS, account freeze notification, or relationship manager alert — that could reach the customer.

Case Management: Escalation and Time-Out Behaviours

AML case management systems have workflow states — open, under investigation, escalated, closed, reported. UAT plans typically test the linear path: alert generated, case opened, investigated, closed or reported. What they rarely test are the non-linear paths that regulatory expectation and operational policy require:

• Escalation on breach of investigation time limit — most AML frameworks require that cases open beyond a defined period be escalated to a senior reviewer; this escalation must be automatic, not manual
• Reassignment on analyst absence — cases assigned to an analyst who becomes unavailable must be reassignable without loss of case history
• Audit trail completeness — every action taken on a case must be logged with timestamp and user ID; this must be tested as a specific scenario, not assumed
• Case reopening — a closed case that receives new transaction activity matching the original pattern must be capable of being reopened and linked to the original case

The Root Cause Is Domain Distance

AML implementations are delivered by technology teams. The regulatory knowledge required to write effective AML test cases — what structuring looks like as a transaction pattern, how tipping-off can occur through system automation, what audit trail completeness means to a regulator conducting a review — sits with compliance professionals, not with the delivery team. The gap between the two groups is where these test coverage failures originate.

Bridging that gap before UAT begins — by reviewing the test register against regulatory requirements and building the scenarios that the delivery team would not naturally think to specify — is the most cost-effective point at which to intervene.

Bankly's AML Consulting practice provides functional domain support for teams implementing transaction monitoring, case management, and STR filing workflows — including UAT plan review, ready-to-use test cases covering detection, structuring, and filing scenarios, and on-project consulting during the testing phase.