AML/CFT Transaction Monitoring: Rules, Scenarios, Calibration and Effectiveness Testing

AML/CFT transaction monitoring is the process through which an obliged entity reviews customer transactions and activities to identify behaviour that is unusual, inconsistent with the customer profile or potentially related to money laundering, terrorist financing or other criminal activity.

An effective transaction monitoring framework does more than generate alerts. It must connect:

reliable customer and transaction data;
customer risk classification;
expected customer behaviour;
risk-based monitoring scenarios;
appropriate thresholds;
alert investigation;
escalation and reporting;
ongoing calibration;
quality assurance; and
independent effectiveness testing.

Under Article 26 of Regulation (EU) 2024/1624, the EU Anti-Money Laundering Regulation, or AMLR, obliged entities must continuously monitor business relationships, including customer transactions. The purpose is to establish whether transactions remain consistent with the entity’s knowledge of the customer, the customer’s business activity and risk profile and, where necessary, information concerning the origin and destination of funds. The monitoring must also identify transactions requiring more thorough assessment under Article 69 AMLR.

The AMLR generally applies from 10 July 2027. AMLA is developing guidelines under Article 26(5) that explain how ongoing monitoring, customer-information updates and transaction and activity monitoring should operate in practice. The consultation on those draft guidelines opened on 3 June 2026 and remains open until 3 September 2026. The draft may therefore change before finalisation.

What is AML/CFT transaction monitoring?

AML/CFT transaction monitoring is the structured review of financial and non-financial customer activity for indicators of unusual or potentially suspicious behaviour.

Depending on the obliged entity’s business model, the monitored activity may include:

payments;
cash deposits and withdrawals;
transfers of funds;
card transactions;
merchant acquiring activity;
securities transactions;
investment subscriptions and redemptions;
insurance premiums and payouts;
crypto-asset transfers;
trade-finance activity;
lending and repayments;
gambling activity;
purchases of high-value goods;
changes in ownership or control;
non-transactional customer activity.

Transaction monitoring can be:

automated;
manual;
rules-based;
behaviour-based;
model-supported;
event-driven;
performed in real time;
performed after execution;
or implemented through a combination of these approaches.

The appropriate framework depends on the entity’s customers, products, services, transaction volumes, delivery channels, geographical exposure and assessed money laundering and terrorist financing risks.

Transaction monitoring at a glance

Component	Principal purpose
Customer profile	Establish the expected purpose and nature of the relationship
Transaction data	Provide complete and accurate activity information
Customer segmentation	Group customers with comparable characteristics
Monitoring scenarios	Detect defined risk patterns and typologies
Thresholds	Determine when activity should generate an alert
Alert generation	Identify activity requiring investigation
Alert investigation	Determine whether an explanation is reasonable
Escalation	Refer material concerns for further assessment
Suspicious transaction reporting	Report relevant suspicions to the FIU
Calibration	Adjust scenarios and thresholds to risk and performance
Validation	Determine whether the methodology operates as intended
Effectiveness testing	Assess whether material suspicious activity can be detected
Management information	Enable governance, oversight and remediation

1. Legal basis under the AMLR

Article 26 AMLR requires obliged entities to conduct ongoing monitoring of business relationships, including transactions undertaken by customers throughout those relationships.

Monitoring must determine whether transactions are consistent with:

the entity’s knowledge of the customer;
the customer’s business activity;
the customer’s risk profile;
the expected purpose and intended nature of the relationship;
and, where necessary, information concerning the origin and destination of funds.

Where a customer relationship covers several products or services, the monitoring framework must cover all of them. Group entities must also take relevant information concerning other relationships within the group into account where required.

Article 25 AMLR requires the obliged entity to understand the purpose and intended nature of a business relationship or occasional transaction. Relevant information may include:

the economic rationale;
expected transaction values;
source of funds;
destination of funds;
customer business activity;
customer occupation.

These data provide the baseline against which actual activity should be monitored.

Transaction monitoring and suspicious transaction reporting

Transaction monitoring supports, but does not replace, the obligation to report suspicions.

