Interac Canada: e-Transfer and Limits

1) Interac's context and place in the payment ecosystem

Interac e-Transfer is a popular P2P/P2B/P2M rail within Canada that operates through banks and credit unions. Payment is sent to the recipient's email/phone number or directly to their bank account via Autodeposit. Transfers are close to instant and available 24/7, with final creditworthiness and limits depending on the specific financial institution (FI).

• Addressing without details: sending by email/phone; the recipient selects the bank to be credited.
• Autodeposit - Automatically credits the recipient's account without a security question.
• Request Money: a "request for payment" with the amount and purpose, is confirmed with the payer.
• Native accessibility: Supported by most Canadian banks in mobile/online banking.
• Fees and limits are determined by banks/account plans, not a single "scheme."

2) Members and roles

Interac - network operator, routing and service rules.
Payer FI (Sender FI) - initiates the transfer, applies KYC/AML, limits and anti-fraud.
Recipient FI (Recipient FI) - credits funds, serves Autodeposit/Request Money.
Payer - an individual/business paying by email/phone/request.
Merchant is a business recipient; can use Autodeposit and/or e-Transfer for Business corporate functions from your bank.

3) Identifiers and addressing

Email/Phone number - the main "alias" of the recipient.
Autodeposit-address - email/number is linked to a specific bank account of the recipient; transfer drops immediately without Q & A.
Contact recipient - verified beneficiaries are saved in the bank's address book (affects risk policy and limits for some FIs).
Payment Reference - assignment text/order number; rolled in receipts and reports.

4) Payment flows

4. 1 P2P/P2B (push)

1. The sender indicates the recipient's email/phone number and amount.
2. (Optional) secret Q&A - if the recipient does not have Autodeposit configured.
3. The recipient receives a notification (email/SMS) → chooses his bank/goes to the online bank → answers the question (if any) → funds are credited.
4. With Autodeposit, steps 2-3 are skipped: money comes automatically.

4. 2 Request Money (collect)

1. Merchant sends a request to the payer with the amount/purpose.
2. The payer confirms in the online bank → the funds are sent as a regular e-Transfer.
3. Merchant receives a notice and enlistment.

4. 3 For business (e-Transfer for Business)

Support for bulk scenarios in a number of banks (mass requests/payments).
Advanced reporting and limits on corporate accounts.
Often available API/host-to-host from the bank for integration into ERP/billing.

5) Limits and how to work with them

Limits are set by the payer's bank (and sometimes the recipient) and depend on the account type, history, KYC/AML profile and risk.

• Per-transaction - maximum per operation.
• Per-day/24h - total daily value.
• Weekly/Monthly - weekly/monthly ceilings by amount/quantity.
• New recipient - temporarily reduced limits and/or exposure for the first transfers to a new contact.
• Q&A vs Autodeposit - with Autodeposit, some banks have other thresholds and checks.
• Request Money - limits may differ from "regular" sending.
• Business/Treasury - corporate accounts often have triple or higher basic limits and flexible quotas as agreed.

• Do not hardcode numbers - keep a directory of limits on banks/plans and update it.
• In UX, show the informative error "your bank has exceeded the limit" + a hint of options (split, other method).
• For recurring scenarios, use Request Money with the recipient's auto memory and/or alternative rails (PAD/ACH debit).

6) Security, Q&A and Autodeposit

Q&A (secret question/answer) protects the transfer if Autodeposit is not configured at the recipient. The response is transmitted in encrypted form and is required for enrollment.
Autodeposit reduces the risk of Q&A phishing and speeds up flow - recommended for merchants.

Notification hardening: warn customers that the bank never asks for PIN/passwords by email/SMS; Train to recognize phishing "payment requests."

Device/IP/velocity-controlling at the payer bank level.

7) Statuses, cancellations and returns

Pending/In Progress/Completed/Failed/Expired are typical statuses.
Before the recipient accepts the transfer, you can cancel it at your bank (if not Autodeposit).
Chargeback as in cards is absent. The post-credit return is a new credit transaction from the merchant to the payer.
Partial refund is maintained through separate transactions.
In controversial cases (fraud, addressee error), escalation goes through banks and support regulations.

