This article assumes you know what transaction monitoring is. If you do not, our companion explainer, AML Transaction Monitoring: How It Works and Why It Matters, covers how AML transaction monitoring works end to end. AML means anti-money laundering. CFT means countering the financing of terrorism.
I have watched a lot of monitoring reviews go wrong. Almost none went wrong because the rule was badly built. They went wrong because nobody in the room could say why the rule was set the way it was.
So this is not a list of rules to build. It is the set of questions a supervisor will ask about the transaction monitoring rules you already run, and the evidence that answers each one.
What a supervisor actually assesses in an AML transaction monitoring rule
Key point: an examiner is not testing whether your rule is clever. They are testing whether you can explain and evidence the choices inside it.
"Parameters and filters should be reasonable and tailored to the activity that the bank is trying to identify or control."
"Management should document and be able to explain filtering criteria, thresholds used, and how both are appropriate for the bank's risks."
The obligation is not to have a good threshold. It is to explain it.
In the UAE the duty sits in Cabinet Resolution No. 134 of 2025, the Executive Regulations of Federal Decree-Law No. 10 of 2025. Article 8 defines ongoing monitoring as scrutiny, not as software:
"Scrutinizing Transactions carried out throughout the duration of the Business Relationship to ensure that such Transactions are consistent with the information available thereto regarding the Customer, the nature of their activities, and the risks they represent, including, where necessary, the source of funds."
"Financial Institutions, Designated Non-Financial Businesses and Professions, and Virtual Asset Service Providers shall establish indicators through which they are able to identify suspicion of a Crime for the purpose of submitting Suspicious Transaction Reports, and shall update such indicators on an ongoing basis in line with the development and diversification of methods used in the commission of a Crime."
The illustrative transaction monitoring rule used in this article
Key point: one invented rule, carried through every question, shows connections a list of concepts hides.
The rule carried through this article is a labelled hypothetical. It describes no real institution, customer, case or configuration.
Call it Rule 041, cash aggregation for a defined customer segment. It sums cash credits across a customer's accounts over a rolling period, compares the total to a threshold set for that segment, and alerts when the total exceeds it. That is the whole rule: a scenario, parameters, a segment, an output. No values appear in this article, and the verification section explains why.
| Part | What it is | What a reviewer asks | Common weakness |
| Scenario | The behaviour it detects | Which typology, and where is it named in your risk assessment? | Detects a pattern nobody can tie to a stated risk |
| Parameters | Threshold, period, count, currency, channel | What evidence set each one, and when was it reviewed? | Inherited values, no written rationale |
| Segment | Who it applies to, and who it excludes | Do these customers actually behave alike? | One segment holding customers with nothing in common |
| Output | What an alert asserts | What does an analyst do with it, consistently? | It says "unusual" but nobody agreed what that means |
Why does this transaction monitoring rule exist?
Key point: if the team cannot name the typology the rule is meant to catch, nothing else in the review matters.
Rule 041 exists because the institution identified, in its own business risk assessment, that a customer segment handles cash in a way that could be used to place criminal proceeds. That answer has three parts: the typology, the segment, and the source document saying the risk exists.
If the answer is "it came with the system", the review is already in trouble. Not because the rule is wrong, but because the institution cannot show it made a decision. Article 5 of Cabinet Resolution No. 134 of 2025 requires firms to document their risk identification processes, retain the study and update it on an ongoing basis. The rule set is the mitigation. The AML risk assessment is the reason. They have to be read together.
Coverage: which AML risks have a monitoring rule, and which do not
Key point: coverage asks whether a rule should exist. Tuning asks whether an existing rule is set right. Most teams run only the second.
A team can tune every rule it owns beautifully and still miss the risk entirely, because the risk it missed has no rule against it. That gap doesn't appear in any tuning report. It appears when you lay the risk assessment beside the rule inventory and look for empty rows.
| Risk named in the business risk assessment | Rule addressing it | Segment covered | Evidence | Status |
| Cash placement through a defined customer segment | Rule 041 | Yes | Risk assessment reference, tuning record | Covered |
| Rapid movement of funds through new relationships | Rule 052 | Yes | Risk assessment reference, tuning record | Covered |
| Third party payments inconsistent with stated activity | Rule 067 | Partial, one channel excluded | Change record notes the exclusion | Partial, gap logged |
| Structural risk in a product introduced last year | None | Not applicable | No rule built, no decision recorded | Uncovered |
The last row is the finding. Not the tuning of Rule 041.
Uncovered risks come from predictable places. A product launched without a monitoring assessment. A channel added to an existing product. A segment that grew and was never re-scoped. Product coverage needs its own pass, because correspondent banking, trade finance and virtual assets carry typologies a general cash rule will not touch. Our companion pieces, Correspondent Banking and AML: Risks and Controls for UAE Banks and Trade-Based Money Laundering: Red Flags and Controls, cover the correspondent banking risks and controls and the trade-based money laundering red flags. Our series covers enforcement cases where monitoring coverage was the failure.
Segmentation: why one transaction monitoring threshold cannot cover unlike customers
Key point: a threshold is only meaningful for a population that behaves consistently.
If Rule 041's segment includes both a small retail shop and a large cash-intensive wholesaler, no threshold works for both. Set it for the shop and the wholesaler alerts constantly for normal trading. Set it for the wholesaler, and the shop can do almost anything without alerting. Most firms pick something in the middle and live with the noise.
A defensible answer looks different. The segment was defined by observed behaviour, not just industry code or risk rating. We examined the distribution of activity inside it before setting the threshold. Outliers were moved to their own segment or documented as accepted. The FFIEC manual points the same way:
"System filtering criteria should be developed through a review of specific higher-risk products and services, customers and entities, and geographies."
You cannot do this without pulling your own population. The SQL to pull your alert population for tuning is a small set of query shapes. SQL is Structured Query Language.
Where the threshold came from, and what to do when nobody wrote it down
Key point: a threshold has a few legitimate bases. A vendor default stops being one the moment the rule goes live.
Legitimate bases: the measured behaviour of the segment, the statistical distribution of activity in that population over a defined period, a risk the institution has named and sized, a supervisory expectation, or a deliberate starting position with a date set to review it against real data.
The illegitimate ones are as easy to list. A value that arrived with the system and was never touched. A value copied from a previous employer. A value chosen to keep alert volume at a level the team could staff. That last one deserves care. Setting a threshold partly to manage workload is not automatically wrong. Failing to write it down is what fails a review.
Most readers have inherited a rule whose rationale nobody recorded. Here is the path out.
1. Say so, in writing. Record that the original basis is undocumented. Do not invent a rationale and present it as the original. A reconstructed history is worse than an admitted gap.
2. Rebuild the basis from current data. Pull the population over a defined period and look at how it actually behaves.
3. Test it. Run the two tests below. They give evidence about the setting you have today, whoever chose it.
4. Re-approve it. Take the result to whoever owns rule approval. They confirm the setting or they change it, and either way a dated decision now exists.
5. Record it properly. A tuning record captures seven things: population, period, method, result, decision, approver, date.
Above-the-line and below-the-line testing, in plain language
Key point: below-the-line testing asks whether the threshold is too high. Above-the-line testing asks whether the alerts it produces are worth working.
The two tests point in opposite directions and answer different questions, which is why running only one leaves half the rule unevidenced. Below the line looks at what the rule missed. Above the line looks at what it did catch and what came of it. A supervisor asking about testing wants both, and notices which one is missing from the pack.
The names describe where the sample sits relative to the threshold and nothing more. Neither is a regulatory term, neither carries a mandated method, and that absence is exactly why the sampling has to be written down before the sample is drawn. The most common mistake is reading a clean below-the-line result as proof the rule is right. It is evidence about one threshold, in one segment, over one period, and it says nothing about whether the scenario was the right thing to build in the first place.
What is below the line testing?
Below-the-line testing takes a sample of activity that fell belowthe rule's threshold and did not alert. You review that sample as though it had alerted, then ask whether anything in it should have been escalated. A clean sample is evidence the threshold is not obviously too high. A sample containing activity you would have escalated means it is missing things.
A reviewer asks two questions about any below-the-line pack. What was the sample drawn from, and would you have escalated anything in it? If the sample came from alerts rather than from activity that did not alert, the test has been run backwards and proves nothing.
The result is also only as good as what the people reviewing the sample were given. Give them the same information an analyst would have on a live alert, including the customer profile and expected activity, or a clean result may only mean the reviewers lacked the context to spot anything. Record the reviewer, the date and the disposition for every sampled item. The pack is the evidence. The sentence at the top of it is not.
What is above the line testing?
Above-the-line testing takes a sample of activity that did alert, at and above the threshold, and examines what those alerts produced. Were they worked? Closed for consistent reasons? Did any become a report? If almost nothing above the threshold is ever productive, that is evidence about the rule, not about the analysts.
The failure mode is reading the result as a comment on the team. Where a rule produces very little, the first question is whether the scenario detects a behaviour that occurs in that segment at all. The second is whether the parameters put the alert at the wrong point in the activity. Analyst quality is the third question, and jumping to it first turns a tuning problem into a performance conversation with the wrong people.
The evidence the file needs is the same in both directions: the sampled alerts, their outcomes, the recorded reason each was closed, and a conclusion about the rule rather than about the alerts. An above-the-line pack that ends in a productivity percentage with no decision attached has produced a number, not a test.
Sampling: the part that decides whether the test means anything
Three things must be fixed and written down first. The period, long enough to include normal seasonal variation in that business. The segment, the actual population the rule applies to rather than a convenience extract. The sample size and selection method, stated and reproducible by someone else. A sample chosen by scrolling a report until there were enough rows proves nothing.
Write the selection method down before you draw the sample, not after you have seen the result. A method described afterwards is indistinguishable from a method chosen to suit the answer, and a reviewer has no way to tell the two apart, so they treat both the same way.
The pattern a reviewer looks for is the convenience sample: whatever the system exported easily. Those cluster without anyone intending it, into one month, one branch, one product, or whichever table joined cleanly. The file needs the selection rule stated in words, the population it was applied to, the ordering or seed if the selection was random, and enough detail for a second person to draw a fresh sample the same way and compare the results.
What below-the-line testing cannot prove
A clean result tells you one thing: for that rule, that segment and that period, the threshold does not appear to be missing activity you would have escalated. It does not tell you the risk is absent, or that the scenario is right, and it says nothing about a risk with no rule at all. A folder of clean below-the-line tests is not a coverage assessment.
"Above the line" and "below the line" are industry method terms, not regulatory ones, and the FFIEC manual uses neither phrase. What it does require is the testing:
"Management should periodically review and test the filtering criteria and thresholds established to ensure that they are still effective."
Alert outcome feedback: does anything the rule produces ever change the rule
Key point: alert volume is set by rule design, not by the queue. A productivity ratio on its own proves nothing.
Every rule produces alerts. Some are closed, some escalated, some become a suspicious transaction report, or STR. Those are three populations and must be counted separately.
Measuring the ratios between them is useful. Publishing a target ratio is not, and none appears here. What is reasonable depends on the institution, its customers, its products and its risk appetite. Derive your own baseline and record how you derived it.
The real question is whether the ratio ever changes anything. In the last twelve months, did an alert outcome finding lead to a documented change in a rule? If not, the feedback loop does not exist, and the rule set is running open loop.
The escalation itself is a legal obligation, not a workflow preference. Federal Decree-Law No. 10 of 2025, Article 18 requires that where a firm suspects, or has reasonable grounds to suspect, that a transaction or funds are proceeds of, or related to, the crime:
"regardless of their value, they shall notify the Unit without delay and directly, by providing a detailed report containing all available data and information concerning such Transaction and the relevant parties"
"The Unit" is the UAE Financial Intelligence Unit. Note: "regardless of their value". A reporting duty is not bound by a monitoring threshold.
A rule that produces more alerts than the team can work through does not become safer by producing them. If your queue is underwater, what to do when the alert queue is already backed up is a separate problem, and headcount is usually not the answer. And writing the narrative when the alert becomes a report is where a well designed rule can still produce a poor outcome.
Data completeness: does the transaction monitoring rule see all the data it needs?
Key point: a rule can only detect what reaches it. A broken feed produces silence, not an error.
Rule 041 depends on data from every system where that segment transacts. If one source stops delivering, the rule does not fail loudly. It stops alerting on the missing activity, and the dashboard looks calmer than usual. Calmer looks like success.
Ask five questions of each rule. Which source systems feed it? Does it include every relevant product and channel, or only those live when the feed was built?
What happens when a feed arrives late or incomplete? Who is told, and how fast? When a gap is found, is the missed period reprocessed and recorded?
The reconstruction obligation makes this concrete. Cabinet Resolution No. 134 of 2025, Article 25 requires firms to:
"organize retained records, documents, and instruments in a manner sufficient to permit the reconstruction of individual Transactions, data analysis, and the tracing of financial transactions, so as to be capable, where necessary, of providing evidence for prosecution of criminal activity."
Change control and version history
Key point: every parameter change needs a record showing who requested it, who approved it, what evidence supported it, and when it took effect.
A monitoring rule is a control. Changing it changes the control. The version history should show, for each change: the previous and new setting, the evidence behind it, the requester, the approver, the effective date, and confirmation it was tested outside production first.
Two patterns to watch. A change made in production by someone technical, correctly and for good reason, with no record. And an approval recorded with no evidence attached, so the file shows a decision but not a basis.
Cabinet Resolution No. 134 of 2025, Article 22 places an ongoing review duty on a named person. The Compliance Officer's duties include:
"Reviewing Anti-Money Laundering, and combating Financing of Terrorism, and Proliferation Financing internal systems and procedures, assessing their consistency with the provisions of the Decree by Law and this Resolution, evaluating the establishment's level of compliance with their implementation, proposing what is necessary to update and develop them"
UAE federal law calls that person the Compliance Officer. The DIFC and the ADGM say MLRO, the Money Laundering Reporting Officer. United States law says BSA Officer. Our guide to who is accountable, the Compliance Officer, the MLRO or the BSA Officer sets out the differences.
AML model validation and independent review
Key point: the person who built the rule cannot be the person who validates it.
The FFIEC manual states the expectation directly:
"The monitoring system's programming methodology and effectiveness should be independently validated to ensure that the models are detecting potentially suspicious activity."
A validation examines whether the rule does what it claims, whether its logic matches its documented intent, whether the data feeding it is complete, whether the parameters are supported, and whether the tuning history holds. It reviews the decision, not just the code.
The United States position on model risk changed this year. The Federal Reserve issued SR 26-2, Revised Guidance on Model Risk Management, dated 17 April 2026, superseding SR 11-7 and SR 21-8. If your policy still cites SR 11-7 as current, fix that before someone else finds it. The letter defines the exercise:
"Validation evaluates whether models perform as expected and includes an assessment of a model's reliability and its limitations."
"sufficient independence to maintain objectivity"
Proportionality cuts in your favour. That letter states its guidance "is expected to be most relevant to banking organizations with over $30 billion in total assets". A small money services business or a DNFBP is not expected to run a bank's model risk function.
What a smaller firm needs is still real. Someone other than the rule's owner reviewed it; the review is written down and dated, and the findings went to senior management. Article 21 of Cabinet Resolution No. 134 of 2025 requires internal controls to include "an independent audit function to test the effectiveness and adequacy of internal anti-crime policies, controls, and procedures". The scale is proportionate. The independence is not optional. In a smaller firm the periodic AML audit is often the only genuinely independent look the rule set ever gets, so whether monitoring rules sit inside its scope matters more than how long the report runs.
The examiner question set: 12 questions on transaction monitoring rules
Key point: these are the twelve questions asked of transaction monitoring rules. Answer every row for one rule before anybody external asks.
Table 3 sets out twelve questions and, for each, a weak answer, a defensible answer, and the document the evidence should come from. Read it as a self-assessment rather than as a script for the meeting. The fourth column is the one that does the work: if you cannot name the document, the answer in the third column is an intention rather than evidence, and it will not survive a follow-up question.
Work the table through for one rule before you attempt the whole inventory. Teams that start with the full rule set produce a spreadsheet of amber cells and no finished file. One rule fully evidenced tells you how long the work takes and where your AML programme's records actually live, which is usually across more teams than anyone expected.
The mistake with a question set like this is treating it purely as inspection preparation. A rule nobody can defend is not only a documentation problem. It is a rule producing alerts whose value nobody can state, which is the older and harder question of whether the activity yields anything, and we take that up in the AML effectiveness question and what filing achieves.
| # | The question | A weak answer | A defensible answer | Where the evidence lives |
| 1 | Why does this rule exist? | "It came with the system." | It addresses a named typology recorded in the risk assessment for this segment. | Risk assessment, rule inventory |
| 2 | Which risks have no rule? | "Everything is covered." | Three have none. Here they are, here is why, here is the dated plan. | Coverage matrix |
| 3 | Who is in this segment, and who is excluded? | "All business customers." | Defined on observed behaviour. Exclusions listed with reason and review date. | Segmentation analysis |
| 4 | What evidence set this threshold? | "It is the default." | Population analysis over a defined period, plus the risk assessment. | Tuning record, threshold rationale |
| 5 | When was this rule last reviewed? | "Some time last year." | On this date, under our stated cycle, plus an off-cycle review after a product change. | Tuning calendar, change log |
| 6 | Show me your below the line testing. | "We looked at some transactions." | Defined sample, stated period, reproducible selection, documented result. | Testing pack, sampling method |
| 7 | What did above the line testing show? | "The alerts look fine." | Sampled alerts at and above the threshold, reviewed outcomes, changed this. | Testing pack, outcome analysis |
| 8 | Is this rule productive, and how do you know? | "We do not measure that." | Alerts, escalations and reports counted separately. Here is what it changed. | Alert outcome reporting |
| 9 | Does this rule see all the data it needs? | "The system handles that." | These systems feed it, completeness is monitored, gaps trigger reprocessing. | Data lineage, feed monitoring log |
| 10 | Who approved the last change? | "It was updated at some point." | Named requester, named approver, date, evidence, tested before release. | Change control record |
| 11 | Who validated it, and were they independent? | "Our tuning team reviewed it." | A function independent of the build, on this date, findings to senior management. | Validation report, audit file |
| 12 | Show me the documentation for this rule. | Reaches for a spreadsheet nobody has opened in a year. | Hands over one rule file containing all of the above. | The rule file |
The three examiner questions that cause the most trouble
Question 2, coverage. Almost nobody has run it. An examiner who asks for a coverage matrix and receives a tuning pack has learned something.
Question 9, data. The answer sits with a technology team who were never asked, and a broken feed leaves no trace in the compliance record.
Question 8, feedback. The honest answer in many firms is that outcome data is produced monthly, circulated, and has never changed a rule.
The transaction monitoring rule documentation an examiner expects to be handed
Key point: one file per rule. If answering a question requires finding three people, the file is incomplete.
For each live rule, expect to produce:
The rule specification in plain language: what it detects, and for whom.
The link to the risk it addresses, referenced to the business risk assessment.
The segmentation basis, with exclusions and their reasons.
The threshold and parameter rationale, with evidence.
The tuning history: population, period, method, result, decision, approver, date.
The above-the-line and below-the-line testing packs, with the sampling method stated.
Alert outcome reporting for the rule, and what it changed.
The data lineage: which systems feed it, and how completeness is monitored.
The change control record and version history.
The latest independent validation, with findings and their status.
Most of this already exists somewhere in your institution. Assembling it into one file per rule is the work, and it is far easier before an inspection than during one.
Defending a transaction monitoring rule in the room
Key point: "the vendor set it" is never an answer. "We do not know, and here is what we are doing about it" sometimes is.
When you do not know, say so and commit to a date. An admitted gap with a dated plan is manageable. A confident guess that turns out wrong is a credibility problem, and it spreads to the answers you got right.
Never blame the platform. The institution owns the control. The point isn't where the logic came from. Choosing to run it is.
Bring the file, not the person. If the only way to answer is to call the analyst who has been there the longest, that is itself the finding.
Analysts who can defend a rule end up owning rule sets. It sits alongside the other capabilities in our piece on the AML analyst skills hiring managers actually test.
We sell AML training, so here is our interest in this
Pro AML Training sells applied AML and CFT training. This article argues that monitoring teams need a documented, defensible method, and we sell a course teaching exactly that. Factor it in, then judge the argument on the FFIEC text and the Cabinet Resolution articles quoted above.
Our course, Advanced Transaction Monitoring for Trading, Funds and Wealth Operations, provides conceptual background on transaction monitoring. Enrol Now. If you're wondering whether machine learning should replace some of this, The Role of AI in AML covers where models help and where explainability limits them, and our article on whether AI will replace AML compliance jobs covers the career side.
How this article was researched and verified
We read the FFIEC BSA/AML Examination Manual at source on 30 August 2026, in the Suspicious Activity Reporting section under Assessing Compliance with BSA Regulatory Requirements. Every sentence attributed to it is quoted word for word from the section headed Surveillance Monitoring (Automated Account Monitoring).
Cabinet Resolution No. 134 of 2025 and Federal Decree-Law No. 10 of 2025 were read in their published text on 30 August 2026. Articles 5, 8, 17, 21, 22 and 25 of the Cabinet Resolution and Article 18 of the Decree-Law are quoted or cited from the instruments themselves. These replaced Federal Decree-Law No. 20 of 2018 and Cabinet Decision No. 10 of 2019, which are repealed and are not cited here. The Federal Reserve read SR 26-2 on the same date. It is dated 17 April 2026 and supersedes SR 11-7 and SR 21-8.
No threshold value, parameter setting or scenario configuration appears anywhere in this article, and that is deliberate. Nothing published here should help anyone stay below a detection threshold. Every threshold discussion is written from the institution’s perspective, never from the perspective of someone observing it. Rule 041 is an invented illustration with no values attached, and it describes no real institution, customer or case. No vendor and no monitoring platform is named.
No figure appears for false positive rates, alert productivity, tuning uplift, alert-to-report conversion or any industry benchmark. None could be verified against a primary source that would apply to your institution, and a number published here would be quoted back at somebody in an inspection where it did not fit. The one figure that does appear, the $30 billion relevance threshold, is quoted from SR 26-2 itself.
Frequently asked questions about transaction monitoring rules
