Skip to main content
Category: Risk Assessment

Above-the-Line Testing

Also known as: ATL, Above-the-line test, Above The Line testing, ATL testing
Simply put

Above-the-line testing is a technique used to check whether the rules and thresholds in an automated transaction monitoring system are set at the right level. It focuses on the transactions and alerts that currently fall above a monitoring threshold, helping an institution understand how many of those alerts are genuinely useful versus how many are false positives. It is typically used alongside below-the-line testing to fine-tune a monitoring program so it works more efficiently.

Formal definition

Above-the-line (ATL) testing is a model calibration and tuning method applied to rule-based AML transaction monitoring systems, in which the transactions and alerts generated above an existing detection threshold are examined, often by adjusting or elevating parameters above the current baseline, to assess alert quality and identify the threshold levels at which false positives arise. It is generally performed as one component of a broader calibration or optimization exercise and is paired with below-the-line (BTL) testing, which reviews activity falling below the threshold to detect potentially missed suspicious activity. ATL testing is an operational and analytical technique, frequently applying statistical methods, rather than a regulatory test defined by any single instrument, and its scope, sampling approach, and acceptance criteria vary by institution, system, and applicable supervisory expectations. The specific parameters, sampling volumes, and pass/fail standards should be confirmed against an institution's own model governance framework and any relevant regulatory guidance.

Why it matters

Rule-based transaction monitoring systems generate alerts whenever activity crosses a configured threshold, but a threshold set too low can flood investigators with false positives, while one set too high may leave genuinely suspicious activity undetected. Above-the-line testing gives an institution a structured way to examine the alerts already being produced above a threshold and assess how many represent useful, actionable output versus noise. This matters because alert quality directly affects the efficiency of an AML program: investigators have finite capacity, and time spent clearing false positives is time not spent on higher-risk activity.

ATL testing is one part of a broader model calibration and tuning exercise, and it is generally paired with below-the-line testing, which looks at activity falling below the threshold to check for potentially missed suspicious activity. Together, these techniques help an institution demonstrate that its thresholds are set deliberately and defensibly rather than left at vendor defaults or arbitrary levels. Because supervisory expectations increasingly emphasize documented model governance, being able to show evidence of periodic calibration can be an important element of a program's overall credibility.

It is important to frame ATL testing as an operational and analytical technique rather than a regulatory test defined by any single instrument. It does not guarantee that all suspicious activity is captured, nor does the presence or absence of alerts establish wrongdoing. Its value lies in helping an institution detect, deter, and manage financial crime risk more efficiently by informing where thresholds are placed, with the specific parameters, sampling approaches, and acceptance criteria varying by institution and system.

Who it's relevant to

Transaction Monitoring and Model Calibration Teams
Analysts and specialists responsible for tuning rule-based monitoring systems use above-the-line testing to assess alert quality and identify where thresholds produce false positives. They typically run ATL testing alongside below-the-line testing as part of a structured calibration exercise, applying statistical methods and documenting the parameters and results.
Model Governance and Validation Functions
Teams overseeing model risk and validation rely on ATL testing outputs to evaluate whether monitoring thresholds are set deliberately and defensibly. They confirm that sampling approaches, parameters, and acceptance criteria align with the institution's own model governance framework and any applicable supervisory expectations.
AML Compliance Officers and Program Leadership
Compliance leaders use the results of ATL testing to understand and improve the efficiency of the monitoring program, balancing investigator capacity against the risk of missed activity. They should treat it as a technique to help detect, deter, and manage financial crime risk rather than as a guarantee that all suspicious activity is captured.
Investigators and Alert Adjudication Staff
Those who clear and investigate alerts are directly affected by threshold calibration, since ATL testing informs how many false positives reach their queues. Better-calibrated thresholds can help focus their attention, though an alert or match does not by itself establish wrongdoing.

Inside ATL

Threshold Calibration Focus
Above-the-line testing examines transactions or scenarios that fall at or above the configured detection thresholds of a transaction monitoring system, assessing whether alerts that should generate are in fact generating as designed.
Alert Generation Validation
It verifies that the monitoring rules, scenarios, and parameters produce the alerts they are intended to produce, confirming the system correctly captures activity meeting or exceeding its defined criteria.
Complement to Below-the-Line Testing
Above-the-line testing is typically paired with below-the-line testing, which probes activity falling just under thresholds to assess whether the cut-offs are set appropriately and whether potentially suspicious activity is being missed.
Model and Rule Tuning Input
Results generally feed into the tuning and optimization of transaction monitoring models, informing whether thresholds, scenarios, and parameters remain fit for purpose against the institution's risk profile.
Operational Assurance Function
It serves as an operational and validation control, providing evidence to compliance, model risk, and audit functions that monitoring systems are performing as intended, rather than being a legal test of wrongdoing.