Under Article 69 AMLR, an obliged entity must promptly report to the competent Financial Intelligence Unit where it knows, suspects or has reasonable grounds to suspect that funds or activities are proceeds of criminal activity or are related to terrorist financing or criminal activity.

The reporting obligation applies:

regardless of the amount involved;
to completed transactions;
to attempted transactions;
and to suspicions arising from an inability to complete customer due diligence.

A transaction monitoring alert is therefore not itself a suspicious transaction report. It is an indicator requiring assessment. The reporting obligation arises from the facts and circumstances identified during the investigation, not from the existence or score of an alert alone.

2. Ongoing monitoring vs. transaction monitoring

The terms ongoing monitoring and transaction monitoring are related but not identical.

Ongoing monitoring

Ongoing monitoring is the wider process through which the obliged entity maintains a current understanding of the business relationship.

It includes:

updating customer identification information;
reviewing beneficial ownership;
reassessing customer risk;
repeating PEP and sanctions screening;
assessing adverse media;
reviewing the purpose and intended nature of the relationship;
monitoring transactions and activities.

Transaction monitoring

Transaction monitoring is the component focused on financial transactions and other observable customer activity.

It examines whether activity:

is consistent with the customer profile;
is consistent with expected behaviour;
has an understandable economic or lawful rationale;
involves unusual counterparties or countries;
displays known money laundering or terrorist financing indicators;
requires a more thorough assessment.

AMLA’s draft guidelines under Article 26(5) are structured into general principles, customer-information updates and a transaction and activity monitoring framework. This confirms that transaction monitoring forms part of the broader ongoing-monitoring obligation.

3. Risk-based transaction monitoring

A transaction monitoring framework should be derived from the obliged entity’s identified risks rather than from a generic library of scenarios.

The process should connect:

the business-wide risk assessment;
the customer risk assessment;
products and services;
delivery channels;
geographical exposure;
expected customer behaviour;
known typologies;
monitoring scenarios;
thresholds and parameters;
investigation and escalation procedures.

Relevant risk dimensions

Customer risk

customer type;
occupation or industry;
cash intensity;
legal form;
ownership complexity;
PEP exposure;
high-net-worth status;
use of intermediaries;
history of unusual activity.

Product and service risk

international payments;
correspondent banking;
merchant acquiring;
private banking;
trade finance;
money remittance;
crypto-assets;
prepaid instruments;
high-value goods;
products facilitating rapid movement of value.

Geographical risk

high-risk third countries;
conflict zones;
sanctioned jurisdictions;
corruption-sensitive jurisdictions;
secrecy jurisdictions;
countries associated with relevant criminal typologies.

Transaction risk

high velocity;
unusual value;
unexplained cash activity;
rapid pass-through of funds;
round amounts;
repeated reversals;
complex payment chains;
third-party funding;
transactions inconsistent with known income or turnover.

Delivery-channel risk

remote onboarding;
non-face-to-face relationships;
intermediated transactions;
agents;
digital platforms;
anonymous or pseudonymous features.

The monitoring intensity should be proportionate to the combined risk of the customer, relationship, product and activity.

4. Customer profiles and expected behaviour

Transaction monitoring cannot reliably identify deviations unless the obliged entity has established an expected customer profile.

The customer profile should reflect:

the purpose of the relationship;
products and services used;
expected transaction types;
expected transaction values;
expected transaction frequency;
anticipated counterparties;
expected countries;
source of funds;
destination of funds;
business turnover;
occupation or employment;
seasonal patterns;
expected use of cash.

Dynamic customer profiles

Expected behaviour should not be based exclusively on information obtained at onboarding.

Profiles should be updated when:

the customer’s business changes;
turnover increases materially;
new products are used;
ownership changes;
geographical exposure changes;
transaction behaviour changes;
new risk information becomes available.

The framework should distinguish between:

an explainable change in legitimate customer behaviour;
a material deviation requiring reassessment;
potentially suspicious activity requiring escalation.

5. Customer segmentation

Customer segmentation groups customers with comparable characteristics so that monitoring rules and thresholds can be applied more accurately.

Possible segmentation criteria include:

customer type;
legal form;
industry;
occupation;
country;
product usage;
transaction volume;
transaction value;
delivery channel;
customer risk category;
PEP status;
cash intensity.

