PAD dispute windows

What EFT Rails does

You hold the pre-authorized debit (PAD) agreement with your customer.

A returned payment appears as returned. Payment status and return details are read through the API and in the dashboard. The API reference documents the API.

How long your customer has

The time available for a claim depends on the kind of debit and the reason for the claim. The payor is your customer, and you are the payee. A reimbursement claim asks the payor's bank to repay a debit on one of the recognized grounds. Confirmation and pre-notification refer to notices required for the debit.

For these windows, a Personal PAD keeps its treatment if it is mixed with a Business, Funds Transfer or Cash Management PAD, or if it was miscoded as a Business PAD.³

After the window, the payor and payee must resolve the claim between themselves outside the payments rules. The debit cannot be returned through those rules.⁴

When your customer makes a claim

The payor's bank takes the claim, reimburses the customer and handles the return. For a claim within the Personal, Funds Transfer or Business PAD window, the bank reimburses the payor immediately on a best-efforts basis.¹ For a claim that no agreement existed, the bank reimburses the payor promptly and returns the debit.²

The bank obtains the claim as a signed statement or an authenticated communication made electronically or by telephone, then retains it.⁵ It keeps the claim for at least 12 months from the date the debit was returned. A copy can be requested through the banks. The payor's bank must provide the copy within 30 calendar days of receiving the request or reimburse the amount of the claim.⁶

The payee's bank must honour the return and provide recourse for its amount.¹

When the debit comes back to you

The debit comes back to you and shows as returned in the API and the dashboard.

The customer's bank returns the debit with a code for the ground of the claim: 915 means no agreement existed. For a Personal PAD, code 916 means the debit did not follow the agreement, code 917 means the agreement was revoked, and code 918 means no required confirmation or pre-notification was given. Codes 919, 920 and 921 carry the same respective meanings for a Business PAD.⁷

If you dispute the validity of the customer's claim, resolve that dispute directly with the payor outside the payments rules. Any claim for interest connected with the return is also resolved outside those rules.⁸

Read the EFT return codes guide for the other return codes.

When a debit bounces instead

A dishonoured debit is a debit the payor's bank sends back for a payment problem such as insufficient funds, a stop payment or a closed account. It is a different return from a claim. The payor's bank must return it by the next business day after the office that decides on it receives it.⁹

Only a debit returned for insufficient funds, code 901, or funds not cleared, code 908, can be presented again, and only once. A debit returned on a customer's claim cannot be presented again.¹⁰

See the guide to handling NSF returns for that process.

Be ready for a claim

Good records let you answer a claim with the agreement and notices that support the debit. Keep the PAD agreement, evidence of authorization and the records needed to trace a debit for at least 12 months after the last PAD. When the payor's bank requests a copy of the agreement or authorization evidence on reasonable grounds, your bank must make every reasonable effort to obtain and provide it.¹¹

Money collected by PAD can still come back on a claim until its window passes. Keep the agreement and notices where you can find them, together with the payment reference and collection history.

Use the PAD pre-notification guide when preparing notices and the PAD agreement guide when preparing the agreement.