UAE Payment Token Regulations: Compliance Requirements for Digital Wallet and Token Service Providers

A fintech team planning a dirham-backed token, a wallet that holds customer tokens or a stablecoin payment flow usually starts with product questions: which chain, which features, which integrations. In the UAE, the first question is different. Which regulated activity, if any, does the product perform?

The answer depends on the token’s currency, who controls the private keys and what the business does with customer value. The Central Bank of the UAE (CBUAE) addressed this in its Payment Token Services Regulation (PTSR), issued as Circular No. 2/2024. It requires a CBUAE licence, registration or non-objection for payment token issuing, custody and transfer, and conversion, and it limits which tokens can be moved, promoted or accepted onshore.

Product scope, architecture, vendor selection and launch planning all follow from that classification. This guide explains the framework in plain English, then shows how it shapes the engineering decisions behind fintech application development.

Quick answer: What are the UAE payment token regulations?

The UAE payment token regulations are the CBUAE’s Payment Token Services Regulation (PTSR), which makes issuing, custodying and transferring, and converting payment tokens (stablecoins pegged to a single fiat currency) licensed or registered activities.

Which authorisation applies depends on the activity, the token and the provider’s existing regulatory status, so the first task is to map the product to the right route.

• Issuing Dirham Payment Tokens needs a CBUAE licence, and issuers of foreign-currency tokens need a CBUAE registration.
• Custody and transfer, and conversion, need a CBUAE licence or, for certain regulated firms, a non-objection registration.
• Algorithmic stablecoins and privacy tokens are prohibited, and other virtual assets used as a means of payment face restrictions.

What is the UAE Payment Token Services Regulation?

The PTSR is Circular No. 2/2024 of the CBUAE. The CBUAE Rulebook lists it as effective from 31 August 2024 and in force. Some law-firm commentary quotes different dates, so confirm the position with counsel before relying on any single date.

What does the PTSR regulate?

It regulates three Payment Token Services when performed by way of business. A Payment Token is a virtual asset that aims to keep a stable value by referencing the fiat currency it is denominated in, or another payment token in that same currency.

• Payment Token Issuing: the first sale or transfer of a payment token. A distributor that first sells tokens to the public can be treated as the issuer.
• Payment Token Custody and Transfer: safeguarding tokens, or private cryptographic keys, for customers, or receiving, holding and transferring tokens on their behalf.
• Payment Token Conversion: buying or selling payment tokens by spot conversion, as principal or agent, or enabling counterparties to place and accept offers.

Around these services the regulation sets licensing conditions, capital, governance, reserve, anti-money laundering and countering the financing of terrorism (AML/CFT), technology and consumer-protection rules, and it restricts promotions.

Several things fall outside it. These include activity already licensed under the CBUAE’s Retail Payment Services and Card Schemes Regulation or Stored Value Facilities (SVF) Regulation, and IT security, infrastructure, network or distributed ledger services that do not themselves amount to a payment token service.

Who supervises payment token services in the UAE?

The CBUAE licenses and supervises providers, with applications handled by its Licensing Division. It may consult the Securities and Commodities Authority (SCA), local virtual asset licensing authorities in each emirate and other regulators where an applicant is already regulated elsewhere. Suspicious transactions are reported to the Financial Intelligence Unit at the CBUAE.

Other virtual asset activity may still be regulated by SCA or a local authority, although the PTSR’s prohibitions apply to those firms as well.

When does the regulation apply?

Article 40 gave a one-year transition period during which the Article 2 prohibitions did not apply, extendable by the CBUAE. Law-firm commentary published in August 2025 reported that the period had ended, and the prohibitions should now be treated as applicable. Because secondary sources differ on dates, ask counsel to confirm whether any extension or relief applies to your launch.

Geography matters too. Article 2 uses “the UAE” to exclude the Financial Free Zones, and licence applicants must be UAE companies, including non-financial free zone companies but excluding Financial Free Zone entities. A Financial Free Zone company is treated as a foreign applicant under the registration route. Mainland, free zone and Financial Free Zone structures therefore follow different paths. For a product-side view of the Abu Dhabi position, see SISGAIN’s ADGM and CBUAE compliance checklist for fintech apps.

