UAE tokenised deposits: what the new pilots prove

Mashreq says it has completed a live transaction with Citi using Swift's blockchain ledger. Ant International has also reported UAE treasury pilots through HSBC's Tokenised Deposit Service. For a finance team moving cash outside banking hours, these are worth examining. They are not evidence that every corporate payment can now travel between any two banks around the clock.

The useful distinction is between an available bank service, a particular customer pilot and a multi-bank payment mechanism. They have different eligibility rules and evidence behind them. A treasury integration needs to preserve those differences, especially when a fast payment commitment precedes final interbank settlement.

Cover: original SultanByte artwork illustrating bank-issued deposits, a shared payment commitment and separate settlement.

What the UAE announcements establish

In its 5 October announcement, Mashreq reports a completed live transaction with Citi using bank-issued tokenised deposits. It describes Swift's ledger as a shared orchestration layer connecting participating institutions. The release does not disclose the transaction amount, its currency or a customer-facing tariff. It demonstrates a transaction, not unrestricted commercial availability.

The Paypers reported the same collaboration on 1 October. Its account describes the pilot and the companies' expected benefits; it does not provide an independent performance test. The publication dates also should not be mistaken for the date the transfer occurred.

There is earlier evidence of this multi-bank approach. Citi's 2 September release reports live USD transactions with First Abu Dhabi Bank and OCBC. Citi places those transactions within a controlled proof-of-concept phase running from July to December 2026. That is a stronger description of the rollout boundary than a general promise of always-on payments.

A different route appears in Ant International's 6 October announcement, republished by The Asian Banker. Ant reports intra-UAE dirham transfers and cross-border US-dollar transfers from the UAE, including connections to Hong Kong and Singapore. Its WhaleRTP treasury platform initiated the transactions through HSBC's service. This is a company account of its own pilots, not an independently measured claim about every customer's transfer speed.

These developments make the UAE a concrete place to test corporate treasury use cases. They do not establish equivalent access for a Saudi, Qatari or Egyptian subsidiary. A regional group's account locations and contracting entities still need individual confirmation.

Compare the bank services before the technology

HSBC's 22 June UAE launch notice says its Tokenised Deposit Service is available to eligible corporate and institutional clients, subject to approvals, documentation and onboarding. It adds the UAE dirham to the network's supported currencies and describes domestic and cross-border transfers within that service.

Citi's 28 September expansion announcement has a different currency boundary: its UAE deployment supports USD and euro transactions. The release describes a private permissioned blockchain and near-instant movement across Citi's network.

Those are bank-specific capabilities. Citi's UAE announcement is not evidence of AED support, and HSBC's inclusion of AED does not prove that every destination supports an AED transfer. Neither announcement should be read as automatic connectivity to every participant in Swift's separate ledger initiative.

For buyers, the first comparison should therefore name the sending legal entity, debit account, currency, receiving bank and destination account. Ask each provider to confirm that exact route. A list of supported countries is too coarse to decide whether a supplier payment or intercompany transfer will work.

A payment commitment is not final settlement

Swift's 9 July activation announcement says 17 banks were preparing to pilot live transactions. It describes funds moving for customers overnight and at weekends before final settlement through existing systems.

Its architecture explanation makes the separation explicit: payment processing relies on verifiable funding commitments, while settlement systems remain outside the ledger. Citi's September pilot release also identifies existing settlement models, including real-time gross settlement, as the final-settlement mechanism.

For an engineering team, that means a single completed field is unlikely to answer every operational question. An instruction may be accepted, a commitment recorded, the beneficiary credited and the banks' obligation finally settled at different points. The provider must define which events it exposes and what each means.

Original infographic: SultanByte. Simplified mechanism based on Swift's 9–10 July and Citi's 2 September 2026 explanations. It is not a transaction trace or a timing guarantee.

Do not invent a settlement timestamp because an API returned success. Preserve the provider's original references and status events, and label any internal interpretation separately. If the bank only reports beneficiary credit, the dashboard should say that rather than claim to observe final interbank settlement.

Choose a pilot that can reveal the limits

A suitable first trial is a recurring, permitted treasury movement with known accounts and a measurable delay today. The following is a proposed acceptance framework, not a description of features already offered by every participating bank.

Start with the service contract. Confirm eligibility, permitted currencies, amount limits, fees and the support model outside business hours. Ask when the beneficiary can use the money and which party carries the obligation before final settlement. Obtain the bank's explanation of reversals, investigations and a failed or delayed settlement.

Then instrument the integration. Record submission, bank acknowledgement, beneficiary-credit confirmation where supplied, and reconciliation availability. Keep them as separate events. Compare the elapsed time and total cost with the existing route for the same type of payment; a successful demonstration alone cannot establish a working-capital saving.

Test the awkward cases before expanding volumes. Lose the response after submission and recover the original instruction through the provider's supported status process. Try an ineligible destination and verify that the application does not silently route it through a slower channel while still displaying an instant-payment promise. Exercise a compliance hold and an out-of-hours support escalation.

The treasury team should also test reconciliation across its accounting-day boundary. A transfer arriving on a weekend can change cash availability before the usual statement or reporting cycle. Agree how operations will explain that difference and which record is authoritative for each purpose.

Expand by verified route, not by regional headline

The October announcements provide useful evidence of UAE activity: Mashreq reports a live multi-bank transaction, while Ant describes specific treasury pilots through HSBC. The bank-service notices provide additional, but different, evidence of eligible-client availability and currency coverage.

A CTO and treasurer can use that evidence to commission a narrow trial now. Expansion should follow a reconciled transaction record, an agreed definition of beneficiary credit and settlement, and a tested exception process for each route. That is a more defensible basis for moving corporate liquidity than treating the word “tokenised” as a guarantee of reach, speed or finality.