# IRU Qualification and Deployment Flow

## Overview

This document describes the complete end-to-end process for qualifying, onboarding, and deploying IRU (Irrevocable Right of Use) participation for the Digital Bank of International Settlements (DBIS). The flow covers the entire lifecycle from initial marketplace discovery through full deployment and ongoing monitoring via the Sankofa Phoenix portal.

**Related Documentation**:
- [IRU Participation Agreement](../legal/IRU_Participation_Agreement.md) - Master IRU Agreement
- [IRU Technical Architecture](../legal/IRU_Technical_Architecture_Proxmox_LXC.md) - Technical infrastructure
- [Foundational Charter IRU Excerpt](../legal/Foundational_Charter_IRU_Excerpt.md) - Constitutional foundation
- [Regulatory Positioning Memo](../legal/Regulatory_Positioning_Memo_CBs_DFIs.md) - Regulatory guidance

## Prerequisites

- Sankofa Phoenix marketplace is operational
- Phoenix portal is accessible
- DBIS core systems are operational
- Proxmox VE infrastructure is available
- Keycloak authentication service is operational
- Legal and compliance frameworks are established

## High-Level Process Flow

```mermaid
flowchart TD
    Start([Prospective Participant]) --> Phase1[Phase 1: Marketplace Discovery]
    Phase1 --> Phase2[Phase 2: Qualification Assessment]
    Phase2 -->|Qualified| Phase3[Phase 3: Agreement Execution]
    Phase2 -->|Not Qualified| Reject([Rejection with Feedback])
    Phase3 --> Phase4[Phase 4: Technical Onboarding]
    Phase4 --> Phase5[Phase 5: Infrastructure Deployment]
    Phase5 --> Phase6[Phase 6: Integration & Testing]
    Phase6 -->|Tests Pass| Phase7[Phase 7: Go-Live & Activation]
    Phase6 -->|Tests Fail| FixIssues[Fix Issues & Retest]
    FixIssues --> Phase6
    Phase7 --> Phase8[Phase 8: Ongoing Operations]
    Phase8 --> End([Active IRU Participant])
    
    style Phase1 fill:#e1f5ff
    style Phase2 fill:#fff4e1
    style Phase3 fill:#ffe1f5
    style Phase4 fill:#e1ffe1
    style Phase5 fill:#f5e1ff
    style Phase6 fill:#ffe1e1
    style Phase7 fill:#e1ffe1
    style Phase8 fill:#e1f5ff
```

---

## PHASE 1: MARKETPLACE DISCOVERY & INITIAL INQUIRY

### Overview

Prospective participants discover the DBIS IRU offering through the Sankofa Phoenix marketplace, submit initial inquiries, and provide preliminary information for qualification assessment.

### Visual Flow Diagram

```mermaid
sequenceDiagram
    participant PP as Prospective Participant
    participant SP as Sankofa Phoenix Marketplace
    participant Portal as Phoenix Portal
    participant DBIS as DBIS Sales Team
    participant System as Qualification System
    
    PP->>SP: Browse IRU Offerings
    SP->>PP: Display IRU Information
    Note over SP: IRU Details:<br/>- Capacity Tiers<br/>- Pricing<br/>- Technical Specs<br/>- Legal Framework
    PP->>SP: Select IRU Offering
    SP->>PP: Show Detailed Information
    PP->>SP: Submit Initial Inquiry
    SP->>System: Create Inquiry Record
    System->>DBIS: Notify Sales Team
    DBIS->>PP: Acknowledge Inquiry
    DBIS->>PP: Request Preliminary Information
    PP->>Portal: Create Portal Account (if needed)
    Portal->>PP: Account Created
    PP->>DBIS: Submit Preliminary Information
    DBIS->>System: Record Information
    System->>Phase2: Proceed to Qualification
```

### Step-by-Step Process

#### Step 1.1: Marketplace Browsing
1. Prospective participant accesses Sankofa Phoenix marketplace
2. Navigates to "Financial Infrastructure" or "DBIS" section
3. Reviews available IRU offerings:
   - IRU for Central Banks
   - IRU for Settlement Banks
   - IRU for Commercial Banks
   - IRU for Development Finance Institutions
   - IRU for Special Entities
4. Reviews offering details:
   - Capacity tier information
   - Pricing structure
   - Technical architecture overview
   - Legal framework summary
   - Regulatory positioning

#### Step 1.2: IRU Offering Selection
1. Participant selects appropriate IRU offering based on institutional type
2. Reviews detailed offering page:
   - Complete IRU Participation Agreement (draft)
   - Technical architecture documentation
   - Regulatory positioning memo
   - FAQ and support information
3. Downloads relevant documentation for internal review

#### Step 1.3: Initial Inquiry Submission
1. Participant clicks "Request Information" or "Apply Now" button
2. Fills out initial inquiry form:
   - Organization name
   - Institutional type
   - Contact information
   - Jurisdiction
   - Estimated transaction volume
   - Expected go-live timeline
3. Submits inquiry through marketplace

#### Step 1.4: Portal Account Creation (if needed)
1. System checks if participant has existing Phoenix portal account
2. If no account exists:
   - Participant receives invitation email
   - Clicks registration link
   - Creates account with:
     - Email address
     - Password (meets security requirements)
     - Organization information
     - Two-factor authentication setup
3. Account is provisioned in Keycloak
4. Participant receives portal access credentials

#### Step 1.5: Preliminary Information Collection
1. DBIS sales team acknowledges inquiry (within 24 hours)
2. Sends preliminary information request form via portal
3. Participant completes form with:
   - Legal entity information
   - Regulatory status
   - License information
   - Financial information (high-level)
   - Technical contact information
   - Compliance contact information
4. Participant uploads supporting documents:
   - Corporate registration
   - Regulatory licenses
   - Organizational chart
5. Information is recorded in qualification system

### Roles and Responsibilities

- **Prospective Participant**: Browse marketplace, submit inquiry, provide information
- **DBIS Sales Team**: Acknowledge inquiry, request information, initial qualification review
- **Phoenix Portal**: Account management, document storage, communication hub
- **Qualification System**: Record inquiry, track status, route to appropriate team

### SLA Targets

- Inquiry acknowledgment: 24 hours
- Portal account creation: 2 hours
- Preliminary information request: 48 hours
- Information review: 5 business days

### Error Handling

