Vaults
The vault is the branch's secured cash store. It opens only under dual control, every movement leaves a paired audit entry, and it holds the operating cash that funds the day's tills.
What a vault is in the system
Each branch has exactly one logical vault record (`mfi.cash.vault`). It is linked to a GL cash account, an overnight maximum (default KES 5M), a minimum reserve (default KES 200k), and two or more registered key-holders (typically branch manager + supervisor). A vault is not a till — it never transacts with members directly. It only moves cash to and from tills, to and from CIT bags, and (rarely) accepts emergency direct deposits from a head-of-treasury authorised top-up.
Dual control mechanics
Opening the vault requires two distinct user ids registered as key-holders, swiping within a 120-second window. Both badge events are recorded against the vault session. Movements within an open vault session do not require a second swipe per movement — the session itself is the control. Closing the vault similarly requires both key-holders.
- **Co-holders rule** — the two key-holders must be different physical individuals. The system blocks if both swipes resolve to the same user id (e.g. someone using a borrowed badge).
- **Window** — 120 seconds default. After window expires, both must swipe again.
- **Escalation** — if a primary key-holder is unavailable, the regional manager can be added as a temporary co-holder with a written authorisation.
- **Audit** — every open and close generates a `mail.message` on the vault session record. Internal audit reviews these monthly.
Movement types
Every movement updates the denomination ledger (not just the total). This is critical for forensic work: a KES 1,000 shortage paired with a KES 1,000 overage in coins is usually a counting error, but pure-note shortages without offset usually indicate fraud.
| Type | From | To | Trigger |
|---|---|---|---|
| Till float | Vault | Till | Teller opens session |
| Till return | Till | Vault | Teller closes session |
| Mid-day sweep in | Till | Vault | Till exceeds operating max |
| Mid-day sweep out | Vault | Till | Till below minimum for known transaction |
| CIT outbound | Vault | CIT bag | Sealed for pickup |
| CIT inbound | CIT bag | Vault | Bag arrived and broken |
| Inter-branch | Vault (A) | Vault (B) | Authorised by regional manager |
| Emergency injection | External (HO) | Vault | Treasury top-up |
| Adjustment | — | Vault | Resolves variance, requires incident |
Vault denomination ledger
The vault keeps a running denomination ledger. When a teller pulls a KES 50,000 float as 30 × 1,000 + 20 × 500 + 25 × 200 + 30 × 100 + 20 × 50, every one of those counts decrements the vault ledger simultaneously. When you reconcile at close-of-day, the system compares physical count against this ledger denomination-by-denomination.
Overnight holding rules
The vault overnight maximum is the most-watched control by both internal audit and insurance underwriters.
- **Default maximum** — KES 5,000,000 per branch (urban) or KES 2,000,000 (rural); set per branch in cash policy
- **Breach** — branch session cannot close. Branch manager can override with regional manager email approval; both events are logged.
- **Insurance coupling** — the insurance policy you hold against cash-in-vault has its own limit. If you breach insurance limit, recovery is capped at the policy regardless of actual loss. Treasury should reconcile policy limit and system overnight max quarterly.
- **Carry-forward** — if cash arrives late from CIT (after vault close), it is held in 'sealed bag' status overnight and brought into vault next morning. This counts toward overnight maximum.
Minimum reserve
The vault minimum reserve (default KES 200k) prevents the branch from running dry between CIT replenishments. When vault falls below minimum, the system blocks new outgoing CIT outbound trips and pages the regional treasury team to schedule a top-up. It does not block till floats from being drawn (operations must continue), but each draw decrements toward zero and the alert escalates.
Reconciliation routine
- Branch manager triggers Vault Count from the vault session form (typically once per day at branch close, plus surprise counts at random intervals).
- Two key-holders physically count the vault denomination-by-denomination.
- Both enter their counts independently into the count wizard.
- System compares both counts to each other and to the ledger.
- If both counts match each other and the ledger: vault session reconciled clean.
- If both counts match each other but differ from ledger: incident raised (variance with single source).
- If the two counts differ: re-count required (this is usually a coin-counting error).
Worked scenarios
Scenario — Vault open and float allocation, Karen branch
| Character | Role |
|---|---|
| Florence Achieng | Branch manager (key-holder 1) |
| Peter Otieno | Supervisor (key-holder 2) |
| Mary Mutua | Teller waiting for float |
| Kimani Mwangi | Teller waiting for float |
Timeline
- 07:30: Florence and Peter arrive together. Both swipe within 40 seconds. (Vault session opens, dual control verified)
- 07:32: Both physically inspect the vault — seals on the overnight bag intact. (Visual inspection logged)
- 07:35: They count the overnight bag together: KES 620,000. Matches the closing balance from yesterday evening's branch session. (Opening count verified KES 620,000)
- 07:50: Mary requests float for Till 01. Florence authorises the movement. (Vault → Till transfer KES 50,000)
- 07:55: Kimani requests float for Till 02. Authorised. (Vault balance KES 520,000)
- 11:50: Aisha (Till 03) needs additional KES 100,000 mid-morning to cover a large group disbursement. (Vault → Till transfer KES 100,000)
- 15:45: Mid-day sweep from Mary's till brings KES 150,000 back to the vault. (Till → Vault movement)
- 17:30: All till float returns complete. Vault count: KES 540,000. (Closing count KES 540,000)
- 17:42: Florence and Peter both swipe to close the vault session. (Vault session CLOSED)
Outcome — Clean vault session; ledger matches physical count; KES 540,000 overnight (well below KES 5M max).
Reference
Vault master fields
| Field | Type | Notes |
|---|---|---|
| name | Char | e.g. 'Kawangware Vault' |
| branch_id | M2O res.branch | 1:1 |
| gl_account_id | M2O account.account | Cash GL |
| overnight_max | Monetary | Per policy |
| minimum_reserve | Monetary | Triggers replenishment |
| key_holder_ids | M2M res.users | Two or more required |
| insurance_policy_no | Char | For recovery |
| insurance_limit | Monetary | Recovery cap |
| physical_location | Char | For audit |
| last_count_date | Datetime | For overdue alerts |
Vault session states
| State | Meaning |
|---|---|
| draft | Created, awaiting first swipe |
| open | Both key-holders verified, ready for movements |
| pending_close | Close requested, awaiting count |
| reconciling | Count complete, variance under investigation |
| closed_clean | Reconciled, zero variance |
| closed_with_variance | Reconciled, variance accepted with incident |
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Cannot open vault — 'second key-holder required' | Only one badge swipe within window | Second key-holder swipes within 120 seconds. If unavailable, regional manager can be added as temporary co-holder via the Authorisation panel. |
| Vault movement rejected because 'denomination ledger inconsistent' | A previous movement did not record denomination breakdown (e.g. import or manual adjustment) | Run the vault recount wizard, accept the current physical count as the new baseline, raise a variance incident to document the reset. |
| Insurance limit alert fires every morning | Overnight max is set above insurance limit | Lower the overnight max in cash policy to match the insurance limit, or escalate to head of treasury to renegotiate cover. |
| Minimum reserve breached but no CIT scheduled | CIT route paused or carrier holiday | Head of treasury arranges emergency CIT or inter-branch transfer; in extremis, branch operates on reduced hours. |
| Surprise count shows variance after a clean vault session yesterday | Likely overnight access; check entry logs and CCTV before assuming counting error | Raise an immediate level-3 incident. Do not transact until cause is identified. Follow the robbery/tamper procedure even if you don't yet have evidence of a break-in. |