Your need, understood

3,947 lines. 28 chapters. 152 numbered sections. You are not asking us to invent a product, but to make governable and provable an activity that today rests on multiple entries and manual reconciliation.

1. Proof is the product

A regulator, a partner or you must be able to reconstitute any past day, to the franc, without relying on a cashier's memory.

You require it four times — §3.6, §6.5, §9.9, §22.12: no operation can be modified. We therefore treat data integrity as a feature, not as a compliance constraint. Double-entry ledger, UPDATE and DELETE revoked at database level, chained audit log, locking close. Every displayed value is dated, attributed and explainable.

2. Your duplicate rule

It is the only passage where you correct your own drafting, and you are right:

Two transactions are not duplicates simply because they involve the same sender, the same beneficiary or the same amount.

You require the check to be on the unique identifier supplied by the partner — MTCN or equivalent — and you state the opposite requirement with equal force: never prevent a customer from carrying out several legitimate operations.

Technical translation: the uniqueness key is the pair (partner, partner reference), never the name, the amount or the date. A check that is too strict here blocks a real customer at the counter; that costs as much as an accepted duplicate.

3. The field dictates the technique

A cashier on unstable 3G must be able to record an operation. And above all: retrying must never create a duplicate. Hence:

• Idempotency key generated on the device, before sending: a retry after a drop replays the same key and creates nothing
• Offline mode at the counter: the till carries on without network, the sync queue is visible
• Local float ceiling offline: we do not recreate a double-spend risk on the treasury

4. Your real problem is liquidity

This is the point that does not appear in a feature list, and it is the one that costs the most.

A module that tells you "branch AG03 will run out of cash on Wednesday around 2 p.m. at the current rate" has more economic value than half the entry screens. It is at month 3, with the tills — not optional.

5. Your architecture proposal, stated four times

We are not recommending it to you: we are adopting it.

Six separate partner modules means writing, testing and maintaining the same accounting logic six times, with six chances to diverge. One module configured per partner means one logic proven by six uses — and it is one of the three decisions that make six months achievable.

The points your specification leaves open

We prefer to show them rather than dress them up. Each is settled during framing, before any development.

Two modules announced without being specified. Visa Cards and Banking Partners appear in the chapter 4 list but have no detailed chapter. They are included in the commitment; their specification is produced with you at framing. If their scope exceeds that of a standard module, it is covered by a quoted amendment before any development.

A numbering discrepancy. Chapter 4 announces 21 modules; the detailed chapters describe 20, with different numbering. CRM & KYC is detailed but missing from the list, while Visa Cards and Banking Partners are listed but not detailed. Our delivery covers the union of both lists — the only reading that drops nothing.

Hosting. On-premise, cloud or hybrid: all three are proposed in your §7.4. That is not flexibility, it is a decision not taken, and it changes the infrastructure, the security and the cost.

Data residency. Is there, in any of the target countries, an obligation to keep data on national territory? The answer determines the hosting region and may require one instance per country.

The access level actually available at each partner. See the Partner integration page. Version 1 does not wait for it.