# DBIS RTGS Depository and Custody Operating Model **Last updated:** 2026-03-29 **Purpose:** Implementation-grade operating model for the depository / CSD, global custodian, and custody / safekeeping / asset-servicing layers referenced by the DBIS RTGS canonical production checklist. ## 1. Scope This document freezes the intended runtime boundaries for: - `Depository / CSD layer` - `Global custodian layer` - `Custody / safekeeping / asset servicing flow` It does not claim these layers are already deployed. It defines the operating contract they must satisfy before they can be marked `Complete` in the canonical checklist. ## 2. Canonical role split ### Depository / CSD layer Owns: - authoritative asset register for in-scope instruments - issuance, transfer, pledge, lien, and release semantics - linkage between asset ownership state and RTGS settlement-touch state Does not own: - cash ledger posting - bank-message transport - treasury funding decisions ### Global custodian layer Owns: - safekeeping account hierarchy - sub-custody and global-bank/correspondent custody relationships - statements, confirmations, and servicing references Does not own: - canonical cash settlement - pricing or liquidity decisions - on-chain anchoring ### Custody / safekeeping / asset servicing flow Owns: - holdings lifecycle from registration to reporting - statement generation and custody evidence references - servicing events such as entitlement, transfer instruction, and post-settlement reporting Does not own: - participant master data - FX price formation - liquidity source selection ## 3. Canonical business objects | Object | Primary owner | Required downstream link | |--------|---------------|--------------------------| | `asset_position` | Depository / CSD | custody statement, settlement-touch reference | | `transfer_instruction` | Depository / CSD | RTGS orchestrator, OMNL posting reference | | `custody_account` | Global custodian | participant / office / account mapping | | `custody_statement` | Global custodian | reconciliation package, audit evidence | | `servicing_event` | Custody flow | holdings state, evidence package | | `settlement_touch_reference` | Depository / CSD | chain/off-ledger settlement evidence | ## 4. Required integrations ### Upstream - OMNL participant / office / treasury model - RTGS orchestrator correlation IDs - external institution master data ### Downstream - OMNL / Fineract postings - external bank statements or confirmations - Chain 138 settlement evidence where on-ledger finality is in scope - ISO 20022 / institutional evidence package ## 5. Canonical flow ```mermaid flowchart LR REQUEST["Transfer / Asset Instruction"] --> CSD["Depository / CSD"] CSD -->|"asset ownership update"| CUST["Global Custodian"] CSD -->|"settlement touch reference"| ORCH["RTGS Orchestrator"] ORCH -->|"cash posting"| OMNL["OMNL / Fineract"] ORCH -->|"bank or chain settlement"| SETTLE["Settlement Rail"] CUST -->|"statement / servicing output"| EVIDENCE["Evidence / Reconciliation"] OMNL --> EVIDENCE SETTLE --> EVIDENCE ``` ## 6. Minimum interface contract ### Depository asset-register and settlement-touch contract - Input: - participant reference - instrument reference - action type: issue / transfer / pledge / release - quantity / amount - correlation id - Output: - asset position id - settlement-touch reference - depository state - Failure contract: - reject with reason code and no settlement-touch reference ### Global custodian account/reporting contract - Input: - participant or sub-custody account reference - position or servicing reference - reporting period or event type - Output: - custody statement reference - servicing reference - reconciliation reference - Failure contract: - produce exception state with unresolved custody item ### Custody lifecycle contract - Input: - custody account reference - position reference - servicing action - correlation id - Output: - custody lifecycle state - statement/evidence reference - Failure contract: - unresolved servicing queue with operator-visible reason ## 7. Deployment expectations Before these layers can be considered active: 1. one implementation boundary must be selected for the depository role: - on-ledger - off-ledger - hybrid 2. one implementation boundary must be selected for the global custodian role 3. one canonical custody flow must be bound to OMNL and RTGS settlement 4. reconciliation outputs must include holdings and statement references ## 8. Production gate This operating model is complete only when: 1. one canonical asset flow uses the depository touch point 2. one canonical custody flow generates statements/evidence 3. holdings, settlement, and accounting reconcile in the same package 4. the canonical production checklist rows for these layers can move from `Planned` to `Partial` or `Complete` with evidence