- **Marketplace unavailable**: Redirect to contact form, manual inquiry process
- **Portal registration failure**: Manual account creation by support team
- **Incomplete information**: Automated reminders, escalation to sales team
- **Duplicate inquiries**: Merge records, notify participant

---

## PHASE 2: QUALIFICATION & ELIGIBILITY ASSESSMENT

### Overview

DBIS conducts comprehensive qualification assessment to determine eligibility, appropriate capacity tier, usage profile, and regulatory compliance requirements.

### Visual Flow Diagram

```mermaid
sequenceDiagram
    participant System as Qualification System
    participant Sales as DBIS Sales Team
    participant Legal as Legal Team
    participant Compliance as Compliance Team
    participant Tech as Technical Team
    participant PP as Prospective Participant
    
    System->>Sales: Initial Qualification Review
    Sales->>System: Institutional Type Verified
    System->>Legal: Jurisdictional Law Review
    Legal->>System: Law Review Complete
    System->>Compliance: Regulatory Compliance Check
    Compliance->>System: Compliance Assessment
    System->>Tech: Technical Capability Assessment
    Tech->>System: Technical Assessment
    System->>System: Determine Capacity Tier
    System->>System: Classify Usage Profile
    System->>PP: Request Legal Opinion (if required)
    PP->>System: Submit Legal Opinion
    System->>Legal: Review Legal Opinion
    Legal->>System: Opinion Approved
    System->>Sales: Qualification Decision Ready
    Sales->>PP: Qualification Decision
    alt Qualified
        System->>Phase3: Proceed to Agreement
    else Not Qualified
        System->>PP: Rejection with Feedback
    end
```

### Step-by-Step Process

#### Step 2.1: Institutional Type Verification
1. Sales team reviews submitted information
2. Verifies institutional type against eligibility criteria:
   - **Tier 1**: Sovereign Central Banks
   - **Tier 2**: Settlement Banks
   - **Tier 3**: Commercial Banks
   - **Tier 4**: Development Finance Institutions
   - **Tier 5**: Special/Observer Entities
3. Validates supporting documentation:
   - Corporate registration certificates
   - Regulatory licenses
   - Organizational structure
4. Records verification in qualification system

#### Step 2.2: Capacity Tier Determination
1. System analyzes institutional characteristics:
   - Institutional type
   - Regulatory classification
   - Operational scope
   - Historical transaction volumes (if available)
2. Applies tier assignment criteria:
   - Tier 1: Central banks of sovereign states
   - Tier 2: Designated settlement banks
   - Tier 3: Licensed commercial banks
   - Tier 4: Multilateral development banks
   - Tier 5: Special purpose entities
3. Assigns preliminary capacity tier
4. Determines capacity allocation based on tier

#### Step 2.3: Usage Profile Classification
1. Analyzes projected usage patterns:
   - Transaction volume estimates
   - Frequency of access
   - Peak usage periods
   - Specialized requirements
2. Classifies usage profile:
   - **High-Volume**: High transaction volumes, frequent access
   - **Standard-Volume**: Moderate transaction volumes
   - **Low-Volume**: Infrequent or low-volume usage
   - **Specialized**: Specialized use cases
3. Records classification in system

#### Step 2.4: Regulatory Compliance Check
1. Compliance team reviews:
   - Regulatory licenses and authorizations
   - Regulatory standing (no sanctions, no restrictions)
   - Compliance with local banking regulations
   - AML/KYC program adequacy
   - Data protection compliance
2. Checks against sanctions lists:
   - OFAC sanctions
   - UN sanctions
   - EU sanctions
   - Other relevant sanctions lists
3. Verifies no regulatory restrictions on participation
4. Records compliance assessment

#### Step 2.5: Jurisdictional Law Review
1. Legal team reviews participant's jurisdiction:
   - Applicable local law
   - IRU term requirements under local law
   - Securities law implications
   - Capital control regulations
   - Foreign investment restrictions
   - Tax implications
2. Determines if legal opinion is required:
   - Complex jurisdictions: Required
   - Standard jurisdictions: May be required
   - Well-established jurisdictions: May not be required
3. Requests legal opinion from participant if required

#### Step 2.6: Legal Opinion Requirements
1. If legal opinion required:
   - DBIS sends legal opinion request template
   - Participant engages qualified local counsel
   - Counsel prepares legal opinion covering:
     - IRU term requirements under local law
     - Securities law classification
     - Capital control implications
     - Tax treatment
     - Regulatory approvals (if any)
   - Participant submits legal opinion
   - DBIS legal team reviews opinion
   - Approves or requests clarification

#### Step 2.7: Qualification Decision
1. System compiles all assessment results:
   - Institutional type: Verified
   - Capacity tier: Assigned
   - Usage profile: Classified
   - Regulatory compliance: Approved
   - Jurisdictional law: Reviewed
   - Legal opinion: Approved (if required)
2. Qualification decision made:
   - **Qualified**: All criteria met, proceed to agreement
   - **Conditionally Qualified**: Minor issues, proceed with conditions
   - **Not Qualified**: Significant issues, rejection with feedback
3. Decision communicated to participant:
   - Qualified: Proceed to agreement phase
   - Not Qualified: Detailed feedback, appeal process (if applicable)

### Qualification Checklist

- [ ] Institutional type verified
- [ ] Capacity tier determined
- [ ] Usage profile classified
- [ ] Regulatory compliance approved
- [ ] Jurisdictional law reviewed
- [ ] Legal opinion obtained (if required)
- [ ] Supporting documentation complete
- [ ] Qualification decision made
- [ ] Decision communicated to participant

### Roles and Responsibilities

- **DBIS Sales Team**: Initial review, coordination
- **Legal Team**: Jurisdictional law review, legal opinion review
- **Compliance Team**: Regulatory compliance check, sanctions screening
- **Technical Team**: Technical capability assessment
- **Qualification System**: Automated checks, decision support

### SLA Targets

- Institutional verification: 3 business days
- Regulatory compliance check: 5 business days
- Jurisdictional law review: 7 business days
- Legal opinion review: 5 business days (after submission)
- Qualification decision: 10 business days from complete information

### Error Handling

- **Incomplete documentation**: Request additional documents, pause timeline
- **Regulatory concerns**: Escalate to compliance officer, may require additional review
- **Legal opinion issues**: Request clarification or revised opinion
- **Appeal process**: Participant may appeal rejection with additional information

