AML Software Selection

The law is technology neutral and does not require every reporting entity to purchase a particular AML system. It requires the entity to identify and assess its risks, establish proportionate controls, monitor their implementation, assess their effectiveness, conduct ongoing monitoring, retain accessible records and comply with targeted financial sanctions requirements.

Manual controls may be appropriate for a small and less complex business where they are properly designed, resourced, documented and tested. As volumes, operating hours, delivery channels and risk exposure increase, automation may become necessary to deliver and evidence the required outcomes consistently. The decision should be based on the entity’s documented risk and control capability, not on an assumed statutory requirement to buy software.

It depends on your licence and volumes, but the categories are: sanctions, PEP and adverse media screening; KYC and identity verification for onboarding; customer risk scoring; transaction monitoring; case management and workflow for escalation and decision logging; goAML reporting support; beneficial ownership and registry data; and record retention with retrieval. A small and less complex DNFBP may require only selected capabilities supported by effective procedures. Banks, exchange houses and other higher-volume financial institutions generally require broader and more integrated capabilities, but the final scope must follow the entity’s activities, volumes, delivery channels and risk assessment.

No. We take no commission, hold no reseller agreement, and have no revenue relationship with any vendor. That is deliberate, because the value of a selection exercise collapses the moment the adviser is paid by one of the options. We are paid by you to define requirements, run the process, score the responses, and negotiate the contract, and our recommendation is whichever tool best fits your risk assessment and budget.

The answer depends on the entity’s licence, the information involved and the architecture of the proposed arrangement.

For banks, the CBUAE Outsourcing Regulation requires the Master System of Record, including confidential data, to be continuously maintained and stored in the UAE, subject to the limited exception and approval framework applicable to branches of foreign banks. Separate requirements may apply where customer confidential data is accessed, processed, replicated or shared outside the UAE.

For other entities, the applicable supervisory and data protection framework must be assessed. The review should distinguish between the application’s hosting location, the Master System of Record, backups, disaster recovery, remote support access, administrator access and sub-processors.

Banks must obtain the CBUAE’s prior notice of non-objection before outsourcing a material activity. The requirement does not automatically apply to every software licence or vendor arrangement.

A hosted screening, monitoring or KYC arrangement may constitute outsourcing and may be material depending on the function performed, the information involved, the bank’s operational dependence, the impact of service failure and the arrangement’s effect on regulatory compliance. The bank should therefore complete and document its outsourcing and materiality assessment before entering into the arrangement.

Not necessarily. The controls must be proportionate to the nature and size of the business and capable of delivering the required outcomes. A small and less complex DNFBP may be able to operate defensible manual controls where customer numbers, transaction volumes and delivery channels are limited and the procedures are properly documented, resourced and tested.

The entity should consider how quickly sanctions-list changes are received and implemented, whether customers and beneficial owners are screened consistently, how ongoing monitoring is performed and whether complete evidence can be retrieved. Where manual controls cannot achieve those outcomes reliably, appropriate automation should be considered.

We score against your written requirements rather than against the demo. Every shortlisted vendor gets the same requirement set, the same questions, and a demonstration scripted with your data and your typologies instead of their sample customers. Responses are scored on a weighted matrix covering function, data and list coverage, tuning and explainability, integration, hosting and residency, security, audit trail, vendor viability, total cost of ownership over three years, and exit terms.

At minimum: service levels with meaningful remedies; list update frequency and provenance commitments; tuning and threshold support, with clarity on who may change a rule; audit rights for you, your auditors, and your supervisor; data residency and sub-processor disclosure; security and incident-notification provisions aligned with the data protection and sectoral framework applicable to the entity and information concerned; defined implementation and acceptance criteria; and exit terms giving you your data in a usable format. The exit clause is the one most often missing and the most expensive to omit.

The reporting entity remains responsible for complying with its legal and regulatory obligations. Purchasing or outsourcing technology does not transfer that accountability to the vendor. For banks, the CBUAE Outsourcing Regulation expressly preserves the bank’s responsibility for outsourced activities.

Responsibility within the entity should be allocated through its governance framework, including board and senior-management oversight, the compliance officer’s prescribed functions, operational ownership and independent assurance. The entity should be able to demonstrate how the system was selected, configured, tested, monitored and remediated.

A focused selection commonly takes approximately four to eight weeks from requirements definition to preferred-vendor selection for a mid-sized entity. The timetable may be longer where a prior CBUAE notice of non-objection is required, a proof of concept is conducted, complex integrations are involved or internal procurement and governance approvals apply. Implementation and tuning follow separately. Most of the elapsed time is yours rather than ours: gathering data, scheduling demonstrations, and getting internal decisions made.

Post-implementation effectiveness testing should form part of the entity’s implementation, monitoring and assurance framework. Cabinet Resolution No. (134) of 2025 requires reporting entities to monitor the implementation of their controls and assess their effectiveness, and Article 21 requires an independent audit function to test the effectiveness and adequacy of the AML/CFT/CPF framework.

The legislation does not prescribe a particular exercise called “AML software validation”. However, testing the configured system, data feeds, rules, thresholds, user access, alert handling and audit records is an important way of evidencing that the technology-supported controls operate as intended.

Capability varies by vendor and should be assessed early. Some platforms produce goAML-compatible files or support integrations, while others require information to be entered manually in the portal. Either approach may be workable if the entity’s escalation, investigation, approval, filing and record-keeping procedures are properly controlled and evidenced.

Software may support alerting and workflow, but the reporting entity remains accountable for the filing obligation. The compliance officer must perform the functions prescribed under Article 22 of Cabinet Resolution No. (134) of 2025 and should not rely on the software to make an autonomous and unreviewed reporting decision.