Retention schedule
Retention is the discipline of holding personal data only as long as a lawful basis exists. The Suite ships a default schedule mapped to Kenyan obligations and a daily cron that flags candidates for the DPO's review before the actual purge.
The shipped retention schedule
| Category | Retain | Authority | Action at expiry |
|---|---|---|---|
| Member identity + KYC | 7 years post account closure | POCAMLA + KDPA | Anonymise |
| Loan + savings transactions | 7 years | Companies Act + KRA | Archive then anonymise |
| AML records (STR/CTR) | 10 years | POCAMLA | Archive (cannot anonymise) |
| Audit logs (mail.message) | 7 years | ISO 27001 + SOC 2 | Archive to cold storage |
| HR records | 7 years post separation | Employment Act | Anonymise |
| Marketing data | Until consent withdrawn | KDPA | Delete on toggle |
| iBANK session logs | 1 year | Operational | Delete |
| Cookies (non-essential) | 13 months | EU + KDPA | Browser-side TTL |
| Suspicious activity reports | 10 years | POCAMLA | Archive |
| CRB submissions | 5 years | CRB Act | Anonymise |
The retention cron
Runs daily at 02:30. For each category, queries records past their retention window and flags them as candidates for DPO review. Nothing is purged automatically — the DPO must approve each batch before the second cron (weekly at Sunday 03:00) executes deletions or anonymisations.
Note — Two-stage flow prevents accidental mass deletions. The flag-cron is read-only; the purge-cron requires DPO sign-off on the queue.
Worked scenarios
Scenario — Florence reviews the weekly retention queue
| Character | Role |
|---|---|
| Florence Achieng | DPO |
Timeline
- Fri 14:00: Opens MFI → Privacy → Retention queue. 47 candidates listed (members whose accounts closed 7+ years ago).
- 14:05: Filters out 12 with open CTR holds (POCAMLA 10-year still binding).
- 14:10: Spot-checks 5 random candidates — all confirmed closed, no balances, no holds. (Sample passes)
- 14:15: Bulk-selects the remaining 35 → Action → Approve anonymisation. (35 marked anonymise_approved=True)
- Sun 03:00: Purge cron runs. 35 records anonymised. Certificate batch generated.
- Mon 09:00: Florence reviews the certificate batch + signs as record-keeping.
Outcome — Retention discipline maintained; 35 expired records anonymised cleanly with audit trail.
Reference
When categories conflict (longest wins)
| If member has | Then retain at least | Because |
|---|---|---|
| Any CTR in last 10 years | 10 years from last CTR | POCAMLA |
| Any tax doc in last 7 years | 7 years from doc date | KRA |
| Active CRB negative listing | 5 years from listing | CRB Act |
| Open AML case | Indefinite | Investigation in progress |
| Pending court order | Until court releases | Statutory hold |
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Cron stuck — no flags created for 3 days | Cron disabled or workers throttled | Settings → Technical → Scheduled actions → Retention flag cron → Run manually; check logs. |
| Purge cron deleted records DPO hadn't approved | Anonymise_approved flag manipulated by another script | Restore from last night's backup; investigate which user/system flipped the flag (audit chatter on the records). |
| ODPC asks for proof of last quarter's anonymisations | Standard audit | MFI → Privacy → Reports → Anonymisation certificates → filter by date; export PDF. |
| Some records flagged but cannot be anonymised | FK constraint — e.g., still referenced by an open support case | Close dependents first; re-run the purge for those records. |
See also
Was this page helpful?