Purpose of segmentation

Appropriate segmentation can reduce two types of error:

False positives

Legitimate transactions generate unnecessary alerts because the threshold is inappropriate for the customer’s normal behaviour.

False negatives

Suspicious activity remains undetected because the threshold is too broad or the customer is compared with an unsuitable peer group.

Segmentation weaknesses

Common weaknesses include:

segments that are too broad;
segments with very few customers;
inconsistent customer assignment;
outdated segment definitions;
excessive reliance on risk ratings;
no validation of peer-group comparability.

Segmentation should be documented, approved and periodically reassessed.

6. AML/CFT transaction monitoring scenarios

A monitoring scenario is a defined rule, model or analytical method designed to identify a particular type of unusual activity or risk pattern.

Scenarios should be traceable to:

the business-wide risk assessment;
sector-specific risks;
customer risks;
products and services;
known typologies;
internal investigations;
suspicious transaction reports;
supervisory findings;
law-enforcement information;
emerging risks.

Common monitoring scenarios

Unusual transaction value

Detects transactions materially above the customer’s established or expected range.

Unusual transaction frequency

Detects a sudden or unexplained increase in the number of transactions.

Rapid movement of funds

Detects incoming funds that are transferred onward shortly after receipt without an apparent economic rationale.

Structuring or smurfing

Detects repeated transactions below relevant thresholds or internal limits.

Cash-intensive activity

Detects cash deposits or withdrawals that are inconsistent with the customer’s occupation, business or historical behaviour.

Dormant-account reactivation

Detects significant activity following a prolonged period of inactivity.

Round-value transactions

Detects repeated transactions in unusually rounded amounts, particularly where inconsistent with the expected activity.

Geographic-risk exposure

Detects activity involving higher-risk, sanctioned or otherwise sensitive jurisdictions.

Unusual counterparties

Detects transactions involving counterparties outside the customer’s known business or personal profile.

Funnel-account activity

Detects funds deposited through several locations or persons and rapidly withdrawn or transferred elsewhere.

Circular transactions

Detects funds returning to the originator or connected parties through one or more intermediaries.

Transaction splitting

Detects activity divided into smaller amounts to avoid monitoring, reporting or CDD thresholds.

Third-party funding

Detects unexplained payments made by or to parties with no apparent connection to the customer.

In-and-out activity

Detects accounts used primarily for the receipt and onward transfer of funds with limited retained balances.

Sudden international activity

Detects new or materially increased cross-border activity without a corresponding change in the customer profile.

Activity inconsistent with income or turnover

Detects transaction levels that appear incompatible with known earnings, business revenue or source of wealth.

Unusual merchant activity

Detects acquiring activity inconsistent with the merchant category, expected sales profile or location.

High-risk crypto-asset activity

Detects exposure to mixers, tumblers, darknet services, sanctioned addresses or unusual cross-chain activity where relevant to the business model.

Scenario design documentation

Each scenario should have a documented specification covering:

scenario name;
risk addressed;
legal or typological basis;
in-scope customers;
in-scope products;
data fields;
calculation logic;
thresholds;
lookback period;
alert-suppression logic;
exclusions;
aggregation rules;
expected alert volumes;
owner;
approval date;
review frequency.

7. Thresholds and parameters

A threshold determines when the monitoring logic produces an alert.

Thresholds may be:

absolute;
percentage-based;
behaviour-based;
peer-group-based;
risk-adjusted;
cumulative;
velocity-based;
time-dependent.

Absolute thresholds

An alert is generated when activity exceeds a fixed value.

Example:

Total incoming cash deposits exceed a specified amount within 30 days.

Relative thresholds

An alert is generated when activity deviates materially from the customer’s historical behaviour.

Example:

Monthly outgoing payments exceed the customer’s historical average by a defined percentage.

Peer-group thresholds

The customer’s activity is compared with comparable customers.

Example:

Transaction value is materially higher than the expected range for customers in the same segment.

Composite thresholds

Several conditions must be met.

Example:

High-value incoming transfer from a higher-risk jurisdiction followed by rapid onward transfer to an unrelated third party.

Threshold risks

A threshold that is too low can produce excessive false positives and investigation backlogs.

