defi-arbitrage/docs/settlement/as4/MEMBER_RULEBOOK_V1.md

DBIS AS4 Settlement Member Rulebook v1.0

Effective Date: 2026-01-19
Status: Active
Version: 1.0.0

---

1. Introduction

This rulebook defines the operational rules, rights, and obligations for members participating in the DBIS AS4 Settlement System. The system provides SWIFT-FIN equivalent instruction and confirmation flows (MT202/MT910 semantics) over a custom AS4 gateway, with settlement posting on the DBIS ledger (ChainID 138).

1.1 Purpose

The DBIS AS4 Settlement System enables:

• Final settlement institution operations
• Interbank settlement with instruction + confirmation flows
• Atomic debit/credit posting on DBIS ledger
• Regulatory-compliant, auditable settlement operations

1.2 Scope

This rulebook applies to:

• All member banks participating in AS4 settlement
• DBIS Settlement Institution (ledger authority)
• Governance/Operator entities

---

2. Membership and Onboarding

2.1 Eligibility

Members must:

• Be a licensed financial institution in their jurisdiction
• Complete KYC/KYB onboarding
• Accept this rulebook and legal agreements
• Obtain valid certificates from DBIS CA or recognized CA with pinning
• Maintain minimum capital requirements (as defined by capacity tier)

2.2 Capacity Tiers

• Tier 1: Central Banks
• Tier 2: Settlement Banks
• Tier 3: Commercial Banks
• Tier 4: Development Finance Institutions (DFIs)
• Tier 5: Special Entities

2.3 Onboarding Process

1. Submit inquiry via Sankofa Phoenix Marketplace
2. Complete qualification and risk assessment
3. Execute IRU Participation Agreement
4. Certificate issuance and configuration
5. Test environment access and certification
6. Production activation

---

3. Account Model

3.1 Member Settlement Accounts (MSAs)

DBIS maintains Member Settlement Accounts on the DBIS ledger:

• Each member has at least one MSA
• Optional: sub-accounts per currency/asset, per corridor, per risk partition
• Account identifiers: MSA:{MEMBER_ID}:{CURRENCY}

3.2 Posting Model

Settlement postings are atomic:

• Debit MSA(A) and Credit MSA(B) occur atomically
• Either both occur, or neither
• Record references: instruction ID, value date, currency, amount, fees, compliance tags

---

4. Message Semantics

4.1 Supported Message Types

Instruction Messages (value-bearing):

• DBIS.SI.202 - Interbank settlement instruction (SWIFT MT202 equivalent)
• DBIS.SI.202COV - Cover settlement instruction

Advice/Confirmation Messages (non-value-bearing):

• DBIS.AD.910 - Credit advice (SWIFT MT910 equivalent)
• DBIS.AD.900 - Debit advice (SWIFT MT900 equivalent)

Lifecycle/Controls:

• DBIS.ACK.RECEIPT - Business receipt
• DBIS.NAK.REJECT - Business rejection
• DBIS.ERR.INVESTIGATE - Investigation notification

4.2 Message Requirements

• All messages must include MessageId (UUIDv7 recommended)
• BusinessType must be from supported set
• CreatedAt must be UTC timestamp
• ReplayNonce required for anti-replay protection
• SchemaVersion must match supported versions

---

5. Settlement Finality

5.1 Finality States

• RECEIVED - Transport-level receipt
• ACCEPTED - Business validated
• QUEUED - Awaiting liquidity/compliance
• POSTED_PROVISIONAL - Posted but not yet final (optional)
• POSTED_FINAL - Final settlement
• REJECTED - Rejected with reason
• CANCELLED - Cancelled by member or system

5.2 Finality Rules

• Finality occurs when DBIS posts debit and credit atomically
• Finality is marked according to rulebook
• Once POSTED_FINAL, settlement is irreversible
• ChainID 138 anchoring provides additional tamper-evidence

---

6. Cutoffs and Value Dates

6.1 Cutoff Windows

• Configured per corridor
• Members must submit instructions before cutoff
• Cutoff violations result in rejection or next-day value date

6.2 Value Date Rules

• Value date must be >= current date
• Value date posting rules apply
• Same-day settlement for instructions received before cutoff
• Next-day settlement for instructions received after cutoff

---

7. Compliance and Controls

7.1 Sanctions Screening

• All instructions must pass sanctions screening
• Screening must complete before posting
• Evidence must be stored in WORM storage

7.2 AML/CTF

• AML/CTF checks required per jurisdiction
• Suspicious activity must be reported
• Evidence artifacts must be maintained

7.3 Audit Trail

Every instruction must have:

• Payload hash
• Signature evidence
• AS4 receipt evidence
• Posting reference (PostingId)
• Compliance package reference

---

8. Fees and Charges

8.1 Fee Structure

• Base subscription fee (per capacity tier)
• Per-transaction fees
• Liquidity fees (if applicable)
• Compliance fees (if applicable)

8.2 Charge Models

• BEN - Beneficiary pays
• SHA - Shared
• OUR - Ordering party pays

---

9. Disputes and Resolution

9.1 Dispute Process

1. Member submits dispute with evidence
2. Bilateral resolution attempt (7 days)
3. Escalation to DBIS arbitration (if needed)
4. Final resolution per DIAS framework

9.2 Repairs and Recalls

• Controlled by rulebook
• Require signed repair requests
• Require case IDs
• No "silent overrides"
• All exceptions must be evidence-backed

---

10. Operational Requirements

10.1 Availability

• System availability target: 99.9%
• Maintenance windows: Scheduled and communicated
• Emergency procedures: Defined in operational runbooks

10.2 Performance

• P99 end-to-end: < 2-5 seconds (depending on gates)
• Message throughput: As per capacity tier limits

10.3 Monitoring

• Members must monitor their AS4 endpoints
• Health checks required
• Incident reporting procedures defined

---

11. Security Requirements

11.1 Certificate Management

• Mutual TLS required
• Certificate pinning required
• Certificate rotation procedures defined
• HSM-backed keys for signing

11.2 Message Security

• Message-level signatures required (XMLDSig or JWS)
• Encryption required (XML Encryption or JWE)
• Non-repudiation of origin/receipt (NRO/NRR)
• Time sync (NTP with monitoring)

---

12. Termination

12.1 Member Termination

• 90-day notice period
• Settlement of all pending instructions
• Account closure procedures
• Certificate revocation

12.2 System Termination

• 180-day notice period
• Migration assistance provided
• Data retention per regulatory requirements

---

13. Amendments

This rulebook may be amended with:

• 30-day notice period
• Member consultation (for material changes)
• Version control and audit trail

---

14. Governing Law

• Disputes governed by DIAS framework
• Jurisdiction as per IRU Participation Agreement
• Regulatory compliance per member jurisdiction

---

End of Rulebook