How to Start a Distributed Ledger Technology Business in Dubai

How to Start a Distributed Ledger Technology Business in Dubai

There is one question that decides whether a ledger project is worth building, and it has nothing to do with technology. Are there two or more organisations that need to agree on a single record, none of which the others will accept as the keeper of it? If the answer is yes, a shared ledger is doing something no ordinary system can do. If the answer is no — if one party is trusted by everybody else, or if there is only one party — then a database is faster, cheaper, easier to change and better in every measurable way, and the project should be stopped.

Distributed Ledger Technology, as the line reads in the catalogue, is therefore an unusual business to be in, because competence in it includes the ability to say the thing nobody has been paid to say. A firm whose revenue depends on building the ledger has a structural reason not to ask the question, and the ones that ask it anyway end up with the clients who had a real problem and the reputation that follows from solving it.

The buyer is two parties who will not accept each other's records

Four kinds of client commission this work, and they buy for genuinely different reasons.

A bank or finance house wants settlement plumbing between entities, counterparties or jurisdictions that currently reconcile by sending each other files and arguing about the differences. A supply-chain owner wants provenance that a customer or an authority at the other end of the chain will believe without taking the seller's word for it — the record matters precisely because the party reading it is not the party who wrote it. A government body or a regulated institution wants one version of a fact shared across departments that each hold their own copy today. And a company that already owns an asset wants to represent it digitally so that fractions of it can change hands, which is the shape with the sharpest licensing consequences and is dealt with below.

There is often no single client, and that is why these projects are slow

The distinguishing commercial feature of this trade is that the buyer is frequently a consortium. Two or three organisations have to agree not only to fund the work but to accept the same rules about who may write to the ledger, who may read it, what happens when a party leaves, and who pays to keep it running. Each of those is a negotiation between institutions rather than a technical decision, and none of them can be settled by the firm doing the building.

The cash-flow pattern that follows is predictable and should be planned for from the first engagement. One party funds a proof of concept, because one party can decide to spend that much alone. The production system needs all of them, and that approval arrives months later or never. A firm that treats a funded pilot as the start of a programme rather than as a complete, separately priced piece of work will finance the gap out of its own pocket.

CZ 238 — Distributed Ledger Technology

The line covers designing a ledger and the arrangement by which its participants agree on what is true, writing and reviewing the contract logic that executes on it, building the integration between the ledger and the ordinary systems that feed and read it, identity and key management for the participants, operating the nodes, the mechanics of representing an asset as a transferable entry, analytics and reporting over what the ledger holds, and moving data or value between one ledger and another.

Two technical facts decide the budget, and clients price neither of them

The first is that a deployed contract cannot be edited. A conventional system carries defects that are fixed next Tuesday; logic on a ledger that has already executed against real entries cannot be quietly corrected, and the remedies — a migration, a replacement contract, an administrative override that undermines the point of using a ledger at all — are each worse than the original problem. Review, formal testing and independent assessment are therefore front-loaded and consume a share of the budget that looks disproportionate until the first incident.

The second is key management. A password is recoverable because somebody holds the authority to reset it; a private key is not, and losing it is losing the thing itself. How keys are generated, where they live, who may use them, and what happens when the employee holding one leaves is an operational design problem that belongs in the first week of a project rather than the last.

Four of those six are engineering, and a technology licence with this activity recorded on it is the right instrument for all four. The other two are not technology questions wearing technical clothes — they are financial activities, licensed on their own terms by the authorities responsible for financial and payment activity, and the fact that the implementation happens to involve a ledger changes nothing about that.

The technology is on the licence; the asset is not

This is the single most important boundary on the page and it is worth stating without hedging. Writing, deploying and operating ledger technology is a technology activity. Issuing a virtual asset, taking custody of one, exchanging one for another or for money, operating a venue where others do so, or holding client funds in the course of any of it, are financial activities licensed on their own terms. An activity of that kind is granted by the authorities responsible for financial and payment activity and is subject to its own conditions on capital, systems, controls and the people running the firm. Nothing recorded on a technology licence confers any of it, and a firm that drifts across the line by accident — because a client asked it to hold the keys, or because a pilot started moving real value — has a licensing problem rather than a technical one.

Three narrower exclusions follow from the same principle. Advising a client on whether to invest in a token is investment advice, which is its own line and its own permission, not a by-product of understanding the technology. Moving money for other people is a payment arrangement, licensed as such. And operating a public-facing platform where members of the public hold accounts and publish content brings obligations about users, data and content that attach to the platform rather than to the software behind it.

Two adjacent lines in the same catalogue are worth naming so a client is pointed correctly. Cloud Service & Data Center Providers is where hosting an environment is the product rather than the ledger inside it. Data Management & cyber security is where the work is securing and governing information generally; a ledger project leans on that discipline but is not it.

Because most of the clients are UAE institutions and UAE-resident companies served on UAE soil, a mainland licence is the ordinary route; a free zone licence can hold an activity of this kind and suits a firm building for clients inside its own zone or outside the country. What a given licence permits, and to whom you may sell it, is settled by the authority issuing it rather than assumed from the activity name. What it costs, which form it takes and what conditions attach depend on the emirate and the licensing authority, and ConsultZone establishes those for the specific firm before anything is applied for.

References

1. Central Bank of the UAE — banking, payment services, financing and money services, which is where the activities this line does not cover are licensed. Central Bank of the UAE
2. UAE Government portal — federal law and national strategy, including the UAE's published direction on emerging technology. UAE Government portal
3. Ministry of Economy — company matters and intellectual property, which bear on who owns ledger and contract code built for a consortium. Ministry of Economy
4. Federal Tax Authority — corporate tax and VAT enrolment and filing on technology fee income. Federal Tax Authority