A threshold that is too high can fail to detect material suspicious activity.

Threshold selection should therefore be based on:

identified risk;
historical data;
customer behaviour;
scenario purpose;
alert volumes;
investigation outcomes;
suspicious transaction reporting outcomes;
available investigative capacity.

Investigation capacity should not, however, be used to justify thresholds that leave material risks unmonitored.

8. Real-time and post-event monitoring

Real-time monitoring

Real-time monitoring assesses a transaction before or during execution.

It may be appropriate where:

immediate interdiction is required;
sanctions restrictions apply;
fraud risk is high;
payment speed creates recovery difficulties;
regulatory requirements require pre-execution controls.

Post-event monitoring

Post-event monitoring assesses transactions after execution, often through daily or periodic processing.

It may be appropriate for:

behavioural analysis;
cumulative patterns;
peer-group comparisons;
longer-term typologies;
activity requiring several transactions to become visible.

A comprehensive framework may combine real-time interdiction controls with post-event behavioural monitoring.

9. Data quality and transaction coverage

Transaction monitoring effectiveness depends on the quality and completeness of the underlying data.

Relevant data may include:

customer identifiers;
account identifiers;
transaction date and time;
transaction amount;
currency;
transaction type;
channel;
originator;
beneficiary;
counterparty;
counterparty country;
bank or service-provider identifiers;
payment reference;
merchant category;
device or location data;
customer risk rating;
PEP status;
product information.

Data controls

The monitoring framework should include controls over:

source-system completeness;
interface reconciliation;
rejected records;
duplicate records;
missing fields;
invalid values;
delayed data;
currency conversion;
customer-account mapping;
group-level customer mapping;
reference-data updates.

Transaction coverage assessment

The obliged entity should maintain an inventory showing:

all transaction types;
all systems;
all products;
all legal entities;
all branches;
all monitoring scenarios;
any excluded activity;
the reason for exclusions.

Every material transaction stream should either be monitored or covered by a documented alternative control.

10. Alert generation and prioritisation

An alert indicates that activity meets defined monitoring criteria. It does not establish that the activity is suspicious.

Alert records should contain enough information to support investigation, including:

customer details;
risk classification;
triggering transactions;
scenario and threshold;
relevant historical activity;
counterparties;
countries;
previous alerts;
previous reports;
customer profile;
relevant CDD information.

Alert prioritisation

Alerts may be prioritised according to:

customer risk;
PEP status;
sanctions relevance;
transaction value;
risk jurisdiction;
scenario severity;
previous alerts;
previous suspicious transaction reports;
unusual-activity score;
combination of indicators.

Prioritisation should ensure that higher-risk alerts are investigated more quickly without leaving lower-priority alerts unresolved indefinitely.

11. Alert investigation

The investigation should determine whether the observed activity:

is consistent with the customer profile;
has a reasonable economic or lawful explanation;
is supported by available evidence;
changes the customer risk;
requires enhanced due diligence;
creates knowledge, suspicion or reasonable grounds for suspicion.

Recommended investigation steps

Review the triggering transactions.
Review the customer profile and expected activity.
Review related accounts, products and relationships.
Review ownership and connected parties.
Review PEP, sanctions and adverse-media information.
Review previous alerts and investigations.
Assess source and destination of funds.
Obtain additional information where appropriate.
Document the analysis.
Determine whether escalation is required.

Customer contact

Contacting the customer may help explain unusual activity. However, it should be managed carefully.

The entity should consider:

whether customer contact is appropriate;
whether it could prejudice an investigation;
whether it could create a tipping-off risk;
who is authorised to make contact;
what information may be requested;
whether the response is plausible and evidenced.

12. Alert disposition and escalation

Possible alert outcomes include:

false positive;
expected activity;
activity explained by existing information;
customer profile update required;
customer risk increase required;
enhanced due diligence required;
continued monitoring required;
escalation for suspicious-activity assessment;
restriction or termination consideration.

Closure documentation

A closure should state:

what triggered the alert;
what was reviewed;
which evidence was considered;
why the activity was or was not considered unusual;
whether the customer profile remains accurate;
whether further action is required;
who made and approved the decision.

