Table of Contents

A founder entering the UAE fintech market quickly discovers that the licensing question is more product-specific than in the UK. In the UK, fintech teams often start with a familiar EMI path: launch through a principal EMI, consider SEMI for limited independence, or move toward authorised EMI when the business needs full control. The UAE does not use the same ladder. It has a more activity-based structure, and the right route depends on what the product actually does with money, customer value, payment accounts, data, and tokens.

This distinction matters because “payment licence” can mean several different things in the UAE. A payment gateway, a merchant acquiring product, a wallet, a stored balance, a cross-border transfer product, an account information service, and a payment token model may all sit under different regulatory logic. Some may fall under the Central Bank of the UAE’s Retail Payment Services and Card Schemes Regulation. Others may require Stored Value Facilities analysis, Open Finance analysis, Payment Token Services analysis, or a free-zone money services assessment.

At Finamp, we see UAE licensing as a product-mapping exercise before we treat it as a regulatory checklist. Founders need to understand where their product sits before they decide whether to partner with a licensed provider, apply for a narrower licence, or build a directly regulated institution in the UAE.

Start with the product, not the licence name

The first mistake is to ask, “Which UAE licence is equivalent to a UK EMI?” The better question is: what regulated activity does the product perform?

If the product lets customers hold value for later payments, the stored value question becomes central. If it helps merchants accept payments, merchant acquiring or payment aggregation may be relevant. If it issues cards, digital payment instruments, or payment accounts, the product may sit inside the Retail Payment Services framework. If it uses account data or initiates transactions with user consent, Open Finance may apply. If it uses stablecoin-like payment tokens, the Payment Token Services framework can become central.

The UAE framework rewards precise classification. A founder who treats all payment products as one category may miss the real licensing trigger. A wallet is not the same as a payment gateway. A payment account is not the same as stored value. A partner-led route is not the same as direct authorisation. Those differences shape capital, governance, compliance, product scope, and launch timeline.

Retail Payment Services and Card Schemes Regulation

The main starting point for many fintech payment products is the Retail Payment Services and Card Schemes Regulation, often referred to as the RPSCS Regulation. The regulation lays down the rules and conditions for granting a licence to provide Retail Payment Services in the UAE, and the CBUAE describes those services as digital payment services covering nine categories. These include payment account issuance, payment instrument issuance, merchant acquiring, payment aggregation, domestic and cross-border fund transfer, payment token services, payment initiation, and payment account information services. (Central Bank Rulebook)

This framework is important because it separates UAE payment licensing into service categories rather than copying the UK EMI model. A founder needs to identify whether the product issues accounts, issues instruments, acquires merchants, aggregates payments, transfers funds, initiates payments, provides account information, or involves payment tokens. The same startup may touch more than one category, and that combination can change the licence route.

The RPSCS framework also groups permissions into licence categories. Category I is the broadest route and may apply where the applicant intends to provide one or more of the wider retail payment services, including payment token services. Category II and Category III cover narrower combinations, while Category IV is designed for payment initiation and payment account information-type services. (Central Bank Rulebook)

For founders, the business meaning is straightforward. If the product only supports a narrow regulated function, a narrower RPSCS category may be enough. If the product combines several activities, serves merchants, issues payment instruments, supports transfers, or includes token-related payment services, the licensing route becomes broader and more demanding.

Initial capital under RPSCS

Capital is one of the clearest ways the UAE differs from the UK small EMI logic. Under the RPSCS framework, initial capital depends on the licence category and, in several cases, whether the monthly average value of payment transactions reaches AED 10 million. The CBUAE rulebook states that Category I has an initial capital requirement of at least AED 3 million where monthly average payment transaction value is AED 10 million or above, while lower transaction levels reduce the requirement. Category III and Category IV have their own requirements, with Category IV listed at AED 100,000. (Central Bank Rulebook)

This means founders should avoid using the UK SEMI threshold logic as a mental shortcut. In the UK, SEMI is built around limits such as average outstanding e-money and payment transaction thresholds. In the UAE, the analysis is tied to regulated activity, licence category, transaction value, and, where relevant, stored value or token-specific rules.

