CBUAE transaction monitoring requirements, mapped to system features

The CBUAE's Guidance for Licensed Financial Institutions on Transaction Monitoring and Sanctions Screening, in force since 2021, describes what a monitoring programme should do. Below: its transaction-monitoring expectations, what each means for the system you run, and where Marqib's pilot build covers it.

Reviewed 29 September 2026 · Educational material, not legal advice.

Scope and legal basis

The guidance applies to banks, exchange houses, finance companies, insurers and other institutions licensed or supervised by the CBUAE. It rests on Federal Decree-Law No. (20) of 2018 and Cabinet Decision No. (10) of 2019, which require policies and controls proportionate to the business and approved by senior management, and indicators to identify suspicious transactions (Articles 4.2(a), 16 and 20 of the Decision).

The core duty is to monitor all transactions for consistency with what the firm knows about the customer (Article 7 of the AML-CFT Decision), restated in the CBUAE's guidance on politically exposed persons, section 3.3.1.

Requirement by requirement

The CBUAE expects	What the system should do	In Marqib
Monitoring designed from the risk assessment, with more scrutiny where risk is highest (2.1, 2.2).	Scope rules by customer, product and channel; tighter thresholds for higher-risk segments.	Deterministic rules with per-firm thresholds. A customer risk score (0 to 100) orders the queue; new in the pilot build.
Monitoring at customer or relationship level, not only per account (2.2).	Join accounts that share an owner, device or funding source and look at the combined activity.	Linked parties on every case, drawn as a graph in the case and in the evidence pack.
Documented data sources; complete, traceable loading; data tested at least every 12 to 18 months (2.3).	Validate files on load, reject incomplete batches, keep a record of each load.	Each CSV is validated and loaded in one transaction; every run is logged. Data-quality testing remains the firm's process.
Rules built from a typology assessment, thresholds calibrated by segment, and documentation of scenarios, assumptions, parameters and thresholds (2.4).	Readable rules with named parameters and a written rationale.	Six typology rules for brokers and payment firms, thresholds in one place, and a coverage matrix from typology to rule.
Above-the-line and below-the-line testing for larger volumes (2.4).	Re-run a rule on history with raised and lowered thresholds and compare the output.	Dry-run backtest per rule: in force against proposed, above and below the line, with earlier dispositions. New in the pilot build.
Pre-implementation testing on historical data, and tuning changes tested before use (2.4, 2.7).	Test proposed thresholds and approve them before they go live.	Versioned threshold proposals, approved by a different MLRO; runs use the approved version.
Risk-weighted alert scoring and allocation (2.5).	Score and rank alerts; route by seniority or workload.	Risk-ranked queue, case assignment and workload per reviewer, and a triage recommendation (likely false positive, review, escalate) from listed factors. It never decides.
MI on alerts per rule and the share closed as false positive, investigated and filed as STR or SAR (2.6).	Per-rule counts and conversion, reported to senior management.	MI report with false-positive rate and STR conversion per rule.
A quality assurance process that validates reviews (section 2).	Sample decided cases for independent re-review.	QA sampling of decided cases with a recorded seed and a score per reviewer. New in the pilot build.
Independent validation of the monitoring model, with documented results (2.7).	Give the validator the rules, thresholds, test runs and decisions.	Rules are deterministic, so a validator can re-run them; every change and decision is in a hash-chained audit log. The validation itself must be independent of the vendor and of the users.
STRs filed within the maximum timelines (STR guidance 4.6).	A deadline on every case.	CBUAE clock on each case: 35 business days from alert, 15 for a complex investigation.

What the guidance leaves to the firm

It does not prescribe a vendor, a model type or thresholds. It asks the firm to show that its programme is effective and risk-based, whether monitoring is manual, automated or both (section 2.2). A system produces evidence for that; it does not replace the risk assessment, the typology assessment or independent validation.

Suppression of alerts that are repeatedly cleared as false positives is allowed on a risk basis, but not for higher-risk customers or transaction types, and it must be monitored and tested (section 2.6).

Language models

Nothing in the guidance requires a language model, and Marqib does not use one for detection. Where a firm enables drafting, the model writes narrative text only from the evidence rows, identifiers are tokenised before any call, and a sentence without an evidence citation is removed.

Sources

Questions

Does the CBUAE require an automated monitoring system?

It expects firms with a larger scale of operations to have automated systems that can handle their volume. Smaller firms may rely on less automated monitoring if it addresses their risks (section 2.2).

How often should monitoring data be tested?

Typically at least every 12 to 18 months, depending on the firm's risk profile, with the frequency set in its policies (section 2.3).

Who should validate the monitoring model?

People with the expertise and independence from its development and use, such as internal audit or an external party (section 2.7).