Payment Exceptions, Returns & Reversals Policy¶
| Code | PAY-009 |
| Domain | Payments & Settlement |
| Owner | Head of Payments |
| Status | Draft |
| Applicability | Platform |
| Jurisdiction | NZ + AU |
| Business domain | BD06 |
| Review date | 2027-04-01 |
Regulations: AU Payment Systems Act · Payments NZ Rules · ePayments Code¶
Purpose¶
Govern the handling of payment exceptions, returned payments, and reversals across all rails and channels. Defines the permissible grounds for reversal, the procedural requirements for returns, and the controls that prevent unilateral or undocumented modification of settled transactions.
Scope¶
All payment instructions that enter an exception, failed, returned, or reversed state across NZ and AU operations, regardless of channel, product, or rail.
Policy statements¶
Every payment instruction that cannot be completed SHALL enter a documented exception state with a reason code drawn from the approved reason code catalogue. Silent failure is prohibited. The customer SHALL be notified of a payment failure within the timeframe required by the applicable customer code.
The platform SHALL distinguish between returns (initiated by the receiving bank or scheme), recalls (initiated by the originating bank at customer request), and reversals (technical corrections for unambiguous processing errors). Each category SHALL follow its own defined procedure with separate authorisation requirements.
Reversals of settled payments SHALL require documented grounds, dual approval from the operations and finance teams, and SHALL be executed only through the authorised compensation entry path in the posting engine. Direct mutation of settled records is prohibited.
Recall requests received from another institution SHALL be assessed within the timeframe required by the applicable scheme rules. Where the funds are still available in the receiving account, the platform SHALL place a hold pending customer notification. Where the customer disputes the recall, the dispute SHALL be escalated to the legal and compliance team.
Suspense accounts used to hold funds during exception processing SHALL be reconciled daily. Any item remaining in suspense beyond the defined resolution period SHALL trigger an escalation alert to the Head of Payments.
The fraud operations team SHALL be notified of all returns and exception items exhibiting fraud signals so that the account can be reviewed and, where necessary, restricted.
All exception events, return receipts, recall requests, reversal instructions, and suspense entries SHALL be recorded in the immutable transaction log with full traceability from the original instruction to final resolution.
Satisfying modules¶
| Module | Name | Mode | Description |
|---|---|---|---|
| MOD-119 | BPAY payment integration | AUTO |
BPAY dishonours and returns are handled automatically — funds are credited back to the customer's account and a notification is dispatched. |
| MOD-120 | PayID and Osko integration | AUTO |
Osko payment returns (to wrong PayID, account closed) are processed automatically with immediate customer notification and funds reversal. |
| MOD-122 | NZ faster payments and A2A integration | AUTO |
Returned payments (invalid account, account closed) are credited back to the originating account automatically with a customer notification. |
Part of Payments & Settlement · Governance overview
Compiled 2026-05-22 from source/entities/policies/PAY-009.yaml