When a tokenised security changes hands, several teams need an answer to the same question: what has happened to the investor's entitlement and the associated cash?
A demonstration may show a token moving between wallets. An operating service must also establish who was entitled to transact, whether cash and security movements completed, which record finance relies on, and what happens if the process stops halfway. Those questions should shape the investment case before the platform becomes the centre of the discussion.
For a treasury or capital-markets sponsor, the most useful next document is a transaction-lifecycle map. It connects the commercial proposition to the people, systems and evidence required to run it.
Start with a specific transaction
There are published commercial examples worth examining. In January 2025, OCBC described its sale of bespoke tokenised bonds to corporate accredited investors. The first transaction had taken place in November 2024 for a manufacturing client. The announcement described S$1,000 token denominations and an asset lifecycle covering minting, ownership transfers, custody and redemption.
In August 2025, OCBC announced a US$1 billion digital US commercial paper programme. Its first issuance, on 20 August, involved six-month notes sold to an accredited institutional investor. OCBC reported receiving funds within minutes and described record-keeping and servicing on-chain, using J.P. Morgan's Digital Debt Service on Kinexys Digital Assets. The US$1 billion figure was programme capacity, not the amount issued.
These bank-reported examples show that institutional tokenisation can extend beyond a proof of concept. They do not provide a universal settlement model or reveal every internal control. A new project must establish its own commercial benefit and operating design.
Choose the transaction that matters to that benefit: an issuance, subscription, transfer, financing transaction or redemption. State who participates, which assets and cash are involved, and the problem being improved. Faster settlement may matter to a funding need; smaller denominations may matter to distribution. Each proposition needs different evidence.
Map the records that must agree
The token ledger is one record in a wider financial process. Depending on the arrangement, participants may also rely on an issuer register, a custodian's records, bank-account movements, trade confirmations and general-ledger entries. Determine the legal and operational authority of each record for the particular instrument and jurisdiction.
Use the following map as a design worksheet. The entries describe questions for the project team, not the undocumented architecture of either OCBC example.
| Stage | Evidence needed | Decision owner to identify | Failure to rehearse |
|---|---|---|---|
| Investor and transaction eligibility | Approved party, instrument terms and transaction authority | Relevant onboarding and business owners | An ineligible party or expired approval reaches execution |
| Instruction | Agreed economic terms and a unique transaction reference | Trading or issuance operations | Duplicate, inconsistent or late instructions |
| Asset and cash movement | Recorded state of both legs and defined completion conditions | Settlement operations and treasury | One movement completes while the other remains pending |
| Custody and ownership | Entitlement record, access arrangement and reconciliation | Custody or asset-servicing owner | A ledger record conflicts with another authoritative record |
| Accounting and reporting | Classification, valuation inputs and traceable postings | Finance and reporting owners | A transaction is economically complete but missing from the books |
| Servicing and redemption | Entitlement at the relevant time, payment calculation and completion evidence | Asset servicing and treasury | Incorrect entitlement, failed payment or incomplete redemption |
Assign one transaction reference across these stages wherever feasible. If systems use different identifiers, document the mapping and who repairs a missing or ambiguous link. Reconciliation becomes much harder when the project first confronts identity mismatches during an incident.
Define completion before measuring speed
“Settled in minutes” can be a useful observation, but the business case needs a precise starting point and end condition. Did the clock begin with an approved instruction, a funding request or an order? Did it stop when a ledger transaction appeared, when a participant could use the cash, or when both parties had the required finality?
The answers depend on the instrument, agreements, payment mechanism and relevant legal analysis. Record them explicitly. Faster ledger execution does not, by itself, establish legal finality, readily available liquidity or correct accounting.
Measure the entire service around the event: preparation, funding, approval, execution, reconciliation and exception resolution. Include the people who remain involved. A project may make execution faster while increasing the work needed to manage unusual cases; that can still be worthwhile, but the sponsor should see the trade-off.
Budget for unresolved transactions
An exception process needs more than an alert. Staff require a view of the current state, the evidence for that state, actions they are authorised to take and a route to the other participants.
For each failure in the worksheet, decide whether the system should wait, retry, cancel, reverse through an authorised process or escalate. Some actions may be impossible after a particular point, which makes the point of commitment a critical design decision. Do not assume that a failed technical response means the financial action failed; an instruction might have completed even when the caller did not receive confirmation.
Rehearse recovery with operations, treasury, finance and technology together. Include a duplicate instruction, loss of access, unavailable dependency and disagreement between records. Record how the team determines the truth before it takes another action. The exercise should reveal missing authority and evidence as well as software defects.
Treat delegated action as a separate permission
A tokenised instrument does not grant an AI system authority over its lifecycle. If an institution later connects an agent to the process, identify the exact action it may take: retrieve a record, prepare an instruction, submit an approved instruction or change a financial state. Each step needs its own identity, permission, evidence and recovery design.
Do not infer AI adoption from the bank examples above. They establish reported tokenisation activity, not the use of autonomous agents. Likewise, a proposed machine-commerce architecture does not establish that the intended settlement, custody and accounting arrangements are already operating.
The commercial comparison should include conventional settlement alternatives and the whole lifecycle. Programme capacity, a faster ledger event and a live issuance answer different questions. The sponsor needs evidence about the particular transaction and operating obligation being funded.
Give AI a bounded supporting job
AI can be worth testing for work around a transaction: reading supporting documents, preparing an exception summary or retrieving the relevant operating procedure. Those are proposed applications, not claims about how the published OCBC transactions worked.
Keep financial entitlements, limits and authorised state changes tied to explicit rules and accountable approval. A model's plausible explanation of a mismatch is not sufficient evidence to move funds or amend an ownership record. Any generated investigation pack should link back to the underlying records and make uncertainty visible to the reviewer.
The evaluation should measure whether the pack helps a person resolve a case correctly and faster, including checking time. Producing a longer explanation is not an operating benefit in itself.
The approval record
Before funding implementation, ask the sponsor to complete a one-page record with six fields: the specific commercial benefit; the transaction and participants; authoritative records; completion and recovery rules; named operating owners; and the evidence that will demonstrate value.
Where an answer remains unclear, fund the work needed to resolve it before committing to scale. A lifecycle map with an unresolved cash leg or an unowned exception is already useful: it shows exactly which operating decision the project needs next.
The companion exception tabletop includes a fictional transfer, timed custody/cash evidence and a recovery decision to rehearse with the operating team.
Read our editorial principles for evidence, contribution and correction standards.