Live Product Demonstration
From client outcome to controlled settlement
A stakeholder-ready walkthrough of the flagship tokenised-treasury proposition: the client interface, the bank control plane, the commercial narrative and the cross-functional operating model.
New to the wording on this page? 7 terms explainedShow
Tokenised depositTokenised bank deposit
Money you already hold in a normal bank account, represented as a digital token so it can move instantly and around the clock. Nothing new is created — it is the same deposit, in a form software can move and check automatically.
For example: A company has US$10m sitting in its HSBC Hong Kong account. Tokenised, that same US$10m can be moved to its Singapore subsidiary at 2am on a Sunday. The money never left HSBC and no new money was created — only the record of which entity owns it changed.
Maker-checkerFour-eyes principle
A rule that two different people must be involved in anything sensitive: one to create or request it, a different one to approve it. No single person can act alone.
For example: One treasury analyst prepares a US$5m payment; a second, more senior person must approve it before it goes. Neither can do both, so no single employee can move the money by themselves.
Sanctions screening
Checking every payment's sender, receiver and purpose against government lists of banned people, companies and countries before the money moves.
For example: A payment to 'M. Ivanov' is automatically held because that name resembles someone on a sanctions list. A human then checks whether it is the same person or an innocent match — most are innocent, which is why the review step exists.
Reconciliation
Checking that two separate records of the same thing actually agree — for example that the token ledger and the bank's main account system show the same balance. A mismatch is called a break.
For example: Like comparing your receipts against your bank statement at month end. If the statement says HK$4,000 and your receipts total HK$4,200, you have a break and must find the missing HK$200 before closing the books.
RMRelationship Manager
The banker who owns the commercial relationship with a corporate client — the person who actually sells the product and fields the complaints.
For example: A Hong Kong manufacturer has one main HSBC contact who knows their business, brings them new products, and gets the call when a payment goes wrong.
TreasurerCorporate treasurer
The person inside a large company responsible for its cash: making sure each part of the business has money when it needs it, spare cash earns something, and currency risk is managed.
For example: A group with offices in six countries has one treasurer deciding each morning which subsidiary needs funding, which has surplus cash to sweep back, and what to do about a weakening currency.
Exception handling
What the product does when something goes wrong — a failed check, a timeout, a duplicate request. Who is told, who owns fixing it, and what the customer sees meanwhile.
For example: A transfer is held by a sanctions alert. Good handling: the client immediately sees 'under review, reference 12345', a named team owns it, and there is a deadline. Bad handling: the payment silently disappears and the client phones to ask where the money went.
One transfer, two views: what the client sees and what the bank has to prove.
Do not lead with the ledger. Lead with one client need, then show the bank proving it can either settle safely or stop safely. Choose a scenario below and run it live.
The story you are showing
Use this before touching the interface
- 1. Client problem: Meridian Singapore needs operating cash before its local window; the old process means cut-offs, fragmented status and reconciliation work.
- 2. Product promise: one governed instruction gives the client clear status, while the bank applies the required controls before settlement.
- 3. Proof: run the happy path to show a shared receipt, then the unhappy path to prove that a control hit creates a managed case and no funds move.
Choose the scenario
The controls are not a footnote - they are the product
Presenter cue - ready
Run the happy path: show what happens when the right instruction meets the right controls.
Choose a scenario above. The two flows are intentionally paired: business value only counts when the failure path is as controlled as the success path.
Institution client interface
Treasury manager: Meridian Holdings (HK)
Meridian Treasury
Asia Pacific liquidity workspace
Good morning, Alex
Liquidity is available for today's operating needs.
Group USD
Available liquidity
$9,700,000
Hong Kong USD
Forecast after funding
$6,450,000
Today's priority
Protect SG operating runway
Forecast remains within approved liquidity policy after transfer.
AI treasury brief
No policy conflicts found
Prepared the decision summary from approved account, forecast and policy data.
Bank control plane
The backend mechanism the client should not have to coordinate
API receives a structured treasury instruction
QueuedMeridian HK requests a USD liquidity transfer to its approved Singapore entity.
Policy and sanctions services evaluate the instruction
QueuedThe client is not asked to chase a back-office team for a payment status update.
Funds and maker-checker approval are confirmed
QueuedThe workflow shows exactly what was checked before any value is committed.
Orchestrator writes debit and credit atomically
QueuedThe tokenised-deposit movement is committed only once all controls pass.
Core-ledger reconciliation and reporting complete
QueuedTreasury, operations and finance consume the same transaction evidence.
The narrative to land
Lead with the operating problem, not the technology
Before: cash movement is constrained by cut-offs, opaque status updates and manual reconciliation across systems.
After: a client submits one governed instruction. The bank applies the same risk controls, but clients and internal teams receive shared, timely evidence of what happened.
Be precise: “24/7 in supported corridors” is credible. Do not promise universal, instant cross-border settlement before legal, liquidity and interoperability gates clear.
Why this is better than the old operating model
A product proposition, not a technology claim
| Dimension | Old model | Tokenised treasury model |
|---|---|---|
| Client experience | Instruction, status and receipt split across systems | One governed workflow with live stage visibility |
| Availability | Business-day cut-offs and operational queues | Supported 24/7 corridor with explicit policy controls |
| Reconciliation | Post-event matching and investigation | Continuous core-to-token-ledger reconciliation |
| Risk handling | Manual escalation after a break | Pre-settlement controls; atomic commit or no movement |
| Product delivery | Point integration per payment use case | Reusable policy, orchestration and evidence layer |
Stakeholder playbook
Same product, different proof point
Move approved group liquidity when the business needs it, with a clear audit trail.
Start with the missed cut-off or trapped-cash problem. Then run the transfer: the client sees the instruction, policy result, approval and receipt in one workflow instead of across several portals and teams.
How to run the demo in six minutes
- 1. Start with pain: give one concrete example of cash trapped after cut-off.
- 2. Run the transfer: let the client view and backend control plane progress together.
- 3. Pause at approval: show that AI prepares evidence, while policy and authorised people govern movement.
- 4. Land atomicity: value moves only if all checks pass; exceptions create cases, not partial settlement.
- 5. Close on metrics: agree a narrow pilot and baseline time, breaks, idle cash and operational effort.
The mini-CEO / product-lead role
The job is to translate one client outcome into a commercially viable, legally safe and operable product. That means keeping Sales focused on qualified demand, Technology on a reusable platform, Operations on exception readiness, Risk and Compliance on control evidence, Legal on finality and Product on phased commercial decisions.