Uber’s Tokenized Treasury Pilot: Can the Approval Chain Work All Weekend?

A treasury team can have an available settlement network and still be unable to move money on Saturday. The missing component may be a second authorised approver—or permission to send redemption proceeds to the account that needs funding.

That is the operational question raised by Uber’s tokenized treasury pilot. In its October 30, 2026 announcement, HSBC says Uber bought Franklin Templeton tokenized money-market funds through Tradeweb using HSBC deposit tokens, Canton and Fireblocks. The bank reports synchronised delivery-versus-payment settlement and the ability to liquidate part of the holdings, including over a weekend.

Those are participant-reported pilot capabilities, not a guarantee of unrestricted weekend liquidity. The implementation challenge is to establish whether the entire investment-to-cash process remains usable under the company’s controls when normal staffing is unavailable.

An always-on treasury deployment needs an always-available route to authorised, usable cash—not merely an available ledger.

Separate settlement from cash availability

Delivery-versus-payment links delivery of an asset to payment for it. HSBC’s account of Canton settlement therefore concerns an important transaction dependency. It does not, by itself, establish how quickly every subsequent step can complete.

An acceptance environment should distinguish at least these states: liquidation requested, approval completed, fund transaction settled, deposit tokens available, fiat redemption requested and proceeds available in the intended bank account. These are proposed operational checkpoints, not a description of Uber’s deployed workflow.

That distinction matters because receiving HSBC tokenized deposits and receiving spendable fiat in a particular account are different acceptance outcomes. A business needing on-chain funds may stop at one checkpoint; a business funding an external obligation may need the full sequence.

Before testing, treasury should specify the required currency, destination, amount and completion deadline. Otherwise, a technically successful transaction could be recorded as a liquidity success without meeting the underlying cash need.

The approval rota is part of the architecture

Fireblocks’ Transaction Authorization Objects documentation defines approval groups, thresholds and a setting governing whether an initiator can also approve. These are configurable platform capabilities. They do not reveal the Uber treasury pilot’s actual approval settings.

For a manual approval model, the proposed weekend exercise should remove a normally available approver. Can the remaining authorised staff complete the required quorum? Can they authenticate through the supported access route? Does escalation reach someone empowered to act, rather than merely someone able to receive an alert?

The acceptance criterion should be completion within the company’s cash deadline without weakening the approved control structure. Adding an emergency approver during the incident is not equivalent to proving that the original arrangement works.

Separation of duties needs a distinct negative test. Where corporate policy requires independent approval, attempt initiation and approval using the same identity, then test overlapping group memberships. The expected result should follow the corporate policy, not an assumption that two approval groups necessarily represent two independent people.

Policy-driven automation changes the dependency. A proposed automated design could permit transactions within a tightly defined combination of assets, amounts, destinations and funding conditions, escalating exceptions to people. Implementers must establish which conditions the platform can enforce and which require external controls; the supplied documentation does not establish support for every such condition.

Neither model is inherently safer. Manual approval can accommodate unusual circumstances but depends on availability and informed judgement. Automation can remove a staffing dependency while repeatedly applying an incorrect rule. Compare them using the same permitted, prohibited and borderline transaction cases—not the number of clicks eliminated.

Policy changes need their own approval chain

Transaction authority and authority to change transaction rules are separate concerns.

Fireblocks documents both direct policy publication and a draft-before-publication workflow. It also states that rules are evaluated in their configured order. Platform adoption therefore does not establish that policy changes receive independent review, or that the effective rule order matches treasury’s intention.

A proposed acceptance exercise should introduce a broad permission alongside a narrow restriction, then test the resulting decisions. Reorder the rules and repeat. The purpose is to expose unintended interactions before deployment; no such defect is alleged in the pilot.

The governance exercise should also establish:

• Who can prepare, publish and restore a policy version.
• What independent review is required before permissions expand.
• How urgent weekend changes are authorised and recorded.
• How pending transactions are handled when the active policy changes.

Retain the approved configuration, test results and effective publication time. Where the platform exposes it, capture the policy version associated with each transaction; otherwise, design a reliable way to reconstruct that relationship.

This work creates implementation and maintenance costs. Changes to approver membership, destination data and integration logic should have defined regression tests, rather than relying on the initial pilot exercise indefinitely.

An approved destination is not necessarily the needed destination

HSBC says fiat redemption proceeds can settle only to KYC-verified corporate bank accounts. That is a stated restriction on the pilot’s redemption path. It does not establish that every account a treasury team might need is eligible or available.

The destination test should cover a verified permitted account, an unverified account and a verified account that corporate policy does not authorise for the proposed transfer. Know-your-customer verification and internal spending authority answer different questions.

Account changes deserve particular attention. Test who may add or replace a destination, when that change becomes effective and whether transaction approval can proceed against stale destination data. The desired outcome is a controlled route to the correct legal entity’s account—not merely acceptance of a syntactically valid instruction.

Then test failure beyond the wallet: an unavailable receiving account, a rejected redemption request or a lost status response. These are proposed fault scenarios, not reported pilot incidents.

Fallback must preserve transaction state

A fallback arrangement should state what happens when authorised cash cannot arrive by the required deadline. Depending on the company’s arrangements, that might mean drawing on separately available cash, using an established banking route or deferring a non-critical transfer. None should be assumed available without testing its own access and timing constraints.

Crucially, a missing response must not automatically trigger a second liquidation. The recovery process should first determine whether the original instruction was accepted or completed. Require durable transaction identifiers, status recovery and duplicate-prevention controls across the interfaces involved.

Measure approval delay, settlement completion and destination-account availability separately. Include the cost of weekend coverage, policy administration, integration maintenance and exception recovery in the operating case. The supplied evidence establishes no measured savings.

HSBC’s reported weekend liquidation is a useful starting point. Production readiness would require a broader demonstration: approved transactions finish, prohibited transactions remain blocked, and failures can be recovered without losing control of either the money or the decision record.

*Methodology and limitations: This analysis uses desk research from the supplied verified primary-source excerpts and summaries. The full pages were not independently retrieved for this article, and no system testing, interviews or configuration review was conducted. The acceptance exercises are editorial proposals, not findings about Uber’s controls. Production availability, transaction scale, measured costs and guaranteed weekend liquidity are not established by the supplied evidence.*

Sources and References

• HSBC: Uber on-chain liquidity and settlement pilot announcement, October 30, 2026. Participant account of the pilot and redemption restrictions.
• Fireblocks: Transaction Authorization Objects. Official documentation for approval groups, thresholds and initiator participation; undated.
• Fireblocks: Set Policies. Official documentation for policy publication workflows and ordered rule evaluation; undated.