Safety-Critical Security Architecture
Defense in depth for financial infrastructure. Zero-trust networking, multi-tenant isolation, and immutable audit trails.
Architecture for Security
| Layer | Mechanism | Status |
|---|---|---|
| Gateway | API gateway with TLS termination, rate limiting, and authentication middleware | Implemented |
| Application | Tenant context injected by gateway (X-Tenant-ID), never trusted from caller. OAuth2 client_credentials per tenant. | Implemented |
| Database | Row-Level Security per tenant. Non-superuser role for all application queries. | Implemented |
Zero public exposure of core banking services. Reads execute directly against the finance service; writes route through the durable execution engine.
Data Protection
| Encryption at rest | Database tablespace encryption, ledger engine file-level encryption |
| Encryption in transit | TLS 1.3 at the gateway, isolated internal network for service-to-service communication |
| Data isolation | Per-tenant RLS, tenant-scoped API keys |
| Audit trail | SHA-256 hash-chained audit events (FINMA Circ. 2023/1, DORA Art. 11) |
| Retention | Configurable per jurisdiction (GoBD: 10 years, HGB §257) |
Regulatory Alignment
| Regulation | Status | How ISAAC Addresses It |
|---|---|---|
| FINMA (Swiss Banking Act) | Architecture supports | Operational risk management (Circular 2018/3), ICT resilience (Circular 2023/1), client asset segregation. Designed to support FINMA requirements, subject to formal audit. |
| AMLO-FINMA | Architecture supports | AML screening, KYC/KYB, CDD policy engine, blacklist management. Swiss anti-money laundering ordinance. |
| Swiss Banking Act (BankG) | Architecture supports | Client fund segregation, safeguarding accounts, e-money licensing framework (Art. 7-9). |
| DORA (2022/2554) | Architecture supports | Minimal dependency chain (~30 transitive deps), durable execution journal, hash-chained audit, deterministic restart. Designed to support DORA requirements, subject to formal audit. |
| PSD2 (2015/2366) | Architecture supports | SCA via OAuth2, value date tracking (Art. 87), R-transaction taxonomy (Art. 71, 76). Designed to support PSD2 requirements for SEPA operations, subject to formal audit. |
| PSD3/PSR | Monitoring | VoP and fraud liability not yet implemented. Gap analysis completed. |
| EMD2 (2009/110) | Architecture supports | Safeguarding account types, float isolation, e-money account model. Designed to support EMD2 requirements, subject to formal audit. |
| AMLD5/6 | Architecture supports | AML screening, KYC/KYB, CDD policy engine, blacklist management. Designed to support AML5/6 requirements, subject to formal audit. |
| DSG / GDPR | Designed for | Data minimization, right to erasure (soft-delete with audit), processing records. Swiss DSG and EU GDPR. |
| NIS2 (2022/2555) | Monitoring | Incident reporting and supply chain assessment planned. |
| IPR (2024/886) | Planned | SEPA Instant architecture defined. 10-second SLA, 24/7 availability pending. |
Isaac provides architectural foundations aligned with Swiss regulations (FINMA, AMLO-FINMA) and EU regulations (DORA, PSD2) simultaneously. The platform is jurisdiction-adaptable and can be configured for additional regulatory frameworks. Certification requires formal audit.
Supply Chain Transparency
| Financial core service | ~15 external dependencies, ~30 transitive |
| Durable workflow engine | Minimal curated dependencies, auditable dependency graph |
| Management interface | Larger dependency tree, but not in the critical financial path |
FINMA Circ. 2023/1 (ICT third-party risk, Switzerland) and DORA Art. 15 (EU): ICT third-party risk assessment for all critical providers. The financial core is built on a high-performance systems stack with a deliberately minimal dependency footprint.
Incident Response and Recovery
Every state-changing operation is journaled by the durable execution engine. Recovery after a failure means replaying the journal from the last checkpoint. No manual intervention required for transient infrastructure failures.
The ledger engine uses a replicated write-ahead log with 128-bit end-to-end checksums and strict serializability. Continuous archiving provides database-level backup. Ledger-native replication provides engine-level redundancy. No scheduled maintenance windows for the ledger (designed for 24/7 operation).
What We Do Not Yet Have
- SOC 2 Type II certification: planned, not yet obtained.
- ISO 27001 certification: planned, not yet obtained.
- Penetration test report: scheduled, not yet completed.
- PCI-DSS: not applicable (no card data stored directly).
We publish this section because transparency about our current state is more valuable than claiming certifications we do not hold.