AML for UAE Payment Service Providers and SVFs

Listen To Our Podcast🎧

What must a UAE payment firm do for AML?

A payment firm in the UAE sells speed. Wallets fund in seconds, transfers settle while the customer is still on the app, and merchants expect their money the same day. The AML rules don't ask you to slow any of that down. They ask you to know which product features carry risk, to watch the activity those features make possible, to screen every party, to report suspicion without delay, and to keep a record good enough to rebuild any transaction years later.

This playbook is for the COO or founder who owns the licence and the MLRO who owns the reporting decision at a CBUAE-licensed payment service provider or stored value facility. It maps the CBUAE's retail payment services, stored value facilities and payment token regulations onto the federal AML law, then turns each obligation into a monitoring, screening or case-evidence control you can test.

It reflects the texts in the CBUAE Rulebook, Federal Decree by Law No. 10 of 2025, Cabinet Resolution No. 134 of 2025 and the EOCN's sanctions guidance as amended in March 2026, as they stood on 26 October 2026. It isn't legal advice. Firms licensed in the DIFC or ADGM answer to the DFSA or the FSRA, and this guide doesn't cover their rulebooks. Check the current text with the CBUAE or your adviser before you change a procedure.

The UAE payment firm AML control map

Licence regulation, federal AML duties and product features, turned into monitoring, screening and case-evidence controls the COO and MLRO can test.

1. Identify your licence: RPSCS category, SVF licence or payment token services, and the AML article that comes with it.
2. Read the 2018 references in those regulations as references to Decree by Law 10 of 2025 and Cabinet Resolution 134.
3. List your product features against the SVF risk factors and set limits, funding rules and cash-access controls per account type.
4. Turn each feature into customer risk rating inputs and monitoring scenarios, tested on your own data.
5. Build wire transfer data checks and sanctions screening on every party before release, with the EOCN 24-hour freeze and five-business-day reporting.
6. Keep each case file and goAML filing in your own record for at least five years, and assess every new product or technology before launch.

Which rules apply to UAE payment service providers and SVFs?

Two sets of texts apply at once. The CBUAE's licensing law and payment regulations decide whether you may operate and what your AML program must cover. The federal AML law and its executive regulation set the duties every financial institution shares.

• Federal Decree-Law No. 6 of 2025 is the CBUAE law, and it is the licensing source for the RPSCS Regulation, the SVF Regulation and the Payment Token Services Regulation. Federal Decree by Law No. 10 of 2025 is the AML law, and Cabinet Resolution 134 sets out how it applies. The RPSCS Regulation, the SVF Regulation and the Payment Token Services Regulation each add AML articles that feed one AML program, and Cabinet Resolution 134 sets the federal duties that the same AML program must meet.

The CBUAE law is now Federal Decree-Law No. 6 of 2025, which the CBUAE Rulebook lists as in force from 16 September 2025. Its list of financial activities that need a CBUAE licence includes stored values services, retail payments and digital money services. It repealed Decretal Federal Law No. 14 of 2018, the previous CBUAE law, and the regulations and circulars issued under the old law stay in force until the CBUAE issues replacements. Firms the new law covers had one year from its entry into force to reconcile their positions, and the CBUAE board may extend that period, so check whether an extension applies to you.

Three CBUAE regulations sit under that licensing power for payment firms:

The dates and circular numbers are the ones the CBUAE Rulebook shows for the RPSCS Regulation, the SVF Regulation and the Payment Token Services Regulation, all listed as in force.

The AML side is shorter to describe. 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. Cabinet Resolution No. 134 of 2025 is its executive regulation, in force from 14 December 2025.

The first figure shows how the texts fit together. Federal Decree-Law No. 6 of 2025 is the CBUAE law, and it is the licensing source for the RPSCS Regulation, the SVF Regulation and the Payment Token Services Regulation. Federal Decree by Law No. 10 of 2025 is the AML law, and Cabinet Resolution 134 sets out how it applies. The RPSCS Regulation, the SVF Regulation and the Payment Token Services Regulation each add AML articles that feed one AML program, and Cabinet Resolution 134 sets the federal duties that the same AML program must meet.