Generic statements such as “activity consistent” or “no suspicion identified” are not sufficient without supporting analysis.

13. Suspicious transaction escalation

Where an investigator identifies potentially suspicious activity, the matter should be escalated to the appropriately authorised function.

The escalation process should define:

escalation criteria;
required information;
escalation deadlines;
decision-makers;
FIU reporting responsibility;
post-report controls;
confidentiality and tipping-off restrictions.

Article 69 AMLR requires prompt reporting where knowledge, suspicion or reasonable grounds for suspicion exist. Reporting must not be delayed solely because an internal investigation has not established conclusive proof.

AMLA is also developing an EU-wide common format for reporting suspicions and providing transaction records. The 2026 consultation is intended to harmonise relevant data points while accommodating sector-specific reporting needs.

14. Transaction monitoring calibration

Calibration is the process of adjusting monitoring rules, thresholds, parameters and segmentation so that the system remains aligned with identified risks.

Calibration should determine whether:

scenarios cover the relevant risks;
thresholds are appropriate;
customer segments are meaningful;
alert volumes are manageable without compromising risk coverage;
material suspicious activity can be detected;
unnecessary alerts can be reduced.

Calibration inputs

historical transaction data;
alert volumes;
alert disposition;
suspicious transaction reports;
customer-risk distribution;
scenario performance;
typology changes;
new products;
new customer segments;
new countries;
law-enforcement information;
audit findings;
quality-assurance results.

Calibration process

Step 1: Define the risk objective

Identify the specific risk or typology the scenario should detect.

Step 2: Assess data availability

Confirm that the required transaction and customer data are complete and reliable.

Step 3: Analyse historical behaviour

Review the distribution of relevant transaction values, frequencies and patterns.

Step 4: Test alternative thresholds

Assess how different parameters affect alert volumes and risk coverage.

Step 5: Review alert quality

Determine whether alerts identify meaningful unusual activity.

Step 6: Approve changes

Document the rationale, testing results, expected effects and approval.

Step 7: Monitor post-implementation performance

Confirm that the adjusted scenario operates as intended.

Calibration frequency

Calibration should occur:

periodically;
following significant risk-assessment changes;
after new products or services;
after material customer-base changes;
after system changes;
following significant backlogs;
where false-positive rates indicate weakness;
after audit or supervisory findings;
where new typologies emerge.

15. Back testing

Back testing applies a scenario or parameter change to historical data to assess how it would have performed.

It can be used to determine:

whether previously known suspicious activity would have been detected;
how alert volumes would change;
whether thresholds are too high or low;
whether specific customer segments require different parameters;
whether changes create unexpected gaps.

Back-testing limitations

Back testing is most useful where:

historical data are complete;
known cases are available;
scenario logic can be reproduced;
outcomes are interpreted with appropriate caution.

A scenario that detects all previously known cases may still fail to detect new or different typologies. Back testing should therefore not be the sole effectiveness measure.

16. Below-the-line testing

Below-the-line testing reviews transactions that fell just below an alert threshold.

Its purpose is to determine whether:

the threshold is excluding relevant activity;
the risk changes materially immediately below the threshold;
the threshold should be lowered;
different segments require separate thresholds.

For example, where a scenario generates alerts above a specified cumulative value, the entity may sample customers immediately below that value and assess whether material unusual activity was missed.

17. Above-the-line testing

Above-the-line testing reviews alerts generated by the scenario.

It can assess:

whether the alert logic is correctly implemented;
whether the generated alerts correspond to the intended risk;
whether investigators receive sufficient information;
whether excessive low-value alerts are being generated;
whether closure decisions are adequately supported.

18. Scenario validation

Scenario validation determines whether the monitoring logic is conceptually sound, correctly implemented and fit for purpose.

Conceptual soundness

The validator should determine whether:

the scenario addresses a defined risk;
the logic is consistent with the typology;
the chosen data fields are relevant;
thresholds are supported by analysis;
exclusions are justified.

Implementation verification

The validator should determine whether:

the programmed logic matches the approved specification;
the correct data are used;
aggregation operates correctly;
the lookback period is correct;
alerts are generated as intended;
changes are controlled.

