Tokenization that survives the weekend: the treasury KPIs that matter

The word “tokenization” is doing what “cloud” did a decade ago. It is a convenient label that lets everyone sound modern while avoiding the hard question: what pain are we removing for the people who have to make payroll, fund refunds, and sleep on Sunday night?

The only adult reason to care is liquidity. Not yield. Not a new asset wrapper. Liquidity under constraints: weekends, cut-off times, bank holidays, operational freezes, and the small detail that treasury is judged on not failing. If a new rail cannot make those constraints less brutal, it is decoration.

That is why I paid attention to Uber’s tokenization pilot with HSBC and Franklin Templeton. Not because it is “onchain”. Because the stated point was practical: keep funds invested in money market products while still being able to access cash for payments, even on weekends.

Weekend liquidity is where a lot of “innovations” go to die. It is also where the value is easiest to measure, if you are disciplined enough to measure the right things.

The enemy is not cash, it is cut-off times and human bottlenecks

Most corporate cash management is a sequence of compromises. You park idle cash somewhere sensible. You schedule payments. You work around cut-offs. You keep buffers because you do not fully trust timing. Then you explain to the business why “we have cash” and “we can use cash” are not the same sentence.

Tokenization, at its best, is just a new mechanism for collapsing those compromises. But you do not get that for free. You trade one set of constraints for another: smart contract controls, custody models, new counterparties, new failure modes, and new questions about who can do what when everything is on fire.

The mistake I see in early pilots is that they measure the easy thing (did a transaction go through?) and ignore the thing treasury actually cares about (could we guarantee access, under pressure, inside our control framework?).

So I would force every corporate pilot to start with a KPI stack that is explicitly designed for bad days, not demos.

The adult KPI stack: availability, finality, break-glass cash

If you are running a pilot, you need three top-level metrics. Everything else is a sub-metric or a diagnostic.

1) Availability: can I move value when I need to?

Availability is not uptime of a blockchain node. It is end-to-end “I can turn invested cash into usable cash” availability. That includes every dependency you do not control.

• Definition: percentage of time you can initiate and complete a liquidity action inside policy (redeem, transfer, pay) without manual exception handling.
• Measure it across the real calendar: weekends, month-end, quarter-end, holidays, and during your own internal change windows.
• Split by dependency: asset manager window, bank processing, tokenization platform, custody, wallet policy engine, internal treasury approvals.

This is where most “24/7” claims die. The chain might run continuously. Your ability to redeem into spendable money might not. If your pilot cannot produce a simple chart of availability by day and hour, you are not testing liquidity. You are watching a novelty work once.

2) Settlement finality: when can I stop worrying?

Treasury does not get rewarded for “eventual”. It gets rewarded for “done”. Finality is the moment the payment is irreversible enough that your risk posture changes.

• Definition: time from initiation to final settlement that your bank, auditor, and risk function will accept as complete.
• Two finalities matter: on-ledger finality (the token moved) and off-ledger finality (the money is actually usable for the liability you are paying).
• Track reversals and disputes: not as edge cases, but as part of the metric. If reversals exist, finality is conditional.

In trading systems, the only definition of “real-time” that counts is: can you manage risk with it. Treasury is the same. Finality is not a technical timestamp. It is the point where the person accountable can stop holding breath.

3) Break-glass cash access: what happens when policy meets panic?

This is the KPI everyone avoids because it forces governance into the open. When something breaks, how do you get cash out fast, without turning your control environment into a crime scene?

• Definition: time and steps required to access cash when standard flows are blocked, while remaining compliant with internal controls.
• Test scenarios: primary bank outage, tokenization platform outage, asset liquidity freeze, compromised key, wrong beneficiary batch, fraud suspicion, and a payments deadline that cannot move.
• Measure “human latency”: how long it takes to assemble approvers, how often you hit “nobody has the key”, and how many escalations are needed.

Break-glass is where “decentralization” rhetoric collides with corporate reality. Companies need named decision rights. They need an audit trail. They need the ability to say no. And they need a way to say yes fast when the situation demands it.

Control beats ideology: tokenization is a treasury product, not a crypto product

Most tokenization conversations get pulled into ideology. Public versus private. DeFi versus TradFi. Permissionless versus permissioned. It is mostly noise for a corporate pilot.

The grown-up framing is control. Treasury is not trying to be cool. It is trying to remain solvent, predictable, and explainable.

That means your pilot needs to answer, in plain language, questions like these:

• Who can initiate a redemption? Not theoretically. In your identity and access stack, with your approval rules.
• Who can change limits? And what is the delay, the logging, and the alerting?
• What is the custody model? If keys are involved, where do they live, and who can rotate them under stress?
• What is the legal claim? If something goes wrong, what do you own, and against whom?
• What is the reconciliation path? How do you prove balances match across systems at 02:00 when the numbers disagree?

This is also why many pilots fail quietly. They succeed technically, then die in the gap between “we can” and “we can control”. The seams are where pilots bleed, not the headline feature. It is the same pattern I have seen in connected product rollouts where the device worked fine, but identity, updates, and support workflows were the real system. I wrote about that dynamic in Your IoT pilot didn’t fail. Your seams did.

A pilot design I actually trust

If I had to sponsor a tokenization pilot, I would insist on a design that makes failure visible early. Not a broad “innovation program”, but a narrow, testable cash loop.

1. Start with one pain point that has a clock. Weekends is a great one. Cut-off times is another. Pick one and make the pilot live or die on it.
2. Define a minimum liquidity unit. The smallest cash amount that is meaningful for your payments. If the unit is too small, you are doing theatre. If it is too big, you will never get approval.
3. Instrument the full path. Not just ledger events. Include approvals, bank confirmations, reconciliations, and exceptions.
4. Run planned incident drills. Schedule a break-glass test while everyone is available, then repeat it without warning. The delta is your real risk.
5. Pre-agree stop conditions. If availability drops below X for Y hours, if finality exceeds Z, if reconciliation breaks twice, you pause. Not debate. Pause.

That last point matters more than people admit. Without stop conditions, pilots become political. They continue because nobody wants to declare a failure. Then a year passes and all you have is a slide.

I learned this the hard way building trading infrastructure where the system looked healthy right until it met an edge case at speed. If you do not rehearse failure, you discover it in production, and production is never a safe classroom. One of the most useful habits is to treat every new capability as owning more failure modes. I went deeper on that mindset in Owning More of the Stack Is Just Owning More Failure Modes.

My bias: if it cannot fund real payments, do not call it liquidity

Here is my line in the sand. If the “liquidity” you are creating cannot reliably fund real liabilities, with finality your finance team will sign off, then it is not liquidity. It is a balance you can look at.

The Uber pilot is interesting precisely because it aims at the lived treasury constraint: keep idle cash working, but still access it for payments, including weekends. That is the right ambition. Now the bar is whether a corporate can run that flow with the same discipline it expects from any other treasury mechanism: controls, auditability, predictable timing, and a tested emergency path.

Tokenization will not win because it is new. It will win when it makes cut-off times irrelevant for a class of corporate cash movements, without weakening control. That is a boring promise, and that is why it might actually stick.

If you are considering a pilot, do not start with “should we be onchain?” Start with “what is our weekend liquidity gap, measured in hours and exceptions?” Then build a KPI stack that makes the answer impossible to fake.