---

## PHASE 3: AGREEMENT NEGOTIATION & EXECUTION

### Overview

DBIS prepares customized IRU Participation Agreement based on qualification results, negotiates terms with participant, and executes the agreement.

### Visual Flow Diagram

```mermaid
sequenceDiagram
    participant Legal as DBIS Legal Team
    participant System as Agreement System
    participant PP as Participant
    participant Finance as Finance Team
    participant Exec as Executives
    
    Legal->>System: Generate Agreement Template
    System->>Legal: Customize for Jurisdiction
    Legal->>System: Set IRU Term (jurisdiction-respecting)
    Legal->>Finance: Calculate Fee Structure
    Finance->>System: Fee Schedule
    System->>PP: Send Agreement Draft
    PP->>PP: Internal Legal Review
    PP->>System: Request Changes (if any)
    System->>Legal: Review Change Requests
    Legal->>System: Approve/Reject Changes
    System->>PP: Final Agreement
    PP->>PP: Obtain Signatures
    PP->>System: Submit Executed Agreement
    System->>Legal: Verify Signatures
    Legal->>Exec: Executive Approval
    Exec->>System: Agreement Executed
    System->>PP: Confirmation & Registration
    System->>Phase4: Proceed to Technical Onboarding
```

### Step-by-Step Process

#### Step 3.1: Agreement Preparation
1. Legal team generates IRU Participation Agreement from master template
2. Customizes agreement for participant:
   - Participant name and details
   - Jurisdiction-specific terms
   - IRU term (jurisdiction-respecting, minimum 25 years)
   - Capacity tier and usage profile
   - Fee structure
   - Special provisions (if any)
3. Attaches exhibits:
   - Exhibit A: SaaS Modules Schedule
   - Exhibit B: Fee Schedule
   - Exhibit C: Technical Architecture
4. Prepares agreement package

#### Step 3.2: IRU Term Determination
1. Legal team reviews jurisdictional law requirements:
   - Minimum term under local law
   - Maximum term under local law
   - Standard term preferences
2. Determines IRU term:
   - If local law requires >25 years: Use local law term (max 99 years)
   - If local law requires <25 years: Use DBIS minimum (25 years) unless mandatory
   - If local law permits 25+ years: Use 25 years (DBIS standard)
3. Documents term determination rationale
4. Includes term in agreement

#### Step 3.3: Fee Structure Agreement
1. Finance team calculates fees based on:
   - Capacity tier
   - Usage profile
   - Resource requirements
   - Jurisdictional factors
2. Prepares fee schedule:
   - IRU Grant Fee (one-time)
   - Ongoing operational costs
   - Capacity-based fees
   - Support fees
3. Presents fee structure to participant
4. Negotiates if needed (within approved ranges)
5. Finalizes fee schedule

#### Step 3.4: Agreement Review and Negotiation
1. DBIS sends agreement draft to participant
2. Participant conducts internal review:
   - Legal review
   - Finance review
   - Technical review
   - Executive approval
3. Participant submits change requests (if any):
   - Minor clarifications
   - Jurisdiction-specific adjustments
   - Fee structure adjustments
4. DBIS legal team reviews change requests:
   - Approves standard changes
   - Negotiates non-standard changes
   - Rejects incompatible changes
5. Agreement finalized

#### Step 3.5: Agreement Execution
1. Participant obtains required signatures:
   - Authorized signatory
   - Witness (if required by local law)
   - Corporate seal (if required)
2. Participant submits executed agreement:
   - Scanned copy via portal
   - Original via secure courier
3. DBIS verifies signatures:
   - Signature authentication
   - Authority verification
   - Document completeness
4. DBIS obtains executive approval
5. DBIS executes agreement
6. Both parties receive executed copies

#### Step 3.6: Agreement Registration
1. System registers agreement:
   - Agreement ID assigned
   - Effective date determined
   - Registration in DBIS registry
   - IRU record created
2. Participant receives confirmation:
   - Agreement registration number
   - Effective date
   - Next steps information
3. Agreement stored in secure repository
4. Proceed to technical onboarding

### Agreement Execution Checklist

- [ ] Agreement customized for participant
- [ ] IRU term determined (jurisdiction-respecting)
- [ ] Fee structure agreed
- [ ] Agreement reviewed by participant
- [ ] Change requests resolved
- [ ] Agreement executed by participant
- [ ] Agreement executed by DBIS
- [ ] Agreement registered in system
- [ ] Effective date confirmed
- [ ] Confirmation sent to participant

### Roles and Responsibilities

- **DBIS Legal Team**: Agreement preparation, customization, negotiation
- **Finance Team**: Fee structure calculation, negotiation
- **Participant Legal Team**: Agreement review, change requests
- **Executives**: Final approval and execution
- **Agreement System**: Document management, registration

### SLA Targets

- Agreement preparation: 5 business days
- Fee structure calculation: 3 business days
- Agreement review period: 10 business days
- Change request resolution: 5 business days
- Agreement execution: 3 business days after finalization
- Agreement registration: 1 business day

### Error Handling

- **Signature issues**: Request re-execution, verify authority
- **Missing documents**: Request missing pages or exhibits
- **Jurisdictional conflicts**: Legal team consultation, may require amendment
- **Fee disputes**: Escalate to finance leadership, negotiate resolution

---

## PHASE 4: TECHNICAL ONBOARDING

### Overview

DBIS technical team gathers requirements, assesses network connectivity, sets up security infrastructure, and prepares for infrastructure deployment.

### Visual Flow Diagram

```mermaid
sequenceDiagram
    participant Tech as DBIS Technical Team
    participant PP as Participant Technical Team
    participant Portal as Phoenix Portal
    participant Keycloak as Keycloak
    participant Security as Security Team
    participant Network as Network Team
    
    Tech->>PP: Technical Requirements Gathering
    PP->>Tech: Submit Technical Information
    Tech->>Network: Network Connectivity Assessment
    Network->>Tech: Connectivity Plan
    Tech->>Security: Security Requirements Review
    Security->>Tech: Security Plan
    Tech->>Keycloak: Create User Accounts
    Keycloak->>Portal: Provision Access
    Tech->>Security: Key Management Setup
    Security->>Tech: Keys Generated
    Tech->>Security: Certificate Provisioning
    Security->>Tech: Certificates Issued
    Tech->>Portal: Configure Portal Access
    Portal->>PP: Access Credentials
    Tech->>PP: Technical Onboarding Complete
    Tech->>Phase5: Proceed to Deployment
```