Why do the payment regulations still cite the 2018 laws?

Read the SVF Regulation and you'll see it defines money laundering by reference to the 2018 AML law. The Payment Token Services Regulation does the same, naming the 2018 decree-law and Cabinet Decision No. 10 of 2019 as the AML Law. Both of those texts are now repealed.

That doesn't leave a gap. The 2025 AML law keeps regulations and circulars issued under the 2018 law in force where they don't conflict with it, until replacements are issued. In practice, read every reference to the old AML law as a reference to the 2025 law and Cabinet Resolution 134, and apply the stricter rule where the two differ. For the background on what the old regime required, see our summary of the 2018 AML law that the 2025 law replaced.

Which licence category are you in?

The RPSCS Regulation groups nine retail payment services into four licence categories. The services are payment account issuance, payment instrument issuance, merchant acquiring, payment aggregation, domestic fund transfers, cross-border fund transfers, payment tokens, payment initiation and payment account information. Category IV covers only payment initiation and payment account information services.

The category matters for AML because it tells you what money you touch. A Category IV firm that only initiates payments or reads account data sees far less than a wallet issuer that holds funds and moves them across borders. The AML article applies to every licensed payment service provider, but your risk assessment should reflect the services you run.

Some activities sit outside the RPSCS Regulation altogether. It doesn't apply to payment transactions involving stored value facilities, remittances, or virtual asset tokens. Banks are deemed licensed for retail payment services. When they provide services beyond payment account issuance, payment instrument issuance and fund transfers, they must still comply with the regulation's articles on payment tokens, AML, technology risk and obligations to users.

What do the RPSCS and SVF Regulations require for AML?

Both regulations open their AML articles the same way: comply with the UAE AML laws, deter abuse of the sector, detect money laundering and terrorist financing, and report suspicious transactions. The RPSCS text says payment service providers must "detect money laundering and terrorist financing activities and report any suspicious transactions" to the Central Bank's financial intelligence function, and the SVF text uses almost the same words for SVF licensees. Reports now go to the UAE Financial Intelligence Unit electronically through goAML, as the FIU's page on how to submit a report sets out.

After that opening, the two articles diverge. The RPSCS article is more prescriptive on screening and wire transfers. The SVF article is more prescriptive on product risk factors and compliance staffing. Most firms that hold one licence end up planning for both sets of expectations, because their product roadmap tends to cross the line.

The detail behind each row is below.

Risk assessment and customer risk rating

The RPSCS Regulation requires enterprise-level and business relationship-specific risk assessments, with all CDD, monitoring and controls risk-based and aligned to them. It also requires periodic risk profiling of payment service users and a risk rating for each business relationship. The SVF Regulation asks for the same rating and requires CDD models designed for the customer profile and the SVF product features.

That last phrase is the one firms underuse. A wallet that allows cash top-ups and a corporate card program funded only from a verified bank account should not share one CDD model, and they shouldn't share one set of monitoring scenarios either.

What the RPSCS Regulation prohibits outright

Payment service providers may not deal with shell banks or keep any relationship under an anonymous or fictitious name, pseudonym or number. They may not keep a relationship or execute a payment if they can't complete adequate risk-based CDD, for any reason. They also can't invoke banking, professional or contractual secrecy to avoid a suspicious activity report.

Compliance staffing and independent review

The SVF Regulation requires senior management oversight and the appointment of a Compliance Officer and a Money Laundering Reporting Officer. It also expects an SVF licensee to perform a risk assessment at least annually through its own risk management or audit function. If that assessment calls for it, a detailed independent assessment must cover seven areas, one of which is AML/CFT controls systems.

Under the RPSCS Regulation, payment service providers must establish a risk management function, an internal audit function and a compliance function. An appointed auditor reviews the systems and controls of the retail payment services every year.

The federal rule sits on top of both. Cabinet Resolution 134 requires every financial institution to appoint a Compliance Officer at management level, with independence in decision-making. That officer reviews suspicious transaction data and decides whether to notify the FIU or to retain the matter, stating the reasons.

