Each clause of Bangladesh Bank’s Guidelines on Partner Network is mapped to specific AEGIS capabilities, deployment architecture, and operational procedures.
| Section | BB Requirement | AEGIS Compliance | Status | Evidence / Notes |
|---|---|---|---|---|
| Chapter 2 — Network & Security Controls | ||||
| 2.1 | Segregation of Network — segregate from LAN/WAN, firewall per zone, monitor abnormal traffic | AEGIS deploys in Docker containers within the bank’s segregated network zone. No external network access required for scoring. Connector agent communicates only with CBS (internal) and Kafka (internal). All inter-service traffic uses dedicated Docker bridge networks. | Compliant | Docker Compose network isolation; Traefik ingress controls; Prometheus anomaly alerts |
| 2.2 | Change Management — controlled changes, documented process, audit trails | Immutable Docker images with semantic version tags. Every deployment is a new image; rollback by reverting to previous tag. All changes tracked in Git with signed commits. CI/CD pipeline enforces review gates. | Compliant | Git history; Docker image registry; CI/CD pipeline config |
| 2.2.2 | Rollback plans and pre/post-deployment testing | Blue-green deployment via Docker image tags. Post-deployment health check scripts validate all service endpoints. Automated rollback triggers on health check failure. Staging environment mirrors production for pre-deploy testing. | Compliant | Health check endpoints; deployment runbook; staging environment |
| 2.2.3 | Audit trails for all changes | Immutable audit log on TimescaleDB hypertables. Every scoring decision, alert action, rule change, and user login logged with full context. SHA-3 hash chain ensures log integrity and tamper detection. | Compliant | TimescaleDB audit_* tables; SHA-3 hash chain verification; Seq structured logging |
| 2.3 | Access Restrictions — no internet on extranet zone, no irrelevant apps, authorized personnel only | AEGIS servers require no internet access for operation. All components run internally within the bank DC. Wenme OAuth 2.1 authentication + Darwan RBAC enforce authorized-personnel-only access. No non-essential services installed. | Compliant | Wenme OAuth 2.1 integration; Darwan RBAC policies; minimal Docker images |
| 2.4 | Remote Connection Management — prevent unauthorized infiltration, encryption, integrity, logging | All remote access via bank’s VPN infrastructure. TLS 1.3 on all internal connections. mTLS between microservices. Full audit logging of all access sessions. Privileged access restricted from untrusted domains via Darwan policy. | Compliant | TLS 1.3 config; mTLS certificates; Darwan access policies; audit logs |
| 2.4.2 | Restrict privileged access from untrusted domains; document all remote access | Darwan RBAC enforces domain-based access policies. All remote sessions are logged with user identity, source IP, timestamp, and actions performed. Session recordings available via Seq structured log aggregation. | Compliant | Darwan domain trust policies; Seq session logs; access audit reports |
| Chapter 3 — Connectivity & Compliance | ||||
| 3.1 | Partner Network Connectivity — Category-A or Category-B: dual firewalls, routers, ISP links, DC + DR | AEGIS architecture supports both DC and DR deployment. Helm charts and Docker Compose configs are environment-agnostic. Database replication (PostgreSQL streaming replication) enables DR failover. Application is stateless, enabling instant multi-site deployment. | Bank Infra | Dual firewalls, routers, and ISP links are bank network infrastructure responsibilities. AEGIS provides application-level DR readiness. |
| 3.2 | Extranet Management — no unauthorized access/tampering, encrypt/decrypt data | All data encrypted in transit (TLS 1.3) and at rest (AES-256-GCM). Post-quantum cryptography via CRYSTALS-Kyber (key encapsulation) and CRYSTALS-Dilithium (digital signatures). No personal device access permitted. RBAC enforced at every API endpoint. | Compliant | TLS 1.3 certs; AES-256-GCM encryption; CRYSTALS-Kyber/Dilithium implementation |
| Section | BB Requirement | AEGIS Compliance | Status | Evidence / Notes |
|---|---|---|---|---|
| 3.2.2 | Documented security plan, security zones, firewalls | AEGIS deployment includes a documented security architecture with clear zone boundaries: DMZ (Traefik gateway), application zone (microservices), data zone (PostgreSQL, Redis, Kafka). Each zone has defined ingress/egress rules. | Compliant | Architecture design spec; Traefik ingress config; Docker network policies |
| 3.2.3 | Monitor logs, RBAC/time-based access | Centralized logging via Serilog to Seq. All API requests logged with correlation IDs. Darwan RBAC supports time-based access windows. Grafana dashboards provide real-time log monitoring and alerting. | Compliant | Seq log aggregation; Grafana dashboards; Darwan time-based policies |
| 3.2.4 | No personal devices, antivirus, change default passwords | AEGIS runs on dedicated server infrastructure only. Docker containers have no default passwords — all credentials generated per deployment. Container images scanned for vulnerabilities during CI. No end-user device access to core systems. | Compliant | Docker security scan reports; credential generation scripts; deployment guide |
| 3.2.5 | Filter traffic, disable unused ports | Traefik reverse proxy acts as application-level firewall. Only required ports exposed: HTTPS (443), gRPC (internal). Docker containers expose only necessary service ports. All unused ports blocked by default via Docker network configuration. | Compliant | Traefik routing rules; Docker port mappings; firewall rule documentation |
| 3.2.6 | Backup configs, no BB subnet advertised to LAN/WAN | All configuration stored as code in version-controlled repositories. Docker Compose and Helm chart configs are backed up with the codebase. AEGIS does not interact with BB subnets directly — operates entirely within bank DC. | Compliant | Git-versioned configs; Helm charts in deploy/; no BB subnet interaction |
| 3.3 | VPN Management — VPN connections to BB, compliant crypto algorithms, bank-managed VPN gateways | AEGIS operates entirely within the bank’s data center. No VPN needed for AEGIS itself. Bank manages VPN for BB connectivity separately. AEGIS cryptographic algorithms (CRYSTALS-Kyber, AES-256-GCM, SHA-3) exceed BB compliance requirements. | Bank Infra | VPN gateway is bank infrastructure. AEGIS crypto exceeds requirements per post-quantum standards. |
| 3.4 | Vulnerability Assessment — pre-deployment VA, periodic scans, remediation | Docker images built from minimal base images (Alpine/Debian slim). No dev tools or compilers in production images. Container images scanned via CI pipeline before deployment. Regular dependency audits via automated tooling (Go, Python, .NET, npm). | Compliant | Alpine/slim base images; CI vulnerability scan reports; dependency audit logs |
| 3.4.2 | Periodic vulnerability scans and remediation process | Automated dependency monitoring flags CVEs. Security patch SLA: critical within 24 hours, high within 72 hours. Remediation tracked in issue management system. Quarterly penetration testing supported. | Compliant | CVE monitoring alerts; patch SLA documentation; remediation tracking |
| 3.5 | Patch Management — regular patches, test before deploy, documented procedures | Automated dependency monitoring across all language stacks. Docker image rebuild for any patch. All patches tested in staging environment before production deployment. Documented patch management procedure included in operational runbook. | Compliant | Staging environment; patch runbook; Docker image versioning; CI/CD pipeline |
| Chapter 4 — Administration | ||||
| 4.1 | Extranet Administration — no shared crypto keys, preserve documentation/diagrams | Per-bank cryptographic keys generated independently. No shared keys between tenants (bank_id isolation). Complete architecture documentation, network diagrams, and deployment guides maintained in version control. | Compliant | Per-bank key generation; multi-tenant isolation; docs/ directory in repository |
| 4.1.3 | Device hardening | Docker containers run as non-root user. Minimal base images with no unnecessary packages. No SSH access to containers. Read-only root filesystem where possible. Capabilities dropped to minimum required set (no NET_RAW, no SYS_ADMIN). | Compliant | Dockerfile USER directives; Docker security options; capability drop config |
| Section | BB Requirement | AEGIS Compliance | Status | Evidence / Notes |
|---|---|---|---|---|
| 4.1.4 | Designated focal person + fallback for extranet operations | KaritKarma provides a designated support contact and a designated fallback contact for all AEGIS operations. SLA includes guaranteed response times: critical issues within 1 hour, standard issues within 4 hours. | Compliant | SLA agreement; KaritKarma support contacts; escalation matrix |
| 4.1.5 | Follow BB ICT Security guidelines | AEGIS architecture designed to comply with BB ICT Security Policy Framework. Post-quantum cryptography exceeds current BB requirements. All security controls are documented and auditable. Regular compliance reviews with bank security team. | Compliant | ICT Security compliance checklist; cryptographic standards documentation |
| 4.2 | Incident Reporting — report service interruptions to BB with details | Built-in monitoring via Prometheus + Grafana. Alert notifications via BitsPath (SMS, WhatsApp, Email, Push). Service health checks with automatic reporting. Incident report templates prepared for BB submission format. Automated uptime tracking and SLA compliance metrics. | Compliant | Prometheus metrics; Grafana dashboards; BitsPath alert config; incident report templates |
| Chapter 5 — SLA | ||||
| 5.1 | Service Level Agreement — written agreements with defined terms | KaritKarma provides a comprehensive SLA covering: 99.9% uptime guarantee, response time commitments, escalation procedures, maintenance windows, and penalty clauses. SLA is a formal written agreement signed by both parties. | Compliant | SLA document template; uptime monitoring via Prometheus; penalty clause framework |
| 5.1.2 | Redundant NSPs from BB-approved list | Network service provider selection is the bank’s responsibility. AEGIS is network-agnostic and operates over any provider. KaritKarma recommends dual-ISP configuration as per Category-A requirements. | Bank Infra | NSP selection is bank infrastructure responsibility. AEGIS deployment guide includes ISP redundancy recommendations. |
| Capability | Description | BB Relevance | Status | Benefit |
|---|---|---|---|---|
| Post-Quantum Crypto | CRYSTALS-Kyber (KEM) + CRYSTALS-Dilithium (signatures) + AES-256-GCM + SHA-3 | Exceeds 3.3 cryptographic algorithm requirements. Future-proofed against quantum computing threats. | Exceeds | 10+ year crypto shelf life |
| Multi-Tenant Isolation | Per-bank data isolation via bank_id columns and per-bank schemas in production | Supports 2.1 network segregation at the data layer. No cross-bank data leakage possible. | Exceeds | Consortium-ready architecture |
| Immutable Audit Chain | SHA-3 hash chain on TimescaleDB hypertables for tamper-evident logging | Exceeds 2.2.3 audit trail requirements. Cryptographic proof of log integrity. | Exceeds | Forensic-grade audit trail |
| FAPI 2.0 Authentication | Financial-grade API security with DPoP token binding, mTLS, and Pushed Authorization Requests | Exceeds 2.3 access restriction requirements. Banking-specific OAuth profile. | Exceeds | Financial-grade security |
Overall assessment of AEGIS compliance with Bangladesh Bank Guidelines on Partner Network, Version 1.0 (2026).
For questions about this compliance mapping, to schedule a joint compliance review with Bangladesh Bank, or to discuss AEGIS deployment for your institution, please contact our team.