There is deliberately no approve button on this list. Approval happens only inside the full review — after you have seen what changes, who asked, the before/after, and the evidence. An approval you could give without reading is not a control.

Nothing here has an approve button — Review opens the full before/after and evidence first; approval lives inside the review

In-doubt transfers — the reconciler is on them

Both directions live here. Outbound ↗ in-doubt = we sent money and NIBSS has not given a final answer — the customer's money sits safely HELD (never gone) while the status query (TSQ) cycles until a final answer forces completion or automatic refund. Inbound ↙ in-doubt = another bank says they sent money to us — the credit is PROVISIONAL (visible but not spendable) until settlement confirms it, so a forged or failed inbound notice can never become spendable money. Click a row for its full state history.

Maturing soon

Rollover instructions captured in-app; unanswered maturities pay out to the linked account

Premature termination requests

Penalty computed by the product's rule, shown to the customer before they confirm

Vend monitor

The IBEDC failure below refunded itself before the customer could call support

Float requests — the single-pending rule at work

An agent can hold one pending request; caps derive from their own 30-day volume. Try approving both rows.

Terminal estate

Full device lifecycle: assign, replace, transfer, sync to the terminal-management system

Till sessions

Try closing till 03 — the reconciliation runs before your eyes

Cheque register

Case queue

Click a case for its evidence bundle

August return — draft preview generates live from the ledger

Form 300 excerpt with the CBN item codes — the draft the head of finance reviews before filing. Every line drills to its postings, and the cross-references (“Specify, MMFBR 711”) must agree or the return refuses to emit.

29 of 29 schedules generated ✓ · tie-out 0.00 ✓ · Preview all schedules

Filing archive

What was filed, when, by whom — content-fingerprinted so "what did we file in March?" is retrieved, not reconstructed

End-of-day close — dress rehearsal

Runs automatically at 23:30; the manual run here executes against a copy so you can watch the ceremony. A non-zero tie-out blocks the close and pages finance — the books cannot close wrong.

Chart of accounts

Every product and fee maps here before it can exist — click a row to drill toward its postings

GL postings

Most recent entries on this account today — each drills to its source transaction

Scheduled & recurring transfers

Each run executes through the full payment machinery — fees, limits, AML — and a failed run retries then notifies, never silently skips

Batch pipeline — Vendor batch 22 · executing with failures (the honest mid-flight view)

A failed row never blocks the batch and never disappears: it is named, reasoned, and waits for a decision. The batch cannot close while any row is undecided.

When every row is Paid, Refunded, or explicitly cancelled, the batch reconciles: total debits = total credits + refunds, proven to the kobo, and the closing report goes to the corporate customer automatically.

Tenants

Transfer fee structure · v14 Live since 01 Aug

Try proposing a band change — notice you cannot activate your own proposal

Each charge is versioned configuration with its own ledger mapping and scope. Changes are proposed → dual-approved → effective-dated, and every transaction records which charge version priced it. Statutory items are collected into their own ledger accounts and appear on the remittance report.

Waivers are first-class: a zero-SMS-fee on Kids Trust, or a fee holiday for a segment, is a scoped override with an expiry — proposed and dual-approved like everything else, never a hand edit. Statutory rows collect into liability ledger accounts (2xxxx) and feed the Statutory remittance report; income rows collect into 41xxx fee income.

A waiver is a scoped override on a catalog charge with a MANDATORY expiry — it reverts by itself, so a discount can never quietly become permanent. Two named approvers by charge type, recorded on the waiver.

A loan product is versioned configuration: interest method, bands, penalties, and its provisioning profile — every running loan records which product VERSION priced it, so a product change never rewrites an existing loan.

Staff

Click a role to load its permission grid below. Creating or editing a role is itself a maker-checker change — a permission grant activates only on a second officer's approval.

Every permission is three-dimensional: View, Propose (maker), Approve (checker) — and the engine refuses any grid where one person can both propose and approve the same money action (segregation of duties, enforced at save, not by policy memo)

Active sessions

Concurrent-session limits enforced; force sign-out is immediate server-side revocation, audited

Routing rules — what gets sent, when, on which channel

Every rule fires off an event on the Kafka belt. Transactional and security rules are regulator- or safety-anchored — customers cannot mute them. Marketing respects consent (NDPA) and quiet hours. Rule changes are dual-approved with an effective date, like every other configuration.

Sending and billing are deliberately separate: this screen decides when a message goes out; the ₦4 SMS alert fee it may incur is priced by the Charge catalog on Products & pricing — so a routing change can never silently change what customers pay, and a fee change can never silently change what they receive.

Chain verified 14:30 · block 40,221 · fingerprint 7d1c…90aa — any tampering with history breaks this seal visibly.

Card registry

Try the freeze — it takes effect at the processor in under a second, and the customer sees it instantly in-app

PCI DSS posture: the number shown is a masked token from the processor. Card webhooks post to the ledger through the same idempotent path as every other movement.

Queue

Click a row for the evidence pack · try resolving the double-debit

NIBSS settlement reconciliation — today

Press run: every NIP transfer is matched against the settlement report line by line

Start a migration — what are you moving?

Order matters, and the workbench enforces it: 1 ledger before 2 customers, customers before 3 accounts, accounts before 4 balances & loans — a balance can only land in a real account, owned by a real customer, posting to a real ledger line. Every button walks the same five steps: upload the export file → validate every row → rehearse the load on a copy → tie out the numbers to the kobo → a second officer approves the production load. Nothing touches the live bank before step five.

Pipeline — cohort B (Yola branch customers)

Press run: each stage must go green before the next unlocks; nothing loads into production from a red stage

Migration options — live switches, applied to every cohort

These are real controls, not statements: flip one and every later validation run uses the new setting (a cohort already past validation re-runs it). The recommended position is ON for all three — flipping one off tells you exactly what you would be giving up before it lets you.

Identity coverage — what the legacy book actually looks like

The engine classifies every customer row up front; nobody discovers the gap on cutover weekend

Restricted means: money safe and visible · deposits land normally · withdrawals and transfers blocked until identity is verified — and the first withdrawal attempt IS the KYC moment: the customer presents ID, the officer captures BVN/phone on the spot, verification runs, the restriction lifts, and the customer walks out with their money and a working account. Never a locked-out customer without a stated path.

Balance tie-out — cohort A dress rehearsal (the fourfold report)

Every account in either system lands in exactly one bucket — matched, missing, extra, or mismatched with a signed kobo delta. The report is total: the four buckets sum to both sides, proven.

Six accounts of 12,040 stand between this cohort and a clean load — and the engine will not load ANY row until all six are resolved at source. There is no “load anyway” button, deliberately.

Cutover go/no-go — the checklist that decides the weekend

Verdict today: NO-GO — and the screen says so plainly. Cutover happens when every row here is green, not when a date on a calendar arrives.

Branch — HQ Gombi · code 001 Open · 08:00–16:00

12 Market Road, Gombi, Adamawa · Manager: A. Danjuma · branch GL dimension 001

Scheduled tasks

Every run leaves a record; a missed run pages ops — try pausing one