Which product features raise your money laundering risk?

This is where a payment firm's AML program differs most from a bank's. The SVF Regulation lists the product features that change your risk, and the Payment Token Services Regulation repeats most of the list for tokens. In the SVF Regulation's words, the risk of an SVF product depends "to a significant degree" on its design, its functions and the mitigating measures applied.

• The product features feed the product risk assessment. The product risk assessment decides the mitigating measures, such as limits, funding restrictions and cash-access controls. The product risk assessment also sets the customer risk rating inputs for each product. The customer risk rating and the product risk assessment together decide the monitoring scenarios that run on each product. Limits and other mitigating measures become monitoring scenarios too, because a limit nobody watches doesn't control anything.

The second column restates the risk factors in the SVF Regulation. The third column is our suggested control for each factor, not a CBUAE requirement.

The regulation also lists the measures that bring the risk down: limits on stored value, cumulative turnover or transaction amounts; disallowing higher-risk funding sources; restricting use for higher-risk activities; restricting cash access; and detecting multiple accounts or cards held by the same customer or group. The CBUAE doesn't set a hard cap on stored value. Each SVF licensee must set a reasonable limit for each type of customer account, backed by business justification and control measures.

Payment tokens get a stronger statement. The Payment Token Services Regulation says payment token services carry high money laundering and terrorist financing risk because of their speed, anonymity and cross-border nature. Firms providing them must follow the FATF guidance on a risk-based approach to virtual assets.

The second figure shows how the feature list should reach your monitoring. The product features feed the product risk assessment. The product risk assessment decides the mitigating measures, such as limits, funding restrictions and cash-access controls. The product risk assessment also sets the customer risk rating inputs for each product. The customer risk rating and the product risk assessment together decide the monitoring scenarios that run on each product. Limits and other mitigating measures become monitoring scenarios too, because a limit nobody watches doesn't control anything.

How should transaction monitoring work for a payment firm?

The federal duty is broad. Cabinet Resolution 134 requires financial institutions to scrutinise transactions throughout a business relationship to make sure they are consistent with what the institution knows about the customer, the nature of their activities and the risks they represent. The AML law itself requires CDD and continuous monitoring procedures scaled to risk. Institutions must also keep indicators of suspicion and update them on an ongoing basis.

The CBUAE's guidance on transaction monitoring and sanctions screening, in force since September 2021, sets out how the CBUAE expects that to work. It applies to everyone licensed or supervised by the CBUAE in its listed categories: national banks, branches of foreign banks, exchange houses, finance companies and other licensed financial institutions, plus insurers. It was written under the 2018 law, so read it alongside the 2025 texts; where the guidance and the law in force differ, the law prevails. Larger institutions are expected to run automated systems that can handle higher volumes and more varied transactions. Whatever mix of automated and manual monitoring you use, it's your job to show the program is effective and risk-based.

For a payment firm, five parts of the guidance matter most:

1. Design from your typologies. The guidance expects a typology assessment behind automated scenarios. For a wallet, that means scenarios built for the features in the table above. A bank's scenario library with the thresholds lowered won't fit.
2. Segment your customers and products. Parameters and thresholds should be calibrated to the type of activity being monitored. A remittance-heavy consumer segment and a merchant-acquiring book need different thresholds.
3. Prove the data lineage. Every data source feeding monitoring should be identified and documented, and extraction and loading should give a complete, accurate and fully traceable transfer of data into the monitoring system. If your ledger, card processor and wallet app each hold part of the story, each one is a source system with an owner.
4. Monitor the customer as well as the account. Where practicable and on a risk basis, monitor at customer or relationship level as well as account by account. That's the only way to see one person running five wallets.
5. Test before go-live, then track outcomes. Run pre-implementation testing on historical transaction data. Report how many alerts each rule produces and how many end in further investigation or an STR.

Our guide to AML transaction monitoring covers scenario design, alert handling and investigations in more depth.

Is a rules engine enough?

It can be, for a small firm with a narrow product. The CBUAE doesn't mandate a technology. It mandates outcomes you can demonstrate: scenarios tied to your risks, complete data, alerts that get decided with reasons, and evidence that the rules still work. Firms get into trouble when nobody has retuned the rules engine since launch, or when it monitors one product while the firm sells three.

