Incidents
An incident is the case file that opens any time cash behaves unexpectedly — a variance, a tampered seal, an attempted robbery, a missing CIT bag, a policy override. Every incident is logged, investigated, closed with a documented resolution, and is reviewable by internal audit and the regulator.
What an incident is
An incident (`mfi.cash.incident`) is a structured case record with severity level, type, amount at risk, parties involved, investigation trail, recovery actions, and a documented close-out. It links back to the originating record (till session, vault session, CIT trip, branch session) for traceability.
- **Auto-created** — any variance, any seal mismatch, any policy override, any forced close
- **Manually created** — robbery, attempted robbery, fire, fraud allegation, suspected counterfeiting, internal control failure
- **Never deleted** — even erroneously opened incidents are closed with reason, not deleted
Severity levels
| Level | Meaning | Examples |
|---|---|---|
| Level 1 | Operational, low amount, no fraud suspected | Variance ≤ KES 5,000, denomination mismatch, late closure |
| Level 2 | Material amount or repeat pattern | Variance KES 5,001 – 250,000, repeat overages at one till, single seal mismatch resolved on site |
| Level 3 | Major loss or active security event | Variance > KES 250,000, robbery, fire, missing CIT bag, suspected internal fraud, regulator-notifiable event |
Warning — Level-3 incidents trigger automatic notification to CFO, head of treasury, head of compliance, and (where applicable) FRC / DCI / CBK. Do not downgrade a level-3 without head-of-compliance sign-off.
Incident types
| Code | Description |
|---|---|
| variance_short | Cash shortage detected at EOD or surprise count |
| variance_over | Cash overage detected at EOD or surprise count |
| seal_tamper | Seal damaged or mismatched on CIT bag |
| seal_missing | Seal lost from inventory |
| override_policy | Manager overrode a cash policy threshold |
| force_close | Branch manager force-closed an orphan till session |
| robbery | Armed robbery at branch or CIT route |
| attempted_robbery | Robbery attempted, no loss |
| fire | Fire affecting vault or branch |
| fraud_internal | Suspected staff fraud |
| fraud_external | Suspected customer or third-party fraud |
| counterfeit | Counterfeit notes detected |
| lost_in_transit | CIT bag missing |
| data_loss | Cash transaction record lost or corrupted |
Incident workflow
- **Opened** — auto or manual creation, severity assigned automatically based on type + amount
- **Acknowledged** — branch manager (or higher per level) acknowledges within SLA (4h for L1, 1h for L2, immediate for L3)
- **Investigating** — gather evidence: CCTV, transaction logs, witness statements, denomination ledgers, attachments
- **Resolution proposed** — case officer drafts: cause, action, recovery, prevention
- **Approved** — appropriate authoriser per cap table signs off
- **Closed clean** — fully resolved with no residual loss
- **Closed with loss** — partial or no recovery; loss booked to cash shortage expense
- **Escalated** — handed to police / FRC / DCI / CBK; remains open until external case closes
SLA targets
Missed SLAs trigger escalation to the next role and appear on the head-of-compliance weekly review.
| Level | Acknowledge | Initial investigation | Resolution target |
|---|---|---|---|
| L1 | 4 hours | 24 hours | 48 hours |
| L2 | 1 hour | 4 hours | 5 business days |
| L3 | Immediate | 1 hour | Per investigation; status report daily |
External notification matrix (Kenya)
Some incidents require external reporting:
| Event | Notify | Deadline |
|---|---|---|
| Single cash transaction > KES 1,000,000 | FRC (STR queue) | Within 7 days |
| Robbery / armed attack | DCI + insurance underwriter | Immediate |
| Counterfeit notes seized | CBK Currency Department + DCI | 24 hours |
| Suspected money laundering pattern | FRC (STR) | Within 7 days of suspicion |
| Cyber-incident affecting cash records | Communications Authority + ODPC if PII affected | 72 hours (ODPC) |
| DTM only — material cash loss | CBK Bank Supervision | Per CBK/PG/MFB/05 |
Warning — STR (Suspicious Transaction Report) confidentiality applies. Do not tell the subject that an STR has been filed. The system flags STR-related fields as compliance-only.
Recovery and accounting
Incidents tie directly to GL:
- **Shortage at close** — Dr Cash shortage expense, Cr Till cash for the variance amount
- **Recovered next day** — Dr Cash, Cr Cash shortage expense (reverses the loss)
- **Recovered from teller** — Dr Receivable from teller, Cr Cash shortage expense; receivable cleared as teller pays
- **Insurance recovery** — Dr Insurance receivable, Cr Cash shortage expense, on insurer confirmation
- **Final write-off** — Dr Cash shortage expense (closed), Cr Receivable; tax-deductibility per KRA Income Tax Act
Audit and reporting
All incidents are surfaced in three standard reports:
- **Incident Register** — chronological list, filterable by level / type / branch / date
- **Open Incidents Aged** — open incidents by SLA bucket; tracks SLA breaches
- **Loss History** — cumulative cash loss by branch / type / month, with recovery overlay
Worked scenarios
Scenario — Level-3 incident: CIT bag tamper detected at bank
| Character | Role |
|---|---|
| Florence Achieng | Branch manager Eldoret |
| Peter Otieno | G4S crew chief |
| Aisha Hassan | KCB Eldoret cash desk |
| Mary Mutua | Head of treasury HQ |
| Kimani Mwangi | Head of compliance HQ |
Timeline
- Day 1, 14:30: Florence ships KES 1.8M in bag with seal #91211 via G4S. (Trip CIT/2026/0612 in transit)
- Day 1, 15:45: Aisha at KCB inspects seal — it is intact-looking but does NOT match the manifest number (manifest says 91211, seal reads 91212). (—)
- Day 1, 15:46: Aisha refuses to accept bag. Calls Florence and G4S Ops simultaneously. (—)
- Day 1, 15:50: Florence opens an L3 incident: type seal_tamper, amount at risk KES 1,800,000, parties G4S crew + KCB receiver. (Incident INC/2026/0612 OPENED, L3)
- Day 1, 15:55: Automation pages Mary, Kimani, CFO, CEO. Bag stays in joint custody at KCB pending investigation. (Escalation matrix triggered)
- Day 1, 16:30: Kimani notifies G4S insurance (24h clock), drafts DCI report (police filing). (External notification logged)
- Day 1, 17:00: Joint count of bag at KCB with Aisha, Florence (driven down), G4S regional manager: KES 1,800,000 intact. (No loss)
- Day 1, 17:30: Investigation: G4S admin loaded wrong manifest — physical seal was always 91212, manifest data-entry error. (Cause: G4S data-entry error)
- Day 1, 18:00: Bag accepted into KCB cash desk. Trip reconciled. Incident remains L3 but moves to 'investigating'. (Trip closed_clean)
- Day 5: G4S provides written root cause + control fix. DCI report withdrawn (no crime). Incident closed clean with control finding logged for next G4S service review. (Incident CLOSED CLEAN)
Outcome — No financial loss; level-3 procedure handled correctly; G4S control improvement logged; learning shared institution-wide.
Reference
Incident states
| State | Meaning |
|---|---|
| opened | Created, awaiting acknowledgement |
| acknowledged | Owner acknowledged within SLA |
| investigating | Evidence gathering in progress |
| resolution_proposed | Draft resolution awaiting authoriser sign-off |
| closed_clean | Resolved, no residual loss |
| closed_with_loss | Resolved with documented loss / partial recovery |
| escalated_external | Handed to police / FRC / regulator |
| reopened | Reopened after fresh evidence (manager + audit approval) |
Key incident fields
| Field | Type | Notes |
|---|---|---|
| name | Char | Auto INC/YYYY/NNNN |
| level | Selection | L1 / L2 / L3 |
| type | Selection | See types table above |
| amount_at_risk | Monetary | Maximum exposure |
| amount_lost | Monetary | Confirmed loss |
| amount_recovered | Monetary | Recovered to date |
| branch_id | M2O res.branch | Site of incident |
| origin_record | Reference | Till / vault / CIT trip / branch session |
| acknowledged_by | M2O res.users | SLA stamp |
| closed_by | M2O res.users | Sign-off |
| external_reports | O2M attachment | FRC / DCI / CBK filings |
| str_filed | Boolean | True if FRC STR submitted; restricts visibility |
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Cannot acknowledge incident — 'not the authorised owner' | Auto-assignment routed to a different role | Open the incident, check assigned owner. If reassignment needed, the current owner reassigns, or head of compliance forces. |
| Incident sits in 'closed_clean' but ledger still shows a loss | Recovery journal not posted | Open the incident's GL panel, click Post Recovery Journal. Verify cash shortage expense reverses to zero. |
| Cannot close L3 incident even after investigation complete | External notification (DCI, FRC, CBK) not yet acknowledged | Attach the regulator acknowledgement letter PDF to the incident, then close-out is enabled. |
| STR-flagged incident is visible to branch managers | STR confidentiality flag not set; without flag, normal RLS applies | Compliance officer ticks str_filed = True; visibility instantly restricts to compliance-only group. |
| Incident SLA appears breached even though we resolved on time | Resolution time captured in user local timezone but SLA computed UTC | Verify server timezone; incident SLA computation should use res.partner.tz of the assigned owner. Update record manually with reason. |
See also
Was this page helpful?