Right to erasure

KDPA s.40 grants the right to have personal data erased. The Suite implements this as anonymisation in place — every PII column is overwritten with cryptographic null and the member ID is replaced by a hash, but the transaction ledger is preserved because POCAMLA mandates 7 years.

Member form (erasure) — Right-to-erasure wizard runs from the member form.

What the erasure wizard actually does

Field	Before	After
name	Jane Wambui	MEMBER-9c4a8e7b
id_number	12345678	(null)
phone, mobile	+254 712 345 678	(null)
email	jane@example.com	(null)
date_of_birth	1985-04-12	(null)
address fields	House 12, Eldoret	(null)
photo, signature	BLOB	(deleted)
biometric template	BLOB	(deleted)
next_of_kin	Peter Wambui	(null)
transaction history	intact	intact (linked to hash, no PII visible)

Preconditions before erasure runs

No active loans (member must clear or write off all loans first)
No outstanding balance (positive or negative) on any savings account
No open AML investigation, suspicious activity report, or court order
Member has signed the erasure request (or it came through iBANK with OTP)
DPO has reviewed and counter-signed
Compliance has confirmed no statutory hold (e.g., active CTR window)

The erasure wizard

Member files request via iBANK or DPO opens a case
Operator runs Settings → Privacy → Erasure wizard → pick member
Wizard runs the preconditions checklist; any red blocks proceed
Operator captures reason + uploads signature/proof
DPO approves in a second screen (two-person rule applies here too)
On approval: the SQL UPDATE runs inside a transaction; mail.message records the act; certificate of erasure generated
Member receives email confirming erasure (the last comms before the email field is nulled)

Worked scenarios

Scenario — Esther erases her account after a clean loan exit

Setting: Member finished her last loan 2 months ago, no savings balance, wants to leave the institution.

Character	Role
Esther Njoki	Member, requesting erasure
Florence Achieng	DPO
Mary Mutua	Branch officer

Timeline

Day 1: Esther logs into iBANK → Profile → Privacy → Request erasure. Submits with OTP. (Case opened, state = pending)
Day 3: Mary verifies preconditions: no loans ✓, balance KES 0 ✓, no AML hold ✓. (Wizard preconditions PASS)
Day 5: Florence reviews + signs. Wizard runs at 11:42. (PII fields nulled; transaction ledger intact; certificate generated)
Day 5, 11:43: System sends final email to Esther with the erasure certificate PDF. (Email queue last access to her address)
Day 7: Esther's record in MFI shows MEMBER-9c4a8e7b. Her old loan history still aggregates to portfolio reports but with no name. (Anonymised)

Outcome — Erasure complete in 5 working days; SLA met. POCAMLA ledger preserved.

Reference

Erasure precondition table

Check	Source	Failure means
No active loans	mfi.loan WHERE state='active'	Close loans first
Savings balance KES 0	mfi.savings.account.balance	Withdraw or close accounts
No AML case open	mfi.aml.case WHERE state='open'	Wait for compliance to close
No court order	mfi.legal.hold	Cannot proceed; explain to member
DPO countersignature	mfi.privacy.erasure.dpo_uid	Get DPO to sign in wizard
7-year CTR window clear	mfi.aml.ctr.max(date)	Wait until 7 years past last CTR

Troubleshooting

Symptom	Likely cause	Fix
Wizard says 'cannot erase — POCAMLA hold active'	Last CTR transaction less than 7 years ago	Explain to member: legally bound to retain. Offer marketing opt-out + service freeze instead.
Member returns 6 months later asking to come back	Erasure is irreversible; new application = new member	Open as a new member; explain prior history cannot be recovered.
Anonymised record breaks a unique-constraint on re-onboarding	Hash collision or stale unique key on ID number	Run migration script `mfi-doctor fix-orphan-anonymised`; clears the placeholder.
Reports show 'unknown member' lines after erasure	Normal — the hash carries the link but PII is gone	Reports can be configured to mask hashed names; Settings → Reports → Display anonymised records.