Demonstration network

Why

Demonstrating the platform across the seventeen States it aims to cover means having a partner institution there, under real technical roles and real currencies — without ever letting a real company receive an offer from a bank that in reality commits no one.

How, in the application

A dedicated operator script — never triggered automatically by an agent — enrolls a demo institution in each of the seventeen OHADA and neighboring States, with a full journey possible in each: request, offer, acceptance, commitment, facility, drawdown, disbursement, repayment schedule. It is the environment_class axis, carried by each institution's financeur space, that guarantees the seal — not the script itself, which only writes within that already-isolated scope.

The visibility rule is symmetric and never a simple switch: a real company never sees a demo bank as an available financeur, but neither can a demo company address a request to a real bank, which would constitute a real solicitation born from a test scenario. Each world sees only its own. The parameter that would control inclusion of the demo network is closed by default: it must be explicitly opened, never the reverse — an omission must never expose the demo network to a real customer.

Safeguards

• The demo-network enrollment script requires an explicit double confirmation (an environment variable and a command flag) — without both, it describes what it would do without writing anything.
• It never performs a deletion or a reset: only idempotent creations, strictly within the demo scope.
• No password is ever chosen or logged by these scripts; every e-mail address created uses a non-resolvable domain reserved for this purpose.
• The demo network is never served to a real customer — this guarantee rests on the environment_class axis, checked on every read, not on a naming convention or human vigilance.