Common questions

Answers to the questions practitioners most commonly ask about ATL.

Is above-the-line testing the same as validating that alerts were investigated correctly?
No. Above-the-line testing focuses on the alerts a monitoring system did generate (those that broke a threshold or rule and rose "above the line"), assessing whether the system produced them as intended and whether the scenarios and thresholds are calibrated appropriately. Reviewing whether analysts investigated and dispositioned those alerts correctly is a separate quality-assurance activity. The two are complementary but distinct, and conflating them can leave gaps in how a program evaluates its transaction monitoring.
If above-the-line testing shows the alerts are generating properly, does that mean the monitoring system is working effectively?
Not on its own. Above-the-line testing examines activity that already produced alerts; it generally does not tell you about potentially suspicious activity that fell below thresholds and generated no alert. That gap is what below-the-line testing is designed to explore. Many programs treat above-the-line and below-the-line testing as paired exercises, because confirming that generated alerts behave as expected does not, by itself, demonstrate that the thresholds and scenarios are capturing the risks they should.
What is typically examined during an above-the-line test?
Testing generally examines whether the monitoring system's scenarios and rules fired as designed for transactions that exceeded the configured thresholds, whether the resulting alerts contain accurate and complete data, and whether the threshold settings appear appropriately calibrated to the institution's risk profile. The specific scope depends on the institution, its systems, and its testing methodology, and should be defined in the applicable testing plan or model validation framework.
How does above-the-line testing relate to model validation and tuning?
In many programs, above-the-line testing is used as an input to threshold tuning and to broader model validation or model risk management processes. Results may indicate that certain thresholds are set in ways that generate large volumes of low-value alerts or that scenario logic is not performing as intended. How these findings are governed and remediated typically depends on the institution's model risk management framework and internal policies rather than a single prescribed standard.
How often should above-the-line testing be performed?
There is no universal frequency; the cadence generally depends on the institution's risk profile, the materiality of the monitoring system, regulatory expectations in the applicable jurisdiction, and internal governance requirements. Testing may be performed on a periodic schedule and also triggered by changes such as new products, system upgrades, or scenario reconfiguration. Institutions should align the frequency with their model risk management and audit expectations and confirm against applicable regulatory guidance.
Who typically performs above-the-line testing and how is it documented?
Depending on the institution, testing may be performed by an independent validation function, internal audit, a dedicated model risk team, or a specialist unit, with independence from those who designed or operate the monitoring system generally considered good practice. Documentation typically covers the scope, methodology, sample selection, results, and any findings and remediation actions, so the work can be evidenced to internal governance bodies and reviewed by examiners. Specific ownership and documentation standards should follow the institution's internal policies and applicable regulatory expectations.

Common misconceptions

Above-the-line testing on its own confirms a transaction monitoring system is effective.
It primarily confirms that alerts fire as designed at or above thresholds; it does not, by itself, reveal activity slipping below thresholds. It is generally used alongside below-the-line testing to assess whether threshold settings are appropriate. Neither approach guarantees prevention of financial crime; both are measures to help detect and manage risk.
An alert generated during above-the-line testing indicates suspicious or criminal activity.
The purpose is to validate that the system generates alerts it is configured to generate. An alert is an operational output for review, not evidence of wrongdoing, and validation testing is a systems-assurance exercise rather than a suspicion or criminal-law determination.
There is a single universally mandated methodology or threshold standard for above-the-line testing.
Approaches to monitoring system validation are generally shaped by supervisory expectations, model risk management practice, and the obliged entity's own risk-based framework, which vary by jurisdiction and regime. Exact methodologies and thresholds should be confirmed against applicable regulatory guidance and internal policy.

Best practices

Pair above-the-line testing with below-the-line testing so that both alerting at thresholds and potential gaps just beneath thresholds are examined as part of a rounded validation cycle.
Document the testing methodology, sample selection, thresholds tested, and results clearly to support review by compliance, model risk, and audit functions.
Use testing outcomes as structured input into the tuning and recalibration of monitoring scenarios and parameters, aligned to the institution's current risk profile.
Perform testing on a periodic basis and after material changes to rules, scenarios, thresholds, data feeds, or the underlying business, rather than treating it as a one-off exercise.
Frame findings as systems-assurance results, avoiding any implication that generated alerts establish suspicion or wrongdoing.
Confirm the testing approach and any threshold assumptions against applicable supervisory guidance and internal model governance policy, as expectations may differ by jurisdiction.