Outcome analysis

The validator should consider:

alert volumes;
false-positive rates;
escalation rates;
reporting outcomes;
customer segments;
undetected known cases;
back-testing results;
below-the-line testing.

Validation should be sufficiently independent from the personnel responsible for designing and operating the scenario.

19. Design effectiveness testing

Design effectiveness assesses whether the transaction monitoring framework is capable of addressing the relevant risks.

Design questions

Are all material transaction streams covered?
Are scenarios linked to identified risks?
Are customer segments appropriate?
Are thresholds supported by evidence?
Are customer-risk factors incorporated?
Are data controls defined?
Are alert-investigation procedures adequate?
Are escalation criteria clear?
Are suspicious transaction reporting responsibilities assigned?
Are changes subject to approval?
Are scenarios periodically reviewed?

A control can be properly documented but still be inadequately designed if it cannot detect the risk it is intended to address.

20. Operating effectiveness testing

Operating effectiveness assesses whether the monitoring framework has operated consistently and correctly over a representative period.

Operating-effectiveness questions

Were all required transactions processed?
Were alerts generated correctly?
Were alerts investigated within required timelines?
Were investigations complete?
Were escalation criteria applied consistently?
Were customer risk ratings updated where necessary?
Were suspicious matters reported promptly?
Were quality-assurance findings remediated?
Were scenario changes approved and tested?
Were data exceptions resolved?

Typical testing samples

generated alerts;
closed alerts;
escalated alerts;
reported cases;
non-reported escalations;
high-risk customers;
PEP relationships;
customers involving higher-risk countries;
dormant accounts;
manually overridden alerts;
alerts closed in unusually short periods;
transactions immediately below thresholds.

21. End-to-end effectiveness testing

End-to-end testing examines whether the complete monitoring process works from data capture through reporting.

The test should cover:

transaction creation;
data extraction;
system interface;
scenario processing;
alert generation;
prioritisation;
case creation;
investigation;
escalation;
reporting;
record retention.

This testing can identify weaknesses that are not visible when individual controls are reviewed in isolation.

22. Quality assurance

Quality assurance assesses the quality and consistency of alert investigations and decisions.

A quality-assurance review should consider:

whether all relevant information was reviewed;
whether the analysis was accurate;
whether the rationale was complete;
whether escalation criteria were applied;
whether the customer risk should have changed;
whether further monitoring was required;
whether the case was closed appropriately.

Quality-assurance sampling

Samples may be risk-based and include:

high-value alerts;
high-risk customers;
PEPs;
complex investigations;
new investigators;
unusual closure patterns;
escalated cases;
non-reported cases;
cases closed near deadlines.

Quality-assurance findings should feed into:

training;
procedures;
scenario design;
staff coaching;
management reporting;
remediation.

23. Transaction monitoring backlogs

A backlog arises where alerts are not investigated within the required or internally defined period.

Backlogs can create significant risk because unusual activity may continue while alerts remain unresolved.

Backlog management should include

ageing analysis;
risk-based prioritisation;
daily or weekly governance;
additional staffing;
temporary controls;
root-cause analysis;
scenario review;
capacity planning;
senior management reporting;
remediation deadlines.

A backlog should not be resolved by mass-closing alerts or raising thresholds without a documented risk analysis.

24. False positives and false negatives

False positive

A false positive occurs where legitimate activity generates an alert.

High false-positive volumes may indicate:

inappropriate thresholds;
poor segmentation;
incomplete customer profiles;
duplicated data;
unsuitable scenario logic;
ineffective suppression rules.

False negative

A false negative occurs where relevant unusual or suspicious activity is not detected.

False negatives can result from:

missing scenarios;
thresholds that are too high;
incomplete data;
excluded transaction types;
incorrect customer mapping;
defective system implementation;
inadequate typology coverage.

Reducing false positives must not be treated as the sole optimisation objective. The primary purpose of calibration is effective risk detection.

25. Machine learning and advanced analytics

Machine learning may support:

customer segmentation;
anomaly detection;
alert prioritisation;
network analysis;
behavioural profiling;
investigator decision support.

It should not eliminate governance, explainability or human accountability.

The entity should understand:

