Run this exercise before treating a tokenisation demonstration as an operating design. Bring the asset/product owner, treasury or cash-settlement owner, custody/technology owner, finance operations and relevant legal/risk colleagues. The digital-asset operations guide supplies the context.
Map one complete transaction
Record the authoritative source for instrument terms, investor eligibility, holdings, cash movement, accounting and servicing. Identify the moment each system considers an event final and the evidence used to reconcile those views. A shared ledger does not by itself establish legal entitlement, settlement finality or accounting treatment.
| Lifecycle event | Questions to resolve |
|---|---|
| Issue | Who authorises issuance, validates terms and confirms subscription/payment conditions? |
| Transfer | Who may transfer, what restrictions apply and what evidence changes ownership records? |
| Cash settlement | How is cash state confirmed, including unknown or delayed responses? |
| Service | Who calculates entitlements and handles record dates, amendments and payments? |
| Redeem | How are cash, token state, custody records and accounting closed consistently? |
Inject failures into the design
These are hypothetical scenarios, not descriptions of any bank's platform.
| Scenario | Decision the team must demonstrate |
|---|---|
| Token transfer appears complete; cash confirmation is delayed | Which state is authoritative, whether to hold further action, and who investigates |
| A settlement request times out and the caller retries | How the system detects prior commitment and prevents duplication |
| Custody and accounting records disagree at the close | Reconciliation owner, evidence needed, escalation and permitted corrections |
| A servicing instruction uses superseded terms | How the approved version is identified and affected calculations are rechecked |
| A key/operator is unavailable | Authorised recovery, segregation of duties and the continuity window |
| An AI summary omits a material exception | How the reviewer sees original evidence and detects an incomplete summary |
For each scenario, record detection, responsible owner, required records, permissible actions, recovery sequence and unresolved dependency. Set deadlines from the instrument and service obligations, not a universal technology benchmark. Rehearse ambiguous transaction state explicitly: a timeout is not proof of failure.
Worked tabletop: an ambiguous transfer response
All identifiers, times and states below are fictional. Hand the first three records to participants before revealing the fourth. In this designed example, the operator may investigate and hold a case; only the settlement supervisor may authorise a new instruction. There is no assumed unilateral reversal right.
| Time | Record | Observed state |
|---|---|---|
| 09:00:00 | Instruction TX-017 / subscription SUB-017 | Transfer instruction submitted; request carries a stable idempotency identifier |
| 09:00:05 | Client response for TX-017 | Timeout; outcome unknown to the caller |
| 09:01:00 | Authoritative custody event C-017 and cash enquiry K-017 | Custody records the asset transfer under TX-017 at 09:00:03; cash is reserved but settlement is still pending; accounting entry J-017 is held |
| 09:03:00, revealed later | Cash-settlement confirmation K-018 | Cash provider confirms settlement linked to SUB-017; custody and accounting references still need reconciliation |
The fictional flawed AI summary says: “TX-017 timed out. Retry the transfer to complete the subscription.” It omits the custody event and treats an unknown response as failure.
Facilitator key: before the final record, the acceptable decision is to hold, retain the original identifier, verify each leg against its authoritative records and escalate the mismatch. Issuing a new financial instruction would disregard evidence that the transfer already occurred. A documented replay-safe retry using the same identifier is different: use it only where the service's idempotency contract establishes the behaviour, scope and retention window. The identifier alone does not prove replay safety. After K-018, reconcile the asset, cash and accounting references under the authorised procedure; a cash confirmation alone does not establish that every required record is complete. The team must identify the summary's omission before using it to support an action.
| Observation log | Entry |
|---|---|
| Proposed action and time | What the participant actually decided, including any attempted retry |
| Evidence used | Specific custody, cash and accounting records; unresolved disagreement |
| Authority | Who may perform the action and who must approve it |
| Remaining state | What remains unconfirmed and which owner can resolve it |
| Next permitted action | Hold, investigate, reconcile or an explicitly authorised correction |
| Remediation | Missing control, owner and evidence needed before operation |
A successful discussion demonstrates understanding of the designed response. It does not prove that duplicate protection, authoritative queries or recovery work in the implemented system; those require technical and operational tests.
Define where AI adds value
Candidate assistance includes classifying exception messages, assembling an investigation pack or drafting a status explanation linked to evidence. Compare it with deterministic rules and the current process using investigation time, missing material facts and final resolution quality.
For the underlying tokenisation proposal, separately compare settlement/funding availability, fees, operating effort, exception work and infrastructure cost with the existing arrangement. Record the source and assumptions for any working-capital benefit. A quicker AI summary is not evidence that tokenisation improves those economics.
Keep entitlement calculations and consequential approvals within their authorised control process. An AI-generated explanation must not become the source of truth merely because it is easier to read. If the source systems disagree, preserve that disagreement in the pack rather than generating a confident resolution.
Conclude with one lifecycle map, an exception register and a bounded test proposal. A buyer can then assess whether AI addresses a meaningful operating burden or whether better interfaces, identifiers or reconciliation rules would solve it more directly.
Read our editorial principles for evidence, contribution and correction standards.