DIFC payment services licence

Payments is the busiest borderline in DIFC licensing. More firms get this question wrong than any other, in both directions — some assuming they need a banking licence when they do not, others assuming a technology licence covers them when it does not.

A DIFC payment services licence is DFSA authorisation for the specific regulated activities a payments business conducts. As with every DFSA authorisation, the licence is issued electronically and specifies the type of Financial Services that can be conducted[DFSA — Authorisation]— so the permissions are explicit and finite rather than a general permission to “do payments”.

DIFC positions payments within its financial firms category, and the surrounding environment is the FinTech and innovation community — 1,933 AI, FinTech and innovation firms as at H1 2026, up 39 per cent year-on-year[DIFC — H1 2026 results], supported by the DIFC Innovation Hub[DIFC — AI, FinTech & Innovation].

This page is mostly about the perimeter, because that is the question that determines everything else. For the broader fintech routes see FinTech licensing; for the DFSA process in depth see asset management licensing.

The DFSA states the threshold obligation directly:

For payments, the operative question is simple to state and uncomfortable to answer honestly: do funds ever come under your control?

Not “do you hold them for long”. Not “do you own them”. Control — including transit, including custody for milliseconds, including situations where funds sit in an account in your name even though they economically belong to someone else.

Software does not change the classification. A platform that moves money is doing a regulated thing regardless of how elegantly it is built, and describing the business as infrastructure, orchestration or an API layer does not alter what happens to the funds.

A working guide, not a substitute for advice:

• Generally inside the perimeter: holding or receiving client funds; executing payment transactions; issuing payment instruments; money remittance; providing accounts that hold value; acting as a merchant acquirer where you settle funds.
• Generally outside: selling payments software that a licensed firm operates; providing fraud, reconciliation or reporting tools; building integration layers where the licensed party holds and moves every dirham.

Where you cannot answer confidently, that uncertainty is the finding. Get a written perimeter analysis before you build, not after — this is the single most expensive thing to discover late in a payments business.

A distinction worth getting right, because it changes your project by an order of magnitude.

Banking involves deposit-taking and credit provision, and carries the heaviest prudential regime the DFSA operates — substantial capital, full governance and risk frameworks, liquidity requirements, and a timeline measured in many months. DIFC hosts 327 banking and capital markets firms[DIFC — H1 2026 results], overwhelmingly established international institutions. See banking licences.

Payment services involve moving and holding client funds withoutthose permissions. You are not taking deposits and you are not lending against them, so the prudential burden is far lighter. The regulator’s focus shifts from solvency to safeguarding — is client money protected, segregated and reconcilable — and to financial crime.

In our experience a meaningful proportion of enquiries framed as “we need a banking licence” describe a payments business. The distinguishing questions are whether you take repayable deposits from the public, and whether you lend. If the answer to both is no, you are almost certainly in payments territory — which is a very different and much more achievable project.

The error in the other direction, and the one that causes the most wasted build time.

DIFC’s Innovation Licence is tailored for tech companies and offers significant discounts and incentives[DIFC — AI, FinTech & Innovation]. It is a commercial licence issued by the Registrar, and the Registrar is explicit about its limits:

DIFC prints that limitation on the face of the document because the misunderstanding is common enough to warrant it. An innovation licence lets you build payments technology. It does not let you provide the payment service.

The distinction in practice: if your customer is a licensed institution that operates your software and holds the funds, you are a technology vendor. If your customer is the end user whose money you are moving, you are providing a payment service.

See the Innovation Licence and FinTech licensing, which sets out six worked borderline examples.

For a payments firm this is the centre of the regulatory relationship, and it is where applications are made or broken.

When you hold funds that belong to customers, those funds are not yours. That sounds obvious and is routinely mishandled — most often by treating float as working capital, or by commingling customer money with the firm’s own.

Expect the DFSA to want clarity on:

• Segregation— client funds held separately from the firm’s own money, in identifiable accounts.
• Safeguarding — what protects customers if the firm fails.
• Reconciliation — how often, by whom, and what happens on a break.
• Where the money sits — which institutions, in whose name, and under what arrangements.
• Governance — who is accountable for client money, and how the board sees it.

Build this properly from the start rather than retrofitting it for an application. A payments firm with clean, well-documented client money handling presents very differently from one that has been moving money for a year and is now trying to describe its arrangements.

Note also the practical banking consequence: your own corporate banking conversation will be materially harder if you cannot explain client money arrangements clearly. Banks are cautious about payments firms for exactly this reason.

The models we are asked about most, with the reasoning rather than just a verdict. None of this is advice on your specific facts.

Cross-border remittance

Funds are received from a sender and paid to a recipient. Squarely inside the perimeter — this is money transmission, and it is regulated everywhere.

Merchant acquiring and settlement

You collect from cardholders and settle to merchants. Funds pass through your control, so inside. The fact that a card scheme and an issuing bank are also involved does not change your position.

Payment orchestration with no settlement

You route transactions between merchants and licensed processors but never receive funds. Frequently outside — but it turns entirely on whether settlement genuinely bypasses you, which is a question about account structures rather than about diagrams.

Embedded payments under a partner’s licence

Your interface, their permission. The hardest case, and the one most often assumed rather than analysed. It depends on whose customer it legally is, in whose name funds are held, and who bears the obligation if something fails. Get this in writing.

Wallets and stored value

Customers hold balances with you. Inside, and with client money obligations at the centre of the assessment.

B2B payments software sold to banks

The bank operates it and holds all funds. A technology business, and the innovation route applies[DIFC — AI, FinTech & Innovation].