What do the wire transfer rules mean for payment firms?

If you move money between people, banks or countries, Cabinet Resolution 134's wire transfer division is the part of the AML regime you'll touch most often. Read it next to the FATF's Recommendation 16 travel rule, which it implements.

• Every payment instruction goes through an originator and beneficiary data check before anything else. A complete originator and beneficiary data check passes the transfer to sanctions screening. Incomplete data sends the transfer from the originator and beneficiary data check to a missing-data decision, which follows your written policy to execute, reject or suspend. A clear sanctions screening result lets the firm execute the transfer. A confirmed or partial match sends the transfer from sanctions screening to a freeze, reject or suspend action, reported to the EOCN through goAML. Once you execute the transfer, the originator and beneficiary information goes to the retained record for at least five years.

Financial institutions must verify originator information on international wire transfers of AED 3,500 or more. Transfers below AED 3,500 still carry the same data, without the need to verify it unless there's suspicion. Institutions must not execute wire transfers that fail these conditions. Intermediary and beneficiary institutions must take reasonable measures to identify international transfers missing required data and set risk-based policies for whether to execute, reject or suspend them. Money or value transfer service providers must meet the same rules whether they act directly or through agents. Occasional wire transfers of AED 3,500 or more also trigger CDD.

The third figure follows a single payment. Every payment instruction goes through an originator and beneficiary data check before anything else. A complete originator and beneficiary data check passes the transfer to sanctions screening. Incomplete data sends the transfer from the originator and beneficiary data check to a missing-data decision, which follows your written policy to execute, reject or suspend. A clear sanctions screening result lets the firm execute the transfer. A confirmed or partial match sends the transfer from sanctions screening to a freeze, reject or suspend action, reported to the EOCN through goAML. Once you execute the transfer, the originator and beneficiary information goes to the retained record for at least five years.

What does sanctions screening require of a payment firm?

The RPSCS Regulation is direct about it. Payment service providers should screen all parties involved in a transaction against all applicable sanctions lists as part of CDD, and those providing wire transfers should freeze and prohibit transactions with designated persons and entities. The Payment Token Services Regulation carries the same two requirements for token providers.

The EOCN's guidance on targeted financial sanctions, last amended in March 2026, sets the detail. Screening must happen when the sanctions lists are updated, before onboarding new customers, at periodic KYC reviews or material changes, and before processing any transaction of a counterparty. It must cover existing customers, potential customers, previous customers up to five years back, the names of parties to transactions and beneficial owners. If you use an automated screening system, every system holding customer data and transactions needs to be mapped to it. The CBUAE's guidance adds that name screening must run before onboarding or an occasional transaction and at least daily after that.

The response to a hit depends on the result.

Freezing without delay means immediately, or in any case within 24 hours of designation. For a confirmed match on an existing customer, freeze immediately and submit a Confirmed Name Match Report through goAML within five business days of taking the freezing measure. For a partial match you can't verify, suspend or reject the transaction without delay and submit a Partial Name Match Report within five business days. A false positive needs no report, but you should keep internal documentation of how you reached it. The Confirmed Name Match Report is the new name for what used to be the Funds Freeze Report.

Our guide to EOCN and UAE targeted financial sanctions covers the list sources and freezing steps in more depth.

How do STRs and goAML work for payment firms?

The reporting duty is the same for a wallet as for a bank. Where an institution suspects, or has reasonable grounds to suspect, that a transaction or funds are linked to a crime, it must notify the FIU without delay and directly, whatever the amount, through the FIU's designated electronic system. Cabinet Resolution 134 says the report goes immediately and without delay through the FIU's electronic system. It also prohibits telling the customer, or anyone else, that a report has been or is about to be filed.

That electronic system is goAML. Reports must be submitted electronically via the goAML platform, and a reporting entity must be connected to it before it can file. The FIU's goAML FAQ says your registration and MLRO details are approved by your own supervisor. For payment firms, three of goAML's practical limits change how you design case files:

