Regulatory Compliance

Built-In, Not Bolted On

Regulatory reporting in African banking is not optional and not simple. Cross-border payment controls, prudential reporting, credit risk provisioning, and data protection are daily operational realities — yet most mid-market core banking platforms leave compliance entirely to the bank’s custom development.

ID.Banking ships with South African regulatory compliance built into the platform architecture, from transaction capture through report submission. No third-party add-ons, no custom middleware, no manual extraction.

Regulatory Framework Coverage

FinSurv / Balance of Payments Reporting

Every cross-border transaction processed by a South African Authorised Dealer must be reported to SARB with the correct Balance of Payments category code. This is a legal obligation under Exchange Control Regulations.

ID.Banking handles the full chain:

flowchart LR
  A[Customer BoP Capture] --> B[Allowance Validation]
  B --> C[Ops Approval]
  C --> D[Payment Execution]
  D --> E[FinSurv Report Generation]
  E --> F[SARB Submission]

1. Customer BoP capture — Category code selection integrated into the payment initiation flow
2. Allowance validation — SDA (R2M) and FIA (R10M) per customer per calendar year, tracked automatically
3. Ops approval workflow — Transactions exceeding thresholds route to compliance officers
4. Payment execution — Approved transactions process through the appropriate payment rail
5. FinSurv report generation — Automated generation in SARB’s prescribed format
6. Submission — Report delivery to SARB via the FinSurv gateway

Inward payment release (suspense → classification → release) is handled natively. No competitor at the mid-market tier offers end-to-end FinSurv compliance.

SARB BA Returns

The South African Reserve Bank requires licensed banks to submit monthly and quarterly returns covering capital adequacy, liquidity, credit exposure, and concentration risk. These BA returns (BA100, BA200, BA300 series) require data extraction across accounts, loans, investments, and off-balance-sheet items.

ID.Banking’s event-driven architecture streams all transactional data into a star-schema data warehouse with SCD2 dimensions. BA return data points are pre-computed as warehouse aggregations, eliminating the manual reconciliation that consumes compliance teams at most banks.

• BA100 (Capital adequacy): Extracted from ledger balances and risk-weight classifications
• BA200 (Liquidity): Real-time position data from treasury and ledger modules
• BA300 (Credit risk): Loan portfolio data with IFRS 9 staging and provisioning

IFRS 9 — Expected Credit Loss

IFRS 9 requires banks to recognize credit losses based on forward-looking expected loss models rather than incurred loss. ID.Banking implements the three-stage classification model:

The lending engine calculates PD (Probability of Default), LGD (Loss Given Default), and EAD (Exposure at Default) parameters, applies forward-looking macroeconomic scenarios, and generates provisioning entries directly in the ledger. No external provisioning tool required.

Stage migration triggers are configurable per product type and updated as payment behavior changes in real time.

POPIA — Data Protection

The Protection of Personal Information Act requires that personal data be processed lawfully, minimally, and with appropriate security safeguards. For banks, this means:

• Data residency: All personal information stays within South African infrastructure boundaries. Self-hosted deployment guarantees this by architecture, not by contract.
• Consent management: Customer consent records are captured at onboarding and tracked through the customer lifecycle.
• Data lifecycle: Retention policies are enforced at the platform level. Automated purge schedules remove data beyond regulatory retention periods.
• Access controls: Role-based access with audit trails on every data access event.
• Breach notification: Event streaming enables real-time detection of anomalous access patterns.

SaaS-only platforms (Thought Machine, Mambu, 10x) require banks to rely on contractual guarantees for data residency. ID.Banking’s self-hosted model provides architectural certainty — data never leaves infrastructure the bank controls.

Jurisdiction Portability

The regulatory reporting architecture separates compliance into three layers, enabling expansion to new African markets without re-engineering:

flowchart TB
  subgraph L1["Layer 1 — Core Data Collection (jurisdiction-agnostic)"]
    direction LR
    E["Event Streaming"]
    DW["Data Warehouse"]
  end
  subgraph L2["Layer 2 — Regulatory Rules Engine (configurable)"]
    direction LR
    TH["Thresholds"]
    CAT["Category Codes"]
    LIM["Allowance Limits"]
  end
  subgraph L3["Layer 3 — Report Generation (pluggable)"]
    direction LR
    ZA["SARB / FinSurv"]
    NG["CBN / NIBSS"]
    KE["CBK"]
  end
  L1 --> L2 --> L3

Layer 1 — Core Data Collection (jurisdiction-agnostic): Transaction, customer, and account data captured via event streaming into the data warehouse. Identical regardless of jurisdiction.

Layer 2 — Regulatory Rules Engine (configurable): Reporting thresholds, allowance limits, BoP category codes, and approval triggers are configuration — not code. Switching jurisdictions means loading new reference data.

Layer 3 — Report Generation & Submission (pluggable): Each jurisdiction implements the IRegulatorySubmission facade. South Africa submits to SARB/FinSurv. Nigeria submits to CBN/NIBSS. Kenya submits to CBK. New jurisdictions require a new adapter — typically 2–4 weeks of effort.

Multi-tenant deployments can run different jurisdictions simultaneously — tenant A under SARB/FinSurv rules, tenant B under CBK rules — from a single platform deployment.

Competitive Gap

No mid-market core banking platform ships with built-in South African regulatory reporting. Temenos handles FinSurv via expensive add-on modules. Thought Machine, Mambu, 10x, and Tuum leave regulatory reporting entirely to bank implementation teams. Fineract has no regulatory reporting capability.

ID.Banking is the only platform where compliance is a product feature, not a consulting engagement.