For a founder, the practical question is not whether the UAE has a “small EMI” route. It does not. The practical question is whether the product fits a narrower RPSCS category or whether the product’s function pushes it into a broader payment services or stored value route.

Stored Value Facilities: the wallet and balance question

Stored Value Facilities, or SVFs, are one of the most important areas for fintech founders to understand in the UAE. A product that stores customer value for later use may trigger a very different analysis from a product that only facilitates payments or transfers.

The CBUAE Stored Value Facilities Regulation sets out the framework for stored value products. The rulebook states that an SVF licensee must maintain paid-up capital of at least AED 15 million and aggregate capital funds of at least 5% of the total float received from customers. (Central Bank Rulebook)

This changes the business case. A founder may describe the product as a wallet, prepaid balance, rewards balance, merchant wallet, customer account, or stored payment balance. The commercial label is less important than the function. If the product stores value that can be used for future payments, SVF analysis becomes central.

This is where many UK-to-UAE comparisons break down. A UK founder may think in terms of e-money issuance and EMI permissions. In the UAE, the relevant question may become whether the product is an SVF and whether the business is ready for the capital, float, safeguarding, governance, and operational expectations attached to that route.

Payment accounts are not the same as stored value

One of the most useful distinctions for founders is the difference between a payment account and stored value. A payment account is generally connected to executing payment transactions, while stored value involves monetary value held for future payment use. This difference matters because a product that looks like a simple account interface to a user may create different regulatory consequences depending on whether funds are only in transit or value is being stored.

This is not only a UAE issue. The DIFC rulebook also distinguishes money services activities such as money transmission, payment accounts, payment instruments, and stored value. It notes that issuing stored value is a separate activity and that a person issuing stored value may also be involved in other money services, such as operating payment accounts, depending on the product design. (Thomson Reuters)

For UAE market entry, this distinction should be decided early. If the product only supports movement of funds, the RPSCS route may be the main area to assess. If the product holds balances, stores prepaid value, or creates wallet-like functionality, SVF analysis may become unavoidable.

Open Finance licences

Open Finance is another area founders should separate from general payment licensing. The UAE Open Finance framework is relevant where the product involves data sharing or service initiation based on user consent. CBUAE rulebook materials describe an Open Finance Licence as a licence to provide Data Sharing and/or Service Initiation, and the framework also includes requirements around user consent for processing personal data. (Central Bank Rulebook)

This matters for founders building products around account aggregation, financial dashboards, consent-based data access, service initiation, or embedded finance experiences that rely on customer account information. These features may look like product enhancements, but they can create a separate regulatory track.

Open Finance also has important limits. The CBUAE rulebook states that an Open Finance Provider must not receive, hold, or transfer funds for or on behalf of a user. (Central Bank Rulebook) This means Open Finance should not be treated as a substitute for payment services or stored value licensing. It can support data and initiation use cases, but it does not automatically authorise the company to hold customer money or operate a wallet.

Payment Token Services

Payment tokens need their own analysis. The UAE Payment Token Services Regulation states that no person may perform any Payment Token Service within the UAE or directed to persons in the UAE unless licensed or registered by the Central Bank. (Central Bank Rulebook)

The rulebook describes Payment Token Services as digital payment services in the UAE and refers to categories such as payment token issuance, payment token conversion, and payment token custody and transfer. (Central Bank Rulebook) For founders, this means stablecoin-like or token-based payment products should not be treated as a simple extension of normal payments infrastructure.

This is especially important for cross-border fintech products. A company may view payment tokens as a settlement tool, liquidity tool, or corridor efficiency feature. In the UAE, those features can change the licensing analysis from the beginning. A product that combines wallet functionality, cross-border transfer, and payment tokens may need a more complex regulatory map than a standard payment service.

Partner-led routes and agents

Not every fintech needs to apply for direct licensing on day one. A UK fintech entering the UAE may choose a partner-led route through a licensed PSP, SVF provider, bank, or other regulated entity. This can be commercially similar to the sponsor model in the UK, although the legal structure is not identical.

