Core banking for African institutions
One codebase runs every institution on the platform. What differs between a commercial bank, a cooperative and a credit-only microlender is configuration resolved at runtime, and the platform refuses to provision any of them beyond what their licence permits.
Where the platform actually is
A core banking platform is a serious claim and this one is part built. Presenting it as finished would be the fastest way to lose the conversation, so here is what runs today, what is being worked on, and what has not been started.
Running today
In progress
Not started
Licence-class provisioning
Choose a licence class and then try to switch on a capability it is not authorised for. The rules below are the ones in the platform's own control plane, and they are enforced on the server so that a crafted request cannot bypass what the screen shows.
Institution archetype
Capabilities requested
Deposit-taking is the line that matters most. A credit-only microlender, a buy-now-pay-later provider, an e-money issuer and a savings and investment house cannot hold current accounts, savings accounts or term deposits, and cannot be given a deposit-insurance scheme. The control plane refuses the request outright, so nothing is provisioned on the assumption that somebody will notice later.
Isolation between institutions
Institutions share the software and never the data. Which institution a request belongs to is derived from the authenticated realm and never asserted by the caller, so no header, query string or request body can change which institution a request belongs to.
Plane 01
One Keycloak realm per institution. A token issued by one realm is only ever valid for that institution and cross-realm tokens are rejected.
iss names the realm
a cross-realm token is rejected
Plane 02
Every request carries the institution it belongs to, resolved from the validated token. Every query is filtered by it, and no endpoint accepts a caller-supplied institution identifier as authority.
the institution is derived, never asserted
no institution resolved returns nothing
Plane 03
Partitioned per institution in PostgreSQL, with the core engine partitioned the same way behind the platform's own services. The engine is never exposed directly.
every row names its institution
reaching across is denied by default
Tier 1 control families
The specific regulator is configuration, because each institution carries its own regulatory profile. What does not vary is the control behind each expectation, and this is the mapping the platform's security model is written against.
| Regulatory expectation | Control in the platform |
|---|---|
| Strong customer and staff authentication | Multi-factor authentication, a second assurance level required for staff and for any movement of money, and phishing-resistant passkeys for privileged roles. |
| Segregation of duties and maker-checker | Maker-checker above configured thresholds. The same person cannot initiate and approve the same act. |
| Least privilege and role-based access | Role, scope and limit together. Reads are purpose-bound and service accounts hold the least privilege that works. |
| Complete, tamper-evident audit trail | Append-only audit recording who, what, when, on whose behalf and why, protected from every role in the institution, including its own administrators. |
| Data confidentiality and integrity | Encryption in transit and at rest, secrets held in a managed vault, and personal data minimised at the point of collection. |
| Customer and institution data segregation | The three isolation planes above, where a request that resolves to no institution returns nothing. |
| Change control and configuration governance | Configuration is versioned, validated and audited. Configuration is preferred to customisation, so no institution runs a fork. |
| Traceability and monitoring | Distributed tracing and structured logging alongside the audit trail, with no secrets or personal data written to logs. |
| Resilience of consequential actions | Confirmation before anything irreversible, and a defined reversal or correction path which is itself audited. |
The core engine
Apache Fineract keeps the double-entry record and runs the product mechanics. It sits behind an anti-corruption layer, so every client, whether a back-office screen, a mobile app or a partner system, only ever talks to the platform's own API in the platform's own language.
An institution is therefore never locked to the engine. If it has to change, the seam it changes behind is the one drawn on the day the platform was designed.
Deployment tiers
Supervisors differ on what separation they will accept, and so do boards. The same platform runs at three levels of isolation without a change of software.
Tier 01
The default. Shared engine and shared database server, with a dedicated database for the institution.
Tier 02
A dedicated PostgreSQL server for the institution, with the engine still shared.
Tier 03
A dedicated engine deployment and a dedicated server, for an institution whose supervisor requires a full infrastructure boundary.
On the platform
The test of a white-label platform is what the second institution costs. Adding one here is a configuration entry and a set of brand tokens, with no branch in the code and no fork of the product.
A savings and credit society in Lesotho and South Africa, and the platform's first customer.
A microlender, added as the proof that a second institution is a configuration exercise.
The platform's own reference institution, used to demonstrate every capability without touching a customer's data.
We would rather show you the control plane refusing an invalid provisioning than talk about it. A working session takes about an hour and you should bring the person who will have to answer for the controls.