proxmox/docs/03-deployment/DBIS_RTGS_DEPOSITORY_AND_CUSTODY_OPERATING_MODEL.md

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

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