How to evaluate a tokenized settlement pilot beyond its first transaction

The first completed transaction is an important milestone, but it is not a complete assessment of a financial service. A tokenized settlement pilot can demonstrate a useful mechanism while leaving operating hours, legal arrangements, exception handling and broad access unresolved. This guide provides an original evaluation worksheet for readers and product teams. It does not claim that BijliCoin has tested the systems described in third-party announcements.

The BIS’s 2026 discussion of tokenization emphasizes the relationship between payment innovation, commercial-bank money and central-bank settlement. It also identifies governance and resilience as conditions for moving beyond experiments. Those ideas motivate the questions below; the worksheet itself is an editorial method for separating a narrow demonstration from evidence of a dependable service.

Define exactly what is being settled

Write down the two sides of the transaction. In an asset purchase, identify the asset, the payment instrument and the parties responsible for their records. In a cross-border payment, identify the sender’s initial balance and the recipient’s required final balance. Do not use the word settlement as a shortcut for every stage of the journey.

A pilot may coordinate payment commitments while final settlement occurs through another mechanism. Another arrangement may coordinate an asset and cash transfer together. Each can be useful, but they answer different questions. Your evaluation should describe what becomes final, when and under whose rules before comparing the systems’ speed.

Establish a baseline that covers the same journey

Choose the existing process that performs the same task for comparable participants. Record its start and end points. A comparison between a token network’s confirmation time and a conventional payment’s total customer journey is not like-for-like. Include the operational stages needed to produce an outcome the recipient can use.

For an illustrative securities transaction, the baseline might cover instruction, approval, asset availability, payment and reconciliation. Add any conversion or custody changes introduced by the new route. This does not imply that the new process is better or worse. It ensures that the evidence answers the question being asked instead of selecting whichever measurement looks most impressive.

List the dependencies outside the ledger

A transaction may depend on identity checks, liquidity providers, reference data, custody systems or an external record of a real-world event. Name those dependencies and identify who operates each one. A shared ledger does not make a missing asset, incorrect instruction or unavailable banking service disappear.

Ask what happens when the dependency is slow, wrong or unreachable. Can the transaction wait safely? Does it expire? Are funds reserved, and who can release them? The answers determine whether automation reduces work or simply moves the most difficult exceptions into a less visible part of the process.

Include failure cases before declaring success

A useful evaluation should examine duplicate instructions, rejected permissions, interrupted connections and a participant that cannot complete its side. The team should specify the expected state after each failure and the evidence that an operator can use to resolve it. These are proposed test categories, not a claim that every pilot must use identical architecture.

Recovery deserves its own result. A system may prevent an incorrect settlement but leave money unavailable until someone intervenes. That can be a preferable failure mode to losing funds, yet it still matters to customers and liquidity managers. Report both the protection achieved and the operational cost of reaching a final resolution.

Measure outcomes that the user recognizes

Useful measures can include time to usable funds, unresolved exceptions, staff effort, required liquidity and the complete cost of a transaction. Report the sample size and conditions alongside the figures. A result from a small controlled cohort should not be extrapolated to every institution, currency and stress scenario without additional evidence.

The strongest pilot report also states what it did not test. That might include scale, legal disputes, prolonged outages or access for new participants. These gaps do not make the pilot worthless. They define the next experiment and prevent readers from treating a successful demonstration as a universal production guarantee.

Finish with a decision that matches the evidence: continue testing, narrow the use case, change a control or expand cautiously under stated conditions. A pilot is most useful when it reduces uncertainty about a real operational choice. The number of tokens moved is only one possible input to that decision.