إنتقل إلى المحتوى الرئيسي

🛡️ Compliance Architecture

BayanCore treats compliance as a core system constraint rather than an optional module. Saudi regulatory requirements (ZATCA, PDPL, NCA, CST) are enforced programmatically at the database, application, and infrastructure layers.


1. ZATCA Phase 2 Technical Enforcement

Electronic invoice compliance is governed by the Guardian Service, an isolated microservice that handles all cryptographic validation:

[ERPNext Invoice Save]
└── Programmatic Event Hook (Frappe)
└── Send payload to Guardian Service
├── Run schema check (UBL 2.1)
├── Verify BR-KSA business rules
├── Calculate invoice hash & generate XML
├── Generate Base64 TLV QR Code
└── Submit to ZATCA Fatoora API (Clearance/Reporting)
  • Cryptographic Stamping: The Guardian Service manages the private keys and cryptographic certificates (CSIDs) issued by ZATCA. It signs invoices using SHA-256 and ECDSA with secp256k1 curves.
  • Invoice Hash Chaining: Every invoice XML must contain the hash of the preceding invoice, forming a chronological chain. This prevents back-dating or deletion of invoices.
  • Local Validation Engine: The Guardian service hosts a local rules engine that validates invoices against ZATCA rules (such as checking if tax categories, buyer IDs, and VAT totals are mathematically correct) before attempting API submission.

2. PDPL Data Residency & Sovereignty

To enforce compliance with the Personal Data Protection Law (PDPL), the infrastructure is locked to domestic servers:

  • Zero Cross-Border Transfer: No customer database, document backup, search index, or AI token payload is allowed to transit servers outside Saudi Arabia. All services run on OCI Riyadh (primary) and OCI Jeddah (DR) regions.
  • Data Minimization & Encryption: Personally Identifiable Information (PII) is encrypted at rest using AES-256. Database tables containing user credentials or contact details are isolated.
  • Programmatic Data Purge: When a customer requests account deletion (Right to Erasure), the system triggers a cascading purge script that deletes the tenant's data across MariaDB, OpenSearch indexes, and caches, recording a signature of completion in the master audit log.

3. NCA & CST Security Alignments

We map our architecture to the National Cybersecurity Authority (NCA) Essential Cybersecurity Controls (ECC) and the Communications, Space and Technology Commission (CST) cloud classification requirements:

  • Secrets Protection (OCI Vault): Database passwords, Clerk API keys, and ZATCA CSID certificates are never stored in plain text or git repositories. They are encrypted and fetched at runtime from OCI Vault.
  • Micro-segmentation: Network Security Groups (NSGs) isolate database nodes, celery workers, and API gateways in private subnets, restricting traffic to specific ports (e.g. MariaDB is accessible only from the execution layer).
  • Immutability: Auditing systems use append-only database configurations combined with SHA-256 integrity hashing to detect logs modifications.