Search public guides, tools, and curriculum pages.

RWA Product Architecture

Trading, Transfer and Settlement

Separate an agreement to trade, token transfer and final exchange of obligations.

What you will learn

  • Distinguish trading from settlement
  • Identify transfer restrictions and settlement failures

AI-assisted educational manuscript. The trade and deadlines are fictional; no market access is offered.

Learning objectives

  • Distinguish agreement, transfer instruction and completed settlement.
  • Map delivery-versus-payment dependencies.
  • Explain why linked settlement reduces a particular risk without removing all risk.

A trade creates obligations; settlement discharges them

Trading establishes an agreed exchange under its rules. Transfer is an instruction or record change involving an asset. Settlement is the discharge of the transaction's obligations through the relevant delivery and payment processes. A product can support one stage without completing all of them.

The CPMI-IOSCO Principles for Financial Market Infrastructures distinguish legal basis, settlement finality, settlement money and linked obligations. Principle 12 describes exchange-of-value settlement designed so final settlement of one obligation occurs if and only if final settlement of the linked obligation occurs, addressing principal risk. The principles do not claim that all credit, liquidity, legal or operational risks disappear. BIS: PFMI overview

Use that distinction as an analytical benchmark, not as a claim that a classroom simulator is a compliant financial market infrastructure.

Worked example: delivery before payment

Imagine a buyer agrees to purchase 100 fictional fund units at 20 currency units each, for 2,000. In an unlinked process, the seller transfers all units first. The buyer then fails to pay. The seller has delivered the asset while remaining exposed to receiving the full purchase price. That is the principal exposure the linked design tries to avoid.

Now imagine a teaching mechanism that reserves the seller's 100 units and the buyer's 2,000 settlement units, checks eligibility and releases both legs together only if both are valid. If the buyer has only 1,900, neither leg completes. This prevents the specific one-leg completion in the model. It does not prove that the settlement units are worth the promised currency or that an external register recognizes the delivery.

Agreement: 100 × 20 = 2,000
  ↓
Check seller's units + buyer's payment + permissions
  ├─ one leg unavailable → no final exchange; release under recovery rules
  └─ both valid → linked completion → reconcile governing records

Suppose the asset token changes hands atomically with a stablecoin, but the stablecoin's redemption is later suspended. The code-level exchange may have worked while the buyer's payment asset has a separate economic or redemption problem. Distinguish atomic execution from money quality and legal finality.

Identify the actual boundary

Ask which ledger records the asset, which system records payment, what “final” means in each, and who resolves a disagreement. A blockchain confirmation count is a technical convention; it should not silently be used as a legal conclusion. If external asset records or bank transfers remain outside the atomic operation, name that limitation.

Liquidity is another prerequisite. An exchange can require both sides to fund before settlement. That can reduce one exposure while creating a need for available cash or assets. A buyer unable to fund may fail before completion; reservation can also tie up resources until expiry or cancellation. Define those transitions and preserve evidence.

Operational rules matter as much as the normal exchange: stale price, expired eligibility, paused participant, unavailable payment asset, duplicate instruction and timeout should have explicit outcomes. Record agreement time, instruction time, recognized finality and reconciliation separately.

Common misconceptions

“The trade was matched, so it settled.” An agreement is not proof of delivery and payment.

“Atomic means risk-free.” Payment-asset, legal and operational risks can remain outside the atomic boundary.

“Continuous trading means continuous external settlement.” The underlying systems may have different availability and finality conditions.

Risks and limits

PFMI is an international standard for relevant infrastructures; this lesson does not certify implementation or decide applicability. Actual instruments, jurisdictions, payment arrangements and venue rules determine the real obligations. The numerical reservation mechanism is invented and does not execute a financial transaction.

Exercise and answer

Exercise: The seller has 100 units, the price is 20, and the buyer has 1,900. In the stated linked model, should the asset leg complete?

Answer: No. Required payment is 2,000. Completing only the asset leg would violate the model's linked-settlement condition. Any reservation should follow its documented expiry or release process.

Continue in product architecture with redemption and servicing. Later engineering lessons compare settlement assets, while Labs expose failure states.

Source map

bis-pfmi: CPMI-IOSCO principles published in 2012, including Principles 1, 8, 9 and 12; international standard, directly read on 2026-10-18. The units, prices and reservation protocol are original teaching assumptions. No legal finality, financial infrastructure compliance or live settlement was verified.

Check your understanding

Preparing knowledge-check controls…

A linked model needs 2,000 payment but the buyer has 1,900. Should the asset leg finish?

Your answer stays in this tab. No account or persistent completion record is created.

Source evidence

Bank for International Settlements · CPMI-IOSCO · International infrastructure standard; applicability and legal implementation require specific review

Principles for financial market infrastructures — overview

Retrieved: 2026-10-18 · VERIFIED OFFICIAL · VERIFIED

Related learning and research

Back to curriculum outline

Report an editorial correction · [email protected]

Include the page or chapter ID, the exact statement and supporting sources. Your email app opens; this site sends nothing. Do not include account details, balances, identity documents or private keys.