8) Reconciliation and Reporting

Save the bank transaction identifiers (confirmation/reference number), recipient's email/phone number, amount, timestamp, purpose.
Enable daily auto-recon and periodic full-recon.
For bulk payments/requests, use bank/PSP reports with results for each line (success/fail/expired/canceled).

9) Fees and costs

The cost of e-Transfer is determined by the tariffs of the account bank (often a fix for sending; for business - package plans).
More often than not, there is no commission for receiving from merchants/individuals, but the conditions depend on FI.
Include support costs (fraud/phishing complaints), request processing SLAs and cancellations.

10) Risks and antifraud

Q&A phishing: an attacker intercepts email/SMS and tries to lure out a response. Mitigated by Autodeposit, training users and limiting attempts.
Incorrect address: confirmation of the recipient's name before sending is limited - compensate for the UX-illumination of the contact and double confirmation of the email/phone.
Social engineering and "refund-scams": Stock up on support check scripts and return standards.

11) iGaming and other sensitive verticals

Banks and payment providers in Canada apply categorical policies: for certain types of business, the limits and availability of e-Transfer may be limited.
Expect reduced limits, expanded KYC, and possible "source of funds" requirements.
Keep alternative rails (e.g. PAD/ACH debit, card payments, AFT) and risk segmentation.

12) Merchant integration

Options

1. Autodeposit to receive

Easy start: publish email/number, configure Autodeposit.
Cons: manually entering the amount by the payer (errors), weaker per-order analyst.

2. Request Money (invoice/collect)

You create a request with a fixed amount/purpose → the payer confirms.
Better in reconciliation and conversion; suitable for both one-off and recurring payments.

3. Business e-Transfer via bank/PSP

Access to bulk operations, extended limits, API/host-to-host.
Requires a corporate account and onboarding from FI.

• 'webhook/callback'on statuses (or backoff polling).
• Idempotency table (orderId + query key).
• Connector to the bank recon report.
• Refund-flow (partial/full).
• SLA monitoring (success/failures/latency/expiries).

13) UX recommendations

For one-off payments - bet on Request Money (fewer errors, clear reconciliation).
Show the request action timer, clear statuses, and redo steps.
Let's choose "Pay now" (Request) or "Send manually" (Autodeposit/email/phone).

Separate security screen: about Q&A, phishing, "we never ask for passwords."

14) Interac Gateway architecture

API поверхности: `createRequest`, `cancelRequest`, `queryStatus`, `processRefund`, `reconcile`.
Reliability: idempotency, retrai exponentially, dedup by external bank references.
Data: catalog of limits by banks, recipient card (new/trusted), expiries statuses.
Security: HMAC signatures of web hooks, bank/PSP IP allowlist, audit log, PII encryption (email/phone).
Observability: channel conversion metrics (Autodeposit vs Request), time to enrollment, percentage of expiries/cancel.

15) Output checklist

1. Select the bank/PSP and corporate plan with the required limits/API.
2. Set up Autodeposit and/or Request Money; test expiries/cancellation.
3. Implement statuses/web hooks, idempotency and recon.
4. Enable Refund flow and ODR procedures in support.
5. Add security screens (Q&A, phishing), understandable limit errors.
6. Start monitoring SLAs and alerts by bank/channel.
7. Run end-to-end tests with multiple large FIs.

Limit Card (Design Guidelines)

Per-txn/24h/7d/30d: store in config and check before initiation.
New recipients: temporarily reduced thresholds and/or exposure.
Autodeposit vs Q&A: different thresholds and anti-fraud rules are possible.
Corporate accounts: increased application limits + additional due diligence.

Summary

For online and accurate reconciliation, use Request Money; for simple reception - Autodeposit.
Do not "lace up" specific numbers: keep the FI limit configs and update them.
Embed refund/ODR, detailed reporting and daily recon.
Educate security customers and offer Autodeposit for better UX and less fraud.