### Step-by-Step Process

#### Step 4.1: Technical Requirements Gathering
1. DBIS technical team contacts participant technical team
2. Conducts technical requirements assessment:
   - Network connectivity requirements
   - Bandwidth requirements
   - Latency requirements
   - Security requirements
   - Integration requirements
   - Compliance requirements
3. Collects technical information:
   - Network architecture
   - Firewall configurations
   - VPN requirements
   - API integration needs
   - Monitoring requirements
4. Documents requirements in technical specification

#### Step 4.2: Network Connectivity Assessment
1. Network team assesses connectivity options:
   - Direct connection (if applicable)
   - VPN connection
   - Internet-based connection
   - Dedicated circuits
2. Determines network architecture:
   - IP addressing scheme
   - Routing requirements
   - Firewall rules
   - Network segmentation
3. Creates network connectivity plan
4. Coordinates with participant network team

#### Step 4.3: Security Requirements Review
1. Security team reviews security requirements:
   - Authentication mechanisms
   - Authorization requirements
   - Encryption requirements
   - Key management
   - Certificate requirements
   - Audit logging
2. Determines security architecture:
   - mTLS configuration
   - Key rotation policies
   - Certificate lifecycle
   - Access control
3. Creates security plan
4. Coordinates with participant security team

#### Step 4.4: Key Management Setup
1. Security team generates cryptographic keys:
   - Node keys for Besu Sentry
   - API keys for FireFly
   - TLS certificates
   - Authentication keys
2. Stores keys securely:
   - Key management system
   - Encrypted storage
   - Access controls
   - Backup procedures
3. Provisions keys to participant:
   - Secure key delivery
   - Key installation instructions
   - Key rotation schedule
4. Documents key management procedures

#### Step 4.5: Certificate Provisioning
1. Security team provisions certificates:
   - TLS certificates for mTLS
   - API certificates
   - Service certificates
2. Configures certificate lifecycle:
   - Validity periods
   - Renewal procedures
   - Revocation procedures
3. Issues certificates to participant
4. Documents certificate management

#### Step 4.6: Access Credentials Issuance
1. Keycloak team creates user accounts:
   - Primary technical contact
   - Secondary contacts
   - Administrative users
   - Monitoring users
2. Configures access roles:
   - Technical administrator
   - Operator
   - Viewer
   - Auditor
3. Issues access credentials:
   - Username/password
   - Two-factor authentication setup
   - API tokens (if needed)
4. Provides access instructions

#### Step 4.7: Phoenix Portal Access Configuration
1. Portal team configures participant access:
   - Organization profile
   - User accounts
   - Dashboard access
   - Monitoring access
   - Support access
2. Sets up portal features:
   - Service status dashboard
   - Performance metrics
   - Log access
   - Support tickets
   - Documentation access
3. Tests portal access
4. Provides portal access credentials

### Technical Onboarding Checklist

- [ ] Technical requirements gathered
- [ ] Network connectivity assessed
- [ ] Security requirements reviewed
- [ ] Key management setup complete
- [ ] Certificates provisioned
- [ ] Access credentials issued
- [ ] Portal access configured
- [ ] Technical onboarding documentation complete
- [ ] Participant technical team trained

### Roles and Responsibilities

- **DBIS Technical Team**: Requirements gathering, coordination
- **Network Team**: Network connectivity assessment, configuration
- **Security Team**: Security review, key management, certificates
- **Keycloak Team**: User account management
- **Portal Team**: Portal access configuration
- **Participant Technical Team**: Provide information, coordinate

### SLA Targets

- Technical requirements gathering: 5 business days
- Network connectivity assessment: 3 business days
- Security review: 5 business days
- Key management setup: 3 business days
- Certificate provisioning: 2 business days
- Access credentials issuance: 1 business day
- Portal configuration: 2 business days

### Error Handling

- **Network connectivity issues**: Troubleshoot, alternative connectivity options
- **Security concerns**: Additional security measures, enhanced monitoring
- **Key management failures**: Regenerate keys, update procedures
- **Certificate issues**: Reissue certificates, update configuration

---

## PHASE 5: INFRASTRUCTURE DEPLOYMENT

### Overview

DBIS deploys Proxmox VE LXC containers, configures network infrastructure, deploys Besu Sentry, FireFly Core, and database services, and applies security hardening.

### Visual Flow Diagram

```mermaid
sequenceDiagram
    participant Tech as DBIS Technical Team
    participant Proxmox as Proxmox VE
    participant Network as Network Team
    participant Security as Security Team
    participant Monitor as Monitoring Team
    
    Tech->>Proxmox: Provision LXC Containers
    Proxmox->>Tech: Containers Created
    Tech->>Network: Configure Network (VLANs/Bridges)
    Network->>Tech: Network Configured
    Tech->>Proxmox: Deploy Besu Sentry Node
    Proxmox->>Tech: Besu Deployed
    Tech->>Proxmox: Deploy FireFly Core
    Proxmox->>Tech: FireFly Core Deployed
    Tech->>Proxmox: Deploy FireFly Database
    Proxmox->>Tech: Database Deployed
    Tech->>Proxmox: Deploy Monitoring Services
    Proxmox->>Tech: Monitoring Deployed
    Security->>Proxmox: Apply Security Hardening
    Security->>Tech: Hardening Complete
    Tech->>Monitor: Configure Monitoring
    Monitor->>Tech: Monitoring Active
    Tech->>Phase6: Proceed to Testing
```

### Step-by-Step Process

#### Step 5.1: Proxmox VE LXC Container Provisioning
1. Technical team provisions LXC containers:
   - `lxc-besu-sentry-01` (and -02 for HA)
   - `lxc-firefly-core-01` (and -02 for HA)
   - `lxc-firefly-db-01`
   - `lxc-monitoring-01`
2. Configures container resources:
   - CPU allocation (pinned for Besu)
   - RAM allocation
   - Disk allocation
   - Network interfaces
3. Applies container templates
4. Verifies container creation

#### Step 5.2: Network Configuration
1. Network team configures network infrastructure:
   - VLAN 10: Management network
   - VLAN 20: Private services network (FireFly/DB)
   - VLAN 30: Sentry DMZ (Besu P2P/RPC)