the model objective;
training data;
input features;
limitations;
bias risks;
performance metrics;
threshold logic;
change management;
human review requirements.

Advanced analytics should be validated and monitored in the same way as other material transaction monitoring models.

26. Management information and key indicators

Management information should enable the management body and compliance function to assess both operational performance and risk coverage.

Recommended indicators

total transactions monitored;
transaction streams covered;
alert volumes;
alerts by scenario;
alerts by customer segment;
alert-to-escalation rate;
escalation-to-reporting rate;
false-positive rate;
investigation time;
overdue alerts;
backlog age;
high-risk-customer alerts;
PEP alerts;
alerts involving higher-risk countries;
scenario changes;
data-quality exceptions;
quality-assurance error rate;
audit findings;
overdue remediation actions.

Indicators should be analysed over time and supported by explanatory commentary.

27. Governance and responsibilities

Management body

The management body should:

approve the overall monitoring framework;
ensure adequate resources;
receive meaningful reporting;
challenge significant weaknesses;
oversee remediation.

AML/CFT compliance function

The AML/CFT compliance function should:

define monitoring requirements;
oversee scenario design;
approve or challenge calibration;
monitor performance;
oversee suspicious transaction reporting;
report material deficiencies.

Operations and investigators

Operational teams should:

investigate alerts;
document findings;
escalate material concerns;
comply with timelines;
maintain confidentiality.

Information technology and data teams

Technology and data functions should:

maintain system availability;
ensure data completeness;
control changes;
resolve interface failures;
preserve audit trails.

Internal audit

Internal audit should independently assess:

governance;
risk coverage;
scenario design;
data integrity;
alert investigation;
reporting;
calibration;
validation;
operating effectiveness.

28. Common transaction monitoring weaknesses

Generic scenarios are not linked to the risk assessment

The entity uses a standard scenario library without demonstrating how the scenarios address its particular risks.

Not all transactions are monitored

Certain products, channels, branches or systems are omitted without documented justification.

Thresholds are unsupported

Thresholds are based on vendor defaults, historical convention or operational capacity rather than risk analysis.

Customer profiles are incomplete

The system cannot identify deviations because expected activity was not collected or updated.

Alerts are closed with generic comments

The case record does not demonstrate what information was reviewed or why the activity was considered reasonable.

High-risk customers receive the same monitoring as low-risk customers

Risk classifications do not influence scenarios, thresholds, prioritisation or review depth.

Scenario changes are not controlled

Thresholds or logic are changed without testing, approval or post-implementation review.

Data completeness is assumed

The entity does not reconcile source transactions with records processed by the monitoring system.

False positives are the only performance measure

Low alert volumes are treated as evidence of effectiveness without considering false negatives or coverage gaps.

Compliance monitoring replaces independent audit

Operational review, compliance monitoring and independent assurance are not clearly separated.

29. AML/CFT transaction monitoring implementation roadmap

Phase 1: Define scope

identify all transaction types;
identify all systems and interfaces;
identify all legal entities and branches;
map products and services;
confirm regulatory requirements.

Phase 2: Map risks

identify money laundering and terrorist financing risks;
map typologies;
connect risks to products and customer segments;
identify targeted-financial-sanctions risks;
document monitoring objectives.

Phase 3: Establish customer profiles

define expected customer activity;
capture source and destination of funds;
establish customer segmentation;
integrate customer risk ratings.

Phase 4: Design scenarios

define scenario logic;
identify required data;
establish thresholds;
document exclusions;
approve scenario specifications.

Phase 5: Implement data controls

reconcile source systems;
test interfaces;
validate data fields;
establish exception reporting;
maintain transaction coverage records.

Phase 6: Establish investigation procedures

define alert information;
create investigation steps;
establish escalation rules;
define decision authorities;
implement quality assurance.

Phase 7: Calibrate and validate

analyse historical data;
test alternative thresholds;
perform back testing;
conduct below-the-line testing;
validate implementation.

Phase 8: Test effectiveness

test design effectiveness;
test operating effectiveness;
perform end-to-end testing;
assess reporting timeliness;
remediate findings.

AML/CFT transaction monitoring checklist