Secondary commentary also notes that a new federal Central Bank law (Federal Decree-Law No. 6 of 2025) took effect in September 2025 and lists payment services using virtual assets as a licensed financial activity, with a one-year reconciliation period. Ask counsel how it interacts with your model.

Which digital assets qualify as Payment Tokens?

Only some digital assets qualify. The test is whether the asset aims to keep a stable value against a single fiat currency, and what happens next depends on which currency and who issued it.

This table summarises Articles 1, 2, 3 and 12 of the PTSR. Verify each classification against the current text for your token.

Dirham Payment Tokens

A Dirham Payment Token must be denominated only in dirhams. Its issuer cannot pay interest or any other benefit linked to how long a customer holds the token, and its principal business is limited to the issuing for which it is licensed. Banks cannot act as issuers directly, but may set up a subsidiary or affiliate to do so.

Foreign Payment Tokens

Foreign Payment Tokens are denominated in a foreign currency. Their issuer must hold a Foreign Payment Token Issuer Registration, which requires written evidence of non-objection from SCA or a local licensing authority, a list of the tokens to be issued and a legal opinion on compliance. The registered issuer must hold a reserve equal in value and currency to the tokens issued and publish regular external audits of it.

Algorithmic stablecoins and privacy tokens

Article 2 prohibits issuing algorithmic stablecoins or privacy tokens, performing services relating to them and promoting them. The prohibition applies to everyone, including firms licensed or regulated by SCA or a local authority for other virtual asset activity.

Are all cryptocurrencies covered by the PTSR?

No. The PTSR is built around payment tokens and “means of payment”, and a virtual asset that is not used or promoted as one is not within its core scope. The boundary is not always obvious. The regulation prohibits services similar to payment token services for non-payment-token means of payment, bars merchants from accepting them and lets the CBUAE designate additional assets. A token project should assess where its asset sits before choosing a payment feature.

Which CBUAE licence or registration does your business need?

Article 5 lists three licence categories, Article 8 sets out the Non-Objection Registration routes and Article 9 covers Foreign Payment Token Issuer Registration. The table below maps typical activities to those routes.

A licence does not authorise every adjacent financial service. Article 17 limits each category to its principal business, licences can carry conditions, and changes of scope require an application.

Dirham Payment Token Issuer licence

This is the route for a UAE-incorporated company that sells or first transfers AED tokens by way of business. Issuers must maintain initial and ongoing capital of AED 15 million plus 0.5% of the face value of outstanding tokens. An issuer that is a wholly owned subsidiary of a bank may use an alternative reserve structure, with at least half held as cash and the rest in UAE government bonds and CBUAE Monetary Bills of average duration of six months or less, but must then hold 2% rather than 0.5% additional capital.

The application must include a list of tokens to be issued, and the CBUAE may require a legal opinion on compliance, including whether the White Paper is accurate and the reserve properly held.

Payment Token Custodian and Transferor licence

This licence covers custody and transfer of payment tokens for customers. Capital depends on volume: AED 1.5 million where the monthly average value of transfers initiated, facilitated, effected, directed or received is below AED 10 million, and AED 3 million at AED 10 million or above. A provider that exceeds AED 10 million for three consecutive months must report this to the CBUAE and move to the higher requirement.

Payment Token Conversion licence

Conversion providers fall under the same capital tiers as custodians. The scope is selling or buying payment tokens by spot conversion, as principal or agent, or enabling counterparties to place and accept offers. Providers that are also regulated for other virtual asset activity cannot count capital held for SCA or local authority purposes towards the PTSR requirement.

Foreign issuer registration and non-objection registration

A person incorporated outside the UAE, including in a Financial Free Zone, may apply for a Foreign Payment Token Issuer Registration. Non-Objection Registrations are narrower. A virtual asset exchange platform operator licensed by SCA or a local authority may apply for conversion, a bank or exchange house may apply for Dirham Payment Token conversion, and an SCA or local authority licensed virtual asset custodian may apply for custody and transfer of Foreign Payment Tokens. Anyone else wanting to provide custody and transfer needs the CBUAE Payment Token Custodian and Transferor licence.

Does your digital wallet need a CBUAE licence?

