Reports and Audit
The regulatory report catalog and the tamper-evident audit log. Reports generate on
demand or on a schedule; the audit log is append-only, hash-chained and retained for 10 years.
Retention: All regulatory returns and every audit entry are held for the 10 year
regulatory floor. Reports below are generated from the base ledger and lending book; nothing here mutates
source data. The audit chain is verified nightly at day close.
Reports in catalog
12
across 3 modules
Due this week
2
BNR returns
Failed last run
1
RRA VAT evidence
Audit entries
1,482,905
chain verified
Regulatory report catalog
Wallet and payments
BNR and FIC returns| Report | Basis | Frequency | Last generated | Status | Actions |
|---|---|---|---|---|---|
| BNR PSP quarterly return | BNR Regulation N 54/2022 | Quarterly | 30 Jun 2026 | Ready | Generate |
| E-money and trust account reconciliation | BNR Regulation N 54/2022 | Daily | 19 Jul 2026 | Ready | Generate |
| FIC suspicious transaction report | Law N 074/2019 | On event | 17 Jul 2026 | Ready | Generate |
| FIC threshold transaction report | Law N 075/2019 | Daily | 18 Jul 2026 | Due today | Generate |
Marketplace
GMV, settlement and RRA evidence| Report | Basis | Frequency | Last generated | Status | Actions |
|---|---|---|---|---|---|
| GMV report | IFRS 15 basis | Monthly | 30 Jun 2026 | Ready | Generate |
| Merchant settlement report | Internal and RRA | Per cycle (T+1) | 19 Jul 2026 | Ready | Generate |
| RRA VAT evidence pack | RRA requirements | Monthly | 30 Jun 2026 | Failed | Retry |
Error: RRA VAT evidence pack failed on the last run
(marketplace tax service returned 503 DEPENDENCY_UNAVAILABLE). The RRA filing deadline is 15 Aug 2026.
Retry, or generate manually once the dependency is restored.
Lending
Loan book, credit bureau and prudential returns| Report | Basis | Frequency | Last generated | Status | Actions |
|---|---|---|---|---|---|
| Loan book report | Internal | Monthly | 30 Jun 2026 | Ready | Generate |
| PAR and NPL report | BNR and internal | Monthly | 30 Jun 2026 | Ready | Generate |
| TransUnion submission | Consent gated (TransUnion Rwanda) | Monthly | 15 Jul 2026 | Ready | Generate |
| BNR lending return | BNR Regulation N 54/2022 | Quarterly | 31 Mar 2026 | Due 31 Jul | Generate |
| IFRS 9 provisioning report | IFRS 9 | Monthly | 19 Jul 2026 | Ready | Generate |
Audit log (WORM, hash-chained)
Chain verified: 1,482,905 entries checked, no gaps and no
hash mismatches. Each entry hashes the previous entry, so any edit or deletion breaks the chain and is
detected. Last full verification 20 Jul 2026 03:30 CAT.
Audit entries
Chain verified| Seq | Timestamp (CAT) | Actor | Action | Entity | Prev hash | Entry hash | Verified |
|---|---|---|---|---|---|---|---|
| 1482905 | 20 Jul 09:14:02 | Patrick Habimana | Kill switch: BRCE rule disabled | rule:MER-FIN-elig v1.1 | 7c4d9e...a211 | a1b2c3...ef90 | |
| 1482904 | 20 Jul 08:52:47 | Grace Umutoni | Config published (checker approved) | product:SME-LOAN rate | e5f6a7...b2c2 | 7c4d9e...a211 | |
| 1482903 | 19 Jul 03:12:10 | System | IFRS 9 provision run posted to GL | gl:batch-8842 | 22bd10...7f3a | e5f6a7...b2c2 | |
| 1482902 | 18 Jul 16:40:55 | Patrick Habimana | Write-off batch approved (checker) | writeoff:WO-2026-07 | 9ac1f0...0d55 | 22bd10...7f3a | |
| 1482901 | 18 Jul 16:05:31 | Josiane Uwimana | Write-off batch submitted (maker) | writeoff:WO-2026-07 | 4e88b3...6c1e | 9ac1f0...0d55 | |
| 1482900 | 18 Jul 10:22:08 | Divine Ingabire | Report generated: BNR PSP return | report:BNR-PSP-Q2 | 0f3162...9c40 | 4e88b3...6c1e |
Schedule a recurring report
A scheduled report runs by itself and is delivered without anyone remembering to run it. Regulatory returns are the main reason this exists.
A scheduled report will not run for an unclosed period. It waits for the business day close rather than producing a number that is about to change.
Reports and Audit
BNR e-money statistics, June 2026
Generated from a closed period, so the numbers cannot move under it. A regulatory return built from an open period would be a number that changes after you file it, which is worse than a late filing.
| Report | BNR e-money statistics return |
| Basis | BNR Regulation N 54/2022 |
| Period | 1 to 30 June 2026, closed 30 June 23:58 |
| Generated | 19 July 2026 16:44, by j.mukama |
| eMoney in issue at close | RWF 2,284,118,000 |
| Trust account at close | RWF 2,284,118,000 |
| Difference | RWF 0 |
| Active wallets | 418,204 |
| Transaction value in the month | RWF 84,118,204,000 |
| Formats | The regulator XML schema, plus XLSX and PDF |
| Checksum | sha256:4c1f...88e0 |
| Section | Source | Reconciled to | State |
|---|---|---|---|
| Balances and issuance | L4 bank and trust reconciliation | The BNR trust account | Agrees |
| Transaction volumes | The ledger, closed period | L1 internal reconciliation | Agrees |
| Agent network | CICO service and float accounts | L3 float reconciliation | Agrees |
| Customer counts | Identity module, party records | KYC tier register | Agrees |
Every section traces to a reconciliation layer. A regulatory number that cannot be tied back to a reconciliation is a number somebody typed.
Reports and Audit
July 2026 cannot be reported yet
19 July is still open, so a July return cannot be generated. The report is not produced with a warning attached: it is refused, because a regulatory filing built on a moving number is worse than no filing.
| Error returned | 409 PERIOD_NOT_CLOSED |
| Period requested | 1 to 31 July 2026 |
| Days closed | 18 of 31 |
| Today | 19 July, open |
| What is blocking today close | Nothing. The day closes at 23:58 as usual. |
| Earliest you can run July | 1 August, once 31 July closes |
| What you can run now | Any period up to and including 18 July |
| Business day | Close state | Reportable |
|---|---|---|
| 16 July 2026 | Closed | Yes |
| 17 July 2026 | Closed | Yes |
| 18 July 2026 | Closed | Yes |
| 19 July 2026 | Open | No |
| 20 to 31 July | Not reached | No |
Reports and Audit
Hash chain verified over 4.2 million records
No break found. Every audit record hashes the one before it, so a single altered or deleted record anywhere in 4.2 million would break the chain from that point on and be reported with its position.
| Records verified | 4,218,904 |
| Period covered | 18 May 2025 to 19 July 2026 |
| First record hash | sha256:0000...a41c |
| Last record hash | sha256:9f2b...c04d |
| Breaks found | 0 |
| Verification time | 2.4 seconds |
| Storage | WORM, write once, ten year retention floor |
| Who can delete a record | Nobody, including Efashe engineers |
| What is written to the chain | Example | Retention |
|---|---|---|
| Every ledger posting | JE-99310, escrow capture RWF 220,700 | 10 years |
| Every operator decision | j.mukama approved KYC-2026-1188 at 14:07 | 10 years |
| Every config and rule version | Commission plan v14, maker and checker | 10 years |
| Every consent grant and withdrawal | Aline Uwase withdrew partner sharing v1 | 10 years |
| Every KYC document registration | National ID registered against case 1188 | 10 years, WORM |
| Every access to a party record | d.ingabire read Aline Uwase profile at 16:04 | 10 years |
The last row is the one operators forget. Reading a customer record is itself audited, so browsing somebody account out of curiosity is visible.
Reports and Audit
The chain does not verify
The chain breaks at record 3,118,204, on 2 March 2026 at 04:12. Every record before that point verifies. Every record after it cannot be trusted to be unaltered, and the viewer says exactly that rather than reporting a percentage.
| Records verified before the break | 3,118,203 |
| First bad record | 3,118,204 |
| Timestamp of the break | 2 March 2026, 04:12:08 |
| Expected hash | sha256:7a1c...4f2b |
| Found hash | sha256:e904...11ac |
| Records after the break | 1,100,700, all unverifiable |
| What this means | Either a record was altered or the store lost integrity. Both are incidents. |
| What it does not mean | That the data is necessarily wrong. It means it cannot be proven right. |
What happens next is not a repair. A broken chain cannot be re-hashed into looking correct; doing that would destroy the only evidence. The incident is raised, the WORM store backups are compared, and the break stays on the record permanently.
| Step | Who | State |
|---|---|---|
| P0 incident raised automatically | The platform | Done, INC-2026-0119 |
| Regulator notified | MLRO and compliance | Within 24 hours |
| WORM backup compared | Platform engineering | In progress |
| Break recorded permanently | The platform | Done, never removed |
| Re-hash the chain to hide it | Nobody | Not possible, and not offered |