Guide
Setting Up a Money-Market and Liquidity-Management Platform in the UAE
The short answer
Whether a UAE money-market or liquidity platform needs financial-services authorisation turns on one question: does it only display information, or does it also choose, move or recommend client cash? Onshore, deposit-taking and arranging deposits sit with the Central Bank of the UAE (CBUAE); inside the DIFC and ADGM, advising, arranging and managing assets sit with the DFSA and the FSRA respectively. The fact that most often decides the route is who chooses the instrument and who controls the cash once a transaction happens — not whether the product calls itself treasury software.
The regulatory perimeter: CBUAE, DFSA and FSRA, and which one decides
A money-market or liquidity platform is usually one of four things wearing the same label:
- Treasury analytics — shows rates, balances and yield comparisons, never touches a client's cash.
- Deposit or fund marketplace — lists products from banks or fund managers and lets a client place an order.
- Automated cash sweep — client balances move into a third-party deposit or fund on a rule the platform runs.
- Discretionary short-duration management — the platform, or a person behind it, decides where client cash sits without asking each time.
Which regulator applies follows from where the platform is established and which function it performs. Onshore, deposit-taking and arranging deposits sit with the CBUAE. A DIFC platform falls under the DFSA's advising, arranging and managing-assets regime; an ADGM platform falls under the equivalent FSRA regime. These are three separate regimes, not three price points for one permission, and the activities performed decide which applies.
A platform that only ever displays data, with no order flow, no discretion and no client money, can sit outside all three regimes on the right facts. The moment it recommends a product, executes an order, sweeps a balance automatically or decides allocation on a client's behalf, it performs one of the functions above, whatever the label — "cash management", "treasury tech", "MML". The regulator reads the order and the cash flow, not the pitch deck.
What tests the classification, feature by feature
Each of these can move a feature from software into a regulated function, and each should be tested on its own, not assumed away by the product's overall description:
- Does it recommend or rank a specific deposit, fund or product, rather than simply listing published rates?
- Does it place, arrange or execute an order, or only display one for the client to place elsewhere?
- Does a balance move automatically into a third-party product under a rule the platform, not the client, sets?
- Does the platform or anyone behind it decide allocation, duration or counterparty for the client?
- Does the platform hold client money at any point, or control settlement instructions?
A feature that fails one of these tests does not mean the whole platform needs authorisation; it means that feature needs its own classification, separate from the others. Treasury platforms often split into more than one entity for this reason — a technology company running the display layer, and a separately licensed entity, or licensed third party, carrying the transaction function.
How client cash moves, and what a bank or custodian checks
Banks, fund administrators and custodians run their own diligence, and read the regulatory position first. The practical point is where the client's money sits at each step, not what the dashboard says. On any platform with a transaction feature, funds sit in segregated client money accounts with licensed institutions, under the relevant regulator's oversight, never mixed with the operator's own funds. Before approaching a bank or custodian, have ready:
- A diagram of the order and cash flow: where money sits before, during and after a transaction, and who can move it.
- The feature-by-feature classification above, with regulated functions marked.
- Product-provider agreements, where the platform lists third-party deposits or funds.
- The yield calculation and disclosure method, if the platform displays or ranks a rate.
This is the file corporate bank account readiness work assembles. A consistent account across the regulatory file, the flow diagram and the bank application shortens onboarding; one story in the business plan and another in the flow diagram is the fastest way to stall a review.
Ownership, substance and the roles the regulator expects filled
An entity carrying a licensed function — arranging, advising or managing assets, onshore or in the DIFC or ADGM — needs resident senior officers and compliance cover matched to what it does, not a registered address and a nominee director. Where technology and the regulated function sit in separate entities, the licensed one carries the substance: the people, the systems and the capital the regulator attaches to that function. A structure designed mainly to keep the displayed setup cost low reads as exactly that in an authorisation review, and again at every bank that reads the file afterwards. Mapping which entity in a group carries which obligation, before a regulator or a bank asks, is what regulated and complex ownership setup work is for.
What commonly goes wrong in this sector
- Treating "cash management" as a label that proves the activity is unregulated, rather than testing each feature on its own.
- Displaying ranked yields that function as a recommendation without treating them as one.
- Running an automatic sweep without first establishing whether it counts as arranging or managing on the client's behalf.
- Using an acronym — "MML", "liquidity platform" — in place of naming the actual operating model to a regulator or a bank.
- Comparing routes on the incorporation fee rather than on the regulated function, the capital it carries and the reporting it brings.
From classification to operating
Once the operating model and regime are fixed, the path runs from feature classification through entity choice, any required authorisation, formation and bank onboarding, before office, visas and ongoing filings become routine. Where a feature requires authorisation, that runs on the regulator's timetable — application, review, any interviews, then licensing — and an incorporation date is not a launch date. Where the features clear the tests above without triggering a licensed function, the business can usually proceed through ordinary fintech setup and commercial registration, provided that conclusion came from testing the features, not from preferring the faster answer. Cost follows the same split: software-only formation carries ordinary company costs; each transaction-enabled feature can add the capital, officers and reporting its function requires, set by the regulator rather than by a formation headline. Otherwise, the Velarozone service fee is itemised in the engagement letter — see how Velarozone works.