It depends on who controls the tokens. A wallet provider that holds customers’ payment tokens or private keys, or transfers tokens on their behalf, is performing Payment Token Custody and Transfer and needs CBUAE authorisation. A provider that only supplies technology that users operate themselves may fall outside the regulation, but the facts decide, not the product label.

Custodial wallets: when the provider controls tokens or keys

The PTSR defines custody by activity. It covers safeguarding, or safeguarding and administering, payment tokens for customers, safeguarding private keys on customers’ behalf so that tokens can be held, stored and transferred, and receiving, holding and transferring tokens for customers. A wallet operator that signs transactions for users, keeps their keys in its own infrastructure or can sweep customer balances sits inside that definition.

For a fintech business, this distinction matters because it comes before the build. The Payment Token Custodian and Transferor licence, or the non-objection route for eligible firms, drives capital, governance, authentication, audit-trail and reporting duties covered below. For the product-design side of wallets, see SISGAIN’s eWallet app development guide.

Non-custodial wallets: when users retain control

The definition carves out technology provision, including updates and technical support, that enables another person to safeguard their own payment tokens or keys, or to transfer tokens on their own behalf. That is why a genuinely software-only wallet may sit outside custody.

The carve-out turns on substance. Ask who can actually move the tokens. Does the provider hold key shares, a recovery mechanism or an administrative override that can move funds? Does it control signing in its own back end, or freeze and redirect transfers? If so, “non-custodial” is a marketing description, not a regulatory outcome.

Merchant wallets and payment acceptance

The custody definition expressly contemplates a service that lets a merchant receive payments in payment tokens under a merchant acquiring-style arrangement. Merchants may accept only a Dirham Payment Token from a licensed issuer, or a Foreign Payment Token used to purchase virtual assets or their derivatives. A merchant-facing wallet should therefore restrict the tokens it supports, which usually means an allow-list tied to licensed or registered issuers. Fiat-side merchant acquiring may fall under the Retail Payment Services and Card Schemes Regulation, which this article does not cover.

A practical wallet-classification example

This is a hypothetical comparison, not a SISGAIN project. Two wallets can look identical to the user and be regulated very differently.

The difference is control, not the interface. Wallet B can also drift: adding a recovery feature in which the provider holds a key share can change the analysis. Treat key architecture as a regulatory decision as well as an engineering one, and have counsel review it before scope is finalised.

Core compliance requirements for payment token providers

Not every requirement applies to every category. Issuers carry the reserve duties, and registered foreign issuers face a narrower set. Each point below covers what the rules say, why it matters operationally and what evidence a business may need.

Corporate governance and fit-and-proper approvals

Applicants must show sound governance, risk management and internal control. The board, senior management and controllers (anyone holding at least 10% of shares or voting power) must be approved by the CBUAE as fit and proper before the licence is granted, and a new controller or senior manager needs prior approval later. Providers must have risk management, internal audit and compliance functions, review risk policies annually and keep a business plan covering target markets, products, channels and marketing.

This matters because approval of people is on the critical path. A platform can be technically ready long before the governance is. Typical evidence includes organisation charts, fit-and-proper submissions, board-approved policies and the business plan.

Regulatory capital and financial planning

Capital consists of paid-up capital, reserves excluding revaluation reserves, and retained earnings, less items such as accumulated losses, anticipated first-year losses and goodwill. The licence application must be accompanied by an unconditional, irrevocable bank guarantee in favour of the CBUAE equal to full paid-up capital, which must remain in place. The CBUAE can impose higher capital as a licence condition. Providers must show the source of funds and the ability to wind down in an orderly way, including refunding customers, and must manage liquidity so that redemption requests can be met.

Capital tiers and guarantee mechanics belong in the financial model from the outset. Evidence includes projections, source-of-funds documentation, the guarantee, a wind-down plan and a liquidity process.

Reserve-of-assets management and redemption

Licensed issuers must hold the Reserve of Assets as cash in a separate escrow account in the same currency as the tokens. The account must be in the issuer’s name at a UAE-licensed bank outside its group and used only for the reserve. Customers must have a contractual claim on it if the issuer becomes insolvent. A Tokenholder may request redemption at any time, and the issuer must redeem at par without delay, generally by the same time on the next business day, with only proportionate, cost-based fees. Issuers must also keep a copy of the ledger, provide a redemption process that does not depend on normal ledger operation and have policies for forks and adverse governance actions. An external auditor audits the reserve.

