Irrevocable payments

What EFT Rails does

On EFT Rails, a payment whose sending failed with no answer from the bank shows as unknown: it may already be on its way, so it must not be sent again. Failed means it definitely did not happen. The API reference documents the states. You can give each user an approval limit so a payment above it waits for a second person, and changing where an existing counterparty's money goes also needs a second person's approval. An Interac e-Transfer EFT Rails receives is final and is not held, because it cannot be taken back.

When each payment is final

Payment finality tells you when money can no longer be pulled back and what process remains if something went wrong. The Real-Time Rail (RTR), Lynx and electronic funds transfer (EFT) payments reach that point differently.

The return process and its records are covered in EFT returns and reconciliation. For the timing and use of each payment method, see EFT versus wire transfer.

Before the money reaches the payee

A receiving bank can still return a real-time payment before it makes the money available to the payee. It must start that return by its next business day when it finds a duplicate, an error or omission that prevents it from crediting the account, a foreign-currency account it will not convert, malicious or harmful content, a restriction on the payee or account, a law or court order, or a request from the payee.⁷

These returns happen before the payee has the money. A technical failure beyond the receiving bank's control works differently: the credit is delayed until its systems are restored, and the bank must make the money available as soon as reasonably practicable after that.⁸

After the money reaches the payee

Once the payee has the money, a return is limited to specific circumstances. The receiving bank may return it for a processing error, an error by the payor, an unauthorized payment, fraud that tricked the payor into sending it, a payee who has died, or a legal requirement to remove the money, and it must start the return as soon as reasonably practicable.⁹

An error by the payor produces a duplicate, a payment to the wrong place or the wrong amount. A processing error is the same kind of outcome caused by a bank's systems. An unauthorized payment is started by someone who was not allowed to start it, while the fraud case covers a payor who authorized the payment because someone posed as the intended payee.¹⁰

A return requested or authorized by the payee must be started within 90 calendar days of the original payment. The rules also leave anyone involved free to seek recourse outside them.¹¹

Asking for money back

A sender starts by asking its bank to request the money back from the receiving bank. The sending bank can make one request for the original payment within 60 calendar days, for the payor's request, a processing error, an error by the payor, fraud or an unauthorized payment.¹² The formal message is a Payment Return Request, called a return request here.

The receiving bank must answer within 10 calendar days by accepting, refusing or asking for more time. An extension can give it up to 30 calendar days, and no answer by then counts as a refusal.¹³

A refusal must give a reason: insufficient funds, a closed account, money already returned, the payee's decision, no answer from the payee, or other. The receiving bank may also ask the sending bank for an indemnity against loss, costs or damages before it returns the money.¹⁴

Checks before you send

The checks before a real-time payment determine whether the money goes to the intended payee for the intended amount. A receiving bank may rely on the account number to credit a payment that identifies the payee by both name and account number, and doing so meets its obligation to make the payment available.¹⁵ Check the account number as carefully as the name.

The sending bank must authenticate the payor. A central tool called Central Confirmation of Payee also checks the payee's name against the account number before the payment is sent.¹⁶

The unique reference, formally a unique end-to-end transaction reference (UETR), must also be new. Reusing one within 90 calendar days causes the payment to be rejected as a duplicate.¹⁷

Confirm who the payee is and verify the amount before approval. Use a second approver, and never send a replacement for a payment whose fate is unknown. The distinction between a rejection before processing and a return afterwards is explained in EFT reject versus return.