Industry & regulatory knowledge

Blockchain

A shared, append-only digital ledger maintained across multiple computers rather than one central database, where new entries are cryptographically linked to and dependent on all prior entries — making the history very hard to alter after the fact without everyone noticing.

Example: Not every blockchain is public or permissionless. This case study's platform runs on a permissioned ledger — only approved bank entities can write to it, unlike a public network like Bitcoin or Ethereum that anyone can join.

DLT (Distributed Ledger Technology)

The broader category blockchain belongs to — any system where multiple parties keep synchronised copies of the same record, without one party unilaterally controlling it. Blockchain is one specific way to build a DLT; there are others (e.g. directed acyclic graphs) that don't chain blocks at all.

Example: When the JD or this case study says 'DLT-based settlement flows,' it's being deliberately broader than 'blockchain' — a bank might use permissioned DLT that technically isn't structured as a chain of blocks at all.

DvP (Delivery versus Payment)

A settlement mechanism where an asset only transfers if the corresponding payment settles at the same time — never one leg without the other. It exists specifically to remove the risk that a seller delivers an asset and then never gets paid, or a buyer pays and never receives the asset.

Example: On this case study's Bond DvP page: Meridian Asset Management's cash only leaves escrow the instant Horizon Capital Markets' bond units are confirmed available — if either check fails, neither leg moves, and both parties keep what they started with.

PvP (Payment versus Payment)

The FX equivalent of DvP — both currency legs of a foreign-exchange trade settle simultaneously, so neither counterparty is ever exposed to having paid out one currency without receiving the other. Removes what's called Herstatt risk (named after a 1974 German bank failure mid-settlement).

Example: On this case study's FX PvP page: Party A's USD and Party B's HKD only release together — if HKD liquidity isn't available, the USD leg is never released either, even though it was technically ready.

Atomic settlement

A technical guarantee that a set of linked actions either all complete together, or none of them do — there's no possible state where only some of them happened. DvP and PvP are both specific applications of atomicity to settlement.

Example: The 'Simulate exception' buttons on the Bond DvP and FX PvP pages exist specifically to demonstrate this: when one leg can't complete, the platform rolls back the other leg too, rather than leaving a half-finished trade.

Tokenised deposit

A digital representation of money a client already holds as a normal bank deposit — moving the token moves a claim on that same underlying deposit. It isn't a new form of money; it's an existing bank liability made programmable and instantly transferable.

Example: On this case study's Tokenised Treasury page, transferring a tokenised USD deposit between two entities doesn't create new money — it debits one entity's underlying account and credits the other's, just faster and with richer data than a traditional wire.

Smart contract

Code that runs automatically on a ledger when pre-agreed conditions are met, without needing a person to manually execute each step. Not a legal contract itself — a programmatic enforcement of terms that a legal contract separately governs.

Example: The atomic-settlement logic in this case study's DvP/PvP simulators is conceptually a smart contract: 'if funds check passes AND holdings check passes AND compliance passes, release both legs simultaneously; otherwise, release neither.'

Escrow (in a settlement context)

Holding an asset or payment in a neutral, conditional state — committed but not yet released to either party — until the conditions for final settlement are confirmed.

Example: In the atomic-settlement diagram on the Architecture page, both legs sit in escrow through the pre-settlement checks, and are only released together once every check clears.

Reconciliation break

A detected mismatch between two systems that are supposed to agree — e.g. a tokenised ledger showing one balance while the core banking system shows another. Not itself a failure of the platform; it's the control that catches when something has gone wrong upstream.

Example: This case study's risk framework treats a reconciliation break as a first-class operational event with its own SLA and exception case — not something quietly corrected later.

Legal finality

The point, under a specific jurisdiction's law, at which a transfer becomes irrevocable and enforceable against third parties — including in an insolvency. A separate question from whether a system is technically 'final' (i.e. atomic).

Example: This case study's risk framework deliberately keeps this control at 'Monitoring' status rather than 'Effective' — technical atomicity is real today, but a legal opinion confirming finality has to be obtained corridor by corridor before production use.

Maker-checker

A control requiring two different people (or systems) for any sensitive action — one to initiate ('maker'), a different one to approve ('checker') — so no single actor can both propose and authorise the same action.

Example: In this case study's Transfer wizard, the compliance-check step and the confirmation step are deliberately separated so a single user can't both initiate and self-approve a transfer.

New Product Approval (NPA)

A bank's internal governance process for reviewing and signing off a genuinely new product before launch — covering risk, legal, compliance, operations and technology, not just the commercial case.

Example: This case study's Risk & Controls page 'Governance' category (new-product approval, risk acceptance, control testing) is a simplified version of the real NPA process a bank would run before any of these products actually launched.

Orchestration (in a settlement platform)

The layer that sequences and coordinates calls to multiple underlying services in the correct order, so a client or downstream system can't skip a required step by calling a service directly.

Example: The Architecture page's 'Settlement Orchestration API' is exactly this — it forces every transfer through entitlement, screening and funds checks in order, rather than letting a caller jump straight to the ledger.

RTGS (Real-Time Gross Settlement)

Central-bank systems that settle high-value payments individually, in real time and in central-bank money — the benchmark 'gold standard' for settlement finality that most other systems are compared against.

Example: See the Industry & Regulatory Knowledge section above — RTGS (e.g. CHAPS, Fedwire) is why 'settlement finality' is treated as such a heavily scrutinised gate throughout this case study.