The RPSCS framework recognises that PSPs may use agents or branches. It also requires licensed PSPs to assess those arrangements, ensure disclosure that agents act on the PSP’s behalf, and remain responsible for relevant acts and omissions. The SVF framework similarly recognises agents and service providers, while keeping responsibility with the licensee. (Central Bank Rulebook)

For founders, the benefit is speed and local market access. The cost is dependence. A partner-led route can help a fintech test the UAE market before committing to direct licensing, but the product will be limited by the partner’s permissions, risk appetite, controls, commercial terms, and operating capacity.

This route usually works best when the fintech is still validating the UAE opportunity, the first use case is narrow, and the licensed partner can legally and operationally support the regulated function. It becomes restrictive when the fintech needs direct control over customer value, product scope, compliance decisions, settlement flows, or long-term economics.

DIFC and ADGM money services

DIFC and ADGM can also be relevant, but they should not be treated as simple replacements for CBUAE licensing. These financial free zones have their own regulators and frameworks for certain financial services, including money services.

ADGM’s FSRA has enhanced its framework for Providing Money Services to better cover activities such as payment accounts and issuance of stored value, alongside currency exchange and money transmission. (ADGM) DIFC’s DFSA rulebook defines Providing Money Services to include activities such as currency exchange, money transmission, providing or operating a payment account, executing payment transactions, issuing payment instruments, and issuing stored value. (Thomson Reuters)

The practical point is that free-zone structuring may be relevant for some fintech models, especially institutional, cross-border, or regional setups. But founders should not assume that a DIFC or ADGM permission automatically answers UAE mainland retail payment activity. If the product targets UAE onshore users or performs CBUAE-regulated payment activity, the CBUAE perimeter still needs to be assessed carefully.

How founders should choose the right route

The best way to choose the right UAE route is to move through a simple sequence.

First, define whether the product stores customer value. If it does, SVF analysis should happen early. Second, identify whether the product provides one or more Retail Payment Services, such as payment account issuance, payment instrument issuance, merchant acquiring, aggregation, domestic or cross-border transfer, payment initiation, account information, or payment token services. Third, check whether Open Finance applies because the product uses data sharing or service initiation. Fourth, check whether payment tokens or stablecoin-like functionality create a separate CBUAE route. Fifth, decide whether a licensed partner can support the first market entry phase, or whether direct licensing is required from the beginning.

This order matters because it keeps the business decision grounded in the product. A founder should not choose a licence because it sounds lighter or more familiar. The product determines the perimeter. The business strategy then determines whether the company should partner first, apply directly, or use a staged model.

Common founder mistakes

The first common mistake is treating the UAE as if it had a direct UK-style EMI ladder. It does not. The UK has EMI agent, SEMI, and AEMI as familiar reference points. The UAE uses a more product-based map across retail payment services, stored value, open finance, payment tokens, and free-zone money services.

The second mistake is underestimating stored value. A founder may think they are building a simple wallet or account balance, but if the product stores customer value for future payments, the SVF framework can materially change the cost and structure.

The third mistake is assuming that Open Finance gives payment permissions. Open Finance may allow data sharing or service initiation, but it does not allow the provider to receive, hold, or transfer funds for users. (Central Bank Rulebook)

The fourth mistake is treating partner-led launch as a permanent solution without checking long-term control. A partner can help with speed, but the fintech should still understand how it would migrate, scale, or become directly licensed if UAE traction becomes meaningful.

Conclusion

UAE payment licensing has its own difficulties because the structure is more product-based than many UK and European founders expect. A fintech has to understand whether it is moving money, holding value, issuing instruments, acquiring merchants, aggregating payments, initiating payments, accessing account information, using payment tokens, or operating through a licensed partner.

For early-stage founders, the right route may be partner-first if market validation is still the main goal. For founders building a long-term UAE operation, direct licensing may be the more coherent route. For products involving stored value, payment tokens, or Open Finance, the answer can change quickly because those functions sit under more specific frameworks.

The most useful starting point is therefore simple: define the product accurately before choosing the licence. Once the regulated activity is clear, the licensing strategy becomes a business decision about speed, control, capital, dependency, and scale.