Redemption is the core promise of a payment token, so mint and burn logic should reconcile continuously to the reserve. Evidence includes escrow and bank agreements, reconciliation procedures, redemption runbooks and fork-response policies.

AML/CFT, KYC and sanctions screening

Article 24 treats payment token services as high risk for money laundering and terrorist financing because of their speed, anonymity and cross-border nature. Providers must run enterprise-level and customer-level risk assessments, apply risk-based customer due diligence (CDD), screen all parties to a transaction against applicable sanctions lists, refuse anonymous or pseudonymous accounts and decline to serve customers whose CDD cannot be completed. They must appoint a compliance officer and a money laundering reporting officer and report suspicious transactions to the CBUAE’s Financial Intelligence Unit.

The rules list risk factors to weigh, including maximum stored value, funding method, cross-border use, person-to-person transfers, multiple wallets and high-risk merchant activity. The CBUAE also states that the electronic know-your-customer (KYC) process licensed banks use for digital onboarding is acceptable for opening wallets, without face-to-face meetings, provided digital authentication and document verification meet its requirements.

The operational consequence is that limits, funding rules and monitoring logic are product decisions. Evidence includes risk assessments, CDD procedures, screening and monitoring logs, a reporting workflow and training records. For the software side, see SISGAIN’s guide to KYC automation, transaction monitoring and regulatory reporting.

Cybersecurity and technology risk management

Article 35 requires an effective technology and cyber security risk framework, proper IT governance and compliance with the UAE Information Assurance Standards at a minimum. Security requirements must be defined early in development, customer authentication must use multi-factor authentication, and providers need an incident response plan, fraud monitoring and major-incident reporting to the CBUAE. Article 34 adds an annual external audit of systems, controls and technology, including any smart contracts.

The controls table in the next section separates what these articles require from what is only good engineering practice. Evidence includes the risk framework, assessment results, test reports and incident plans.

Customer protection and transparent disclosures

Business conduct and customer-protection duties sit in Articles 25 to 32 and should be reviewed in full for your model. Specific points found elsewhere in the regulation include clear and prominent redemption terms and fees in the customer agreement before signing, fees only where proportionate to actual cost, prominent and regularly reviewed security advice to customers, complaints reporting to the CBUAE and display of the licence reference number on websites and promotional materials. Issuers must also prepare a White Paper, which an external auditor audits.

Evidence includes customer agreements, fee schedules, security notices and a complaints procedure.

Independent assessment and licensing documentation

An applicant must submit an independent assessment report, no more than six months old, on how it will meet the ongoing requirements. It must cover at least capital, governance and risk management, reserve management, technology risk, payment security, business continuity, conduct and customer protection, and AML/CFT systems. The assessor must be competent, independent of the business units and free of conflicts, and must confirm that to the CBUAE.

Applications are filed on the CBUAE’s form with the documents listed in the regulation’s Annex, and the CBUAE may meet the board and senior management. An incomplete application can be treated as draft or suspended, and one suspended for six months or more needs a fresh application. After licensing, providers must run an annual risk assessment and, where it shows the need, a detailed independent assessment that goes to the CBUAE after board approval.

Technology architecture for a compliant digital wallet

Technical controls support compliance but do not, by themselves, establish legal compliance. A well-engineered wallet can still be unlicensed, and a licensed provider can still fail an audit. What architecture can do is make obligations demonstrable.

The table separates statutory requirements from design choices. Article 35 applies to licensees and registrees other than registered foreign issuers.

Wallet and cryptographic key management

Hardware security modules (HSMs), multi-party computation (MPC) and multisignature schemes are common ways to avoid a single point of key compromise, alongside separated signing approvals, documented key generation, rotation and recovery, and logged break-glass procedures. None is a universal legal requirement. The regulation does require controls over privileged and emergency access, including restricting privileged users, strong remote-access controls, logging and monitoring of their activity and no shared privileged accounts. Issuers that hold their own tokens need a safeguarding and security policy. The key model also decides the custody analysis, so settle it with counsel first.

Transaction monitoring and auditability