2. Creates Proxmox bridges:
   - `vmbr0`: Management + WAN
   - `vmbr1`: Private service network
   - `vmbr2`: Sentry DMZ
3. Assigns IP addresses:
   - Management: 10.10.10.0/24
   - Services: 10.20.20.0/24
   - DMZ: 10.30.30.0/24
4. Configures DNS:
   - Internal DNS records
   - Service discovery
5. Tests network connectivity

#### Step 5.3: Besu Sentry Node Deployment
1. Technical team deploys Besu Sentry:
   - Installs Besu binary (version-pinned)
   - Configures P2P interface
   - Configures RPC interface (restricted)
   - Sets up node keys
   - Configures TLS certificates
2. Configures Besu settings:
   - Network ID
   - Genesis block
   - P2P peer configuration
   - RPC allowlist
   - Performance tuning
3. Creates systemd service
4. Starts Besu service
5. Verifies P2P connectivity

#### Step 5.4: FireFly Core Deployment
1. Technical team deploys FireFly Core:
   - Installs FireFly binary (version-pinned)
   - Configures event listener
   - Configures transaction orchestrator
   - Sets up API endpoints
   - Configures mTLS
2. Configures FireFly settings:
   - Besu RPC endpoint
   - Database connection
   - API configuration
   - Event subscription
   - Performance tuning
3. Creates systemd service
4. Starts FireFly service
5. Verifies connectivity to Besu and DB

#### Step 5.5: FireFly Database Deployment
1. Technical team deploys FireFly Database:
   - Installs PostgreSQL
   - Creates database
   - Creates user accounts
   - Configures network access
   - Enables required extensions
2. Runs database migrations:
   - FireFly schema
   - Initial data
   - Indexes
3. Configures database:
   - Performance tuning
   - Backup configuration
   - Replication (if HA)
4. Tests database connectivity

#### Step 5.6: Monitoring Services Deployment
1. Technical team deploys monitoring:
   - Installs monitoring agents
   - Configures metrics collection
   - Configures log shipping
   - Sets up alerting
2. Configures monitoring:
   - Metrics endpoints
   - Log aggregation
   - Alert thresholds
   - Dashboard configuration
3. Integrates with Phoenix portal
4. Tests monitoring functionality

#### Step 5.7: Security Hardening
1. Security team applies hardening:
   - Host-level hardening (Proxmox)
   - Container-level hardening
   - Network hardening (firewall rules)
   - Secrets management
   - Certificate rotation procedures
2. Implements security controls:
   - Default deny firewall rules
   - mTLS enforcement
   - Access controls
   - Audit logging
   - Intrusion detection
3. Verifies security configuration
4. Documents security procedures

#### Step 5.8: Resource Allocation
1. Technical team allocates resources:
   - CPU quotas
   - RAM limits
   - Disk quotas
   - Network bandwidth
2. Monitors resource usage
3. Adjusts allocations as needed
4. Documents resource allocation

### Deployment Checklist

- [ ] LXC containers provisioned
- [ ] Network configured (VLANs, bridges, DNS)
- [ ] Besu Sentry deployed and configured
- [ ] FireFly Core deployed and configured
- [ ] FireFly Database deployed and configured
- [ ] Monitoring services deployed
- [ ] Security hardening applied
- [ ] Resource allocation configured
- [ ] All services verified operational

### Roles and Responsibilities

- **DBIS Technical Team**: Container provisioning, service deployment
- **Network Team**: Network configuration, connectivity
- **Security Team**: Security hardening, compliance
- **Monitoring Team**: Monitoring configuration, alerting
- **Proxmox Infrastructure**: Container hosting, resource management

### SLA Targets

- Container provisioning: 2 business days
- Network configuration: 1 business day
- Besu deployment: 1 business day
- FireFly deployment: 1 business day
- Database deployment: 1 business day
- Monitoring deployment: 1 business day
- Security hardening: 2 business days
- Total deployment: 5-7 business days

### Error Handling

- **Container provisioning failures**: Retry, alternative hosts, escalate
- **Network configuration issues**: Troubleshoot, alternative configurations
- **Service deployment failures**: Rollback, fix issues, redeploy
- **Security hardening failures**: Additional measures, enhanced monitoring

---

## PHASE 6: INTEGRATION & TESTING

### Overview

DBIS conducts comprehensive testing including connectivity, API integration, end-to-end transactions, performance, security, and acceptance testing.

### Visual Flow Diagram

```mermaid
sequenceDiagram
    participant Tech as DBIS Technical Team
    participant PP as Participant Technical Team
    participant System as Test Systems
    participant Security as Security Team
    participant Monitor as Monitoring Team
    
    Tech->>System: System Connectivity Testing
    System->>Tech: Connectivity Verified
    Tech->>System: API Integration Testing
    System->>Tech: API Tests Pass
    Tech->>System: End-to-End Transaction Testing
    System->>Tech: E2E Tests Pass
    Tech->>System: Performance Testing
    System->>Tech: Performance Verified
    Security->>System: Security Testing
    Security->>Tech: Security Tests Pass
    Tech->>PP: Acceptance Testing
    PP->>Tech: Acceptance Sign-Off
    Tech->>Monitor: Monitoring Verification
    Monitor->>Tech: Monitoring Verified
    Tech->>Phase7: Proceed to Go-Live
```

### Step-by-Step Process

#### Step 6.1: System Connectivity Testing
1. Technical team tests connectivity:
   - Besu Sentry P2P connectivity
   - FireFly to Besu RPC connectivity
   - FireFly to Database connectivity
   - External network connectivity
   - VPN connectivity (if applicable)
2. Verifies network paths:
   - All required flows operational
   - Firewall rules correct
   - DNS resolution working
   - Service discovery functional
3. Documents test results
4. Fixes any connectivity issues

#### Step 6.2: API Integration Testing
1. Technical team tests API integration:
   - FireFly API endpoints
   - Authentication/authorization
   - Request/response formats
   - Error handling
   - Rate limiting
2. Tests API scenarios:
   - Successful requests
   - Invalid requests
   - Authentication failures
   - Authorization failures
   - Rate limit handling
3. Verifies API documentation accuracy
4. Documents test results

#### Step 6.3: End-to-End Transaction Testing
1. Technical team conducts E2E testing:
   - Transaction submission
   - Event processing
   - Ledger posting
   - Settlement confirmation
   - Error scenarios