Authorisation is given in the form of a licence specifying the type of Financial Services that can be conducted[DFSA — Authorisation]. A payments application will address:

• A regulatory business plan — the payment flows, the counterparties, the corridors, the customers, and how each risk is controlled.
• Client money arrangements — segregation, safeguarding, reconciliation. The centrepiece.
• Financial crime controls — payments is inherently high AML risk, and screening, monitoring and reporting proportionate to your corridors will be examined closely.
• Operational resilience — payments fail loudly; the regulator wants to know what happens when systems do.
• Capital, by prudential category and permissions.
• Named individuals in senior management, compliance and money-laundering reporting roles[DFSA — Authorisation].
• Third-party dependencies — your banking partners, processors and technology providers, and what happens if one withdraws.

That last point is underrated. Payments businesses depend on banking relationships they do not control, and a regulator will ask what your plan is if a partner exits.

The DFSA assesses individuals performing board, senior management and key control functions — including compliance and anti-money laundering — against suitability and integrity criteria[DFSA — Authorisation].

For payments, the MLRO role carries particular weight. This is a sector where financial crime risk is intrinsic rather than incidental, and a money-laundering reporting officer with genuine payments experience is worth considerably more to your application than a generalist.

The scheduling point applies as it does everywhere: these are application inputs, not post-approval hires. Fintech founders consistently underestimate this and plan a launch date around a build timeline rather than a hiring one.

A question to settle before the licence question, because getting it wrong is unrecoverable.

DIFC is a financial free zone with its own regulator, and a DFSA licence is oriented to Financial Services conducted in or from the DIFC[DFSA — Authorisation]. Onshore UAE payments and banking activity sits under the federal regime administered by the Central Bank of the UAE[Central Bank of the UAE].

For a payments business the practical read is about customers. A proposition serving regional corporates, international clients or institutional counterparties fits the DIFC orientation. A consumer wallet or domestic remittance product aimed at UAE residents engages the federal regime, and needs advice on that basis rather than an assumption that a DIFC licence reaches everywhere.

See DIFC vs mainland for the general framing. For payments the stakes are higher because the perimeter is defined by where your customers are, not by where your office is.

Payments is an area where new models appear faster than regulatory categories, and DIFC has a route for that.

The Innovation Testing Licence allows firms to test genuinely novel regulated propositions in a controlled environment before committing to full authorisation. DIFC frames its innovation proposition around exactly this kind of accommodation — fit-for-purpose regulation and legislation alongside cost-effective licensing[DIFC — AI, FinTech & Innovation].

Two honest points. It suits a firm whose regulatory treatment is genuinely uncertain because nothing quite like the product has been authorised — not a firm using it to defer a decision already made. And it is time-limited with restrictions on scale: it is a route towards authorisation, not around it.

The commercial argument for DIFC over a cheaper jurisdiction is who else is in the district[DIFC — H1 2026 results].

1,933 AI, FinTech and innovation firms, up 39 per cent year-on-year, with 361 new companies joining the Innovation Hub in a single half[DIFC — H1 2026 results]. Alongside them, 327 banking and capital markets firms[DIFC — H1 2026 results] — which for a payments business is both the partner list and, frequently, the customer list.

DIFC also lists payments-adjacent names among firms establishing regional offices since H1 2025, including LianLian and Payrails[DIFC — H1 2026 results].

Access to banking partners is the practical reason this density matters. Payments businesses live or die on their banking relationships, and being in a district with 327 banking firms is materially better than explaining your model to institutions who have never seen a DIFC payments entity.

1. Get a written perimeter analysis. Before building, before incorporating.
2. Confirm DIFC or onshore based on where your customers are[Central Bank of the UAE].
3. Define the regulated activities precisely. The licence specifies them[DFSA — Authorisation].
4. Design client money arrangements properly from the outset.
5. Recruit compliance and the MLRO — payments-experienced, and part of the application[DFSA — Authorisation].
6. Build the regulatory business plan, financial crime framework and operational resilience documentation.
7. Incorporate through the Registrar[DIFC Registrar of Companies] in parallel with the DFSA application.
8. Start banking conversations early — see bank account opening.
9. Submit, engage, satisfy conditions and take up the licence.

DIFC publishes its fees in the Registrar of Companies Table of Fees and the per-structure checklists[DIFC — Handbooks & Fees]; the DFSA publishes its own. Price from those.

Budget across:

• DFSA application fees for the permissions sought.
• Regulatory capital — lighter than banking, but real and held continuously.
• People — compliance and a payments-experienced MLRO. Recurring, and usually the largest operating line early on.
• Systems — transaction monitoring, screening and reconciliation are not optional and are not cheap.
• Premises sized to headcount — see office space.
• Annual supervision fees and audit.

The planning point for a venture-backed payments firm: model the regulated cost base before you raise, not after. A firm that raises against an unregulated burn rate and then becomes authorised discovers a permanent cost floor it did not budget for.

• Assuming a technology framing keeps you outside. The regulator looks at the money[DFSA — Authorisation].
• Relying on an innovation licence for a payment service. The Commercial Licence does not authorise Financial Services, and says so[DIFC Registrar of Companies].
• Applying for a banking licence when you need payment permissions. An order of magnitude of unnecessary work.
• Treating float as working capital. Client money is not yours.
• Assuming a partner’s licence covers you. The archetypal borderline case, and it needs analysis.
• Hiring the MLRO after approval. Fitness is assessed at application[DFSA — Authorisation].
• Leaving banking partners until the end. They are your critical dependency.
• Building the product before the perimeter analysis. The most expensive ordering error in fintech.