Most AML software demos in the UAE start with a dashboard. Your supervisor starts somewhere else: with the data that feeds the system, the scenarios it runs, how each alert was decided and what reached the Financial Intelligence Unit through goAML. If the software can't show that chain, it doesn't matter how good the dashboard looks.
This guide is for the MLRO and the CTO who have to choose a system together. It sets out which UAE rules decide what AML software must do, what the CBUAE, DFSA, FSRA and the Ministry of Economy and Tourism each add, what goAML means for your data and records, and the questions to put to a vendor before you shortlist. It names no vendors. It gives you the requirements and the evidence to ask for, so you can compare any system on the same terms.
It reflects Federal Decree by Law No. 10 of 2025, Cabinet Resolution No. 134 of 2025, the CBUAE's transaction monitoring guidance, the DFSA AML module version of April 2026 and the FSRA AML Rulebook version of May 2026, as they stood on 25 October 2026. It isn't legal advice. Check the current text with your supervisor before you change a procedure or sign a contract.
Federal duties, supervisor rules, goAML constraints and CBUAE vendor evidence, turned into one requirement set the MLRO and CTO agree before any demo.
Choose AML software in the UAE by starting from the rules, not the demo. Decree by Law 10 of 2025 and Cabinet Resolution 134 require monitoring, current indicators, STRs through goAML without delay and five-year records. The CBUAE guidance sets tests for data, scenarios, validation and vendor evidence; the DFSA and FSRA add six-year records and recorded reasons for not filing.
Start with the law, because every supervisor's rulebook sits beneath it. Federal Decree by Law No. 10 of 2025 is the UAE's AML law, and it repealed Federal Decree by Law No. (20) of 2018. Executive regulations, resolutions and circulars issued under the 2018 law stay in force insofar as they do not conflict with the new law, until replacements are issued.
The new executive regulation is Cabinet Resolution No. 134 of 2025, which repealed Cabinet Resolution No. (10) of 2019. The CBUAE Rulebook shows it in force from 14 December 2025.
Four duties in these two texts shape any AML system you buy.
The first is monitoring. The law requires financial institutions, DNFBPs and virtual asset service providers to implement Customer Due Diligence (CDD) Measures and continuous monitoring procedures, determining their scope based on the multiple risk dimensions. The executive regulation says ongoing monitoring includes 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 second is indicators. Firms 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 a software purchase, those indicators are your scenarios, rules and models.
The third is reporting. When a firm suspects a transaction, it must notify the FIU without delay and directly, by providing a detailed report containing all available data and information concerning such Transaction and the relevant parties, through the electronic system designated by the Unit. That electronic system is goAML.
The fourth is records. Firms shall retain all records, documents, instruments, and data relating to all domestic and international financial and cash Transactions and commercial dealings, for a period of not less than five (5) years. The same article covers records from ongoing monitoring, Suspicious Transaction Reports and results of any analysis conducted.
One more article matters when the system you are buying uses new technology. Cabinet Resolution 134 requires firms to identify and assess the risks that may arise from the use of new or developing technologies for both new and pre-existing products. They shall assess such risks prior to the launch or use of products, practices, or technologies. If you are bringing in machine learning or AI agents, that assessment belongs in your procurement file before go-live.
The first figure shows how these texts stack. Federal Decree by Law No. 10 of 2025 sits above Cabinet Resolution 134, which sets the monitoring, indicator, reporting and record duties. Cabinet Resolution 134 is applied through each supervisor's rules: the CBUAE guidance for licensed financial institutions, the DFSA AML module in the DIFC, the FSRA AML Rulebook in ADGM, and Ministry of Economy and Tourism supervision for DNFBPs. Those supervisor rules are what your AML software has to meet.
For a plain summary of the older framework that these texts replaced, see our page on UAE Federal Decree-Law No. 20 of 2018. Read it as background: Federal Decree by Law No. 10 of 2025 replaced that law.
Yes, with a caveat. The CBUAE Rulebook shows its Guidance for Licensed Financial Institutions on Transaction Monitoring and Sanctions Screening in force from 8 September 2021, and the guidance was written against the 2018 law and the 2019 Cabinet Decision. The guidance itself says that in the event of a discrepancy between this Guidance and the legal or regulatory frameworks currently in force, the latter will prevail.
It is still the most detailed public statement of what the CBUAE expects a monitoring system to do. Use it to design your tests, and use the 2025 law and regulation for the duties themselves.
The federal duties apply to every regulated firm. Your supervisor decides the detail, the notification routes and, in the financial free zones, the record period. The table below is the requirement matrix to hand to every vendor.
| Requirement | CBUAE (onshore LFIs) | DFSA (DIFC) | FSRA (ADGM) | Ministry of Economy and Tourism (DNFBPs) |
|---|---|---|---|---|
| Monitoring standard | TM guidance (2021): risk-based design, data quality, testing and validation | AML Rule 7.6.1: monitor transactions against knowledge of the customer | Ongoing CDD rules: monitor transactions, manual or automated | Federal law and Cabinet Resolution 134 |
| Automated system expected? | Larger LFIs: yes | Depends on size, nature and transaction volume | Depends on size, nature and transaction volume | No automation rule found in the texts reviewed |
| STR or SAR route | goAML to the FIU | goAML to the FIU, then notify the DFSA immediately | goAML to the FIU; Notice 84/2025 asks for an email to FCCP | goAML to the FIU |
| Reasons for not filing | No explicit rule found in the CBUAE texts reviewed | Must be recorded (Rule 13.3.2) | Must be recorded (Rule 14.3.3) | No explicit rule found in the texts reviewed |
| Record period | At least five years | At least six years | At least six years | At least five years |
The CBUAE guidance applies to national banks, branches of foreign banks, exchange houses, finance companies and other LFIs; and insurance companies. It accepts manual and automated monitoring, but says LFIs with a larger scale of operations are expected to have in place automated systems capable of handling the risks from an increased volume and variance of transactions. It also makes clear who carries the result: regardless of whether automated or manual processes are used, it is the LFI's responsibility to demonstrate that the monitoring program is effective and appropriately risk based.
In the DIFC, AML Rule 7.6.1 of the DFSA AML module requires a Relevant Person to monitor transactions undertaken during the course of its customer relationship to ensure that the transactions are consistent with the Relevant Person's knowledge of the customer, his business and risk rating. The DFSA's guidance says monitoring may be implemented by manual or automated systems, or a combination thereof, and that the choice depends on the size and nature of the Relevant Person's business and customer base and on the complexity and volume of customer transactions.
When the MLRO decides to report, Rule 13.3.1 requires the firm to make a Suspicious Activity Report to the FIU and notify the DFSA of the making of such Suspicious Activity Report immediately following its submission to the FIU. Where no report is made, a Relevant Person must record the reasons for not making a Suspicious Activity Report. Records, including internal findings and analysis, must be kept for at least six years.
The FSRA AML Rulebook defines goAML as the federally mandated reporting portal administered by the FIU, and any successor portal, platform or reporting tool. Its monitoring guidance mirrors the DFSA's: monitoring may be implemented by manual or automated systems, or a combination thereof.
Under Rule 14.3.1 the MLRO investigates and documents the circumstances, determines whether a SAR/STR must be made and documents such determination, and if required, makes a SAR/STR as soon as practicable. Where no SAR/STR is made, a Relevant Person must record the reasons for not making a SAR/STR. The FSRA's record period is also at least six years.
Its July 2025 Notice FSRA/FCCP/84/2025 adds an operational step: firms must submit a STR/SAR to the FIU using the goAML platform and notify FCCP of the submission by email to FCCP@adgm.com. The notice predates the 2025 law and still lists the 2018 legislation, so check it against the current law, but the notification step is the kind of detail your workflow has to carry.
The Ministry of Economy and Tourism supervises specified DNFBPs falling within its supervisory jurisdiction in the UAE mainland and Commercial Free Zones. Its mandate covers real estate agents and brokers, dealers in precious metals and stones, independent accountants and auditors, and trust and company service providers.
The Ministry's goAML registration page says all DNFBPs were required to register on the goAML portal. It warns that failure to register on goAML may result in severe penalties invoked by the Ministry of Economy & Tourism.
DNFBPs also file sector reports. The FIU's goAML FAQ tells dealers to obtain identification documents (Emirates ID or Passport) for cash transactions equal to or exceeding AED 55,000 and file a DPMSR. For a DNFBP the software question is often smaller: can the tool capture these thresholds, keep the ID evidence and produce the report data without a spreadsheet in between? Our DNFBP compliance guide for the UAE covers the sector duties in detail.
If your firm was licensed by the Securities and Commodities Authority, note the change of supervisor name. Under Federal Decree-Law No. 32 of 2025, the Capital Market Authority (CMA) replaces the Securities and Commodities Authority (SCA) and is its legal successor. The law came into effect as of January 1, 2026. Procedures, policies and vendor documents that still say SCA should be updated.
The second figure shows the reporting route that your software has to support. A monitoring alert goes to an analyst investigation. The analyst investigation goes to the MLRO decision. When the MLRO decides to report, the MLRO decision leads to a goAML report to the FIU. In the DIFC and ADGM, the goAML report also triggers a supervisor notification to the DFSA or the FSRA. When the MLRO decides not to report, the MLRO decision leads to a recorded reason for not filing, which DIFC and ADGM rules require.
The UAE jurisdiction overview gives the wider regulator map, including the free zones and virtual asset supervision.
goAML is not a feature you can add later. It decides how your case data has to be shaped, what you keep and how fast you can move from decision to filing.
The FIU's page on how to submit a report says that to submit an STR, a reporting entity should be connected to the goAML platform, which is the UAEFIU's reporting platform launched in June 2019. All reports must be submitted electronically via the goAML platform.
Registration has two stages, set out in the FSRA's notice:
The notice says completion of both stages is mandatory for RPs and their users. The FIU's FAQ adds that the respective Supervisory Body/Regulator will be approving their regulated entities registrations and any changes related to its details or its MLRO/Compliance Officer's details.
None of that is a software feature. It is a dependency: until your MLRO and users are registered, no system can file anything. Our guide to goAML registration and STR filing in the UAE walks through the steps.
goAML carries more than STRs. The FSRA's Notice 84/2025 lists the report types and triggers firms meet in practice.
| Report | When it applies | Timing stated in Notice 84/2025 |
|---|---|---|
| STR | A transaction, executed or attempted, is suspected to be linked to ML/TF or criminal activity | As soon as practicable and without delay after the MLRO determines suspicion |
| SAR | Suspicious activity, or transactions that appear unusual in source, amount or destination | As soon as practicable and without delay after the MLRO determines suspicion |
| DPMSR | Dealer transactions at or above AED 55,000, in cash or by wire transfer | Within two weeks of the transaction |
| REAR | Real estate transactions involving cash at or above AED 55,000, or virtual assets | Per occurrence |
| PNMR and CNMR | Partial or confirmed name match against the UN or UAE Local Terrorist List | Follow the current EOCN guidance, which postdates the notice |
| HRC and HRCA | Transactions with, or engagement with clients in, high-risk jurisdictions | At least three calendar days before the transaction or engagement |
| AIF, AIFT, RFI | Supplementary information on an earlier report or an FIU request | On request or internal reassessment |
The notice still uses the old name Funds Freeze Report. The EOCN's guidance on targeted financial sanctions, last amended in March 2026, says the Funds Freeze Report (FFR), which was used to report Confirmed Name Matches, has been updated to Confirmed Name Match Report (CNMR). Ask any vendor whose templates or training material say FFR when they will update them.
The high-risk country reports have a consequence for system design. The notice says such reported transaction(s) may only be executed three working days after reporting such to the FIU, and if the FIU does not object. If you process payments to or from listed high-risk countries, your system needs a way to hold a transaction for that window as well as flag it.
The FIU's FAQ answers questions that every implementation team runs into. The "Description of the Report" field on the web form holds 4,000 characters. Each attachment size should not exceed 5MB, with a max capacity of 20MB per report. Fraud is not a report type on the goAML, so fraud incidents go in as an STR or SAR with the most suitable reason for reporting. Processed reports remain on goAML web for 5 calendar days before they are cleaned, and draft reports are cleaned up after 15 calendar days.
Key insight: goAML is a reporting channel, and your own system is the archive. It has to hold the case file, the narrative as filed, the attachments and the goAML reference for at least five years onshore and six in the DIFC and ADGM.
If a vendor's answer to "where is the record of what we filed?" is "in goAML", keep looking.
The FIU's page on the STR process says an STR includes all relevant information about the suspected crime, including the background, the parties involved, the reasons for the report and possible red flags. The FSRA's notice adds that a quality report must be structured, chronological, and intelligible to an independent reviewer unfamiliar with the case.
Software can help by assembling the timeline and evidence in the order an investigator would explain them. It can't decide that the activity is suspicious. That determination belongs to your MLRO.
The third figure shows the evidence flow from alert to filing. The monitoring alert opens a case file that gathers the transactions, customer profile and prior alerts. The case file goes to the analyst decision. An escalated analyst decision goes to the MLRO determination. The MLRO determination produces the goAML report. The goAML report and the whole case file go to the retained record, which your firm keeps for five or six years because goAML clears processed reports after five days.
The CBUAE guidance describes a monitoring program in seven stages, from risk assessment to post-implementation validation. Each stage translates into a capability you can test. The DFSA and FSRA texts are shorter on mechanics, so the CBUAE stages are a sensible checklist for free zone firms too. If you want the monitoring basics first (scenarios, alerts and investigations), start with our AML transaction monitoring guide.
The CBUAE expects the design of an LFI's TM program to be informed by the LFI's risk assessment, so that TM controls are applied across the full range of risks to which the institution is exposed. LFIs utilizing automated systems should perform a typology assessment to design appropriate rule- or scenario-based automated monitoring capabilities and processes.
Thresholds have to fit your business: LFIs should perform risk-based customer and product segmentation, so that rule parameters and thresholds are appropriately calibrated to the type of activity subject to TM. Ask the vendor to show how its scenarios map to your typology assessment and segments. A library of 200 default rules says nothing about your risks.
LFIs should identify and document all data sources that serve as inputs into their TM program, and source system documentation should include the identification of a system owner. Where automated TM systems are used, LFIs should institute data extraction and loading processes to ensure a complete, accurate, and fully traceable transfer of data from its source to TM systems.
The CBUAE expects data testing and validation at minimum every 12 to 18 months, including the reconciliation of transaction codes across core banking and TM systems. For the CTO, this is the heart of the evaluation. Ask for the reconciliation report format, the exception reports and who owns each feed.
The guidance says that where practicable and on a risk basis, LFIs should monitor transactions at the customer or relationship level, including across financial groups, rather than on an individual account basis alone. The guidance says monitoring a customer across multiple accounts is especially important for customers assessed to be politically exposed persons or as belonging to other high-risk categories. Check that the system resolves one customer across products and, if you run a group, across entities.
Where automated systems are employed, LFIs should perform pre-implementation testing of TM rules and systems, using historical transaction data as appropriate. That testing should include system integration testing and user acceptance testing to ensure that the system performs as anticipated in the operating environment.
For calibration, larger LFIs should consider statistical methods such as above-the-line and below-the-line testing to better fine-tune their calibrations and reduce the volume of false-positive alerts. Our transaction monitoring software acceptance checklist for UAE banks sets out how to run that test once you have a shortlist.
The CBUAE allows risk-weighted alert scoring to prioritize higher-risk alerts for expedited review. It also expects outcome reporting to senior management, which may include an analysis of the number of alerts produced by each TM rule and the proportion of such alerts that are cleared as false positives, that require further investigation, and that end in the filing of an STR/SAR.
Suppression of repeatedly cleared patterns is allowed, but should not be applied to higher-risk customer or transaction types and should be carefully monitored. Ask to see the management information the system produces out of the box, rule by rule.
TM model testing and validation should be performed by individuals with sufficient expertise and appropriate level of independence from the model's development and implementation. Post-implementation testing should also include back-testing of TM rules to ensure that they remain current and effective.
If only the vendor can test the system, it fails this expectation. Your internal audit or an independent third party needs access to rules, parameters, test data and results.
Records should be sufficient to permit reconstruction of individual transactions so as to provide, if necessary, evidence for prosecution of criminal activity. Firms must make the records available to the competent authorities immediately upon request. The DFSA adds internal findings and analysis relating to a transaction, whether or not it results in a Suspicious Activity Report.
The record therefore covers more than the transactions. It includes every alert, every decision, the reason and the evidence that the analyst saw at the time.
The CBUAE guidance covers both controls, and expects name screening on an ongoing basis (at least daily) after onboarding. Most UAE institutions buy monitoring and screening together or need them to share a case file. If they come from different vendors, test that a screening hit and a monitoring alert on the same customer land in one investigation. For the screening duties themselves, see our guide to EOCN targeted financial sanctions in the UAE.
The fourth figure shows the selection lifecycle the CBUAE guidance implies. The risk assessment sets the requirements. The requirements shape the vendor evidence you ask for. The vendor evidence feeds the pre-implementation test on your historical data. The pre-implementation test goes to independent validation. Go-live waits for independent validation, and after go-live, outcomes monitoring feeds back into the risk assessment.
The CBUAE guidance has a section on vendors, and it reads like a procurement brief. It starts with responsibility: LFIs remain responsible for complying with AML/CFT and sanctions requirements, even if they choose to use third-party models to assist with their compliance obligations. It lists the factors that should guide selection: the LFI's size, geographic footprint, business and technology environments, and financial crimes risks, as well as functional requirements, such as the volume of data to be screened. The list also includes the nature of existing data integrity processes, and the ability of the application to integrate effectively within an LFI's technological infrastructure.
Then it tells you what to demand. LFIs should require the vendor to provide developmental evidence explaining the product components, design, and intended use. Vendors should provide appropriate testing results that show their product works as expected. They should also clearly indicate the model's limitations and assumptions and where the product's use may be problematic. LFIs should expect vendors to conduct ongoing performance monitoring and outcomes analysis, with disclosure to their clients.
It also puts the validation on you. LFIs are expected to validate their own use of vendor products, and where code access is limited the LFI may have to rely more on sensitivity analysis and benchmarking. LFIs should obtain information regarding the data used to develop the model and assess the extent to which that data is representative of the LFI's situation. An LFI's customization choices should be documented and justified as part of validation. LFIs should have contingency plans for instances when the vendor model is no longer available or cannot be supported by the vendor.
Turned into questions, that gives you a shortlist screen:
| Question for the vendor | Why the CBUAE expects it | Evidence to ask for |
|---|---|---|
| What are the product's components, design and intended use? | Developmental evidence | Design documentation, model descriptions, scenario logic |
| What testing shows it works as expected? | Testing results | Test reports on data like yours, with method and base rates |
| Where does it not work, and what does it assume? | Limitations and assumptions | A written limitations statement |
| What data trained or calibrated any model? | Representativeness | Data description by market, segment and period |
| How will you monitor performance after go-live and tell us? | Ongoing outcomes analysis | Sample performance report and disclosure terms |
| How do we validate it without your source code? | Validation of vendor products | Sensitivity analysis access, parameter export, test environment |
| What happens if you stop supporting it? | Contingency planning | Exit plan, data export format, documentation handover |
| Where does our data sit, and who can access it? | Integration with your infrastructure | Hosting options, residency terms, access model |
Two questions sit outside the CBUAE list but follow from the rules above. First, ask how the system records the MLRO's reasons when no report is filed, because DFSA and FSRA firms must keep them. Second, ask how the system keeps the filed narrative, attachments and goAML reference after goAML clears its copy.
Be wary of any accuracy, detection or false-positive figure that isn't measured on your own data with the base rate shown. The CBUAE asks you to validate your own use of the product, and a number from someone else's alerts can't do that for you.
Illustrative scenario, not a customer result.
The firm and every detail below are invented to show the process, not drawn from a real case.
A CBUAE-licensed exchange house runs remittance and currency exchange through branches and a mobile app. Its monitoring is a set of threshold rules in the core system, reviewed in spreadsheets. Its board approves a replacement project after an internal audit finds that the rules haven't been retested since they were written.
AI agents can now do much of the investigation work around an alert: gathering the transactions, comparing them with the customer's history, pulling counterparties and earlier alerts, and drafting the case. That changes the workload. It doesn't change who is accountable. The UAE rules put the reporting determination with the MLRO, and the CBUAE guidance puts responsibility for the system's results on the institution.
The fifth figure shows that architecture. The monitoring system sends each alert to the AI agent layer, which gathers transactions, customer history and counterparties. The AI agent layer sends each case to the analyst with its proposed disposition and reasoning. The AI agent layer also writes every step and data version to the audit trail. The analyst escalates suspicious cases to the MLRO. The MLRO decides on the goAML report, and that decision and its reasons go to the audit trail. Autonomy settings and a kill switch sit on the agent layer, under the institution's control.
The monitoring system sends alerts to an AI agent layer that gathers evidence and proposes a disposition with reasons; the analyst decides each alert; the MLRO decides and files every goAML report; every step goes to the audit trail.
| Component | Responsibility | Boundary |
|---|---|---|
| MLRO | Determines whether to file an STR or SAR, files through goAML and records the reasons when no report is made. | Doesn't delegate the reporting determination to software. |
| Analyst | Reviews each alert and its case file and decides whether to close it or escalate it, with a reason. | Doesn't file reports. |
| AI agent layer | Gathers evidence for each alert, compares activity with the customer's baseline, proposes a disposition with its reasoning and writes every step to the audit trail. | Doesn't close alerts, file reports, block payments or change scenarios on its own. |
| Model risk or independent validation | Tests and validates scenarios, models and agent behaviour, independent of the build. | Doesn't run the alert queue. |
| Senior management and board | Approve the AML program, set risk appetite and receive outcome reporting. | Don't decide individual alerts. |
The analyst decides each alert, the MLRO decides and files every goAML report, the institution sets how much each agent does on its own, and any agent can be stopped with its kill switch.
Applicability; automated systems for larger LFIs and less automated systems for smaller ones; risk assessment and typology-based scenarios; data lineage and 12 to 18 month testing; customer-level monitoring; pre-implementation testing; alert scoring; outcome reporting; independent validation; vendor evidence and validation of vendor products; records; daily name screening.
Onshore CBUAE-licensed financial institutions; written against the repealed 2018 law and 2019 decision; the law in force prevails.
2026-10-25
Article 18 STR duty through the FIU electronic system; Article 19 CDD and continuous monitoring; Article 41 repeal and continued effect of non-conflicting circulars.
Federal law; English translation, the Arabic text governs.
2026-10-25
Ongoing monitoring (Article 8); indicators (Article 17); new technologies (Article 24); five-year records and their start dates (Article 25); repeal of Cabinet Resolution 10 of 2019 (Article 70).
Federal executive regulation; English text on the CBUAE Rulebook.
2026-10-25
goAML as the reporting platform; STR contents; registration approval; 4,000-character description; attachment limits; fraud reporting; report clean-up periods; DPMSR threshold.
Federal FIU guidance pages, retrieved 2026-10-25 and re-fetched the same day with identical visible text.
2026-10-25
Two-stage goAML registration; goAML report types, triggers and deadlines; quality standard for reports; FCCP email notification; high-risk country three-working-day rule.
ADGM; predates the 2025 law, lists the 2018 legislation and uses the old FFR name.
2026-10-25
Rule 7.6.1 monitoring and the manual or automated choice; SAR to the FIU and DFSA notification (13.3.1); reasons for not filing (13.3.2); six-year records including internal findings.
DIFC; consolidated version from the DFSA rulebook site; check the authentic instruments.
2026-10-25
goAML definition; monitoring guidance; MLRO determination (14.3.1); reasons for not filing (14.3.3); six-year records.
ADGM; consolidated rulebook version.
2026-10-25
Supervisory scope and sectors; mandatory goAML registration for DNFBPs and penalties.
Mainland and commercial free zone DNFBPs within the Ministry's jurisdiction.
2026-10-25
The CMA replaces the SCA as its legal successor; effective 1 January 2026.
Federal; CMA-hosted English text.
2026-10-25
The Funds Freeze Report is now the Confirmed Name Match Report (CNMR).
Federal EOCN guidance; used here only for the report name.
2026-10-25
Product capabilities (alerts from your existing system, case preparation, one case file, reason codes, tuning evidence, deployment options), the no-demo-accuracy position and the kill switch. Observation-mode pilot wording comes from the user-supplied Q4 calendar workbook.
FluxForce page and calendar workbook; product and CTA claims only.
2026-10-25
| Metric | Definition | Decision guardrail |
|---|---|---|
| Alert-to-decision time | Time from alert creation to the analyst's recorded decision. | Review any alert older than your policy limit with the MLRO. |
| Escalation rate by rule | Share of each rule's alerts escalated to the MLRO. | Retune or retire rules with sustained zero escalation, after testing. |
| Filing lag | Time from MLRO determination to goAML submission. | Treat any delay beyond your policy as a finding. |
| Reasoned closures | Sampled closures with evidence and a written reason. | Treat any closure without them as a finding. |
| Data exceptions | Records rejected or incomplete at load, by source. | Every recurring exception has an owner and a fix date. |
| Validation status | Scenarios and models with a current independent validation. | Nothing runs past its validation date without sign-off. |
Choosing AML software in the UAE is a regulatory decision before it is a technology one. The 2025 law and Cabinet Resolution 134 set the duties: monitor, keep indicators current, report to the FIU through goAML without delay, and keep the records. The CBUAE guidance turns those duties into tests for data, scenarios, alerts, outcomes and validation, and its vendor section tells you which evidence to demand. The DFSA and FSRA add six-year records and recorded reasons for not filing. goAML adds field limits and a short memory, so your system has to keep what you filed.
Write the requirement matrix first. Then ask every vendor the same questions, test on your own data and keep the decisions with your analysts and MLRO.
No law names a product, but the duties make some form of monitoring system necessary. The CBUAE expects larger licensed financial institutions to have automated systems; smaller ones may rely on less automated systems, provided they are run well enough to address the risks of their day-to-day transactions. DFSA and FSRA firms choose manual or automated monitoring based on factors that include their size, customer base and transaction volume. For CBUAE firms, the guidance makes it the institution's responsibility to show that its monitoring is effective and risk based.
The CBUAE supervises licensed financial institutions and sets expectations for how monitoring and screening systems are designed, tested and governed. goAML is the FIU's reporting platform, through which regulated firms file STRs, SARs and other reports. Your software has to meet the CBUAE's control expectations and produce the data you need for goAML filings.
The reporting determination belongs to the MLRO. Under DFSA and FSRA rules the MLRO investigates, determines whether a report is required and documents that determination. Software can assemble the case, the timeline and the evidence, but a person decides whether to file and submits the report.
At least five years under Cabinet Resolution 134 of 2025, counted from the latest of several events such as the end of the business relationship or completion of an inspection. The DFSA and FSRA require at least six years for the records in their rulebooks. Keep the case file and a copy of each goAML filing for the full period, because goAML clears processed reports from its web interface after five days.
It remains in force on the CBUAE Rulebook, and the 2025 law keeps earlier circulars effective where they don't conflict with it. The guidance says the law prevails if the two differ. Use it as the CBUAE's statement of what good monitoring looks like, and use the 2025 law and Cabinet Resolution 134 for the duties themselves.
Ask for developmental evidence on design and intended use, testing results and a written statement of limitations and assumptions. Ask for a description of the data used to build any model, a plan for ongoing performance monitoring and an exit plan. Make sure you can validate the product yourself, because the CBUAE expects LFIs to validate their own use of vendor products.
They can gather evidence, compare activity with the customer's history and propose a disposition with reasons. Your analyst makes the call on each alert, and every reporting determination stays with your MLRO. You decide how much each agent does on its own, and every agent has a kill switch. Any AI component also needs a risk assessment before you use it, because Cabinet Resolution 134 requires firms to assess the risks of new or developing technologies prior to their launch or use.