• The description field holds 4,000 characters.
• Each attachment can be up to 5MB, with 20MB in total per report.
• Processed reports stay on goAML web for five calendar days before they're cleared.

Key insight: goAML is a reporting channel. Your own system is the archive, and it has to hold what you filed, the attachments and the case file behind them for at least five years.

Our walkthrough of goAML registration and STR filing in the UAE covers the filing mechanics.

Two goAML questions come up often at payment firms. The FIU says fraud isn't a goAML report type, but a fraud incident can be reported as a suspicious transaction report or a suspicious activity report, depending on the case. Where a money or value transfer provider acts as both the originator in the UAE and the recipient in another country, it must collect the information on both sides to decide whether to file, and file any STR with the FIU of the country concerned.

What should a case file and record hold?

Every one of these duties ends in a record, and the federal rule is five years. Cabinet Resolution 134 requires records of all domestic and international transactions to be kept for at least five years from the date the transaction completes or the relationship ends. CDD records, monitoring records, STRs and the results of any analysis must be kept for the same period. Records must be organised well enough to rebuild individual transactions and trace funds, so they can serve as evidence if needed.

• A monitoring alert opens a case file that gathers the transactions, the customer profile, the screening results and prior alerts. The case file goes to the analyst decision, which is recorded with a reason. An escalated analyst decision goes to the MLRO determination. The MLRO determination produces the goAML report when the MLRO decides to file. The goAML report and the whole case file go to the retained record, kept for at least five years because goAML clears processed reports after five days.

The payment regulations add their own record rules. Payment service providers must keep records of personal and payment data for five years from the date they receive them, unless another law or the CBUAE requires longer. SVF licensees must store and keep all customer and transaction data for five years from the date the customer data was created, and that customer data must be stored and maintained in the State. SVF licensees must also keep information and accounting systems that maintain an appropriate audit trail.

The safest design takes the longest applicable period and the latest start date, then applies it to the whole case: the alert, the data the analyst saw, the decision and its reason, the MLRO's determination and the goAML filing.

The fourth figure shows that chain. A monitoring alert opens a case file that gathers the transactions, the customer profile, the screening results and prior alerts. The case file goes to the analyst decision, which is recorded with a reason. An escalated analyst decision goes to the MLRO determination. The MLRO determination produces the goAML report when the MLRO decides to file. The goAML report and the whole case file go to the retained record, kept for at least five years because goAML clears processed reports after five days.

What about agents, merchants and outsourced services?

Payment firms rarely operate alone. They use agents for cash, acquirers for merchants and vendors for screening, cards and cloud. The rules treat each of those as your responsibility.

Under the RPSCS Regulation, a payment service provider using agents or branches must assess the arrangement and report annually to the CBUAE, including an assessment of the agent's internal controls for AML requirements. Outsourcing to service providers, agents or group entities needs the CBUAE's prior approval and an annual report, and the provider stays fully liable for their acts. Under Cabinet Resolution 134, money or value transfer service providers must keep an updated list of their agents, include them in their AML programs and monitor their compliance. SVF licensees need CBUAE approval to outsource and stay responsible for the outsourced activity. When an SVF licensee works with business partners such as merchant acquirers, it must make sure they have proper systems for settling funds with merchants and for mitigating money laundering and terrorist financing risk.

For monitoring, this means the agent and the merchant are entities in your system with their own history. Cash top-ups through one agent location, or a merchant whose refund pattern suddenly changes, should be visible as patterns you can alert on.

What must happen before you launch a new product or technology?

Payment firms launch features constantly, and the AML rules expect a risk assessment first. Cabinet Resolution 134 requires institutions to assess the money laundering, terrorist financing and proliferation financing risks of new products, practices, delivery channels and technologies before launch or use. The SVF Regulation says the same for any new product, service or technology. It also accepts the eKYC process that banks use for digital onboarding when SVF accounts are opened.

That covers a new corridor, a cash-out partner, a crypto on-ramp or an AI component in your monitoring. Write the assessment before the launch, name the controls it relies on, and test those controls in the monitoring system before customers can use the feature.

