Architecture overview

This page describes NEXCLARA's architecture for an institution's architecture and security teams: what separates one institution's data from the others', what separates the operation of the platform from borrowers' data, and which components it relies on.

Two separate planes

The control plane has its own database, its own operators and its own interface contract. Its operators have no ordinary account in an institution's space. It issues signed commands that the instance pulls itself and acknowledges; it does not read applications. Exceptional support access follows the regime set in the institution's contract: prior consent from one of its administrators, or notification with a right to object before the deadline. It goes through a separate support identity, read-only, bounded in time and scope; the institution can end it at any moment, and every consultation is logged on its side.

Isolation of each institution

In the data plane, each institution has its own space, and isolation is enforced at three independent levels:

1. one database schema per institution;
2. row-level security enabled and forced on every table of the institution, for reads as well as writes;
3. an institution context carried by the transaction, removed by the database itself at the end of each transaction.

The application connects with a role that can neither bypass these rules nor modify an audit record. These properties are checked at every integration: an isolation test suite passes with the application role, then the same suite must fail with a privileged role, which proves that it really tests something. A resource of another institution responds exactly like a resource that does not exist.

Standard components

The platform relies only on standard interfaces: PostgreSQL, Redis (optional) and containers. S3-compatible object storage is planned by the architecture, but none is used yet: uploaded files are kept in the institution's database. No proprietary service of a cloud provider is used, and an automated check verifies it. The full stack starts and runs on a closed network, without any mandatory outbound call.

The web interface is a server-side intermediary: the browser never sees the session token, which is kept in a protected cookie. The API neither reads nor issues cookies: it receives a bearer token (see Authentication).

Deployment modes

The architecture provides for four modes: shared service, service dedicated to one institution, deployment on the institution's infrastructure, and a hybrid mode. Moving from one mode to another is a matter of configuration, not of business code.

What is still under construction

• only a shared deployment is in service, in a pre-production environment on synthetic data; no banking production environment is in service;
• the control plane has been online since 2026-10-15, in validation and production, reserved for NEXCLARA operators behind a gateway; it drives only part of the operations described above so far;
• no hosting site in the WAEMU is selected, and no hosting provider certification is verified;
• neither signed images nor an installation guide for a deployment on the institution's infrastructure.