Control area	Minimum requirement
Legal requirements	Map Article 26 and Article 69 AMLR requirements
Risk assessment	Link scenarios to identified ML/TF risks
Scope	Identify all monitored products, systems and transactions
Customer profile	Define expected activity and relationship purpose
Segmentation	Group genuinely comparable customers
Scenarios	Maintain a documented and approved scenario inventory
Thresholds	Support parameters through risk and data analysis
Data	Establish completeness, accuracy and timeliness controls
Interfaces	Reconcile source transactions with monitoring-system records
Alerts	Provide sufficient information for investigation
Prioritisation	Prioritise alerts according to risk
Investigations	Establish consistent investigative procedures
Escalation	Define materiality and suspicion escalation criteria
Reporting	Ensure prompt FIU reporting where required
Documentation	Retain complete investigation and closure rationales
Calibration	Review scenarios and thresholds periodically
Back testing	Test scenarios against historical data
Below-the-line testing	Assess activity immediately below thresholds
Validation	Verify conceptual soundness and implementation
Quality assurance	Review investigation and decision quality
Backlogs	Monitor, escalate and remediate overdue alerts
Model governance	Control rules, models and machine-learning tools
Management information	Report performance, risk coverage and deficiencies
Internal audit	Test design and operating effectiveness
Remediation	Track findings to validated closure

Frequently asked questions

What is AML/CFT transaction monitoring?

AML/CFT transaction monitoring is the review of customer transactions and activities to detect behaviour that is unusual, inconsistent with the customer profile or potentially related to money laundering or terrorist financing.

Is transaction monitoring mandatory under the AMLR?

Yes. Article 26 AMLR requires obliged entities to monitor business relationships continuously, including transactions undertaken throughout the relationship.

What is an AML/CFT transaction monitoring scenario?

A scenario is a rule, model or analytical method designed to detect a defined unusual pattern or financial-crime risk.

What is transaction monitoring calibration?

Calibration is the process of adjusting scenarios, thresholds, parameters and customer segmentation so that the monitoring system remains aligned with the entity’s risks and produces meaningful alerts.

How often should transaction monitoring scenarios be reviewed?

Scenarios should be reviewed periodically and whenever material changes occur in the entity’s risks, customers, products, systems, data, typologies or regulatory obligations.

What is back testing?

Back testing applies a monitoring scenario or parameter to historical data to assess how it would have performed.

What is below-the-line testing?

Below-the-line testing examines transactions immediately below an alert threshold to determine whether relevant unusual activity is being missed.

Is every transaction monitoring alert suspicious?

No. An alert indicates that predefined criteria have been met. Investigation is required to determine whether the activity is explainable, unusual or suspicious.

Must every suspicious transaction be reported?

Article 69 AMLR requires prompt reporting where the obliged entity knows, suspects or has reasonable grounds to suspect that funds or activities are related to criminal activity or terrorist financing. The obligation applies regardless of the amount and includes attempted transactions.

Can machine learning replace transaction monitoring rules?

Machine learning can complement rules through anomaly detection, prioritisation or network analysis. It does not remove the need for risk coverage, validation, explainability, human review and accountable decision-making.

Transaction monitoring must demonstrate effective risk detection

An effective AML/CFT transaction monitoring system is not measured solely by the number of alerts it generates or the percentage of alerts closed without escalation.

It must demonstrate that:

all material transaction streams are covered;
scenarios address identified risks;
customer profiles are reliable;
thresholds are evidence-based;
transaction data are complete;
alerts are investigated consistently;
suspicious activity is escalated promptly;
scenarios are calibrated and validated;
deficiencies are identified and remediated;
design and operating effectiveness are independently tested.

Obliged entities preparing for the AMLR should therefore evaluate transaction monitoring as an end-to-end control framework connecting risk assessment, customer due diligence, data, technology, investigation, reporting and independent assurance.

Is your transaction monitoring framework ready for the AMLR?

An AML/CFT transaction monitoring assessment can evaluate:

risk and typology coverage;
transaction coverage;
customer segmentation;
scenario design;
threshold calibration;
data completeness;
alert investigation;
suspicious transaction escalation;
quality assurance;
model validation;
design and operating effectiveness.