2. Tests transaction types:
   - Payment transactions
   - Settlement transactions
   - Multi-asset transactions
   - Cross-border transactions
3. Verifies transaction integrity:
   - Data consistency
   - Audit trails
   - Reconciliation
4. Documents test results

#### Step 6.4: Performance Testing
1. Technical team conducts performance testing:
   - Load testing
   - Stress testing
   - Latency testing
   - Throughput testing
2. Measures performance metrics:
   - Transaction latency
   - Throughput (TPS)
   - Resource utilization
   - Network performance
3. Verifies performance meets SLAs:
   - <100ms settlement target
   - Required throughput
   - Resource efficiency
4. Documents performance results

#### Step 6.5: Security Testing
1. Security team conducts security testing:
   - Penetration testing
   - Vulnerability scanning
   - Access control testing
   - Encryption verification
   - Certificate validation
2. Tests security scenarios:
   - Unauthorized access attempts
   - Malformed requests
   - Injection attacks
   - Network attacks
3. Verifies security controls:
   - Firewall rules
   - mTLS enforcement
   - Access controls
   - Audit logging
4. Documents security test results

#### Step 6.6: Acceptance Testing
1. Technical team prepares acceptance test plan
2. Participant technical team reviews test plan
3. Conducts acceptance testing:
   - Participant executes test scenarios
   - Verifies functionality
   - Validates performance
   - Confirms security
4. Participant provides feedback:
   - Issues identified
   - Concerns raised
   - Sign-off or conditions
5. Resolves any issues
6. Participant signs off on acceptance

#### Step 6.7: Monitoring Verification
1. Monitoring team verifies monitoring:
   - Metrics collection
   - Log aggregation
   - Alert configuration
   - Dashboard functionality
   - Portal integration
2. Tests monitoring scenarios:
   - Service health monitoring
   - Performance monitoring
   - Error detection
   - Alert generation
3. Verifies portal access:
   - Dashboard access
   - Metrics visibility
   - Log access
   - Alert notifications
4. Documents monitoring setup

### Testing Checklist

- [ ] System connectivity tested
- [ ] API integration tested
- [ ] End-to-end transactions tested
- [ ] Performance tested and verified
- [ ] Security tested and verified
- [ ] Acceptance testing completed
- [ ] Participant sign-off obtained
- [ ] Monitoring verified
- [ ] All issues resolved

### Roles and Responsibilities

- **DBIS Technical Team**: Test execution, issue resolution
- **Security Team**: Security testing
- **Monitoring Team**: Monitoring verification
- **Participant Technical Team**: Acceptance testing, sign-off

### SLA Targets

- Connectivity testing: 1 business day
- API integration testing: 2 business days
- E2E testing: 3 business days
- Performance testing: 2 business days
- Security testing: 3 business days
- Acceptance testing: 5 business days
- Total testing: 10-15 business days

### Error Handling

- **Test failures**: Fix issues, retest, escalate if needed
- **Performance issues**: Optimize, retest, adjust resources
- **Security issues**: Remediate, retest, enhanced monitoring
- **Acceptance issues**: Address concerns, negotiate, resolve

---

## PHASE 7: GO-LIVE & ACTIVATION

### Overview

DBIS activates production environment, confirms IRU effective date, enables service availability, processes initial transactions, and hands off to support.

### Visual Flow Diagram

```mermaid
sequenceDiagram
    participant Tech as DBIS Technical Team
    participant System as Production Systems
    participant PP as Participant
    participant Support as Support Team
    participant Monitor as Monitoring Team
    participant Legal as Legal Team
    
    Tech->>System: Activate Production Environment
    System->>Tech: Production Active
    Legal->>System: Confirm IRU Effective Date
    System->>Tech: Effective Date Confirmed
    Tech->>System: Enable Service Availability
    System->>PP: Service Available Notification
    PP->>System: Submit Initial Transaction
    System->>PP: Transaction Processed
    Monitor->>System: Activate Monitoring
    Monitor->>Tech: Monitoring Active
    Tech->>Support: Support Handoff
    Support->>PP: Support Contact Information
    Tech->>PP: Go-Live Complete
    Tech->>Phase8: Proceed to Operations
```

### Step-by-Step Process

#### Step 7.1: Production Environment Activation
1. Technical team activates production:
   - Final system checks
   - Service startup
   - Health verification
   - Connectivity confirmation
2. Verifies all services operational:
   - Besu Sentry: Running, connected
   - FireFly Core: Running, connected
   - FireFly Database: Running, accessible
   - Monitoring: Active, collecting
3. Confirms production readiness
4. Documents activation

#### Step 7.2: IRU Effective Date Confirmation
1. Legal team confirms IRU effective date:
   - Agreement execution date
   - Conditions precedent met
   - Effective date calculation
2. System records effective date:
   - IRU term start date
   - IRU term end date
   - Renewal dates
3. Notifies participant of effective date
4. Updates IRU registry

#### Step 7.3: Service Availability Confirmation
1. Technical team confirms service availability:
   - All services operational
   - Network connectivity confirmed
   - API endpoints accessible
   - Portal access functional
2. Sends service availability notification:
   - Service status
   - Access information
   - Support contacts
   - Documentation links
3. Participant confirms receipt
4. Service officially available

#### Step 7.4: Initial Transaction Processing
1. Participant submits initial transaction:
   - Test transaction (if desired)
   - First production transaction
   - Transaction monitoring
2. System processes transaction:
   - Validation
   - Processing
   - Settlement
   - Confirmation
3. Verifies transaction success:
   - Transaction confirmed
   - Ledger updated
   - Reconciliation passed
4. Confirms successful processing

#### Step 7.5: Monitoring Activation
1. Monitoring team activates monitoring:
   - Real-time monitoring active
   - Alerts configured
   - Dashboards available
   - Portal integration complete
2. Verifies monitoring functionality:
   - Metrics collection
   - Log aggregation
   - Alert generation
   - Dashboard updates
3. Participant accesses portal:
   - Dashboard view
   - Metrics review
   - Log access
   - Alert configuration
4. Confirms monitoring operational

#### Step 7.6: Support Handoff
1. Technical team hands off to support:
   - Support documentation
   - Known issues
   - Escalation procedures
   - Contact information
2. Support team contacts participant:
   - Introduction
   - Support procedures
   - Contact methods
   - Response times
