Interac Consumer and Business Payment. Compare consumer and business Interac journeys across initiation, fraud controls, posting, remittance and reconciliation.
Block 15 · Chapter 73 of 75
Interac e-Transfer is familiar enough that customers often think the entire payment is “an email with money attached.” It is not.
The email address or mobile number is an addressing and notification mechanism in many e-Transfer journeys. The payment instruction is routed through the Interac e-Transfer service; participating financial institutions debit and post the funds. Autodeposit removes the security-question acceptance step for registered aliases. Business variants add features such as higher participant-configured limits, account-number routing, bulk payables and receivables, Request Money, richer transaction data and integration with accounting or ERP workflows.
The practical lesson is:
Consumer and business Interac payments share a fast digital customer experience, but business payments add approval, scale, remittance, reconciliation and fraud requirements that must be treated as first-class banking controls.
Interac Corp. operates the Interac e-Transfer service. Its public disclosure describes participating financial institutions as Direct or Indirect Connectors and lists services including Autodeposit, Q&A Send Money, Request Money, Interac e-Transfer for Business real-time account-number-routing payments and bulk disbursement services. Interac is separate from Payments Canada.
As of 5 October 2026, Interac e-Transfer is a live domestic service. Payments Canada still describes the Real-Time Rail (RTR) as launching in Q4 2026, with initial Interac e-Transfer clearing-and-settlement migration participants targeted for Q1 2027, additional participants in Q2 2027 and full volumes for initial launch participants in Q3 2027. Those are a sequenced target schedule subject to testing and participant readiness; no source reviewed for this chapter confirms that RTR production launch has occurred by this audit date. Current e-Transfer payments must therefore not be described as already settling on RTR.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- trace a consumer Interac e-Transfer from initiation to deposit;
- explain the difference between email/SMS notification and money movement;
- distinguish security-question acceptance from Autodeposit;
- explain Request Money as a request followed by a separate customer-authorized payment;
- describe business e-Transfer use cases such as supplier payables, payroll and other bulk payouts, claims and collections;
- explain bulk payables and bulk receivables at a functional level;
- describe account-number routing and richer business remittance data;
- distinguish customer limits from Interac product maximum capabilities;
- explain sender-side and receiving-side fraud controls;
- connect business e-Transfer to ERP, accounting and reconciliation;
- investigate non-receipt, wrong recipient, cancellation and fraud without confusing notification status with financial status;
- compare consumer and business customer journeys without assuming identical UI at every financial institution;
- explain the future relationship between e-Transfer clearing/settlement migration and the RTR without describing it as already complete.
Chapter navigator
- Consumer and business payment needs
- Participants and service boundaries
- Consumer send-money journey
- Autodeposit and Request Money
- Business payment journey
- Bulk, account-number routing and remittance
- Posting, accounting and reconciliation
- Fraud and security controls
- Exceptions, cancellations and investigations
- Architecture and implementation
- End-to-end consumer and business scenarios
- Testing, takeaways and authoritative references
1. Consumer and business payment needs
Consumer scenario:
- Maya owes Arjun CAD 85 for dinner.
- She knows his mobile number.
- She sends an Interac e-Transfer from online banking.
Business scenario:
- Cedar Repairs needs to pay 1,200 contractors after a storm.
- It wants automated approvals, structured references and reconciliation.
- It uses business/bulk capabilities supported by its financial institution.
Both want:
- fast payment;
- trusted banking channel;
- clear status.
But the business needs more:
- entitlements;
- dual approval;
- higher scale;
- beneficiary management;
- ERP integration;
- reconciliation;
- audit.
Consumer mental model
Customer sees:
Choose recipient → enter amount → confirm → recipient gets money
Bank operating model
Bank sees:
Authenticate
→ validate account/limit
→ fraud decision
→ create e-Transfer instruction
→ Interac service
→ receiving participant
→ deposit
→ posting/reporting/reconciliation
The customer journey is simple because the complexity is hidden.
2. Participants and service boundaries
Sender
Consumer or business authorizes payment through a participating FI.
Sending FI
Responsibilities include:
- authentication;
- account;
- limits;
- fraud;
- payment creation;
- customer debit;
- status/support.
Interac Corp.
Operates e-Transfer service and related capabilities.
Interac's public disclosure describes:
- Direct Connectors;
- Indirect Connectors;
- downstream entities.
Receiving FI
Supports:
- recipient identification;
- deposit;
- account posting;
- customer service;
- fraud monitoring.
Recipient
May:
- accept with security question;
- receive automatically via Autodeposit;
- receive account-number-routed business payment depending service/product.
Email/SMS provider
Notification transport is not a settlement system.
Interac's consumer FAQ explicitly explains that money never travels by email or text; those channels provide notification/instructions.
ERP/accounting system
For business:
- creates payable;
- supplies reference;
- receives bank result;
- closes invoice.
Payments Canada
Interac is separate from Payments Canada. Interac’s current public disclosure describes e-Transfer as a Bank of Canada-designated Prominent Payment System and identifies Direct Connectors, Indirect Connectors and Downstream Entities.
Future RTR migration of e-Transfer clearing/settlement should not be confused with current ownership of the e-Transfer service. Interac’s 2026 PPS disclosure publishes service-level settlement facts, but public product pages do not specify each FI’s private connector protocol, message/file schema, return-code catalogue or ledger design. The conceptual implementation patterns below are therefore labelled as FI-specific or illustrative unless a source says otherwise.
3. Consumer send-money journey
Step 1: login
Customer authenticates with bank.
Step 2: select recipient
Recipient can be identified by:
- email;
- mobile;
- available addressing options.
If new recipient:
- name;
- contact information;
- account number where supported for business flows.
Step 3: amount
Customer enters amount.
Actual transaction limit is set by participating FI/account.
Do not promise every customer the maximum displayed on Interac marketing pages.
Step 4: security question or Autodeposit
If recipient is not registered for Autodeposit in the applicable alias journey:
- sender may create security question/answer.
If Autodeposit:
- sender can see recipient information according to participating FI experience;
- funds deposit automatically after routine controls.
Step 5: fraud/risk
Sending bank can evaluate:
- login/device;
- new recipient;
- amount;
- behavior;
- velocity;
- scams.
Step 6: send
Payment instruction enters Interac service.
Step 7: notification
Recipient may get:
- email;
- SMS;
- bank notification.
The notification itself is not money.
Step 8: deposit
Recipient:
- answers security question and selects institution/account;
or
- Autodeposit deposits automatically.
Step 9: confirmation
Sender/recipient receive status/notification.
Step 10: reconciliation
Banks and service reconcile:
- debit;
- service transaction;
- deposit;
- exceptions.
4. Autodeposit and Request Money
Autodeposit
Interac's official setup guidance says a customer registers:
- email and/or mobile number;
- destination account;
- confirms registration.
Then incoming transfers to that registered identifier can be automatically deposited without a security question.
Security benefit
Autodeposit reduces:
- interception of notification plus security-answer theft.
It does not make every payment fraud-proof.
A scammer can persuade a sender to pay the scammer's legitimate Autodeposit account.
Recipient-name check
Interac's business getting-started guidance says a sender may see the recipient's full legal name for an Autodeposit-registered recipient depending the flow/FI.
This is useful confirmation.
But:
- matching name is not proof the underlying commercial purpose is legitimate.
Request Money
Request Money is a request, not a debit.
Flow:
- requester creates request;
- payer receives;
- payer reviews;
- payer authorizes payment;
- payment is sent.
Do not model it like PAD.
The payee cannot simply pull funds because a request was delivered.
Fraud risk
A scammer can send a Request Money that looks like a refund or incoming payment.
Customer UI should make direction obvious:
Business Request Money
Useful for:
- invoices;
- rent;
- donations;
- services.
Business system can attach reference and reconcile response.
5. Business payment journey
Interac e-Transfer for Business extends the model.
Interac's current business page advertises:
- 24/7 payment capability;
- data-rich payments;
- higher limits;
- bulk payables;
- bulk receivables;
- Request Money;
- Autodeposit.
It states transaction limits can be up to CAD 25,000 and up to 10,000 payments at a time for relevant business capabilities, while actual limits vary by participating FI/account.
Business initiation
ERP creates:
- supplier invoice;
- employee reimbursement;
- contractor payment;
- claim;
- refund.
Data:
- payee;
- amount;
- invoice/customer reference;
- due date;
- purpose.
Approval
Business banking should support:
- maker/checker;
- role limits;
- approval thresholds.
Beneficiary addressing
Depending on service:
- email;
- mobile;
- account number routing.
Fraud
Business controls emphasize:
- supplier-master changes;
- invoice diversion;
- business email compromise;
- compromised approver;
- unusual batch.
Release
Bank performs:
- entitlement;
- account;
- limit;
- fraud;
- service validation.
Recipient
For account-number-routed or Autodeposit flow:
Reporting
Business receives:
- accepted;
- failed/rejected;
- completed;
- remittance/reference.
ERP close
Invoice moves:
If payment later has exception:
- ERP needs corrective state.
6. Bulk, account-number routing and remittance
Bulk payables
Interac's business page describes sending to one person or thousands through bulk payables.
Use cases:
- contractor payouts;
- payroll and other bulk payouts;
- insurance claims;
- rebates;
- settlements.
Bulk is not “one giant payment.”
It is a batch/business instruction containing multiple payment outcomes.
Bulk receivables
Business can issue many payment requests.
Use cases:
- membership fees;
- donations;
- invoice collection.
Each payer independently authorizes.
Data-rich payments
Interac’s current business FAQ describes Interac e-Transfer for Business as ISO 20022 compliant and says remittance data can be added, including invoice and customer numbers. Interac’s April 30, 2026 PPS disclosure says the business product uses the latest ISO standard in its entirety, while legacy Q&A and Autodeposit implementations vary by participant and message type. Exact fields, mapping, file/API syntax and what the receiving FI exposes remain FI/ERP-specific.
Business remittance can include:
- invoice number;
- customer ID;
- reference.
This enables automatic cash application.
Account-number routing
Business e-Transfer capabilities can use account routing rather than only alias/contact.
Controls:
- validate institution/account data;
- secure beneficiary master.
ERP integration
Example:
Invoice AP-55881
→ Payment PAY-771
→ Interac transaction INT-991
→ Bank debit LED-442
→ Status COMPLETED
→ ERP invoice CLOSED
References should survive.
7. Posting, accounting and reconciliation
The reconciliation diagram above traces every sender and receiver entry below from Interac notification to ledger close; expect first, then close.
Sender accounting
Business:
- reduce cash;
- clear payable.
Bank:
- customer debit;
- service/settlement position;
- fee if applicable.
Receiver accounting
Recipient bank:
Business recipient:
- increase cash;
- clear receivable.
Reconciliation
Consumer:
- statement enough for many use cases.
Business:
Match:
- bank reference;
- Interac reference;
- invoice;
- amount;
- payer;
- date.
Bulk reconciliation
For 1,200 contractor payments:
1,200 instructed
1,198 completed
1 failed validation
1 pending/exception
Do not mark entire batch complete without item detail.
Request Money reconciliation
Business creates 500 requests.
Outcomes:
- paid;
- declined;
- expired;
- outstanding.
A request is not cash until payment completed.
Statement
Bank statement should carry useful reference.
ERP status report should agree with ledger.
8. Fraud and security controls
Consumer account takeover
Signals:
- new device;
- password reset;
- new recipient;
- unusual amount.
Controls:
- MFA;
- step-up;
- transaction monitoring;
- alerts.
Authorized scam
Customer authenticates correctly but is deceived.
Examples:
- bank impersonation;
- marketplace;
- investment;
- emergency scam.
Controls:
- contextual warnings;
- beneficiary risk;
- behavioral analytics;
- receiving-side mule monitoring.
Business email compromise
Supplier says:
“New payment details.”
Business should verify independently.
Bank can monitor:
- beneficiary changed;
- first payment;
- amount increase;
- new account concentration.
Autodeposit fraud misconception
Autodeposit reduces security-question interception risk.
It does not validate invoice legitimacy.
Request Money scam
User thinks they are “accepting money.”
UI:
- direction;
- amount;
- payee name;
- explicit authorization.
Receiving-side mule detection
Receiving FI can see:
- many unrelated incoming transfers;
- rapid onward transfers;
- account profile mismatch.
Bulk fraud
Compromised business account can cause high-volume loss.
Controls:
- dual approval;
- batch limit;
- beneficiary changes;
- unusual file;
- out-of-band verification for high risk.
9. Exceptions, cancellations and investigations
Notification missing
Recipient says:
“No email.”
First question:
If Autodeposit:
- funds may already be deposited.
Email failure is not payment failure.
Security answer failed
If recipient cannot answer:
- payment may remain pending under service state;
- sender/recipient follow FI process.
Do not share answer in memo or insecure channel.
Wrong email/mobile
If unregistered/wrong recipient:
- cancellation may be possible depending current transaction state and FI experience.
If funds already deposited:
Wrong account-number-routed payment
A valid wrong account can receive funds.
Investigation/recovery:
- exact payment reference;
- receiving FI;
- fraud/error classification.
Cancellation
Whether sender can cancel depends on service state.
Do not teach “all e-Transfers can be cancelled.”
Autodeposited/completed transfers are not simply cancelled after deposit.
Fraud complaint
Immediate:
- secure account;
- identify transaction;
- receiving-side contact/recovery;
- preserve evidence.
Duplicate send
Customer taps twice or business API retries.
Use:
- idempotency;
- duplicate monitoring;
- clear UI.
Uncertain outcome
If response times out:
- query transaction;
- do not send again blindly.
Customer support ownership
Interac business FAQ tells customers with current transaction trouble to contact their bank/credit union.
This reflects operating model:
- customer's FI owns support relationship.
10. Architecture and implementation
Consumer architecture
Mobile/web banking
→ authentication
→ e-Transfer service in bank
→ fraud/limits
→ Interac connector
→ receiving FI
→ recipient account
→ notifications
Business architecture
ERP
→ corporate banking/API
→ entitlements/approvals
→ payment orchestration
→ fraud/limits
→ Interac connector
→ receiving FI
→ ledger/reporting
→ ERP reconciliation
Alias directory / registration
Autodeposit registration:
- identifier;
- account;
- confirmation;
- lifecycle.
Controls:
- change notification;
- secure registration;
- duplicate/ownership handling.
API idempotency
Business API:
- request ID;
- payment ID;
- safe retry.
Bulk processing
Need:
- batch ID;
- item ID;
- item-level status;
- partial completion.
Reporting
Provide:
- synchronous acceptance;
- asynchronous final status;
- statement.
Do not conflate API 200 OK with recipient credit.
Monitoring
Consumer:
- transaction success;
- latency;
- fraud decline;
- notification issues.
Business:
- batch throughput;
- item failure;
- reconciliation;
- API errors.
Future RTR integration
Payments Canada’s current launch strategy targets initial Interac e-Transfer clearing-and-settlement migration participants in Q1 2027, additional participants in Q2 2027 and full volumes for initial launch participants in Q3 2027, subject to testing and readiness.
Architecture should be adaptable.
But current e-Transfer product and customer experience should not be documented as if that migration is already complete.
11. End-to-end consumer and business scenarios
Scenario A: consumer Autodeposit
Maya sends Arjun CAD 85.
Arjun registered mobile number for Autodeposit.
Flow:
- Maya authenticates;
- selects Arjun;
- sees recipient confirmation according to bank experience;
- authorizes;
- fraud controls pass;
- transfer sent;
- Arjun account credited;
- both get notifications.
No security question.
Scenario B: consumer Request Money
Landlord sends tenant CAD 1,800 request.
Tenant:
- reviews;
- authenticates;
- decides to pay.
The landlord did not debit tenant account merely by sending request.
Scenario C: business supplier payment
Cedar Repairs owes supplier CAD 18,450.
ERP:
- invoice;
- beneficiary account;
- reference INV-8821.
Corporate:
- maker creates;
- checker approves.
Bank:
- validates;
- fraud checks new beneficiary;
- release.
Supplier:
- receives direct deposit/account-routed payment.
ERP:
- matches INV-8821;
- closes payable.
Scenario D: bulk contractor payouts
1,200 contractor payments.
One invalid destination.
Batch:
- 1,199 process;
- one item exception.
Corporate report shows item.
Do not resend 1,199.
Scenario E: BEC attempt
Supplier email compromised.
Attacker provides new account.
Corporate master change triggers:
- callback verification;
- change rejected.
Payment never created.
Scenario F: notification outage
Interac notification email delayed.
Autodeposit recipient already credited.
Customer support checks payment/deposit before treating as missing payment.
Consumer versus business operating model
| Dimension | Consumer e-Transfer | Business e-Transfer |
|---|
| Primary intent | P2P / small payments | payables, receivables, payouts |
| Initiation | mobile/online banking | portal, ERP, API, file/bulk |
| Approval | individual authentication | entitlements + maker/checker |
| Addressing | alias / supported options | alias and business routing options |
| Remittance | memo/basic reference | richer structured business data |
| Volume | usually individual | individual or bulk |
| Reconciliation | statement/manual | automated ERP/accounting match |
| Fraud | ATO, scams | ATO + BEC + batch compromise |
| Support | individual FI | business FI + corporate operations |
This is a functional comparison. Actual features vary by participating FI.
Consumer journey in more detail
A customer may have:
- daily limit;
- per-transaction limit;
- recipient limit;
- fraud risk threshold.
These are not the same thing.
A payment can be below product maximum yet still be declined because:
- available balance;
- FI limit;
- fraud;
- account restriction.
Recipient identity and aliases
Email/mobile addresses are convenient because people remember them.
Risks:
- recycled phone numbers;
- compromised email;
- typo;
- alias changed.
Autodeposit registration reduces some risk because recipient account mapping is established with FI.
But sender still needs to verify intended person.
Security question design
Where Q&A flow is used:
- answer should not be obvious;
- do not put answer in memo;
- do not send answer in same compromised channel.
Security questions protect acceptance, but are weaker than well-controlled Autodeposit for interception risk.
Notification lifecycle
Potential notification events:
- transfer sent;
- recipient notified;
- reminder;
- accepted/deposited;
- cancelled;
- expired.
A notification event should not overwrite payment financial state.
Recipient bank selection
In Q&A flow recipient may select participating FI and authenticate there.
Security boundary:
- recipient does not disclose banking credentials to sender.
This is one reason notification link phishing is dangerous: fake pages can imitate bank selection.
Phishing controls
Customer education:
- check sender;
- do not enter credentials on suspicious page;
- navigate to online banking directly if unsure;
- Autodeposit can avoid acceptance links.
Banks:
- phishing-domain detection;
- secure notifications;
- account-takeover controls.
Autodeposit registration lifecycle
States:
PENDING_VERIFICATION
ACTIVE
UPDATED
DEREGISTERED
Change destination account:
- authenticate strongly;
- confirm change;
- notify customer.
A compromised Autodeposit registration can redirect future incoming funds.
Request Money lifecycle
REQUEST_CREATED
DELIVERED
VIEWED
PAID
DECLINED
EXPIRED
CANCELLED
Only PAID creates payment.
Business reconciliation should not treat delivered request as receivable settled.
Business payable workflow
Example:
- invoice approved;
- ERP creates payment;
- treasury/AP selects Interac business rail;
- beneficiary resolved;
- maker/checker;
- bank limits/risk;
- payment;
- recipient deposit;
- status returned;
- ERP closes invoice.
Rail-selection logic
Business should choose e-Transfer when it fits:
- CAD domestic;
- recipient reachable;
- amount within FI/product limit;
- urgency;
- remittance need.
Other rails may be better for:
- very high value;
- international;
- specific settlement needs;
- bulk payroll with different economics.
Do not force every payment into Interac because it is fast.
Limits
Interac’s current business product page says business transactions can be up to CAD 25,000 and bulk files can contain up to 10,000 payments; the page and business setup guidance state that actual limits and availability vary by participating FI and account type.
Actual:
- participating FI sets limits;
- account/customer segment may differ;
- batch limits may differ.
Application should read configured limits, not hard-code 25,000.
Bulk payables lifecycle
Batch created
→ item validation
→ business approval
→ FI acceptance
→ item processing
→ individual outcomes
→ batch summary
→ reconciliation
One bad item should not necessarily fail all valid items unless file validation rules require.
Bulk receivables lifecycle
Business sends requests:
- customer A pays;
- B declines;
- C ignores;
- D pays later.
Receivables system must track each.
Remittance data design
Good fields:
- invoice ID;
- customer number;
- payment purpose;
- order number.
Bad:
- free text only with truncated invoice reference.
Structured data reduces manual cash application.
Data-rich payment example
PaymentId: PAY-882
Invoice: INV-2026-5541
CustomerId: C-9931
Amount: 8,420.15 CAD
Reference: Annual equipment service
Recipient accounting can match automatically.
Consumer accounting
Sender:
- account debit;
- transfer reference.
Recipient:
Customer sees statement.
Fees depend on FI/account.
Business accounting
ERP:
Dr Accounts Payable
Cr Bank/Cash
Recipient:
Dr Bank/Cash
Cr Accounts Receivable
Illustrative accounting only.
Bank accounting
Bank tracks:
- customer subledger;
- service position;
- settlement;
- fee;
- exceptions.
Exact internal posting and accounting remain FI-specific. Interac’s April 30, 2026 PPS disclosure states that the current service calculates participant obligations and provides a settlement advice plus a reconciliation file; participants settle through Lynx, as a Settlement Agent or through one. The current service does not support real-time settlement: settlement cycles run from 00:00:00 to 23:59:59 Eastern Time, extend across weekends and holidays, and normally settle on the next business day (up to four days after the value date for weekends/holidays). The disclosure identifies 13:00 ET as the normal Lynx processing deadline, within the stated 08:00–17:29:59 ET settlement window. These are service-level settlement facts, not a promise about when a particular FI posts a customer account.
Interac says the service is planned to migrate to the RTR Clearing & Settlement system, described as pre-funded real-time gross settlement; that future model must not be presented as today’s e-Transfer settlement.
Reconciliation keys
Consumer support:
- transfer reference;
- sender/recipient;
- amount;
- timestamp.
Business:
- bank transaction ID;
- Interac/service reference;
- invoice/customer ID;
- amount;
- recipient.
Bulk control totals
Batch:
BatchId: B-991
Items: 1,200
Total: CAD 6,440,882.55
Report:
1,198 completed
1 rejected
1 pending
Financial reconciliation sums item outcomes.
Business settlement certainty
Do not equate:
- “batch accepted” with “every recipient credited.”
Report item-level final states.
Customer-support diagnostic sequence
For non-receipt:
- exact transfer?
- sender debit?
- transfer status?
- recipient Autodeposit?
- notification issue?
- recipient account posting?
- cancellation/expiry/return?
- fraud?
Autodeposit non-receipt
If sender says completed and recipient has Autodeposit:
- verify alias registration;
- destination account;
- service status;
- receiving FI posting.
Do not ask recipient for security answer; Autodeposit has no Q&A acceptance.
Wrong-recipient recovery
If payment deposited to wrong person:
- identify transaction;
- contact sender FI;
- recovery process;
- no guarantee from simple “cancel.”
The bank should not promise to debit recipient without authority.
Consumer scam example: marketplace
Victim buys laptop.
Seller demands e-Transfer.
Victim sends.
Seller disappears.
Authentication was genuine.
Fraud controls:
- new recipient;
- warning;
- beneficiary intelligence.
But bank cannot infer every marketplace purchase is scam.
Bank investigator scam
Fraudster tells customer:
“Send money to this safe account.”
Bank should use specific warnings.
If customer sends:
- immediate fraud case;
- receiving-side recovery.
Business BEC example
Accounts payable receives legitimate-looking supplier email.
Change:
- existing supplier;
- bank details new.
Good process:
- independent callback to known contact;
- second approver.
Bank:
Payroll via business e-Transfer
Interac’s current business material includes payroll among potential bulk-payment use cases.
But business should assess:
- limits;
- economics;
- employee reachability;
- reconciliation;
- payroll obligations.
Traditional AFT may remain more appropriate for regular payroll.
Claims payouts
Insurance/settlement payouts:
- bulk disbursement;
- recipient notification;
- references.
Controls:
- recipient identity;
- duplicate claim;
- fraud.
Rent collections
Request Money can support collection, but it is not a debit mandate.
Tenant chooses to authorize each payment.
Compare PAD:
- payee initiates debit under prior mandate.
Request Money:
- payee requests, payer pushes.
Fraud monitoring data
Sender-side:
- device;
- session;
- amount;
- new recipient;
- velocity.
Receiver-side:
- inbound fan-in;
- rapid onward;
- mule indicators.
Service/network:
- cross-institution patterns.
Sanctions/AML
Banks apply applicable AML/ATF, sanctions, fraud and recordkeeping controls. Do not describe Interac as exempt merely because the customer-facing transfer is domestic.
Regulatory rule, not an Interac scheme limit: FINTRAC defines an international electronic funds transfer as an electronic funds transfer other than a transfer of funds within Canada. For a financial entity, an Electronic Funds Transfer Report is required for an international EFT of $10,000 or more in a single transaction when initiated or finally received, and must be submitted within five business days; the 24-hour aggregation rule can also apply. This does not turn a domestic Interac transfer into an EFT report, but it also does not remove applicable suspicious-transaction, identity, recordkeeping or sanctions obligations. Do not label every Interac e-Transfer as FINTRAC-reportable under the international-EFT threshold.
Privacy
Email/mobile are personal information.
Business bulk may include:
- names;
- account numbers;
- invoice data.
Controls:
- encryption;
- access;
- retention;
- masking.
API architecture
Business payment API should separate:
POST payment
→ synchronous validation/acceptance
→ asynchronous processing
→ webhook/status query
→ final outcome
HTTP success = request accepted, not necessarily recipient credited.
Webhook idempotency
Status webhook may arrive twice.
Consumer:
Do not post ledger twice.
Retry model
Client timeout:
- reuse idempotency key;
- query payment.
Never generate new payment ID automatically if original might exist.
Connector resilience
If bank-to-Interac connector unavailable:
- queue/reject according product;
- clear customer status.
After recovery:
Notification-service resilience
Email down:
Customer support should know notification dependency separately.
Monitoring dashboard
- initiation success;
- service latency;
- completed;
- pending;
- cancellation;
- Autodeposit registration failures;
- notification delivery;
- fraud decline;
- bulk item failures;
- reconciliation breaks.
Future RTR migration operating impact
Payments Canada’s current launch-strategy page lists these target phases:
- Q4 2026: initial direct-to-Exchange RTR participants;
- Q1 2027: initial Interac e-Transfer clearing-and-settlement migration participants;
- Q2 2027: additional e-Transfer migration participants;
- Q3 2027: initial launch participants at full transaction volumes.
The page also says onboarding is sequenced by testing, safety and participant readiness. These are programme targets, not evidence that a specific bank or e-Transfer flow is already live on RTR. Bank architecture should manage the transition carefully.
Possible implications:
- settlement model;
- liquidity;
- 24/7 treasury;
- reconciliation;
- incident management.
But Interac customer service remains its own service layer.
Business analyst requirements
Define:
- service type;
- addressing;
- limits;
- approval;
- remittance;
- statuses;
- cancellation;
- fraud;
- reporting;
- reconciliation.
Data model
Transfer
transferId
customerId
recipient
amount
serviceType
batchId?
invoiceRef?
state
externalRef
Related:
- notification;
- fraud decision;
- ledger;
- case.
Testing consumer
- known recipient;
- new recipient;
- Autodeposit;
- Q&A;
- wrong answer;
- notification failed;
- cancelled before deposit;
- completed.
Testing Request Money
- paid;
- decline;
- expiry;
- duplicate request;
- spoofed-looking request warning.
Testing business
- maker/checker;
- limit;
- bulk;
- one invalid item;
- API timeout;
- webhook duplicate;
- remittance;
- ERP reconciliation.
Testing fraud
- ATO;
- BEC;
- mule;
- unusual batch;
- Autodeposit change;
- Request Money scam.
Testing resilience
- connector outage;
- notification outage;
- ledger outage;
- DR;
- duplicate replay.
Comparison: consumer versus business support
Consumer support asks:
- recipient?
- amount?
- transfer status?
Business support also asks:
- batch ID;
- item ID;
- ERP reference;
- approval;
- API request ID.
Final practitioner checklist
For any Interac payment, prove:
- who authorized;
- which recipient;
- which service variant;
- what limit/control applied;
- whether transfer completed;
- which account was posted;
- what reference/remittance was preserved;
- whether there is an exception or fraud case;
- whether accounting reconciles.
Interac transaction state model
A bank should not rely on one generic “sent” flag.
An internal state model can include:
CREATED
AUTHORIZED
RISK_APPROVED
SUBMITTED
PENDING_RECIPIENT
AUTODEPOSIT_PROCESSING
DEPOSITED
CANCELLED
EXPIRED
FAILED
UNDER_INVESTIGATION
The exact external service states vary, but internally the bank must distinguish:
- not yet submitted;
- submitted but not deposited;
- deposited;
- cancelled/expired.
This determines whether customer can cancel or must use recovery/investigation.
Customer-facing status mapping
| Internal situation | Customer wording |
|---|
| waiting for recipient | Awaiting deposit |
| Autodeposit processing | Processing |
| recipient deposited | Deposited/Completed |
| transfer cancelled | Cancelled |
| notification delayed | Transfer status unchanged; notification issue |
| uncertain technical state | Confirming status — do not resend |
| fraud case | Under investigation / contact bank |
Avoid saying “failed” during uncertainty.
Alias validation and lifecycle
An email or mobile alias can change ownership over time.
Risks:
- recycled phone number;
- abandoned email;
- typo;
- alias registered to unexpected person.
Sending UI can reduce risk by:
- showing recipient identity information when service provides it;
- asking sender to confirm;
- warning on new recipient.
The bank should never display more personal information than the service/privacy rules permit.
Autodeposit change controls
A customer changes registered destination account.
High-risk event.
Controls:
- strong authentication;
- device/session risk;
- customer alert;
- confirmation;
- audit.
A fraudster who compromises online banking may redirect future incoming transfers without initiating an outbound payment.
Autodeposit dispute
Sender says:
“I sent to the right email but wrong person got it.”
Investigation:
- exact alias at time of send;
- Autodeposit registration state;
- name displayed to sender;
- recipient account posting;
- whether alias ownership changed.
Do not assume email string alone proves intended beneficiary.
Security-question flow edge cases
Wrong answer attempts are governed by service/FI handling. If the sender shares the answer insecurely or puts it in the transfer memo, interception risk increases. Banks should encourage safer practices and Autodeposit where suitable, without implying that Autodeposit guarantees the commercial legitimacy of a payee.
Request Money directionality
The most important UI element is payment direction.
Request screen should make clear:
You are being asked to PAY
Requester: XYZ
Amount: CAD 450
Not:
“XYZ sent you CAD 450.”
Scammers exploit wording confusion.
Request Money business workflow
A clinic sends 500 payment requests.
Receivable ledger may show:
REQ-1 outstanding
REQ-2 paid
REQ-3 declined
REQ-4 expired
Only paid requests create bank cash.
A business should not reduce accounts receivable when a request is merely delivered.
Request Money reconciliation
Keys:
- request ID;
- customer/invoice;
- resulting payment ID;
- amount;
- payer;
- date.
One request may expire and be reissued. The business should avoid accidental duplicate requests.
Business beneficiary-master lifecycle
For supplier payments:
Supplier created
→ account/contact verified
→ approved
→ active
→ amended
→ suspended
A new e-Transfer destination should be linked to supplier-master change governance.
BEC control workflow
Supplier sends new details.
Accounts payable:
- does not rely only on the email thread;
- calls a known supplier contact;
- validates the change;
- obtains second approval;
- updates master;
- flags the first payment for appropriate review.
This control exists before the bank fraud engine.
Business entitlements
Roles can include:
- preparer;
- approver;
- administrator;
- viewer.
Payment approval can depend on amount and customer policy. A business may require two approvers above a configured threshold. The exact threshold is not a scheme rule and should not be copied from training material.
Corporate API authentication
Business APIs can use mechanisms such as mutual TLS, OAuth/client credentials or signed requests depending on the bank.
Security goals:
- authenticate company/system;
- protect instruction integrity;
- rotate credentials;
- prevent replay.
Do not embed shared user passwords in ERP scripts.
Payment initiation API example
Conceptual payload:
clientRequestId
debtorAccount
recipient
amount
currency=CAD
remittance
invoiceId
requestedExecution=NOW
Bank returns:
- bank payment ID;
- accepted for processing.
Final status can arrive asynchronously.
Idempotency example
ERP submits client request ID REQ-7788.
The bank accepts, but the response is lost. ERP retries the same request ID. The bank returns the existing payment ID rather than creating a second transfer.
Bulk item state
Batch state should derive from items.
Example:
Batch B-100
Items: 10,000
Completed: 9,984
Rejected: 6
Pending: 10
A batch can be completed with exceptions.
Do not use only SUCCESS/FAIL.
Bulk file integrity
Controls:
- batch ID;
- item count;
- amount total;
- file hash;
- duplicate.
If one item is malformed, handling depends on service/product design. The bank should document whether the whole batch or only the item is rejected.
Bulk approval after file change
If one beneficiary is edited after approval:
- invalidate approval;
- recalculate totals;
- reapprove.
Business remittance data quality
A fast payment without usable reference creates operational cost.
Good:
- invoice INV-8821;
- customer ID;
- purchase order.
Poor:
The receiving business should be able to match without calling the payer.
Receivables cash application
Incoming business e-Transfer:
Bank credit
→ identify payer
→ parse invoice/reference
→ match open A/R
→ apply cash
→ exception if unmatched
Unmatched cash goes to a controlled unapplied-cash process, not automatically to the nearest invoice.
Overpayments and underpayments
If customer pays CAD 1,050 for a CAD 1,000 invoice, the bank payment can still be fully successful. The business applies CAD 1,000 and handles CAD 50 as a credit or unapplied amount under its policy.
If customer pays CAD 950, the payment succeeds and the receivable retains CAD 50. Payment status and commercial balance are different.
Business refunds
A merchant or business may refund through a supported credit-payment capability.
A refund is a new outgoing payment linked to the original commercial transaction. It is not a deletion of the original incoming transfer.
Consumer cancellation timing
A sender may be able to cancel a transfer that has not yet been deposited, depending on FI/service state.
Autodeposit can complete without recipient acceptance. Therefore customer UI should display cancellation only when the system confirms eligibility.
Transfer expiry
If a recipient does not accept within the service validity period, the transfer may expire according to service/FI rules. The bank should report expiration separately from customer cancellation.
Do not invent one fixed expiry period unless current FI/product rules are verified.
Wrong-recipient workflow
If the sender realizes the mobile/email is wrong:
Before deposit:
After deposit:
- open recovery/investigation;
- do not guarantee recovery.
Customer service must not say “we reversed it” merely because a request was sent.
Fraud recovery data
A fraud case should link:
- original transfer;
- sender authentication;
- recipient;
- deposit status;
- receiving FI;
- fraud type;
- recovery requested;
- recovered amount;
- customer reimbursement.
As with other rails, reimbursement and recovery are separate financial events.
Mule-account network
A receiving bank can observe:
- many unrelated senders;
- a newly opened account;
- rapid onward movement.
This can trigger fraud investigation, account restrictions under policy/law and AML assessment. The sending bank alone cannot see the full network.
AML and fraud handoff
Fraud operations may stop/recover funds. AML/compliance separately assesses suspicious activity and reporting obligations. The legal reporting decision should not be treated as an ordinary payment-status field.
Sanctions data quality
Domestic transfers can still involve names/entities of concern. Banks apply applicable legal and policy controls. Richer business data can improve screening but requires accurate party names.
Consumer support playbook
Customer says:
“I sent CAD 500 but recipient cannot see it.”
Agent:
- authenticates customer;
- locates exact transfer;
- determines financial state;
- checks recipient method;
- checks cancellation/expiry;
- separates notification issue from deposit issue;
- escalates receiving-side only if needed.
Do not tell the customer to resend while state is uncertain.
Business support playbook
Business says:
“20 of 1,000 contractors are missing payments.”
Support should retrieve:
- batch ID;
- item IDs;
- common failure reason;
- receiving-FI concentration;
- service incident status.
If 20 share a common receiving institution, investigate a common cause before opening 20 duplicate external traces.
Incident: notification provider outage
Payments can deposit normally while emails are delayed.
Dashboard can show:
- deposit success normal;
- notification failure elevated.
Customer communication should say notifications may be delayed, not that all payments failed.
Incident: connector timeout
For transactions with unknown state:
- stop blind retry;
- use stable transaction IDs;
- query service;
- classify each item.
Incident: bank ledger outage
If the sending bank cannot reliably debit/reserve customer funds, initiation may need to be held or rejected according to product design. If recipient posting is delayed after a successful service outcome, treat it as a posting exception rather than resending.
Disaster recovery
Preserve:
- bank payment ID;
- external reference;
- idempotency key;
- batch/item state;
- Autodeposit registration state;
- Request Money state.
After recovery, reconcile service transactions before allowing retries for the unknown population.
Reconciliation layers
Consumer:
Customer instruction
↔ service transaction
↔ sender ledger
↔ recipient deposit
Business adds:
ERP payable/receivable
↔ bank transaction
↔ remittance
↔ GL
Future RTR transition testing
Before e-Transfer clearing/settlement migration:
- parallel reconciliation;
- liquidity impact;
- 24/7 treasury;
- participant settlement;
- incident playbook.
The customer product may look similar while the bank settlement layer changes.
Avoiding a migration misconception
Do not say:
“Interac e-Transfer becomes the RTR.”
More precise:
Payments Canada plans migration of Interac e-Transfer clearing and settlement participants onto RTR infrastructure in phases. Interac remains a service with its own customer features and operator.
Monitoring during migration
Compare:
- transaction count;
- value;
- settlement positions;
- customer outcomes.
No customer double posting should result from transition.
Business value metrics
- straight-through processing rate;
- invoice auto-match rate;
- completion rate;
- time to reconcile;
- manual cash application;
- fraud loss;
- failed beneficiary changes.
Speed alone is not business value.
Consumer value metrics
- send success;
- deposit time;
- cancellation;
- support contacts;
- fraud complaints.
Final end-to-end business case
Cedar Repairs creates a batch of 1,200 contractor payments worth CAD 6.44 million.
Approval:
Bank:
- validates;
- six transactions exceed the customer's configured item limits and are rejected before send;
- 1,194 enter the service.
Of those:
- 1,193 deposit;
- one has a recipient issue and remains an exception.
ERP:
- closes 1,193 invoices;
- six remain unpaid due to rejects;
- one remains pending.
Operations investigates one item rather than resending the 1,193 completed payments.
Reconciliation proves:
- batch count;
- completed value;
- rejects;
- pending;
- bank debit/fees;
- ERP state.
The batch is neither “failed” nor “100% complete.” It is complete with defined exceptions.
Exception decision model
The exception process should always start with the service state rather than with the customer's description.
A practical decision sequence is:
- identify the exact transfer;
- determine whether the sender account was debited;
- determine whether the transfer is pending, deposited, cancelled, expired or uncertain;
- determine whether Autodeposit, Q&A or another business-routing flow applies;
- separate notification failure from financial failure;
- if deposited to the wrong recipient, move to recovery/investigation;
- if fraud is suspected, escalate immediately to fraud operations;
- if the state is uncertain, prevent duplicate resend until proven.
This sequence is more reliable than telling the customer to “try again.”
Consumer case: notification link never arrives
Sender sees the transfer as sent.
Recipient sees no email.
The investigator should ask:
- is the recipient registered for Autodeposit?
- is the alias correct?
- what is the transfer state?
- is notification service delayed?
If Autodeposit completed, the missing email is only a notification problem.
If the transfer remains pending, the sender may still have options according to the FI/service state.
Consumer case: payment goes to an old email address
The sender selected a saved recipient whose email is no longer used by the intended person.
Possible outcomes:
- no one accepts and transfer remains pending;
- an unintended party controls the address and accepts;
- the address is registered for Autodeposit by someone else.
This is why sender confirmation of recipient details remains important even for familiar contacts.
Consumer case: bank-investigator scam
A fraudster calls Elena:
“Your account is compromised. Send CAD 4,500 to this secure account.”
Elena:
- authenticates normally;
- uses known device;
- approves the transfer.
Traditional account-takeover controls may not fire.
Better signals:
- first-time recipient;
- unusual amount;
- recipient risk;
- transaction velocity;
- contextual scam warning.
If the transfer completes:
- fraud recovery case begins immediately;
- receiving-side mule intelligence becomes important.
Consumer case: Request Money impersonation
A customer receives a message that appears to say they are receiving a refund.
In reality it is a Request Money for CAD 850.
The bank UI must emphasize:
- the customer is paying;
- requester's identity;
- amount;
- authorization action.
A customer should never be able to confuse “accept refund” with “authorize debit.”
Business case: supplier master compromise
Cedar Repairs has paid Supplier A for five years.
A compromised mailbox asks to change the payment destination.
The business control stack should detect:
- beneficiary changed recently;
- first payment to new account;
- large invoice.
The bank can add:
- new recipient risk;
- device/session behavior;
- business payment anomaly.
The best prevention may be the business callback before the bank ever sees the payment.
Business case: bulk payout with one recipient problem
A claims company sends 8,000 payouts.
7,999 complete.
One recipient record fails validation.
The business should receive:
- batch summary;
- failed item ID;
- reason;
- ability to correct only that item.
Resending the whole batch is a severe control failure.
Business case: remittance missing
Supplier receives CAD 7,250 but cannot identify the invoice.
The money moved correctly.
The operational problem is data quality.
Resolution:
- retrieve payer/remittance reference;
- update ERP/cash application;
- improve payment-data mapping.
Do not open a “missing payment” investigation.
Business use-case selection
| Use case | Why e-Transfer may fit | Key control |
|---|
| contractor payout | speed, broad reach | beneficiary + batch controls |
| insurance claim | fast disbursement | claimant identity + duplicate claim |
| supplier payment | data-rich remittance | BEC/beneficiary governance |
| expense reimbursement | employee convenience | employee/account validation |
| rent collection | Request Money | payer authorization |
| customer refund | rapid credit | original transaction linkage |
| payroll or other urgent disbursement | urgent payment | payroll duplicate/entitlement |
| donation collection | Request Money | reference/cash application |
Not every use case should use this rail. Amount, volume, cost, settlement need and business process determine fit.
Corporate limit governance
A business can have multiple limit layers:
Interac service capability
↓
FI product limit
↓
customer agreement limit
↓
user entitlement limit
↓
fraud/risk limit
The effective permitted amount is the most restrictive applicable control.
This is why a published “up to” limit should not be coded as a universal authorization rule.
Limit-change controls
A customer requests higher business limit.
Bank should:
- authenticate authorized administrator;
- credit/risk assessment where applicable;
- fraud review;
- maker-checker internally;
- effective-date change;
- notify customer.
A compromised admin account should not be able to raise limits and immediately send a suspicious batch without additional controls.
Corporate-beneficiary verification
A bank can support beneficiary verification through:
- Autodeposit recipient information;
- account validation;
- internal beneficiary history;
- future/other payee-verification capabilities.
The business still owns the commercial fact that “this is my supplier.”
ERP status mapping
An ERP should not close an invoice on API submission success.
Better:
BANK_ACCEPTED → payment initiated
PROCESSING → invoice payment in progress
COMPLETED → close payable
REJECTED → reopen/action
CANCELLED/EXPIRED → reopen
UNKNOWN → hold, do not reissue automatically
This prevents duplicate supplier payments.
Business webhook design
Webhooks should include:
- payment ID;
- batch/item ID;
- new state;
- timestamp;
- reason.
Webhook processing:
- authenticate source;
- idempotent;
- order-aware.
If a completed-status webhook arrives twice, the ERP should close the payable once.
Out-of-order events
Distributed systems can deliver a completed event before an earlier processing event because of delay.
The consumer should use state version/timestamp and avoid moving a final payment backward to an earlier state.
Data retention for business payments
Retain according to bank policy/legal requirements:
- instruction;
- approvers;
- beneficiary;
- remittance;
- bank/external reference;
- status;
- fraud decision;
- accounting;
- cases.
This supports audit and supplier disputes.
Consumer complaint evidence
For a disputed transfer, collect:
- sender authentication;
- device/session;
- recipient selected;
- amount;
- warnings shown;
- Autodeposit/Q&A state;
- final deposit;
- customer communications.
A passed authentication is evidence, not proof that an authorized scam did not occur.
Receiving-side support
Recipient says:
“I see a deposit but don't know sender.”
Receiving FI can provide available transaction/reference information subject to privacy/service rules.
If sender identity/remittance is insufficient, the issue may require interbank inquiry.
Privacy in support tools
Customer-service screens should mask:
- full account numbers;
- sensitive contact data,
unless role requires it.
Business bulk files can contain thousands of recipients and should not be broadly exposed.
Operational segregation
Different teams can own:
- service operations;
- fraud;
- customer support;
- business support;
- reconciliation.
One case ID should link them.
Daily reconciliation
A participating FI should reconcile:
- sender debits;
- recipient credits where relevant;
- service reports;
- settlement position;
- fees;
- exceptions.
During future RTR migration, this becomes especially important because the settlement layer changes while customer product remains familiar.
Migration readiness questions
Before moving e-Transfer clearing/settlement to RTR infrastructure, a bank should answer:
- Which Interac product flows migrate in each phase?
- Which participant role does the bank hold?
- How will settlement liquidity change?
- How are existing customer references preserved?
- How are pending/in-flight transactions handled at cutover?
- What is the rollback/contingency plan?
- How will reconciliation compare old and new settlement populations?
- How will 24/7 treasury support the new model?
These are implementation questions; the public launch schedule does not answer every bank-specific design detail.
Customer communication during migration
The bank should avoid messaging that confuses:
- Interac e-Transfer product;
- RTR infrastructure.
A customer may continue to see “Interac e-Transfer” even if the back-end clearing/settlement model changes.
Operational metrics by segment
Consumer:
- send completion;
- deposit time;
- fraud rate;
- cancellation;
- support calls.
Business:
- batch completion;
- item STP;
- remittance match rate;
- API availability;
- fraud/BEC losses;
- reconciliation breaks.
Release testing for business APIs
Test:
- valid API payment;
- invalid beneficiary;
- amount over FI limit;
- duplicate idempotency key;
- same request ID with changed payload;
- webhook duplicate;
- webhook out of order;
- API timeout;
- batch partial reject;
- DR replay.
Release testing for consumer journeys
Test:
- Q&A send;
- correct/incorrect answer;
- Autodeposit;
- recipient alias changed;
- cancellation eligible;
- completed non-cancellable transfer;
- notification outage;
- fraud warning;
- app timeout.
Accessibility and clarity
Payment screens should be readable for customers under pressure.
For Request Money:
- direction should be visually and verbally clear.
For recipient confirmation:
- do not rely only on color.
For fraud warnings:
- explain specific risk and action.
This is not decorative UX; it reduces payment mistakes.
Final consumer scenario
Maya sends CAD 85 to Arjun.
Her bank:
- authenticates;
- validates balance/limit;
- checks risk;
- submits the transfer.
Arjun is registered for Autodeposit.
His account is credited.
Email notification is delayed by five minutes.
Maya calls support.
The support agent sees:
- transfer completed;
- recipient deposited;
- notification delay.
The agent does not cancel, resend or start a missing-payment investigation.
Final business scenario
Cedar Repairs sends 1,200 supplier/contractor items.
The batch report shows:
- 1,193 completed;
- six rejected before send;
- one pending exception.
ERP closes exactly 1,193 payables.
The reconciliation team matches the bank's debit/report to those item outcomes.
That is a bank-grade business payment outcome: not a single green batch status, but a fully explainable population.
Business continuity and support ownership
Because e-Transfer is customer-facing and fast, operational ownership must be clear before an incident.
Digital banking team
- channel availability;
- customer initiation.
Payments team
- transaction state;
- Interac integration;
- exceptions.
Fraud team
- account takeover;
- scams;
- mule recovery.
Corporate banking
- business approvals;
- API/file customers;
- batch support.
Ledger/reconciliation
- customer postings;
- financial matching.
Technology
The customer should not have to understand this internal structure. One support case should route to the correct owner.
Business-continuity decision table
| Dependency outage | Can payment continue? | Key action |
|---|
| email/SMS notification | often payment may continue | communicate notification delay |
| corporate API gateway | new API initiation affected | preserve in-flight states |
| Interac connector | external send affected | stop blind retries |
| sender ledger | funding/debit uncertain | hold/reject safely |
| fraud control | depends on approved policy | never bypass required controls casually |
| receiving posting | recipient credit delayed | investigate without resend |
| reconciliation feed | payments may continue only under risk-approved controls | backfill and reconcile |
This table should be converted into product-specific runbooks rather than used as a universal scheme rule.
Customer status after channel recovery
A common incident pattern is:
- payment completed externally;
- customer channel stayed down;
- user returns after service restoration.
The bank should rebuild status from payment truth and show the completed transaction.
It should not invite the customer to initiate again merely because the original UI session was lost.
Support escalation for business batches
A business batch case should identify:
- batch ID;
- affected item count;
- affected value;
- whether common receiving institution exists;
- whether issue is payment or reporting only.
This allows one incident to cover a common cause while keeping each item financially traceable.
Audit evidence for a business transfer
For a material business transfer the bank should be able to produce:
corporate instruction
maker/checker approval
recipient data
fraud/limit decision
Interac/service reference
sender ledger debit
recipient outcome or exception
customer reporting
reconciliation
For a batch, add:
- batch control totals;
- item outcomes.
Product-selection comparison
A product owner deciding between e-Transfer, AFT and Lynx should consider:
| Requirement | e-Transfer | AFT | Lynx |
|---|
| customer speed | fast/near-instant | batch | real-time settlement in cycle |
| typical use | consumer/business digital | high-volume scheduled | high-value |
| approval | channel/FI | file/corporate | high-value corporate |
| remittance | business features available | file/message dependent | ISO 20022 |
| amount | FI/service limits | product limits | high-value use |
| settlement model | current Interac arrangement; planned RTR migration | ACSS batch/net | RTGS |
| 24/7 customer use | yes for e-Transfer experience | no universal batch 24/7 | operating cycle |
The table is directional. Actual bank products, fees and limits decide rail selection.
Final implementation review questions
Before releasing a consumer/business e-Transfer change:
- Does the UI distinguish notification from deposit?
- Is Request Money direction unmistakable?
- Are Autodeposit changes protected?
- Are business API retries idempotent?
- Are batch/item statuses separate?
- Are customer limits configuration-driven?
- Can support identify the receiving outcome?
- Can fraud reach the receiving institution quickly?
- Does ERP get usable remittance and final state?
- Can the bank reconcile the settlement layer before and after future RTR migration?
If these answers are clear, the product is operating as a bank payment service rather than only a fast digital feature.
Consumer harm scenario: completed transfer shown as failed
The transfer deposits successfully, but the sender app loses the final response and displays “failed.”
If the customer retries, a second transfer can occur.
The correct architecture keeps the financial payment state independent of the app session and makes the retry idempotent. After status reconstruction the app should show the original completed transfer.
Business harm scenario: one failed item closes the entire batch
A corporate batch contains 5,000 payments and one malformed recipient.
If the bank reports only “batch failed,” operations may resend 4,999 valid payments.
A bank-grade design exposes batch and item states separately and clearly identifies whether the malformed item prevented the whole batch or only itself according to the product rules.
Interac quality gate
Before release, the bank should prove:
- payment state is authoritative outside the notification channel;
- Autodeposit registrations are protected;
- Request Money direction cannot be misunderstood;
- business retries cannot duplicate payment;
- batch reporting is item-aware;
- fraud and receiving-side recovery routes are tested;
- settlement/reconciliation changes required for future RTR migration are understood without changing today's customer facts.
Practical production acceptance workshop
Run two transactions side by side.
Consumer:
A CAD 250 transfer to an Autodeposit recipient with delayed email notification.
The team should prove that notification delay does not alter the deposit state.
Business:
A 500-item contractor batch with one invalid recipient and one API response timeout.
The team should prove:
- valid items are not duplicated;
- the invalid item is isolated according to product behavior;
- the timeout is resolved through idempotency/status lookup;
- ERP closes only completed payables;
- batch reconciliation explains every item.
Interac handover documentation
Maintain:
- supported service variants;
- FI/customer limits;
- Autodeposit support process;
- Request Money states;
- cancellation rules;
- business API idempotency;
- batch/item reporting;
- fraud recovery contacts;
- reconciliation;
- future RTR migration assumptions and dates.
Final learning check
Remember:
- email/SMS is notification, not the money;
- Autodeposit improves the acceptance journey but does not guarantee the payment is legitimate;
- Request Money is a request followed by a payer-authorized payment, not PAD;
- business e-Transfer needs approvals, remittance and reconciliation in addition to speed;
- a future RTR clearing/settlement migration does not mean Interac e-Transfer and RTR are the same product.
12. Testing, takeaways and authoritative references
Functional tests
- consumer send;
- Q&A accept;
- Autodeposit;
- Request Money;
- business account-number payment;
- bulk payables;
- bulk receivables;
- data-rich reference;
- cancellation eligible;
- completed transfer non-cancellable.
Fraud tests
- account takeover;
- new recipient;
- BEC;
- mule receiving;
- Request Money scam;
- Autodeposit account change.
Technical tests
- API timeout;
- duplicate request;
- notification delay;
- receiving FI timeout;
- bulk partial failure;
- DR replay.
Reconciliation tests
- sender debit;
- service transaction;
- recipient credit;
- batch/item status;
- remittance;
- ERP invoice.
Final takeaways
For consumer:
- keep direction and recipient clear;
- notification is not money;
- Autodeposit changes acceptance but not fraud fundamentals.
For business:
- approvals, beneficiary governance, remittance and reconciliation are as important as speed.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.