Interview prep

Q: Why tokenised deposits and not a stablecoin?

A tokenised deposit is a digital representation of an existing, regulated commercial-bank liability — it inherits deposit insurance treatment, existing legal and prudential frameworks, and the bank's existing balance-sheet and AML controls. A stablecoin is a new, separately reserved instrument that creates a second balance sheet and a new regulatory perimeter to negotiate. For a bank's first digital-money product, tokenised deposits let you ship inside the perimeter you already operate in — stablecoin-adjacent use cases are a later, harder conversation, not a reason to delay what you can ship now.

Q: Why start with intrabank treasury rather than DvP or cross-bank PvP?

Sequencing by risk and dependency count. Intrabank treasury only requires the bank to trust its own controls — one legal entity, one ledger, approved group entities as counterparties. DvP and PvP both require coordinating external legs — a custodian or another bank — multiplying the legal, technical and commercial dependencies before the core control model is even proven. You want the hardest cross-institutional problems to be the second thing you solve, not the first.

Q: What would you cut if you had half the roadmap time?

Phase 3 (tokenised-asset DvP) and Phase 5 (broader connectivity) go first — DvP needs an external custody/asset partner outside the bank's control, and Phase 5 depends on industry infrastructure (Agorá, RLN) that isn't the bank's call alone. Phase 1 and Phase 2 stay fully protected, because that's where the actual client value and the reusable control model live.

Q: How do you know this solves a real client problem rather than being technology-led?

The starting point was four things treasury teams already complain about — trapped liquidity across time zones, cut-off-driven funding delays, manual reconciliation, fragmented visibility — not 'what can tokenisation do'. The test before scaling: does a pilot client's treasury team report a measurable reduction in idle cash or reconciliation hours. If not, the technology worked but the product didn't.

Q: Walk me through what happens if the tokenised ledger and core banking ledger disagree.

That's a reconciliation break, treated as a first-class operational event. Reconciliation runs continuously, so a break is detected within minutes, raised as an exception case with an SLA, and routed to operations with amount, entity and transaction reference. Client-facing balances never reflect the tokenised ledger's view until the break is resolved — settlement finality and ledger consistency are two separate guarantees, and you don't get to claim the first without the second.

Q: What's the difference between atomicity and legal finality, and why does it matter?

Atomicity is a technical property enforced by the settlement engine — both legs settle together or neither does. Legal finality is a jurisdictional legal question: at what point, under which law, is the transfer irrevocable, including in an insolvency. A platform can be technically perfect and still legally ambiguous if that hasn't been tested corridor by corridor — which is why technical atomicity is explicitly not treated as proof of legal finality, and production use requires a legal opinion per corridor first.

Q: How do you control an ERP or AI agent initiating payments automatically?

The same control discipline as a human initiator, enforced at the API layer rather than assumed at the UI layer: scoped API permissions, a policy engine enforcing payment limits, maker-checker approval an automated caller can't self-satisfy, a human escalation threshold, and an immutable audit trail. The risk isn't automation — it's a control model that only checks intent at a human-facing screen while a machine-facing API has a back door.

Q: What's the biggest risk you're not solving for yet?

Cross-jurisdictional legal finality at scale. The platform enforces atomicity and screening everywhere, but a legal opinion confirming finality has to be obtained corridor by corridor — a legal and governance bottleneck, not an engineering one. It's deliberately shown as 'Monitoring' rather than 'Effective' in the risk framework, because a technical control shouldn't imply a legal question is solved.

Q: How would a regulator's objection to something change the roadmap?

Depends what they object to. A corridor-specific issue (e.g. data residency) narrows Phase 2's corridor list without touching the model. A structural objection — say, atomic settlement not meeting their definition of finality — blocks Phase 3/4, not Phase 1, because Phase 1 never leaves a single legal entity. That's the real argument for the phased structure: a regulatory setback later doesn't retroactively invalidate the earlier phases.

Q: How does this make money?

Three components sequenced with the roadmap: retained operating balances (frictionless movement keeps higher average balances), a transaction/volume-based fee once cross-border corridors are live, and eventually a platform/participation model if it extends to multi-bank interoperability. Phase 1 deliberately doesn't need a fully worked pricing model — that's built out once there's a pilot to price against.

Q: What's your moat against Partior, Kinexys, or Citi Token Services?

Limited technical moat — atomic-settlement mechanics are converging industry-wide. The differentiator is distribution: an existing corporate treasury relationship, existing multi-entity KYC/entitlement base, existing correspondent-banking corridors a new entrant has to build from zero. That's why Phase 2 targets corridors the client already banks with the group in, not green-field expansion — the moat is in where you already have the client, not the ledger technology.

Q: What does success look like at the end of the pilot?

Not 'the technology worked' — that's necessary but not sufficient. At least one pilot client can point to a measurable liquidity or reconciliation-hours improvement, the exception/break rate stayed within SLA under real (not synthetic) volume, and Financial Crime, Legal and Operations sign off the control model held under real client behaviour. If those three don't all hold, it isn't ready to scale, however good the demo looks.

Q: What's the weakest part of this case study?

The success metrics are the categories to measure, not real production numbers — worth saying explicitly rather than implying otherwise. And the commercial model is directional, not costed — pricing a wholesale product properly needs Finance and real client willingness-to-pay data outside a real mandate. Volunteering this before being asked lands better than waiting for the interviewer to find it.

Q: If you got this mandate for real tomorrow, what's the first thing you'd do?

Talk to five corporate treasurers who already bank with HSBC across multiple entities, and find out whether 'trapped liquidity across time zones' is actually their top-three problem — or whether this is a solution to a problem an engineer would find interesting and a treasurer wouldn't rank in their top five. Everything in the case study is a hypothesis about their problem; the first real step is testing it against theirs.