Every payment token transfer needs an audit trail, and providers must operate proportionate fraud monitoring with specific screening of suspicious or high-risk transactions. Personal and payment data must generally be kept for five years. In practice that means append-only event logs, token allow-list enforcement at the point of transfer (licensees may knowingly transfer only permitted token types), sanctions screening in the transaction path and case management for alerts.

API integrations, cloud security and resilience

A provider that develops or provides an API must put safeguards around it. Licensees must also follow the CBUAE’s Outsourcing Regulation as if they were banks, so cloud, custody-technology, KYC and analytics vendors need due diligence, contractual controls and exit planning. Business continuity is among the areas an independent assessment must cover, and a cyber incident response plan is required. Design for tested recovery and clear incident escalation. For integration work, see SISGAIN’s API development services.

Designing compliance into the product lifecycle

Security requirements must be defined at the start of development and built in, which argues for threat modelling and compliance requirements in the first sprint rather than a pre-launch review. From a product engineering perspective, map each obligation to an owner, a control and a piece of evidence, keep infrastructure and change records in version control, generate audit evidence automatically where possible and schedule penetration testing on a risk basis.

What are the prohibited activities and available exemptions?

Prohibited token issuance, services and promotions

Article 2 bars anyone from performing a payment token service in the UAE, or directed at persons in the UAE, without a licence or registration. It also prohibits services for other means of payment that are similar to payment token services, and prohibits issuing or servicing algorithmic stablecoins and privacy tokens. Promotion is restricted: only a licence or registration holder, or someone it appoints, may promote payment token services, and promotions for means-of-payment services are limited to licensed Dirham tokens or registered foreign tokens used as permitted. The CBUAE can require evidence that a person is not in breach. Banks cannot act as issuers, and issuers cannot pay interest on holdings.

Restrictions on permitted token transfers and payment use

Licensees and registrees must not knowingly facilitate a transfer unless it involves a Dirham Payment Token from a licensed issuer used for any lawful purpose, or a Foreign Payment Token from a registered foreign issuer used as a means of payment to purchase virtual assets or their derivatives. Dirham tokens may be issued only to UAE residents, but the regulation otherwise sets no territorial limit on where tokens are used or sent. The CBUAE can also cap token volumes and customer numbers, with daily compliance reporting when it does.

Cross-border use is permitted but treated as a risk factor under the AML rules. Teams exploring that model may find SISGAIN’s overview of blockchain for cross-border payments useful for the technical context.

When might a loyalty or closed-loop scheme be exempt?

Article 4 exempts payment token services limited to certain low-risk types: tokens used for certain reward schemes (issued for money paid by the issuer or a merchant under an agreement with the issuer, and usable only for goods or services of that issuer or merchant), bonus-point schemes usable only with the issuer or its merchants, and tokens usable only for non-financial goods or services provided by the issuer.

Separately, the CBUAE may exempt an issuer, on conditions it specifies, where the Reserve of Assets would not exceed AED 500,000 and there are no more than 100 Tokenholders. That is a discretionary exemption, not an automatic one. The CBUAE can also decide that a service is not, or is no longer, exempt and require a licence.

No loyalty scheme, closed-loop token, low-volume issuer or free zone business is exempt by default. Consider a hypothetical retailer’s points token. If customers can only spend it with the retailer, it may fit an exemption. If it becomes redeemable for cash or tradable between users, it may no longer fit the description. Seek advice before relying on any exemption.

Step-by-step roadmap to launching a compliant payment token platform

This roadmap is a planning guide. Adapt it to your actual business model and the rules that apply to it. No approval timeline is guaranteed, and the CBUAE decides each application on its merits.

Step 1: Map the product and regulatory perimeter

• List every token the product will touch, its currency and who issues it.
• Document who mints and burns tokens, who holds keys, who can move customer balances and which flows involve merchants.
• Record the legal entity, its jurisdiction (mainland, free zone or Financial Free Zone) and any existing CBUAE, SCA or local authority licences.
• Note intended customers, since Dirham Payment Tokens may be issued only to UAE residents.

Step 2: Confirm the licensing pathway