3. Provides support information:
   - Support portal access
   - Ticket system
   - Emergency contacts
   - Documentation
4. Confirms support handoff complete

### Go-Live Checklist

- [ ] Production environment activated
- [ ] IRU effective date confirmed
- [ ] Service availability confirmed
- [ ] Initial transaction processed successfully
- [ ] Monitoring activated and verified
- [ ] Support handoff complete
- [ ] Participant notified
- [ ] Go-live documentation complete

### Roles and Responsibilities

- **DBIS Technical Team**: Production activation, service confirmation
- **Legal Team**: Effective date confirmation
- **Support Team**: Support handoff, ongoing support
- **Monitoring Team**: Monitoring activation
- **Participant**: Initial transaction, confirmation

### SLA Targets

- Production activation: 1 business day
- Effective date confirmation: Same day
- Service availability: Same day
- Initial transaction: Within 24 hours
- Monitoring activation: Same day
- Support handoff: Same day

### Error Handling

- **Activation failures**: Rollback, troubleshoot, reactivate
- **Service issues**: Immediate support, rapid resolution
- **Transaction failures**: Troubleshoot, reprocess, verify
- **Monitoring issues**: Alternative monitoring, rapid fix

---

## PHASE 8: ONGOING OPERATIONS & MONITORING

### Overview

Participant accesses Phoenix portal for monitoring, DBIS provides ongoing support and maintenance, conducts regular reviews, and ensures continuous service availability.

### Visual Flow Diagram

```mermaid
sequenceDiagram
    participant PP as Participant
    participant Portal as Phoenix Portal
    participant Monitor as Monitoring Systems
    participant Support as Support Team
    participant Tech as Technical Team
    participant Compliance as Compliance Team
    
    PP->>Portal: Access Monitoring Dashboard
    Portal->>Monitor: Retrieve Metrics
    Monitor->>Portal: Real-Time Metrics
    Portal->>PP: Display Dashboard
    PP->>Portal: Review Performance
    PP->>Portal: Access Logs
    PP->>Portal: Configure Alerts
    alt Issue Detected
        PP->>Support: Submit Support Ticket
        Support->>Tech: Escalate if Needed
        Tech->>Support: Resolution
        Support->>PP: Issue Resolved
    end
    Support->>PP: Regular Health Checks
    Compliance->>PP: Compliance Reviews
    Tech->>PP: Performance Reviews
```

### Step-by-Step Process

#### Step 8.1: Phoenix Portal Monitoring Access
1. Participant accesses Phoenix portal:
   - Login with credentials
   - Two-factor authentication
   - Dashboard access
2. Views monitoring dashboard:
   - Service health status
   - Performance metrics
   - Transaction statistics
   - Error rates
   - Resource utilization
3. Accesses additional features:
   - Log viewer
   - Alert configuration
   - Support tickets
   - Documentation
   - Reports
4. Configures monitoring preferences:
   - Alert thresholds
   - Notification methods
   - Dashboard customization
   - Report schedules

#### Step 8.2: Service Health Monitoring
1. Monitoring systems continuously monitor:
   - Service availability
   - Response times
   - Error rates
   - Resource usage
   - Network performance
2. Generates alerts for:
   - Service outages
   - Performance degradation
   - Error spikes
   - Resource exhaustion
   - Security events
3. Participant receives alerts:
   - Email notifications
   - Portal notifications
   - SMS (for critical alerts)
4. Participant reviews and responds to alerts

#### Step 8.3: Performance Monitoring
1. Monitoring systems track performance:
   - Transaction latency
   - Throughput (TPS)
   - Success rates
   - Resource efficiency
   - Network performance
2. Generates performance reports:
   - Daily performance summary
   - Weekly performance trends
   - Monthly performance analysis
   - SLA compliance reports
3. Participant reviews performance:
   - Dashboard metrics
   - Performance reports
   - Trend analysis
   - SLA compliance
4. Identifies optimization opportunities

#### Step 8.4: Compliance Monitoring
1. Compliance systems monitor:
   - Regulatory compliance
   - AML/KYC compliance
   - Data protection compliance
   - Audit trail completeness
2. Generates compliance reports:
   - Compliance status
   - Audit reports
   - Regulatory reports
   - Exception reports
3. Participant reviews compliance:
   - Compliance dashboard
   - Compliance reports
   - Audit trails
   - Exception handling
4. Ensures ongoing compliance

#### Step 8.5: Support and Maintenance
1. Support team provides ongoing support:
   - Ticket management
   - Issue resolution
   - Technical assistance
   - Documentation updates
2. Maintenance activities:
   - Regular updates
   - Security patches
   - Performance optimizations
   - Capacity adjustments
3. Communication:
   - Maintenance notifications
   - Update announcements
   - Best practices
   - Training materials
4. Participant engagement:
   - Support requests
   - Feedback submission
   - Feature requests
   - Training requests

#### Step 8.6: Regular Reviews and Assessments
1. DBIS conducts regular reviews:
   - Quarterly service reviews
   - Annual performance reviews
   - Capacity reviews
   - Security assessments
2. Participant participates in reviews:
   - Service feedback
   - Performance feedback
   - Improvement suggestions
   - Issue escalation
3. Reviews cover:
   - Service performance
   - SLA compliance
   - Capacity utilization
   - Security posture
   - Compliance status
4. Implements improvements:
   - Performance optimizations
   - Capacity adjustments
   - Security enhancements
   - Process improvements

### Operations Checklist

- [ ] Portal access configured and tested
- [ ] Monitoring dashboard accessible
- [ ] Alerts configured and tested
- [ ] Support procedures documented
- [ ] Maintenance schedule established
- [ ] Review schedule established
- [ ] Documentation accessible
- [ ] Training completed

### Roles and Responsibilities

- **Participant**: Portal access, monitoring, support requests
- **DBIS Support Team**: Ticket management, issue resolution
- **DBIS Technical Team**: Maintenance, updates, optimizations
- **DBIS Compliance Team**: Compliance monitoring, reporting
- **Monitoring Systems**: Continuous monitoring, alerting

### SLA Targets

- Portal availability: 99.9%
- Support response time: 4 hours (standard), 1 hour (critical)
- Issue resolution: 24 hours (standard), 4 hours (critical)
- Maintenance windows: Scheduled, 4 hours advance notice
- Review frequency: Quarterly service reviews, annual performance reviews

