Rejects, Returns, Recalls and Reversals. Classify pre-settlement and post-settlement exceptions while preserving original transaction identity and control evidence.
Block 14 · Chapter 67 of 75
Payment operations become dangerous when every unsuccessful payment is described as “rejected” or every recovery is described as a “reversal.” Those words are not interchangeable.
A reject normally means the payment or file failed before the intended interbank or beneficiary-side completion. A return is a later movement of value back toward the sender after an earlier payment or debit progressed far enough to require a separate return event. A recall is generally a request to recover or return a payment; it does not itself move funds and does not guarantee recovery. A reversal is an accounting or payment correction that undoes a previous entry or event, but the precise meaning depends on the rail, product and ledger design.
The operational question is therefore not “Did the payment fail?” It is:
What state had the original payment reached, who owns the next action, what rule permits it, what new financial event is required, and which identifiers must link the exception to the original transaction?
This chapter builds a practical Canadian exception model across AFT/ACSS, PAD, Interac, Lynx, cards and Canada’s planned Real-Time Rail (RTR). It separates external scheme events from internal bank repairs, customer cancellations from interbank recalls, and ledger reversals from actual recovery of money.
Evidence boundary: rule and legal statements below are labelled as Payments Canada, Interac, or federal requirements and should be checked against the linked version-in-force source. Architecture and bank workflow are implementation guidance, not a universal bank policy. Scenarios marked fictional are illustrative only.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- distinguish reject, return, recall, cancellation, reversal, repair and investigation;
- determine whether an exception happened before or after settlement;
- explain why payment state determines which recovery options still exist;
- connect AFT returns to Rules F1/F4 and Standard 007 return reason codes;
- explain why PAD returns and customer reimbursement are not the same event;
- explain the importance of Rule 10 finality and return for Lynx;
- treat a Lynx return as a new payment event rather than silently deleting settlement history;
- explain the difference between a recall request and a successful return;
- describe RTR Rule 7 at a functional level without treating RTR as already live;
- preserve original transaction identifiers and references across exception events;
- design accounting entries that keep original and corrective events separately auditable;
- build customer statuses that accurately describe payment state;
- route exceptions to operations, fraud, sanctions, investigations or reconciliation based on cause;
- test duplicate, late, partial and uncertain exception scenarios;
- identify when an internal reversal must not be presented as interbank recovery.
Chapter navigator
- The exception taxonomy
- Payment state before exception type
- Rejects and repairs
- Returns in AFT, PAD and retail batch payments
- Lynx finality, returns and misdirected payments
- Recalls, cancellation requests and recovery
- Reversals and accounting corrections
- RTR exception and return model
- Customer communication and case ownership
- Architecture, identifiers and reconciliation
- Practical exception scenarios
- Implementation, testing and authoritative references
1. The exception taxonomy
A useful exception model begins by classifying what happened, not by choosing a generic operations queue.
Reject
A reject normally means the payment did not pass a required validation or acceptance point.
Typical causes:
- invalid account or routing data;
- malformed message or file;
- missing mandatory information;
- unsupported transaction type;
- duplicate instruction;
- customer account restriction;
- insufficient available funds before release;
- sanctions or compliance decision;
- participant or rail validation failure.
A reject usually preserves the original customer instruction and records why no further payment state was created.
Repair
Repair means the instruction is not yet released because an error may be correctable.
Examples:
- missing beneficiary address;
- invalid routing combination;
- truncated corporate reference;
- ambiguous beneficiary bank;
- file-control-total mismatch requiring customer resubmission.
Repair is a workflow state, not a clearing event.
A bank should define which fields operations may change and which changes require customer re-authorization. Changing a spelling error in a non-critical narrative field is not equivalent to changing the beneficiary account.
Return
A return is a separate event after the original transaction has progressed.
Examples:
- AFT credit returned because the account is closed;
- PAD returned due to insufficient funds or another valid return reason;
- Lynx amount returned under Rule 10 circumstances;
- an RTR return under the Rule 7 framework once the RTR service is live for the relevant participants and use case.
The original transaction remains in history. The return references it.
Recall
A recall is a request to another party to return funds or stop further completion if still possible.
A recall has at least three states:
- request created;
- request accepted/rejected or otherwise dispositioned;
- funds returned or not returned.
The request itself is not the recovery.
Cancellation
Cancellation is usually a customer or bank action against a payment that has not yet reached an irreversible stage.
Examples:
- cancel future-dated AFT file before release;
- cancel an Interac e-Transfer where the product permits cancellation and the transfer has not been completed;
- cancel a queued internal instruction before external release.
A cancellation after settlement is normally impossible in the literal sense; recovery then requires a return or another recovery process.
Reversal
A reversal is the broadest and most abused term.
It can mean:
- reverse an internal provisional posting;
- reverse a fee;
- reverse a duplicate ledger entry;
- reverse an authorization hold;
- process a scheme-defined reversal message;
- post a correcting entry after a return.
A ledger reversal does not prove that external funds were recovered.
Investigation
An investigation is an information and evidence process.
It may ask:
- where is the payment?
- was it settled?
- was the beneficiary credited?
- can funds be returned?
- was the payment duplicated?
- who authorized it?
- which amount remains recoverable?
An investigation can lead to a recall, return, reimbursement, write-off or no financial action.
2. Payment state before exception type
Exception handling should always begin by reconstructing the original payment state.
The pre-versus-post-settlement diagram above is the first branch in every exception decision: return eligibility and timing come from the applicable rail/product rules and law, while recalls remain requests that require the receiving side’s disposition.
A robust state model might include:
CREATED
VALIDATING
REPAIR
AUTHORIZED
RELEASED
EXTERNALLY_ACCEPTED
SETTLED
BENEFICIARY_POSTED
RETURN_REQUESTED
RETURNED
CANCELLED
FAILED
Not every rail exposes the same states, but the bank should understand equivalent events.
Before external release
If a payment has not been released externally, options are broad.
The bank may:
- repair;
- reject;
- cancel;
- re-date;
- re-route;
- obtain new authorization.
The risk is mostly internal.
Released but not settled
The bank may have a narrow cancellation or intervention window depending on the rail.
Operations must know:
- whether the rail supports cancellation;
- whether the receiving side already accepted;
- whether the bank can suppress a queued message;
- whether the payment is conditionally queued;
- whether any guarantee or customer commitment has already been given.
Settled
Once settlement is final, the original settlement history must remain intact.
Recovery generally requires:
- a new return payment;
- a recall/return request;
- bilateral cooperation;
- legal or fraud recovery procedures.
The bank cannot make external settlement “unhappen” by changing its internal status.
Credited and onward moved
Recovery becomes more difficult when the beneficiary has already:
- withdrawn;
- transferred onward;
- converted currency;
- paid another party;
- moved funds cross-border.
This is particularly important in fraud cases.
State evidence
For every exception, operations should retrieve:
| Evidence | Why it matters |
|---|
| Original instruction | Proves customer intent/data |
| Authentication/approval | Shows authorization |
| Validation result | Shows what bank accepted |
| External reference | Connects bank to rail/network |
| Settlement evidence | Determines finality stage |
| Beneficiary posting evidence | Helps locate funds |
| Return/recall reference | Links recovery action |
| Ledger entries | Shows financial impact |
| Communications | Shows customer/participant notices |
A good investigation can explain the lifecycle without reading application logs manually.
3. Rejects and repairs
Rejects are safest when they happen early.
Channel rejects
Examples:
- mandatory field missing;
- invalid date;
- invalid account pattern;
- unsupported currency;
- amount exceeds product limit.
The channel should reject immediately where the rule is deterministic.
Payment-hub rejects
Some checks require richer context:
- account status;
- sanction-screening outcome;
- funding;
- customer entitlement;
- route reachability;
- duplicate detection.
The payment hub should return a reason code meaningful enough for operations and customer channels.
External rejects
A rail or participant may reject because:
- message structure is invalid;
- participant is not reachable;
- payment fails system validation;
- transaction violates a system rule.
The bank should preserve both:
- external technical/business reason;
- translated customer reason.
Do not expose raw infrastructure messages where they are confusing or sensitive.
Repair governance
Repair rules should distinguish:
Safe operational repair
- formatting;
- known branch-code enrichment;
- normalization.
Customer-impacting change
- beneficiary account;
- beneficiary identity;
- amount;
- currency;
- payment purpose in regulated contexts.
The second category often requires fresh authorization or customer confirmation.
Repair ageing
Repair queues need time limits.
A payment stuck in repair across a cutoff can become a date exception.
The case should record:
- entered repair;
- owner;
- reason;
- last action;
- deadline;
- whether customer contacted;
- final outcome.
4. Returns in AFT, PAD and retail batch payments
Payments Canada’s retail-batch framework includes Rule F1 for AFT transactions, Rule F4 for AFT transactions exchanged using ISO 20022 messages, and Standard 007 for transaction and return-reason codes. Rule A4 covers returned and redirected items more broadly. The version-in-force documents in Payments Canada’s rules catalogue are the controlled source; the catalogue records ACSS rule updates effective July 27, 2026.
AFT credit return
Example: payroll credit to a closed account.
Flow:
- employer submits AFT credit;
- originating FI validates and exchanges;
- receiving FI attempts posting;
- account is closed;
- receiving FI creates a return with the correct reason;
- return flows back through the clearing arrangement;
- originator’s FI credits or otherwise accounts for returned value;
- employer receives item-level exception reporting;
- employer corrects master data and pays employee by an appropriate method.
The return is not the same file as the original credit. It is linked to it.
Return reason data
Return codes are operational data, not decorative text.
They drive:
- customer messaging;
- retry eligibility;
- fee handling;
- account-master correction;
- collection strategy;
- reconciliation.
A bank should not map ten different return reasons into one generic “failed.”
PAD returns
PADs are pull transactions supported by a pre-authorized debit agreement and Payments Canada Rule H1.
A PAD may be returned for reasons such as account/funds issues or other valid rule-based circumstances. Under Rule H1 section 22, a dishonoured PAD is returned no later than the Business Day following receipt by the first organizational unit able to decide to dishonour, subject to the applicable A4/F1/F4 procedure. Rule H1 sections 23–24 also distinguish reimbursement claims from ordinary dishonour and set different claim windows for personal, business and other PAD types.
Operationally separate:
- the original debit;
- the return;
- any customer dispute;
- any reimbursement;
- any collector recovery attempt.
A reimbursement to a customer and the bank’s recovery from another party can occur at different times.
Retry is a new control decision
A returned item should not automatically be resent.
Before retry, the bank or originator may need to consider:
- product/rule permission;
- return reason;
- customer instruction;
- mandate validity;
- duplicate risk;
- amount/date;
- customer communication.
For the specific AFT/PAD re-presentment permission, F1 and F4 allow a debit returned for NSF (901) or Funds Not Cleared (908) to be re-presented once, within 30 calendar days of the original debit’s return; a PAD re-presentment must be for the original amount and cannot add charges. A different return reason, a second dishonour, or a customer reimbursement claim needs a different rule/product decision.
A retry should carry its own transaction identity while retaining the business relationship to the original item.
Redirected items
Rule A4 also addresses returned and redirected items.
Operational systems should not assume that a changed routing/account situation allows silent alteration of all future payments. The bank must follow the applicable rule and its customer/product obligations.
5. Lynx finality, returns and misdirected payments
Lynx requires disciplined language because it is a real-time gross settlement system.
Payments Canada Rule 10 is titled Finality and Return. Payments Canada also publishes a Misdirected Lynx Payments guideline.
Finality
A settled Lynx payment is not simply “cancelled” by deleting the sending bank’s booking.
Finality means the inter-participant settlement event has legal and operational effect under the system framework.
If value needs to come back, the return is a separate payment action.
Return timing
Current Rule 10 sets requirements around returns in specified circumstances. Before payee availability, a receiving participant must return or correctly process specified errors under section 2; a sending participant’s error request under section 5 only permits return if the amount has not yet been made available. Required/elected returns under sections 2, 7, 10, 11 or 12 use a new pacs.004 and must be initiated as soon as practicable, normally no later than the end of Settlement Window 1; Rule 10 sections 14–15 contain the late-decision and after-16:00 exceptions. A return above $25 million also requires prompt telephone or email notice to the sending participant’s Lynx Payment Operations contact before return.
Operations should therefore:
- use the current Rule 10 text;
- capture decision time;
- create the appropriate return payment;
- preserve linkage;
- reconcile both legs.
Training material should not turn a rule excerpt into a universal SLA without reading the current rule and the specific triggering circumstance.
Misdirected payment
A misdirected payment can arise from:
- wrong beneficiary account;
- wrong receiving institution;
- stale payment template;
- corporate master-data error;
- manual keying error.
The sending bank should first establish:
- whether the payment was actually sent;
- whether it settled;
- correct receiving participant;
- original references;
- customer authority;
- whether fraud is suspected.
Then the bank follows the applicable recovery/return process.
Do not promise recovery
A customer may say, “I sent it to the wrong account; reverse it.”
A controlled answer is:
- payment state has been confirmed;
- a recovery/return request will be initiated where available;
- recovery may depend on recipient/receiving institution action and applicable law/rules;
- outcome is not guaranteed merely because the request was sent.
Return accounting
Original:
- debit customer;
- settlement outflow;
- fee/FX entries as applicable.
Return:
- new settlement inflow;
- credit customer or suspense according to policy;
- separate fee/FX treatment;
- separate statement entry.
The original payment should not disappear.
6. Recalls, cancellation requests and recovery
A recall is best modelled as a case object linked to a payment.
Recall attributes
Useful fields:
- recallCaseId;
- originalPaymentId;
- externalReference/UETR where relevant;
- request reason;
- initiator;
- requested amount;
- date/time;
- receiving institution;
- current status;
- response;
- returned amount;
- settlement reference of return;
- customer communication status.
Full and partial recovery
A recovery case may result in:
- full return;
- partial return;
- no return;
- pending legal/fraud process.
Do not force every case into binary successful/failed logic.
Fraud recall
Fraud cases add urgency.
Sequence:
- secure customer/account;
- stop unreleased payments;
- identify affected transactions;
- send recovery requests quickly;
- notify receiving-side fraud contact where appropriate;
- preserve authentication and device evidence;
- assess regulatory/AML reporting separately;
- communicate realistic recovery status.
Sanctions hold versus recall
A payment held before release due to sanctions review is not a recall.
If a payment already settled and a sanctions issue is identified later, escalation may involve legal/compliance actions rather than ordinary payment cancellation.
Cross-border recalls
In correspondent banking, a SWIFT message requesting cancellation or return is still only a message.
Funds may already have:
- settled through correspondent accounts;
- reached beneficiary bank;
- been credited;
- moved onward.
The investigation must separate message status from funds status.
7. Reversals and accounting corrections
Internal accounting is where terminology often becomes misleading.
Example: technical posting failure
Suppose:
- customer account is debited;
- external payment is never released due to technical failure.
The bank may reverse the customer debit.
That is an internal reversal because no external settlement occurred.
Example: external settlement succeeded, posting wrong
Suppose:
- Lynx payment settles;
- bank accidentally posts a duplicate debit internally.
The bank reverses the duplicate internal debit.
It must not reverse the genuine settlement posting.
Example: return received
Suppose:
- original payment settled;
- receiving bank later returns value.
The sending bank posts:
- new incoming settlement;
- new customer credit/recovery;
- link to original.
Calling this simply “reverse original” can destroy audit clarity.
Reversal design
Use compensating entries.
Instead of:
Original transaction deleted
Use:
T100 Original debit -1,000
T101 Reversal of T100 +1,000
Reason: duplicate internal posting
This preserves:
- who posted;
- why;
- when;
- approval;
- relationship.
Fees and FX
A return may not economically equal the original customer experience.
Questions include:
- was an original fee refundable?
- did correspondent charges occur?
- did FX conversion occur?
- must FX be reversed at original or current rate under product terms?
- did beneficiary bank deduct anything?
The payment return and commercial adjustment should be separate concepts.
8. RTR exception and return model
As of October 5, 2026, RTR By-law No. 10 and the RTR Rules are in force (effective August 24, 2026), but Payments Canada still describes launch as Q4 2026 after successful testing and sequenced onboarding. This chapter therefore treats RTR as a legally established but not-yet-live customer production rail at this audit date; it must not be described as already processing live production customer payments.
RTR Rule 7 is titled Funds Availability Exceptions and Returns and was implemented August 24, 2026. It covers both exceptions before payee credit and payment-return requests after settlement. A sending participant may submit one return request within 60 calendar days of exchange, including the original UETR, acceptance date/time, amount and reason; the receiving participant must accept, reject or request an extension within 10 calendar days, with any extension capped at 30 calendar days. This is a scheme rule, not a promise that funds will be recovered.
Why the model matters
In a real-time system:
- validation happens in seconds;
- settlement/finality occurs quickly;
- beneficiary funds availability is expected rapidly;
- fraud recovery windows are compressed.
There is very little space for a traditional “repair after send.”
Pre-exchange failure
If the sending participant rejects before introducing the payment into the RTR exchange:
- no interbank payment has settled;
- customer should receive a clear non-completion status;
- any temporary debit/reservation must be released or corrected.
Post-settlement return
Once settled, recovery is a return process governed by the RTR framework, not an internal cancellation.
The original real-time transaction remains final according to the applicable rules; the return is separately recorded.
Funds availability exception
Rule 7 specifically addresses circumstances where the receiving participant is relieved of normal funds-availability obligation and the related return handling.
Banks implementing RTR should map:
- condition;
- evidence;
- timing;
- message;
- customer account action;
- return action;
- investigation;
- reconciliation.
Fraud return request
A fraud complaint does not mean the original transaction can be “unsettled.” Under RTR Rule 7, authorized-fraud and unauthorized-RTR-payment are permissible return-request reasons, but the request remains distinct from an accepted request and a settled returned amount.
The operations model should:
- identify original UETR/reference;
- open fraud case;
- initiate rule-supported recovery/return interaction;
- coordinate with receiving participant;
- record amount recovered;
- reconcile a successful returned payment independently.
Uncertain outcome
A real-time timeout is not the same as failure.
If the channel does not receive a response:
- do not automatically resend;
- query/reconstruct state;
- use idempotency;
- determine whether settlement occurred;
- then decide customer/account treatment.
That principle prevents duplicate real-time payments.
9. Customer communication and case ownership
The customer sees one payment. The bank sees multiple operational events.
The status model should translate without lying.
Suggested customer-facing language
| Internal situation | Better customer status |
|---|
| Validation failed | Could not be sent |
| Under repair/manual review | We are reviewing this payment |
| Future payment cancelled | Cancelled before sending |
| Recall initiated | Return requested |
| Return accepted but not yet received | Return in progress |
| Return settled | Funds returned |
| Recovery unsuccessful | We could not recover the funds |
| Technical timeout | Status being confirmed |
Avoid:
- “reversed” when only a recall was sent;
- “refunded” when bank has not credited customer;
- “cancelled” after final settlement;
- “failed” when status is unknown.
Ownership
A practical queue model:
Payments operations
- rejects;
- repairs;
- rule-based returns;
- routing errors.
Fraud operations
- scam/ATO recovery;
- mule coordination;
- urgent recall.
Sanctions/compliance
- blocked/held transactions;
- legal restrictions.
Investigations
- missing/duplicate/misdirected payments;
- interbank inquiry.
Finance/reconciliation
- unmatched settlement/ledger items;
- suspense.
Customer service
- communication, not technical disposition.
The case owner coordinates; they do not necessarily execute every action.
10. Architecture, identifiers and reconciliation
Exception processing should be event-based.
Core data model
Payment
├─ paymentId
├─ customerReference
├─ externalReference/UETR
├─ rail
├─ amount/currency
└─ currentState
ExceptionCase
├─ caseId
├─ originalPaymentId
├─ exceptionType
├─ reason
├─ openedAt
├─ owner
└─ status
CorrectivePayment
├─ correctivePaymentId
├─ originalPaymentId
├─ caseId
├─ amount
├─ direction
└─ settlementEvidence
This is stronger than editing the original payment row repeatedly.
Identity preservation
Keep:
- original transaction ID;
- original end-to-end/customer reference;
- UETR where relevant;
- return payment ID;
- case ID;
- external return reason.
A reconciliation engine should be able to traverse the chain.
One-to-many
One original payment may produce:
- multiple investigation messages;
- partial recoveries;
- fee refunds;
- separate FX adjustment.
The data model must permit one-to-many relationships.
Reconciliation layers
For exceptions, reconcile:
- original instruction;
- original settlement;
- exception case;
- return/recovery settlement;
- customer corrective posting;
- GL entries;
- statement reporting.
A return should close a break only when all financially relevant legs match.
Suspense
Use suspense when the bank has financial evidence it cannot yet allocate.
Examples:
- return settled but customer account closed;
- recovery received without clear original reference;
- amount differs;
- FX discrepancy.
Suspense is not a permanent destination.
Every item needs:
- owner;
- age;
- root cause;
- expected action.
11. Practical exception scenarios
Scenario A: payroll credit to closed account
A fictional company sends 1,000 payroll credits.
999 post successfully.
One receiving bank cannot post because the employee account is closed.
The receiving bank returns the item using the applicable AFT return reason.
The employer’s bank receives the returned item and:
- matches it to original payroll instruction;
- posts returned funds;
- informs employer at item level;
- keeps the other 999 payments completed.
Correct classification:
- not “whole payroll rejected”;
- not “recall”;
- not “reversal” of all file activity;
- one returned AFT credit.
Scenario B: customer sends Lynx payment to wrong beneficiary
The customer authorized the payment correctly but selected an obsolete beneficiary account.
The bank confirms:
- instruction was authorized;
- payment was released;
- Lynx settlement completed.
The customer asks to cancel.
The bank cannot treat final settlement as though it never happened.
It opens a recovery case, follows applicable Lynx procedures/guidance, sends the appropriate request, and tells the customer recovery is being attempted.
If funds return, the returned amount is a new incoming settlement event linked to the original.
Scenario C: duplicate internal posting
A bank sends one payment externally but debits customer twice due to a ledger retry defect.
External evidence shows one settlement.
The bank reverses the duplicate internal debit.
No interbank return or recall is required.
Correct classification:
- internal accounting reversal;
- technology incident;
- customer correction;
- no external recovery.
Scenario D: real-time timeout
After RTR launch, a customer initiates a real-time payment.
Channel times out before showing result.
Unsafe design:
Controlled design:
- query state by idempotency/reference;
- determine whether original was accepted/settled;
- if settled, show completion;
- if rejected, release reserved funds;
- if still uncertain, hold customer status as pending and investigate;
- never create second payment unless customer explicitly initiates a new instruction after state is resolved.
Deeper operating practice: build the exception model around financial state
The most reliable exception architecture uses a state machine that separates the customer instruction, the external payment, the settlement event and the corrective event. A single status field is not enough.
Consider a bank that stores only:
status = FAILED
That word cannot answer whether the customer was debited, whether the payment entered a clearing system, whether settlement occurred, whether another institution received funds, whether a return is already on its way, or whether the bank must reimburse the customer from its own funds.
A stronger record stores independent states:
| Dimension | Example values |
|---|
| Instruction | created, authorized, cancelled |
| Bank processing | validating, repair, released |
| External | accepted, rejected, unknown |
| Settlement | not applicable, pending, final |
| Beneficiary | pending, credited, unable to apply |
| Exception | none, inquiry, recall requested, returned |
| Accounting | reserved, posted, corrected, suspense |
The benefit is not database elegance. It is prevention of wrong financial action.
If the external state is rejected and settlement is not applicable, retry may be safe after correcting the cause. If settlement is final and beneficiary is credited, retry is dangerous and recovery must use a separate return or recall process. If settlement is unknown, both retry and customer refund can create financial exposure until state is reconstructed.
Exception eligibility rules
Every exception action should have eligibility conditions.
For example:
Cancel
- instruction exists;
- customer/product permits cancellation;
- payment has not crossed the point where cancellation is no longer supported;
- no contradictory external settlement evidence.
Repair
- field is operationally repairable;
- repair does not change the customer’s economic intent without authorization;
- payment has not been finally released in a form that makes alteration invalid;
- audit captures before/after value.
Recall request
- original payment can be uniquely identified;
- payment is sufficiently progressed that a recall/recovery request is relevant;
- requested reason is valid;
- receiving institution/contact route exists.
Return
- applicable rail/rule permits or requires return;
- receiving institution has made the return decision;
- original reference is available;
- return amount is controlled;
- new settlement/payment event is created.
Internal reversal
- original accounting entry is identified;
- reversal reason is valid;
- maker-checker/automation control is satisfied;
- reversal does not falsely represent external recovery.
Encoding these rules in workflow prevents an operations user from selecting “reverse” merely because that button sounds appropriate.
Original identity and related-event identity
An exception platform should preserve a graph, not a flat history.
Example:
PAY-001 original customer payment
├─ SET-001 original settlement
├─ CASE-009 beneficiary non-receipt inquiry
├─ RECALL-003 recall request
├─ RET-004 returned payment
├─ POST-077 returned customer credit
└─ FEE-012 fee refund
The original payment remains the parent business event.
This matters when:
- a recall is sent twice accidentally;
- partial funds return first;
- a second amount returns later;
- customer receives goodwill fee refund;
- investigation remains open after financial recovery;
- a fraud case and payment case both refer to the same payment.
Reason codes: preserve external truth and customer meaning
Reason-code handling should have at least three layers.
-
External code
The exact scheme/network/participant code.
-
Internal normalized reason
Example: ACCOUNT_CLOSED, INSUFFICIENT_FUNDS, INVALID_ACCOUNT, DUPLICATE, CUSTOMER_REQUEST.
-
Customer wording
Plain language suitable for the product and disclosure rules.
Do not discard external codes after translation.
Operations may need them for:
- rule interpretation;
- trend analysis;
- counterparty discussions;
- audit;
- testing.
At the same time, do not show a corporate customer a cryptic technical code without explanation.
Reject versus return analytics
Reject rate and return rate measure different problems.
High reject rate may indicate:
- channel validation weakness;
- poor reference data;
- formatting defects;
- sanction/fraud policy friction;
- reachability errors.
High return rate may indicate:
- stale beneficiary master data;
- closed accounts;
- weak mandate management;
- collections quality;
- fraud;
- recipient posting problems.
A useful dashboard separates:
| Metric | What it can reveal |
|---|
| Pre-release reject rate | customer/channel data quality |
| External reject rate | integration/routing quality |
| Return rate | downstream/account validity |
| Recall rate | customer error/fraud |
| Recall success | recovery effectiveness |
| Reversal rate | internal posting quality |
| Manual repair rate | STP weakness |
| Duplicate corrective action | control failure |
A single “failed payment rate” hides the operational cause.
AFT operational edge cases
Case: account closed after file creation but before due date
The originator’s data was valid when file was prepared. The receiving account is closed by the time posting is attempted. This is not necessarily an originator-format defect. The return reason should drive customer master-data correction.
Case: invalid routing data detected before exchange
The originating bank may reject the item or file before external exchange. Do not report it as a downstream return.
Case: duplicate payroll file
If detected before release, reject/cancel duplicate. If both files exchanged and credited, the problem is now duplicate payment recovery, not simple file rejection.
Case: return file arrives but original customer account is closed
Returned funds may need suspense/controlled allocation. Do not lose the return because the original debit account no longer exists.
Case: partial file returns
File-level status should remain processed with item-level exceptions. A bank should never describe 5 returned items out of 20,000 as “file failed” if the other items completed.
PAD operational edge cases
PAD is especially sensitive to the distinction among payment return, mandate dispute and reimbursement.
A customer might say:
“I never agreed to this debit.”
That statement triggers questions beyond ordinary insufficient-funds return:
- what PAD agreement exists?
- what evidence was retained?
- was notice required/provided under applicable Rule H1 conditions?
- did the debit match authorized terms?
- is customer exercising a reimbursement right?
- does the originator contest the claim?
The customer may be credited under applicable rules/process before the originator’s financial recovery chain is fully resolved.
Therefore keep:
- debit transaction;
- return;
- reimbursement;
- originator recovery;
- case evidence
as linked but separate records.
Interac operational edge cases
An Interac journey creates different exception language.
Notification not received is not automatically payment failure.
Autodeposit completed to an unexpected account can become a fraud/customer-profile investigation.
Sender wants to cancel depends on whether the transfer is still cancellable under the service state.
Recipient already deposited means recovery is not equivalent to cancelling an outstanding transfer.
The bank’s UI should use service-appropriate wording rather than importing AFT or wire terminology.
Lynx operational edge cases
High-value operations should train explicitly on finality.
Scenario: beneficiary bank says account invalid after settlement
Receiving participant determines treatment under applicable rules/process. A returned amount is a new payment. Sending bank waits for actual return evidence before crediting customer unless it chooses separate customer remediation.
Scenario: customer identifies error seconds after settlement
Speed does not recreate a cancellation right. Open recovery/recall workflow.
Scenario: wrong receiving institution due routing defect
Determine if payment is truly misdirected, then follow current Payments Canada guidance and Rule 10 requirements as applicable.
Scenario: receiving institution needs clarification
Information request is not a return. Keep settlement status unchanged.
Cross-border edge cases
Correspondent banking introduces more states.
A recall message may reach an intermediary while funds already moved to beneficiary bank.
Possible outcomes:
- intermediary stops before onward settlement;
- beneficiary bank returns full amount;
- beneficiary bank returns partial amount after charges;
- beneficiary declines return;
- legal hold;
- funds moved onward.
Therefore the case should record where value was last proven, not simply “SWIFT recall sent.”
RTR readiness edge cases
A real-time design should test at least:
Timeout before exchange acceptance
Status unknown until proven. Do not resend blindly.
Accepted and settled, customer screen says failed
Repair channel status; do not create new payment.
Receiving participant invokes Rule 7 exception
Handle the rule-supported return process and customer status.
Fraud report immediately after settlement
Initiate recovery/fraud workflow; do not describe the original final settlement as cancelled.
Return message duplicated
Idempotent posting prevents customer double credit.
Partial returns and amount controls
A corrective workflow should never assume returned amount equals original amount.
Reasons for difference can include:
- partial recovery;
- charges;
- FX;
- multiple staged recoveries;
- customer reimbursement separate from returned value.
Store:
- original amount;
- requested recovery amount;
- returned amount;
- customer credited amount;
- bank loss/exposure;
- charges.
This is particularly important for fraud analytics.
Customer reimbursement versus interbank recovery
These are separate financial decisions.
Example:
- customer loses CAD 5,000 in disputed payment;
- bank gives customer CAD 5,000 provisional credit;
- receiving institution later returns CAD 3,000;
- bank still has CAD 2,000 exposure.
If operations simply “credits return to customer,” customer gets CAD 8,000.
The case platform must know whether returned value belongs:
- to customer;
- to bank receivable/exposure;
- partly both.
Settlement finality and operational wording
The safest wording library should be reviewed by payments, legal/compliance and product.
Examples:
Instead of reversed wire, prefer:
- return received;
- return requested;
- customer correction posted;
depending on actual event.
Instead of payment failed, prefer:
- instruction rejected before sending;
- external system rejected;
- status being confirmed;
- beneficiary bank could not apply and returned funds.
Language is a control because it determines how staff and customers react.
Maker-checker and privileged operations
High-risk exception actions should use dual control.
Examples:
- manually create high-value return;
- override beneficiary/routing;
- post customer correction;
- close high-value suspense;
- waive/rebook large fee;
- change return reason after submission.
Audit should record:
- maker;
- checker;
- timestamps;
- before/after data;
- justification;
- linked case.
Exception case ageing
Age from two perspectives:
Operational age
Time case has been open.
Financial age
Time unresolved money has remained in suspense/exposure.
A low-value informational inquiry can remain open longer than a high-value unmatched settlement.
Suggested severity factors:
- final settlement mismatch;
- customer funds trapped;
- fraud;
- regulatory/legal;
- value;
- repeat defect;
- approaching rail deadline.
Root cause and prevention
Every exception should eventually belong to a preventable or non-preventable root cause.
Examples:
- customer data;
- stale beneficiary master;
- bank validation defect;
- routing reference-data defect;
- external participant;
- scheme/network issue;
- ledger defect;
- duplicate retry;
- fraud/scam;
- sanctions/compliance;
- expected account closure/return.
Trend analysis should drive:
- validation improvements;
- channel warnings;
- reference-data updates;
- fraud rules;
- automation;
- training.
Detailed test catalogue
A strong test pack for exception management includes more than happy-path return.
Pre-release
- invalid beneficiary;
- invalid date;
- insufficient funds;
- sanctions hold;
- manual repair;
- customer cancels.
External acceptance
7. message validation reject;
8. participant unavailable;
9. timeout before acknowledgement;
10. duplicate external send.
Post-settlement
11. beneficiary account closed;
12. misdirected payment;
13. recipient refuses return;
14. partial return;
15. duplicate return.
Accounting
16. customer debited twice;
17. return credited twice attempt;
18. return received to closed account;
19. fee refund separate;
20. FX amount differs.
Fraud
21. recall after scam;
22. full recovery;
23. partial recovery;
24. no recovery;
25. provisional customer credit before recovery.
Continuity
26. exception service outage;
27. delayed return file;
28. case reopened after late response;
29. accounting day rollover;
30. disaster-recovery replay.
Each test should assert:
- original state unchanged;
- corrective event identity;
- customer status;
- ledger;
- reconciliation;
- audit trail.
Production monitoring
Monitor anomalies such as:
- sudden rise in one return code;
- returns missing original references;
- unusually high manual reversals;
- high recall failure;
- operators using generic reason disproportionately;
- returned amount not matching case;
- customer credited before return with no exposure record;
- cases closed with uncleared suspense.
A spike can indicate:
- upstream channel defect;
- fraud campaign;
- reference-data issue;
- participant problem;
- release defect.
Operational runbook: before taking money action
Before any manual corrective posting, the operator should answer:
- Which original payment is this?
- What external state is proven?
- Is settlement final?
- Is this a request or an actual returned-value event?
- Has customer already been reimbursed?
- Is another corrective transaction already in flight?
- What amount/currency is actually available?
- Which rule/product policy authorizes action?
- What accounting template applies?
- Who approves?
- What will the customer see?
- How will reconciliation prove closure?
If any answer is unknown, financial action should normally wait or escalate.
Architecture pattern: orchestration without loss of rail detail
Banks often want one exception service across all payment types.
That is useful only if the common layer does not erase rail-specific rules.
A good design has:
Common services
- case ID;
- ownership;
- SLA;
- customer communication;
- accounting integration;
- audit;
- documents.
Rail adapters
- AFT return reasons;
- PAD rules;
- Lynx Rule 10;
- Interac service states;
- cross-border messaging;
- RTR Rule 7.
The common platform orchestrates. Rail adapters determine eligibility and message semantics.
Final operational principle
The best exception teams do not “fix payments.” They preserve the truth of what already happened and create the correct next event.
That mindset protects:
- settlement finality;
- customer balances;
- audit;
- investigations;
- regulatory evidence;
- reconciliation.
Role-by-role operating model
Exception handling becomes much clearer when each team knows which decision it owns.
Customer channel
- captures cancellation/recall request;
- shows current payment status;
- prevents duplicate customer resubmission;
- does not claim recovery before confirmed.
Payment hub
- preserves original state;
- enforces action eligibility;
- creates corrective transaction;
- maintains relationships.
Payments operations
- interprets rail state;
- manages repair/return/recall workflow;
- contacts participant;
- monitors ageing.
Fraud
- classifies unauthorized versus scam;
- coordinates urgent recovery;
- protects account;
- captures fraud evidence.
Compliance
- decides sanctions/AML escalation;
- prevents unsafe repair;
- owns regulatory interpretation.
Treasury
- understands settlement/liquidity impact;
- confirms funding for corrective payments where needed.
Accounting/reconciliation
- posts/corrects;
- matches returned value;
- clears suspense.
Customer service
- communicates accurately;
- does not substitute customer goodwill decision for actual interbank state.
Action eligibility matrix
| Original state | Cancel | Repair | Recall request | Return | Internal reversal |
|---|
| Created | usually possible | possible | no | no | reservation only |
| Authorized, not released | product-dependent | controlled | no | no | possible correction |
| Released, externally rejected | no need | resubmit after correction | generally no | no | correct customer posting |
| Accepted, not final | rail/state-dependent | generally no mutation | may be relevant | rail-dependent | only internal error |
| Settled | no | no | yes where process supports | receiving-side/process action | only separate accounting error |
| Returned | original remains | no | normally closed | return already happened | post corrective entry if needed |
The matrix is conceptual, not a replacement for rail rules.
The “money location” method
When terminology is confusing, ask where the money is.
Still on sender account
Likely reject/cancel/repair.
Debited customer but not externally settled
Internal pending/correction risk.
Settled to receiving institution
Recall/recovery/return process.
Credited beneficiary
Recovery now depends on receiving-side action and circumstances.
Returned to sending institution
Post/reconcile corrective value.
This method is especially useful for customer-service escalation.
What not to do
Do not:
- mark a settled payment “cancelled”;
- delete original transaction;
- resend after timeout without state proof;
- credit customer twice after provisional reimbursement;
- change beneficiary data after authorization without required consent;
- collapse fraud recovery into normal return queue;
- close case because recall was acknowledged;
- force unmatched return into random customer account;
- use manual journal to hide settlement break.
Control evidence pack
For a material exception, retain a compact evidence pack:
Original instruction
Authorization evidence
Original payment/message
External acceptance
Settlement evidence
Exception reason
Recall/return communication
Corrective payment
Customer posting
GL/reconciliation result
Customer communication
Approvals
An auditor should reconstruct the case without asking the original operator to remember it.
Bank-implementation user stories
As a payments operator, I want the system to block “cancel” after final settlement so that I cannot perform an invalid action.
As a fraud analyst, I want one-click access to original payment identity and receiving institution so that urgent recovery starts quickly.
As a reconciliation analyst, I want returned settlement automatically linked to original case so that customer correction is not missed.
As customer service, I want plain-language exception status so that I do not tell customer that funds are recovered before they are.
As a product owner, I want return/reject analytics by reason so that upstream data-quality issues can be fixed.
Data-quality controls for exceptions
Mandatory fields:
- originalPaymentId;
- exceptionType;
- externalReason;
- normalizedReason;
- amount/currency;
- rail;
- event timestamp;
- owner.
Conditional:
- settlement reference for post-settlement;
- recall reference for recall;
- return payment ID for return;
- original posting ID for reversal.
Validation:
- return amount cannot be negative;
- currency valid;
- original exists;
- duplicate return identity rejected;
- reason applicable to rail.
Manual exception risk
Manual actions are needed for unusual cases but increase operational risk.
Common failures:
- wrong original payment selected;
- wrong amount;
- wrong beneficiary/account;
- duplicate return;
- wrong reason code;
- reversal after customer already credited;
- wrong business date.
Controls:
- search by strong identity;
- display original summary prominently;
- confirmation screen;
- maker-checker;
- amount cap;
- idempotency;
- post-action reconciliation.
Exception automation maturity
Level 1
Email/spreadsheet/manual journals.
Level 2
Case system but disconnected from payment/ledger.
Level 3
Integrated state view, standardized actions.
Level 4
Automated return matching, eligibility, accounting.
Level 5
Predictive anomaly detection and root-cause analytics with human control for high-risk decisions.
Maturity should increase safety, not just speed.
Operational controls by lifecycle phase
Before payment
- validate reference;
- duplicate control;
- account status;
- mandate/authority;
- fraud/sanctions.
During payment
- idempotent send;
- acceptance tracking;
- settlement tracking.
After payment
- return/recall workflow;
- customer status;
- reconciliation.
The cheapest exception is prevented before release.
Customer-experience design
A good exception UI answers:
- What happened?
- What are we doing?
- Is money currently returned?
- Should customer do anything?
- When will next update occur?
Examples:
Rejected
“We could not send this payment because the beneficiary account details were invalid. No payment was completed.”
Recall requested
“We have asked the receiving institution to return the payment. The funds have not yet been recovered.”
Returned
“The receiving institution returned the payment and we have credited your account.”
Avoid legal conclusions unless approved.
Corporate API/status model
Corporate customers may consume status through an API/file. The following are illustrative internal status values (or a bank’s mapping of external statuses), not a claim that every rail exposes these exact codes:
Design distinct codes:
- RJCT;
- PENDING_REPAIR;
- SENT;
- SETTLED;
- RETURN_REQUESTED;
- RETURNED.
If using ISO 20022 status messages, map carefully to internal business semantics and product rules.
Do not invent nonstandard meanings in external ISO codes.
Exception reporting to product owners
Monthly review should show:
- top reject reasons;
- top return reasons;
- customer segments;
- channels;
- receiving institutions;
- time-of-day;
- repeat beneficiaries;
- manual touch rate.
This can reveal:
- bad UI;
- outdated routing directory;
- corporate master-data issue;
- fraud pattern;
- external participant problem.
Lessons from duplicate-payment incidents
Duplicate incidents often follow:
- timeout;
- system assumes failure;
- retry;
- original succeeds late;
- both settle.
Prevention:
- idempotency;
- state query;
- no blind retry;
- unique external identity.
Recovery:
- identify both settlements;
- determine intended one;
- recall duplicate;
- decide customer correction;
- reconcile.
Lessons from wrong-beneficiary incidents
Wrong beneficiary can originate:
- customer;
- employee;
- compromised vendor email;
- bank enrichment;
- routing table.
Root cause determines prevention.
Confirmation of payee may help in real-time context but does not make fraudulent invoice legitimate.
Lessons from return-processing incidents
Common defects:
- return file not consumed;
- wrong reason mapping;
- return posted to suspense and aged;
- duplicate return credit;
- return reference lost.
Controls:
- monitor expected return intake;
- match automatically;
- alert unmatched;
- reconcile.
Exception continuity
During DR:
- preserve cases;
- preserve related event IDs;
- preserve action eligibility;
- do not replay manual return commands blindly.
After recovery:
- query whether corrective transaction already executed before reissuing.
Exception security
Privileged users can move money via corrective actions.
Security:
- least privilege;
- MFA;
- session monitoring;
- command audit;
- segregation of duties;
- alerts for unusual manual returns/reversals.
Policy-versus-system distinction
A bank may choose stricter controls than rail minimum.
Example:
rail permits action under condition, but bank requires second approval above threshold.
Training should separate:
- mandatory rail requirement;
- bank policy;
- product choice.
Final readiness checklist
Before declaring exception capability ready:
- every rail has taxonomy;
- state machine prevents invalid action;
- current rulebook linked;
- return/reason codes maintained;
- accounting templates tested;
- customer wording approved;
- fraud/compliance escalation tested;
- reconciliation matches corrective events;
- dashboards exist;
- DR preserves cases;
- manual action reviewed;
- no placeholder/generic “reverse” button without semantics.
Practitioner review: classify these before acting
Customer says “cancel my payment” and the bank has settlement evidence.
Classification: post-settlement recovery request, not cancellation. The operator should explain that the bank can request return/recovery where available but cannot rewrite the final settlement state.
Customer account was debited, gateway rejected before external acceptance.
Classification: internal corrective accounting plus failed/rejected payment. No receiving-bank recall is required.
Receiving participant says “we are returning funds” but no return settlement exists yet.
Classification: return expected/in progress. Customer credit depends on actual recovery or separate bank reimbursement policy.
Bank credited customer provisionally for fraud, then full external recovery arrives.
Classification: recovered value should normally clear the bank’s fraud/recovery exposure rather than automatically create a second customer credit.
Operations sees a duplicate statement debit but external records show one payment.
Classification: internal posting/statement investigation, not payment recall.
Questions a business analyst should put into requirements
- What is the exact point of no cancellation for each rail?
- Which fields can operations repair without customer re-authorization?
- Which return reasons are valid per product?
- Can returns be partial?
- How is recall status represented separately from recovery status?
- How do we prevent duplicate recalls/returns?
- How do we know customer has already been reimbursed?
- What is the accounting treatment for returned value?
- How are fees and FX handled on return?
- What customer wording maps to each state?
- Which actions require maker-checker?
- What happens during DR/replay?
- Which reference is used to reconcile original and corrective transactions?
These are functional requirements, not implementation decoration.
Tester-focused acceptance examples
A test should assert both state and money.
Test: rejected before send
- external settlement count = 0;
- customer final debit = 0;
- status = rejected;
- no recall available.
Test: settled then returned
- original settlement remains final;
- return has separate ID;
- customer credit occurs once;
- both entries visible;
- reconciliation closes both legs.
Test: duplicate return message
- second message does not credit customer again;
- duplicate logged;
- case remains consistent.
Test: recall rejected
- original payment remains settled;
- customer not falsely credited;
- case outcome updated.
Operations training quiz
- A recall request is sent. Has the money returned? No.
- A settled Lynx payment is wrong. Can the bank delete settlement? No.
- An AFT item is returned. Should the original payment be erased? No.
- A customer debit was duplicated internally. Must the beneficiary return money? Not if only one external payment occurred.
- A real-time payment times out. Should it be sent again? Not until original state is proven.
The repeated discipline is deliberate: state first, action second.
Final failure-mode matrix
| Failure mode | Wrong reaction | Controlled reaction |
|---|
| Customer cancels after final settlement | mark cancelled | open recovery/return request |
| Timeout after send | resend | query original state |
| Recall acknowledged | credit customer | wait for recovery or separate reimbursement decision |
| Return arrives twice | post twice | idempotent duplicate rejection |
| Customer reimbursed, then return arrives | credit again | clear bank exposure as applicable |
| AFT file partly returned | fail whole file | preserve item-level outcomes |
| Ledger duplicate only | recall beneficiary | reverse internal duplicate |
| Wrong beneficiary due fraud | standard queue | urgent fraud/recovery escalation |
This matrix is useful in operations training because most serious exception losses start with a wrong classification rather than a complex technical defect.
Knowledge check
Why is a return normally a new event?
Because the original transaction may already have progressed or settled. The corrective movement must preserve original history and create its own identity and accounting evidence.
Why is a recall not recovery?
Because it is a request. Financial recovery exists only when returned value or another authorized reimbursement is actually posted.
Why keep external reason and normalized reason?
The external reason preserves scheme truth. The normalized reason supports consistent internal workflows and analytics.
Why are retries dangerous after a timeout?
Because the original may have succeeded even though the response was lost.
Why should customer reimbursement be separate from return?
The bank can reimburse before, after or without successful interbank recovery. The two financial events may belong to different accounts/exposures.
Chapter 67 practical takeaway
When an exception occurs, the safest operator can state four facts before taking action:
- Original state — where the payment reached.
- Financial state — where value currently sits.
- Permitted action — what the rail/product allows next.
- Evidence of completion — what will prove the correction really happened.
That discipline is the difference between controlled exception handling and accidental double payment.
End-to-end control scenario: one payment, four possible exception outcomes
Take a fictional CAD 90,000 supplier payment created by a corporate customer.
The bank validates the customer, account, beneficiary, limits and controls. From that single starting point, four different outcomes can occur, and each requires different language and accounting.
Outcome A — rejected before external release.
The beneficiary routing data fails validation. The bank rejects the instruction before the payment leaves the bank. Any reservation is released. There is no interbank settlement and therefore nothing to recall. The customer can correct the beneficiary and create or re-authorize a valid payment according to the product process.
Outcome B — externally accepted but not yet finally settled.
The payment has crossed the internal release boundary. Whether it can still be stopped depends on the rail and actual state. Operations must not assume that an internal “cancel” command can reach or override the external system. The bank establishes whether a supported cancellation/intervention mechanism still exists.
Outcome C — settlement is final, customer reports an error.
The original payment remains part of the immutable history. The bank opens a recall/recovery case, preserving the settlement reference. A successful response later creates a separate return transaction. Until returned value is received, “return requested” and “funds recovered” remain different states.
Outcome D — external settlement is correct but customer is debited twice internally.
No interbank recovery should be attempted for the duplicate internal debit. The bank reverses the incorrect ledger entry under a controlled accounting process and reconciles one external payment against one intended customer payment.
The four outcomes show why the same customer sentence—“please reverse it”—cannot be translated into one system action.
Designing exception reason hierarchies
A practical reason model can have four levels:
Domain
→ Category
→ Specific cause
→ External code
Example:
PAYMENT_EXCEPTION
→ RETURN
→ ACCOUNT_CLOSED
→ <applicable external return code>
Another:
PAYMENT_EXCEPTION
→ INTERNAL_CORRECTION
→ DUPLICATE_LEDGER_POSTING
→ no external code
This hierarchy lets operations aggregate trends without losing scheme-level precision.
Exception controls for bulk files
Bulk payments require both file-level and item-level state.
A file can be:
- structurally rejected;
- accepted with all items;
- accepted with item-level exceptions;
- processed with later item returns.
A robust design stores:
File
├─ Item 1 → settled
├─ Item 2 → returned
├─ Item 3 → settled
└─ Item 4 → rejected before release
The file summary should be derived from its items, not used to overwrite them.
Corporate reporting should let the originator identify exactly which employees or suppliers require action.
Exception controls for scheduled and future-dated payments
Future-dated payments create a wider cancellation window but also more state transitions.
Possible states:
- scheduled;
- pending authorization;
- authorized for future date;
- released to processing;
- externally sent;
- settled.
The bank should define at which transition the customer can self-cancel.
A future date does not guarantee cancellation remains available if the bank has already started irrevocable external processing.
Customer-error versus bank-error accounting
The operational cause can affect commercial treatment.
Customer error may lead to:
- recall request;
- possible recovery fee;
- no guaranteed reimbursement.
Bank error may lead to:
- bank-funded correction;
- fee refund;
- compensation under policy;
- incident/root-cause remediation.
The payment state still determines the technical corrective process. Liability and compensation are separate decisions.
Return message versus return of value
A payment-return message is meaningful only in the context of the rail’s settlement process.
Operations should ask:
- Has the corrective payment been accepted?
- Has it settled?
- What amount settled?
- Which currency?
- Has customer or bank exposure been credited?
The presence of a message object alone should not trigger blind customer credit.
Operational evidence for partial recovery
Suppose CAD 90,000 was sent in a fraud case and only CAD 25,000 is recovered.
The case should show:
Original amount 90,000
Recovery requested 90,000
Returned value 25,000
Customer reimbursement <policy outcome>
Residual exposure 65,000 before other adjustments
This enables accurate fraud-loss and recovery reporting.
Exception-service non-functional requirements
A bank-grade service should support:
- high availability appropriate to the underlying rail;
- idempotent commands;
- immutable audit history;
- role-based access;
- maker-checker for privileged actions;
- event sequencing;
- retry-safe integration;
- time-zone-aware timestamps;
- disaster-recovery consistency;
- searchable historical cases.
Performance requirements should reflect the payment type. An instant-payment fraud recovery case needs faster creation than a low-priority historical statement inquiry, but both require the same integrity principles.
Chapter 67 final practitioner checklist
Before action, confirm:
- exact original transaction;
- current financial state;
- rail-specific rule;
- requested corrective action;
- amount/currency;
- prior reimbursement;
- prior return/recall;
- required approval;
- customer wording;
- reconciliation path.
After action, confirm:
- corrective event created once;
- external response captured;
- returned value, if any, settled;
- customer/accounting treatment complete;
- original history preserved;
- case closed only after reconciliation.
12. Implementation, testing and authoritative references
Implementation checklist
A production-ready exception service should support:
- state-aware action eligibility;
- rail-specific reason codes;
- original-reference preservation;
- recall/return case workflow;
- partial recovery;
- duplicate prevention;
- maker-checker for high-risk manual actions;
- accounting templates;
- customer status mapping;
- interbank contact management;
- SLA/ageing;
- investigation notes;
- audit logging;
- reconciliation.
Test scenarios
Test at minimum:
- reject before authorization;
- reject after authorization but before release;
- external reject;
- repair then release;
- customer cancellation before send;
- AFT return;
- PAD return;
- duplicate return;
- return without original reference;
- Lynx return;
- recall rejected;
- partial recovery;
- internal ledger reversal;
- fee-only reversal;
- timeout with payment actually settled;
- duplicate retry after timeout;
- fraud recall;
- sanctions hold;
- customer account closed before return received;
- return after accounting date rollover.
Quality questions
Before release, ask:
- Can the bank prove the original payment state?
- Can it distinguish request from financial recovery?
- Can it preserve final settlement history?
- Can it explain the event to a customer without misleading words?
- Can it reconcile the original and corrective entries?
- Can it stop duplicate corrective actions?
- Can an auditor reconstruct who approved every manual action?
If not, the exception process is incomplete.
Authoritative references
- Payments Canada — Rules & documentation (version-in-force catalogue; ACSS updates effective July 27, 2026): https://www.payments.ca/systems-services/rules-documentation
- Payments Canada — Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions: https://payments.ca/sites/default/files/f1eng.pdf
- Payments Canada — Rule F4, Rules Applicable to AFT Transactions Exchanged Using ISO 20022 Messages: https://payments.ca/sites/default/files/f4eng.pdf
- Payments Canada — Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files: https://payments.ca/sites/default/files/standard007eng.pdf
- Payments Canada — Rule A4, Returned and Redirected Items: https://payments.ca/sites/default/files/a4eng.pdf
- Payments Canada — Rule H1, Pre-Authorized Debits (PADs): https://payments.ca/sites/default/files/h1eng.pdf
- Payments Canada — Lynx Rule 10, Finality and Return (2026 version): https://www.payments.ca/sites/default/files/rule_10_finality_and_return.pdf
- Payments Canada — Lynx system page and participant/settlement model: https://www.payments.ca/systems-services/payment-systems/high-value-payment-system-lynx
- Payments Canada — Misdirected Lynx guideline listing: https://www.payments.ca/rules-updates-2022
- Payments Canada — Lynx ISO 20022 resources: https://www.payments.ca/payment-resources/iso-20022/high-value-payment-system-lynx
- Payments Canada — RTR rules catalogue (Rule 7 effective August 24, 2026): https://www.payments.ca/systems-services/rules-documentation?field_rules_type=3
- Payments Canada — RTR Rule 7, Funds Availability Exceptions and Returns: https://www.payments.ca/sites/default/files/rtr_rule7.pdf?v=1787337847
- Payments Canada — RTR Rule 8, Clearing, Settlement, Funding and Defunding: https://www.payments.ca/sites/default/files/rtr_rule8.pdf?v=1787573995
- Payments Canada — RTR system page (Q4 2026 launch): https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- Payments Canada — RTR testing and sequenced launch: https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/testing-and-launch
- Payments Canada — RTR PSP participation, finality and access model: https://www.payments.ca/connect/membership/payment-service-provider-participation
- Bank of Canada — Settlement account policies for Payments Canada systems: https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/
- Bank of Canada — RTR settlement-account access policy (funding/defunding via Lynx): https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/bank-canada-settlement-account-access-policy-real-time-rail/
- Interac — Personal FAQs (cancellation after deposit and cancellation workflow): https://www.interac.ca/en/resources/personal-resources/personal-faq/
- FCAC — Resolving an unauthorized transaction: https://www.canada.ca/en/financial-consumer-agency/services/resolving-unauthorized-transaction.html
- FINTRAC — Travel rule for electronic funds and virtual currency transfers: https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/travel-acheminement/1-eng
- Department of Finance Canada — Retail Payment Activities Act: https://www.canada.ca/en/department-finance/corporate/transparency/access-information-privacy/reports/rpaa-laapd.html
- Justice Canada — Payment Clearing and Settlement Act (current to September 21, 2026): https://laws-lois.justice.gc.ca/eng/acts/P-4.4/
- Canada Gazette — Canadian Payments Association By-law No. 10 — RTR: https://gazette.gc.ca/rp-pr/p2/2026/2026-07-01/html/sor-dors133-eng.html
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.