Illustrative scenario: a wallet adds cross-border transfers

Illustrative scenario, not a customer result.

The firm and every detail below are invented to show the process. They aren't drawn from a real case.

A CBUAE-licensed SVF issuer runs a consumer wallet funded by bank card and by cash at partner agents. Customers can pay merchants and send money to other wallet users in the UAE. The product team now wants to add transfers abroad.

1. The MLRO updates the product risk assessment: cross-border use and person-to-person transfers both raise the risk, and cash funding is already in the product.
2. The COO and MLRO agree mitigating measures before launch: a lower stored-value limit for cash-funded wallets, no cash funding for the first cross-border transfer, and a cap on transfers per corridor per day.
3. Engineering confirms that every outgoing transfer carries complete originator and beneficiary data, and that a transfer with missing fields can't be released.
4. Sanctions screening is extended to beneficiaries abroad, before each transfer is released, and to every list update.
5. The monitoring team writes new scenarios for fan-in to one wallet followed by cross-border fan-out, and for cash top-ups followed by an immediate transfer abroad, then tests them on six months of the firm's own data.
6. The CBUAE outsourcing approval for the new correspondent partner is in place, and the agent report reflects the cash agents now feeding cross-border flows.
7. After launch, the MLRO reviews alert outcomes by scenario every month and feeds them back into the risk assessment, so every step leaves a record the CBUAE can follow, from the risk assessment to the first alert on the new corridor.

Who decides what when AI agents are part of the system?

AI agents can take on a lot of the preparation work in a payment firm's alert queue. They shouldn't take the decisions the law gives to people. Cabinet Resolution 134 gives the decision on whether to notify the FIU to the Compliance Officer, and the SVF Regulation expects a named MLRO. The analyst decides each alert, and the agents prepare the evidence for that decision.

• The monitoring and screening systems send each alert to the AI agent layer, which gathers the 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.

The fifth figure shows the same split. The monitoring and screening systems send each alert to the AI agent layer, which gathers the 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.

Two more rules from the texts above apply directly. An AI component in monitoring is a new technology, so it needs a risk assessment before use. Your institution stays responsible for compliance even when a third-party model assists it.

Roles and boundaries when AI agents review alerts

The monitoring and screening systems send 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.

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.

Which sources support this playbook?

How FluxForce fits payment firm transaction monitoring

What should the COO and MLRO agree before the next CBUAE review?

1. The enterprise risk assessment names every product and feature, including cash funding, cross-border use, person-to-person transfers and cash-out.
2. Stored-value and transaction limits are set per account type, justified and written into the operating rules.
3. CDD models differ by product where the risk differs, and onboarding stops when CDD can't be completed.
4. Every outgoing transfer carries complete originator and beneficiary data, and non-compliant transfers can't be released.
5. Every party to a transaction is screened before release and on every list update, including previous customers for five years.
6. Monitoring scenarios map to the product risk factors, run at customer level, and were tested on your own data.
7. Every alert closure has evidence and a written reason.
8. Your system keeps a copy of each goAML filing, its attachments and the case file for at least five years.
9. Agents, merchants and outsourced services are on the CBUAE-approved list and visible in monitoring.
10. A new-technology risk assessment is signed before each launch, including any AI component.

Conclusion

The CBUAE's payment regulations are short on AML compared with a bank rulebook, but they point at everything else: the federal AML law, Cabinet Resolution 134, the CBUAE's monitoring guidance and the EOCN's sanctions rules. For a payment firm, the work is turning that stack into controls that match the products you sell. Start from your features, build monitoring and screening around them, and keep a case record that would let an examiner replay any decision. Our UAE regulator overview maps who supervises what across the country.

Frequently Asked Questions

About the author

Sahil works on secure AI and financial technology for regulated industries. His engineering background spans identity verification, payment security and compliance automation. He has led teams across Africa, the United States, Europe and India.

At FluxForce.ai, his focus is on explainable AI and auditable financial workflows. He writes for banking and compliance teams about the practical decisions behind these systems: how to assess risk, keep controls visible and introduce automation without losing accountability.

Related articles