### Error Handling

- **Portal access issues**: Alternative access methods, support escalation
- **Monitoring failures**: Alternative monitoring, manual checks
- **Support issues**: Escalation procedures, management involvement
- **Service issues**: Incident response, rapid resolution, communication

---

## Integration Points

### Sankofa Phoenix Marketplace
- **Purpose**: Initial discovery, offering selection, inquiry submission
- **Integration**: Web interface, API for inquiry submission
- **Data Flow**: Inquiry data → Qualification system

### Phoenix Portal
- **Purpose**: Account management, document storage, communication, monitoring
- **Integration**: Keycloak authentication, monitoring APIs, document management
- **Data Flow**: Bidirectional - user actions, system updates, monitoring data

### DBIS Core Systems
- **Purpose**: IRU management, service provisioning, transaction processing
- **Integration**: API integration, database integration, service integration
- **Data Flow**: IRU data, service configuration, transaction data

### Proxmox VE Infrastructure
- **Purpose**: Container hosting, resource management, network management
- **Integration**: Proxmox API, container management, network configuration
- **Data Flow**: Deployment commands, status updates, resource metrics

### Keycloak
- **Purpose**: Authentication, authorization, user management
- **Integration**: OAuth2/OIDC, user provisioning, role management
- **Data Flow**: Authentication requests, user data, access tokens

### Monitoring Systems
- **Purpose**: Service monitoring, performance tracking, alerting
- **Integration**: Metrics collection, log aggregation, alert management
- **Data Flow**: Metrics, logs, alerts → Portal, Support systems

### Support Systems
- **Purpose**: Ticket management, issue tracking, knowledge base
- **Integration**: Portal integration, email integration, API integration
- **Data Flow**: Support tickets, issue updates, resolution data

---

## Error Handling and Exception Flows

### Qualification Rejection
- **Flow**: Phase 2 → Rejection notification → Appeal process (optional) → End
- **Handling**: Detailed feedback, appeal process, alternative options
- **Documentation**: Rejection reasons, appeal procedures

### Agreement Negotiation Failure
- **Flow**: Phase 3 → Negotiation failure → Alternative terms or termination
- **Handling**: Mediation, alternative proposals, graceful termination
- **Documentation**: Negotiation history, failure reasons

### Technical Onboarding Issues
- **Flow**: Phase 4 → Technical issues → Extended timeline or alternative solutions
- **Handling**: Technical support, alternative approaches, timeline adjustment
- **Documentation**: Issue logs, resolution procedures

### Deployment Failures
- **Flow**: Phase 5 → Deployment failure → Rollback → Retry or alternative
- **Handling**: Rollback procedures, issue resolution, alternative deployment
- **Documentation**: Deployment logs, failure analysis, resolution

### Testing Failures
- **Flow**: Phase 6 → Test failure → Issue resolution → Retest
- **Handling**: Issue identification, resolution, retesting, acceptance
- **Documentation**: Test results, issue logs, resolution procedures

### Go-Live Issues
- **Flow**: Phase 7 → Go-live issues → Immediate support → Resolution
- **Handling**: Rapid response, issue resolution, service restoration
- **Documentation**: Incident logs, resolution procedures, post-mortem

### Ongoing Operations Issues
- **Flow**: Phase 8 → Service issues → Support escalation → Resolution
- **Handling**: Support procedures, escalation, resolution, communication
- **Documentation**: Support tickets, resolution logs, improvement plans

---

## Performance Metrics

### Phase Timelines
- **Phase 1**: 1-2 weeks
- **Phase 2**: 2-4 weeks
- **Phase 3**: 2-4 weeks
- **Phase 4**: 1-2 weeks
- **Phase 5**: 1-2 weeks
- **Phase 6**: 2-3 weeks
- **Phase 7**: 1 week
- **Phase 8**: Ongoing
- **Total Timeline**: 10-18 weeks (typical)

### SLA Targets
- Inquiry acknowledgment: 24 hours
- Qualification decision: 10 business days
- Agreement preparation: 5 business days
- Technical onboarding: 10 business days
- Infrastructure deployment: 5-7 business days
- Testing: 10-15 business days
- Go-live: 1 business day
- Support response: 4 hours (standard), 1 hour (critical)

### Success Metrics
- Qualification approval rate: Target >80%
- Agreement execution rate: Target >90%
- Deployment success rate: Target >95%
- Testing pass rate: Target >90%
- Go-live success rate: Target >95%
- Participant satisfaction: Target >4.0/5.0

---

## Security Considerations

### Authentication and Authorization
- Multi-factor authentication required
- Role-based access control
- Principle of least privilege
- Regular access reviews

### Data Protection
- Encryption in transit (TLS)
- Encryption at rest
- Secure key management
- Data privacy compliance

### Network Security
- Network segmentation
- Firewall rules
- mTLS enforcement
- Intrusion detection

### Audit and Compliance
- Comprehensive audit logging
- Regular security assessments
- Compliance monitoring
- Incident response procedures

---

## Testing Scenarios

### Qualification Testing
- Valid institutional types
- Invalid institutional types
- Regulatory compliance scenarios
- Jurisdictional law scenarios

### Agreement Testing
- Standard agreements
- Jurisdiction-specific agreements
- Fee structure variations
- Term variations

### Deployment Testing
- Standard deployment
- High availability deployment
- Multi-region deployment
- Disaster recovery scenarios

### Integration Testing
- API integration
- Database integration
- Network integration
- Monitoring integration

### Performance Testing
- Load testing
- Stress testing
- Latency testing
- Throughput testing

### Security Testing
- Penetration testing
- Vulnerability scanning
- Access control testing
- Encryption verification

---

## Related Documentation

- [IRU Participation Agreement](../legal/IRU_Participation_Agreement.md)
- [IRU Technical Architecture](../legal/IRU_Technical_Architecture_Proxmox_LXC.md)
- [Foundational Charter IRU Excerpt](../legal/Foundational_Charter_IRU_Excerpt.md)
- [Regulatory Positioning Memo](../legal/Regulatory_Positioning_Memo_CBs_DFIs.md)
- [DBIS Architecture Atlas](../architecture-atlas-overview.md)
- [GPN Payment Flow](./gpn-payment-flow.md)
- [M-RTGS Settlement Flow](./m-rtgs-settlement-flow.md)

---

**END OF FLOW DOCUMENT**