• Decide whether the model needs a licence, a registration, a non-objection route or an exemption, and get a written UAE legal assessment.
• Consider meeting the CBUAE Licensing Division before applying. Article 7 strongly encourages senior management to discuss the business plan first.
• For issuers, line up a UAE-licensed bank for the escrow account.

Step 3: Build the business and control framework

• Appoint board members, senior management and nominated controllers who can pass fit-and-proper review.
• Size capital, arrange the bank guarantee and prepare a wind-down plan.
• Write governance, risk, AML/CFT, technology, outsourcing and business continuity policies, and appoint a compliance officer and a money laundering reporting officer.

Step 4: Prepare the application and independent assessment

• Gather the documents listed in the regulation’s Annex and complete the CBUAE application form.
• Appoint an independent assessor early, and plan for a report no more than six months old at submission.
• For issuers, prepare the token list, White Paper and any legal opinion the CBUAE requires.
• Respond promptly to information requests, because an application suspended for six months or more needs a new filing.

Step 5: Test operational readiness before launch

• Run security and penetration testing, disaster recovery tests and incident drills.
• Test reserve reconciliation, redemption (including a scenario where the ledger is unavailable) and fork handling for issuers.
• Test KYC, sanctions screening, monitoring and reporting workflows end to end.
• Do not promote services until the licence or registration is in place, then display the licence reference number as required.

Step 6: Maintain ongoing compliance

• Run the annual risk assessment, commission the annual external audit and maintain records for five years.
• Notify the CBUAE of material changes, violations, major incidents and the other events listed in Article 18, and submit complaints and other reporting as required.
• Monitor capital against the transfer-volume tier and any CBUAE-imposed limits.
• Track regulatory change and update controls accordingly.

Common compliance mistakes wallet providers should avoid

1. Treating every stablecoin as legally equivalent. A Dirham Payment Token from a licensed issuer, a registered foreign token, an algorithmic stablecoin and an unregistered foreign token have very different treatment. Classify before you integrate.
2. Assuming a non-custodial label decides the outcome. Regulators look at who can move customer tokens. Recovery features and admin overrides can change the analysis.
3. Launching before confirming the applicable authorisation. Providing a payment token service without the right licence or registration, or promoting it, is exactly what Article 2 prohibits.
4. Confusing technology delivery with regulated activity. Building software is not the same as operating the service, but the line depends on who holds the keys and runs the flows.
5. Underestimating reserve and redemption requirements. For issuers, escrow structure, par redemption and ledger-failure processes shape the architecture and the cash plan.
6. Treating cybersecurity as a one-time task. The regulation expects continuing risk management, risk-based testing, incident response and annual external audit.
7. Making unsupported claims about regulatory approval. Marketing that implies CBUAE endorsement before a licence exists creates risk. After licensing, the licence reference number should be displayed.
8. Assuming a free zone structure removes obligations. Free zone companies can be licence applicants, while Financial Free Zone entities follow the registration route. Neither removes the regulation’s requirements.

How technology partners can support compliant product development

A software engineering partner can translate regulatory requirements into systems: key management and signing workflows, token allow-lists, audit trails, KYC and screening integrations, monitoring dashboards, secure APIs, cloud architecture and evidence generation for audits. It can also help structure the build so that the control model the compliance team designs is actually enforced in code.

The limits matter as much. A technology partner cannot grant regulatory approval, give legal advice or take over the provider’s own compliance obligations. The licensee remains responsible for its governance, capital, AML/CFT programme and conduct, and the CBUAE applies its outsourcing rules to outsourced services. For issuers, technology functions performed by another party must be carried out on the issuer’s behalf under those outsourcing requirements. Implementing a particular solution does not guarantee licensing success or compliance.

Conclusion

The most expensive mistake in a payment token project is designing first and classifying later. Whether a business is an issuer, a custodian, a converter, a technology supplier or something outside the PTSR determines its capital, people, reserve, controls and launch plan.

Three priorities follow. First, confirm the regulatory perimeter and authorisation route for your actual token, flows and entity. Second, build the governance, compliance and technical controls that route requires, and treat key control and token allow-lists as regulatory design decisions. Third, obtain qualified UAE legal guidance and define the technical implementation scope that guidance supports.

If you are at the stage of defining that scope, SISGAIN’s team can discuss the architecture and integrations with you through its fintech software services.