Information system

An architecture describes components. An information system describes how they hold together: where you enter, who does what, what is computed at the centre, what is retained, and what flows out. That is the view an auditor, a regulator or a future successor asks for — and it is the one most often missing.

Access channels

Six ways in, a single system behind them. The web application and the two mobile applications serve the counter; the branch portal gives each point of sale its own space; the customer portal opens lookup and tracking; the administration interface stays separate from the other three.

None of these doors owns its data. They all read and write into the same foundation — which is what makes any gap between what a teller sees and what their director sees impossible.

System users

Your specification defines eleven roles. The map above shows the ten profiles that access the system directly; the table below sets out, for the main ones, the data responsibility attached to them — not merely screen rights.

The rule that binds them: whoever enters never approves. Above a configurable threshold, a second signature is required — and it is recorded.

The six module families

They cut the system into clean boundaries: financial operations, network and treasury, finance and accounting, risk and compliance, data and intelligence, configuration and administration.

This split is not a presentation convenience — these are the internal boundaries of the code and the layout of the repository you will receive. Each module is detailed on its own page.

The core: the shared services layer

This is the level diagrams most often omit, and the one that decides the coherence of the whole. Business rules engine, ACID transaction management, workflows, notifications, documents, messaging, reporting, cache.

Each of these services is written once and called by the six families. A commission rule therefore exists in a single place: changing it changes it everywhere, with no need to remember which modules used it.

Data: written once, read many

Not all AiO data is alike. Confusing the kinds is the mistake that produces those systems where the dashboard shows one figure and the accounts another.

We distinguish four natures, each with its own rules:

Reference data changes, but is versioned. A commission rate card changes; the one from six months ago must remain readable, otherwise an old commission becomes inexplicable. An exchange rate is updated; yesterday's operation is read back at yesterday's rate. Reference data is never modified — a new version is created.

Transactional data is written once and never moves. This is the core. An accounting entry, a closed till session, a validated operation: none of these is modifiable. A correction creates new data linked to the old.

Logs only ever append. The audit log is cryptographically chained: each row carries the fingerprint of the previous one. Any alteration of history breaks the chain and becomes detectable — by you, or by an external auditor who does not have to trust you.

Derived data is disposable. Balances, trial balances, statistics, dashboards, projections: everything recomputes from the entries. That is what makes the classic gap between what the screen shows and what the accounts say impossible — since the screen is the accounts, read differently.

Retention and purging

The periods are not decorative: they answer regulatory obligations that vary from country to country.

• Accounting entries: kept permanently. They are never purged.
• Operations, customer files, supporting documents: ten years after the last operation, adjustable per country.
• Audit log: ten years, unalterable.
• Technical log: ninety days. It never contains customer data in clear.
• Derived data: no retention. It recomputes.

A purge never erases an entry: it archives the peripheral data whose legal period has expired, while keeping the record of the purge itself.

Security & control

Strong authentication, roles, encryption in transit and at rest, immutable traceability, monitoring, continuity. The detail is on the Security & compliance page.

One point deserves to be isolated here, because it conditions reselling the product.

Isolation is set in the database, not in the application code. AiO is intended to be deployed at several organisations: isolation is therefore not a precaution, it is the product itself. Each row carries its owning organisation, and a security rule at engine level filters systematically. Even if the application code contained a flaw, the database would not return another organisation's rows.

That is what makes a multi-tenant deployment defensible before a third party — a partner, an auditor, or the organisation itself.

Infrastructure & deployment

The software is containerised, therefore indifferent to where it is hosted: local server, private cloud, public cloud or hybrid. That decision is yours and is taken at framing, because it commits both cost and data residency.

Integrations & ecosystem

Six transfer partners, banks, Mobile Money, ancillary services — all reached through a single configured module, not six separate developments. Feed levels and access conditions are detailed on the Partner integration page.

Steering & governance

Executive dashboards, alerts, reports and statistics are not a separate layer: they are readings of the ledger and of operations. They hold no truth of their own, and that is precisely what guarantees they cannot diverge from reality.

What this gives you on inspection day

A regulator, a partner bank or an auditor never asks "show me your software". They ask for a reconstitution: that day, that operation, that customer. Who did what, when, on which machine, approved by whom, and under which rule in force at that time.

That is precisely what this information system makes possible — and what no spreadsheet, and no database whose rows can be edited, will ever produce.