Reversal Requests

Manages requests to reverse posted transactions (mfi.ib.reversal.request) - erroneous, duplicate or fraudulent entries that need backing out under control. Each request states the reason and original entry and must be authorised before any reversal posts. It keeps corrective postings inside the maker-checker discipline rather than letting staff reverse at will.

Workflow

Open Reversal Requests under Governance.
Create a request, linking the original transaction and reason.
Attach supporting evidence for the correction.
Route it for authorised approval under dual control.
On approval, the reversal posts and the request closes with an audit link.

Fields reference

Every field on this screen, drawn from the live data model.

Field	Type	Required	Description
Rail / channel `rail`	Text	Yes	own / member / mpesa / external / etc.
Txn model `txn_model`	Text	Yes	e.g. mfi.savings.transaction, mmm.transaction
Txn `txn_id`	Number	Yes	Row id in the model above.
Reason Detail `reason_detail`	Long text	Yes	Free-text narrative from the member.
Txn reference / receipt `txn_reference`	Text	—	Cached so we can display even if the row is gone.
Decision reason `decision_reason`	Text	—	Required on reject; optional on approve.
Execution Result `execution_result`	Long text	—	What the underlying action_reverse() returned.
Window Hours `window_hours`	Number	—	Reversal window at the time of submission.
Deadline At `deadline_at`	Date & time	—	Cron auto-expires after this date if still open.
Member `member_id`	Link → mfi.member	Yes	Member
Submitted At `submitted_at`	Date & time	Yes	Submitted At
Reason Kind `reason_kind`	Choice: Wrong amount, Wrong recipient, Duplicate transaction, Suspected fraud / unauthorised, Other (describe)	Yes	Reason Kind
State `state`	Choice: Submitted, Under Review, Approved (awaiting execution), Executed, Rejected, Expired	Yes	State
Has Message `has_message`	Yes/No	—	Has Message
Reference `reference`	Text	—	Reference
Txn Amount `txn_amount`	Money	—	Txn Amount
Txn Date `txn_date`	Date & time	—	Txn Date
Currency `currency_id`	Link → res.currency	—	Currency
Evidence (screenshots etc.) `evidence_ids`	Tags	—	Evidence (screenshots etc.)
Decision By `decision_by`	Link → res.users	—	Decision By
Decision At `decision_at`	Date & time	—	Decision At
Executed By `executed_by`	Link → res.users	—	Executed By
Executed At `executed_at`	Date & time	—	Executed At
Second Rule `second_rule_id`	Link → mfi.two.person.rule	—	Second Rule
Second Approver `second_approver_id`	Link → res.users	—	Second Approver
Second Approved At `second_approved_at`	Date & time	—	Second Approved At
Maker Uid `maker_uid`	Link → res.users	—	Maker Uid
Company `company_id`	Link → res.company	—	Company

Actions & buttons

Buttons available on this screen and what they do:

Start Review
Approve + Execute
Reject

Status lifecycle

Records on this screen move through these statuses:

Submitted → Under Review → Approved (awaiting execution) → Executed → Rejected → Expired

Notes & rules

Every reversal requires a documented reason and approval.
Linked to the original entry being corrected.
Enforces maker-checker on corrective postings.
Approved reversals leave a complete audit trail.

Technical model: mfi.ib.reversal.request · Record: iBANK Reversal Request