Interac e Transfer Send Money. Follow send-money initiation, authentication, addressing, notification, acceptance and account posting.
Block 6 · Chapter 27 of 75
This chapter follows one Interac e-Transfer send from start to finish: a sender starting a transfer inside their own bank app, proving who they are, addressing it with an email or mobile number, the recipient being notified, the recipient accepting inside their own bank, and the accounts being posted on acceptance. It stays at the send-money journey level on purpose. How a recipient registers an address so money lands directly is Chapter 28 (Autodeposit). How a collection starts from the other direction is Chapter 29 (Request Money). Cancellations, failed and uncertain outcomes, fraud events, customer support, and operational reconciliation are Chapter 30. Business payables, bulk sends, and remittance detail are Block 7. Read this chapter first so those chapters land on a journey you already understand.
A useful working rule for this whole block is simple: the send, the notification, the acceptance, the account posting, and the confirmation are related events, but they are not the same event. A sender who confuses "sent" with "deposited" will spend money twice. A recipient who confuses "notified" with "paid" will release goods too early. A banker who confuses "accepted" with "settled between banks" will answer investigations wrong. This chapter keeps those five events separate from the first paragraph to the last.
What you will be able to do after this chapter
After working through this chapter, you should be able to:
- explain what an Interac e-Transfer send is for — person-to-person and person-to-business pushes that start in a bank app and complete when the recipient accepts — and when a different rail should carry the payment instead;
- name the participants in a send — sender, sender bank, Interac Corp as network operator, recipient, recipient bank — and state what each owns, including the fact that each customer always acts inside their own bank;
- trace a send through initiation, authentication, addressing, notification, acceptance, posting, and confirmation without confusing those stages;
- compare the three functional addressing choices — email, mobile number, and directed deposit registration — and explain when each fits, with Autodeposit detail forward-pointed to Chapter 28;
- describe the notification and acceptance handshake — secure link, recipient sign-in at their own bank, security answer unless Autodeposit applies — and why the recipient never accepts inside the sender's bank;
- explain what the sender sees at each state — pending, completed, not completed — and tell a customer the honest difference between "sent" and "deposited";
- describe sender-bank controls before release — authentication, per-FI limits, fraud monitoring, screening — in generic functional terms without inventing limits, fees, or timings;
- place fraud patterns — interception, phishing, scams, account takeover — at the correct point in the flow at functional level, with investigation and control detail forward-pointed to Chapter 30;
- classify expiry, decline, cancellation before acceptance, and post-acceptance problems correctly, with recovery detail forward-pointed to Chapter 30;
- explain posting, reporting, and reconciliation for a send — sender debited, recipient credited on acceptance, bank settlement legs behind the scenes — without treating notification as settlement;
- describe what a bank must build, test, and support to offer send-money safely, including status evidence;
- work through two or three fictional everyday sends — a rent payment to a landlord and a marketplace seller payout among them — and extract the control lesson from each.
For a roughly 60-minute core session, spend about 10 minutes on the scope and Sections 1–2, 20 minutes on Sections 3–4 with the lifecycle and addressing diagrams, 10 minutes on Sections 5–6, 10 minutes on Sections 7–9 with the status model, and 10 minutes on the fictional stories in Section 11 plus takeaways in Section 12. The remaining depth — Autodeposit mechanics, Request Money, exceptions and fraud operations — is follow-up study in Chapters 28–30.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and system boundaries
- Initiation, authentication and sender-bank processing
- Addressing, notification, acceptance and settlement
- Data, identifiers, messages and references
- Rules, service levels, availability and customer impact
- Fraud, compliance and operational controls
- Exceptions, expiry, cancellation and recovery
- Posting, accounting, reporting and reconciliation
- Bank implementation, testing and resilience
- Practical Canadian send-money examples
- Key takeaways and authoritative references
1. Business context and customer need
Every Canadian banker already knows the scene. A tenant owes the landlord rent on the first and does not want to handle cash or wait for a cheque to clear. A buyer from an online marketplace is standing in a parking lot looking at a used bicycle and the seller will only hold it for ten minutes. A parent is sending spending money to a student in another province on a Sunday evening. A friend covered dinner and three people owe their shares. A homeowner is paying a contractor a deposit before work starts on Monday. None of these customers wants a lesson in payment systems. Each wants the same five things: to start the payment from the phone already in their hand, to be sure it reaches the right person, to know when the other side has it, to pay little or nothing for the privilege, and to have someone to call when something looks wrong.
The Interac e-Transfer send answers that need with a push payment that starts inside a bank app and completes when the recipient accepts or Autodeposit deposits the funds. The sender does not need the recipient's account number, transit, or institution. The sender needs an email address or a mobile number — something people actually know about each other. The recipient does not need an account at the same bank. The sender and recipient each need access to a participating Canadian financial institution. Initiation is available around the clock, including evenings, weekends, and holidays, because the starting point is the sender's own online or mobile banking.
That convenience creates the exact misunderstandings this chapter exists to correct. Because the experience feels instant, customers assume the money arrives the moment they press send. It does not. What happens at send is that the sender's bank takes the instruction, checks it, and issues the transfer into the Interac network. The recipient must still be notified. Without Autodeposit, the recipient signs in at their own bank and answers the sender's security question; with Autodeposit, the registered address is matched and the funds are deposited automatically. Only on acceptance does the recipient's account get credited. A sender who treats "sent" as "received" creates real harm: the tenant who stops worrying about rent that the landlord never accepted, the buyer who drives away with goods the seller never got paid for, the business that ships against a notification email alone. Every section of this chapter returns to that discipline, because every loss story in the send-money world starts with somebody acting on the wrong event.
Scale is the second reason bankers must understand the send properly. The Bank of Canada designates Interac e-Transfer as a prominent payment system because disruption could affect economic activity and confidence. High volume with a 24/7 starting point changes operations: monitoring, status inquiries, and support cannot keep branch hours, and a small design flaw repeats at volume.
The third reason is positioning. The send is one member of a family, and bankers must know where its responsibility starts and stops. It is not bill pay, which routes to a registered biller with remittance the biller can match — bill journeys live in Block 10. It is not a wire over Lynx, which carries high-value same-day-final Canadian-dollar value with beneficiary-agent data and intraday liquidity behind it — wire journeys live in Block 8. It is not the Real-Time Rail, which is a separate Payments Canada system — the RTR lives in Block 12. At the audit date, Payments Canada describes RTR as still undergoing testing, with launch targeted for Q4 2026 and phased Interac e-Transfer clearing-and-settlement migration participants in 2027; it is not a current production substitute for this send. The send is the Interac service's answer to everyday pushes between people and small businesses: addressed by email or mobile, notified electronically, deposited through the recipient's participating financial institution, and confirmed to both sides. Needs beyond that envelope belong on other rails. This chapter teaches the send itself, completely, so the routing choice is an informed one.
Consider the two customers who will recur throughout this chapter, both fictional. Amara rents an apartment in Hamilton and pays her landlord, Mr. Chen, by e-Transfer on the first of every month — a repeat send to a known person where addressing accuracy and the security answer matter more than speed. And consider Priya, who sells a used kayak to a stranger she met on a marketplace app — a first-time send to an unknown person where interception and impersonation risk dominate. One journey, two risk profiles, same seven stages. By the end of this chapter you should be able to walk either customer through those stages, tell each what to watch for, and explain what the bank sees at every step.
The diagram above is the chapter anchor: top-to-bottom order of events, with no amounts, fees, or times — those are per-bank schedules. Every later section deepens one or two of its boxes.
2. Participants, responsibilities and system boundaries
A send looks like two people, but it always involves five parties, and the bank professional must keep all five straight. The parties are the sender, the sender's bank, Interac Corp as the network operator, the recipient, and the recipient's bank. Each owns a distinct slice, and every failure in this chapter traces back to somebody assuming another party owned their slice — the sender assuming the network verifies the recipient is the right person, the recipient assuming the sender's bank will complete the deposit, a banker assuming Interac holds the customer relationship.
Start with the sender. The sender owns the economic decision and the instruction: who should be paid, how much, from which account, addressed to which email or mobile number, with what message, and with what security question and answer where one applies. The sender also owns the accuracy of the address. The network routes to the address given, not to the person intended. A transfer addressed to a mistyped email notifies whoever controls that inbox, and the sender's bank cannot un-notify it. That single fact — the sender owns addressing accuracy — is the most operationally important sentence in this chapter, and Section 4 expands it into addressing practice.
The sender's bank owns everything from the sender's tap to the network's door. It authenticates the sender at sign-in, presents the send screen, validates the instruction, applies its own limits and fraud monitoring, runs any required screening, issues the transfer into the Interac service, commits or debits the sender's funds according to its policy, tracks the status, and confirms completion or non-completion back to the sender, and handles the sender's inquiries, cancellation requests before acceptance, and fraud claims after. The sender never touches the network directly. Every send the bank issues is the bank's responsibility to its customer, which is why Section 3 treats sender-bank processing as a full payment pipeline rather than a screen with a button.
Interac Corp provides and facilitates the e-Transfer service. It is not a financial institution, and its role is separate from Payments Canada, which operates Lynx and the retail batch system, and from the Bank of Canada, which oversees Interac e-Transfer under the Payment Clearing and Settlement Act. Interac's public help says that email and text carry the notification while participating financial institutions use existing payment networks to transfer the money. The service can coordinate the notification and deposit journey, but this chapter does not claim that Interac itself owns customer authentication, customer limits, or the inter-financial-institution settlement accounts and cycles. Those are bank, network, and participation-agreement implementation matters. When a customer asks "where is my money," the answer starts with the sender or recipient financial institution's records and the Interac reference — not with an assumption about an undisclosed settlement leg.
The recipient owns the acceptance decision and the acceptance act. Nobody can complete a standard send on the recipient's behalf. The recipient must open the notification, choose their own bank, sign in, select the account, and answer the security question correctly — or, where the recipient has registered an address for Autodeposit, the registered address must match so the funds can be deposited automatically. The recipient also owns the vigilance the channel demands: confirming the notification is genuine before signing in, and checking with the sender through a separate channel when anything looks unexpected.
The recipient's bank owns everything from the network's door to the recipient's account. It hosts the acceptance sign-in, verifies the recipient, checks the security answer or the Autodeposit registration match, credits the recipient's account on acceptance, confirms the deposit to the recipient, reports the status back through the network, and handles the recipient's inquiries and disputes. Critically, the recipient's bank is a full participant with its own controls: it does not accept blindly on the network's instruction, and its fraud monitoring watches incoming transfers as well as outgoing ones, because mule activity and scam proceeds arrive as incoming credits.
Two boundaries complete the map. First, any inter-financial-institution value movement is a banking and network matter behind the customer experience. Customers experience send, notify, accept, and confirm; the applicable participant and network arrangements determine the operational processing and settlement evidence. Bankers must understand that those legs exist and must reconcile them (Sections 4 and 9), but must never describe notification as settlement to a customer. Second, the supervisor boundary: the Bank of Canada oversees Interac e-Transfer as a payment system under the Payment Clearing and Settlement Act, which concerns system safety and resilience without making the central bank a party to an individual transfer. The Bank's current RPAA FAQ explains that payment functions performed on a PCSA-designated system such as Interac e-Transfer are outside the RPAA, while related functions performed outside that system may remain in scope; banks are separately excluded from the RPAA as entities. Consumer-protection guidance, including fraud-awareness material from the Financial Consumer Agency of Canada, sits alongside as public education rather than Bank of Canada consumer-protection oversight.
Responsibility, in one chain: the sender authorizes and addresses. The sender's bank validates, controls, issues, debits, and confirms. The network routes, notifies, and tracks. The recipient verifies and accepts. The recipient's bank verifies, credits, and reports. No gaps, no overlaps. Every investigation in Chapter 30 walks that chain, which is why this chapter teaches the walk once, generically, before any exception detail.
Read the split diagram as an accountability chart: sender questions belong to the top lane, notification and status questions to the middle lane, acceptance and credit questions to the bottom lane.
3. Initiation, authentication and sender-bank processing
Every send begins in the same place: the sender, signed in to their own bank's online or mobile banking, choosing to send money. The bank's processing from that moment to the network's door is a full payment pipeline — initiation, authentication, validation, control, release, debit, tracking, and confirmation — and this section walks it in order. Banks that operate this pipeline with the same discipline as any other payment release get the send right. Banks that treat it as a lightweight feature bolted onto the app get exactly the losses Chapter 30 catalogues.
Initiation captures five things: who pays, how much, from which account, to which address, and with what accompanying detail. Who pays is established by the authenticated session — the sender is whoever signed in, which is why authentication quality determines everything downstream. How much is the amount, entered by the sender and checked against the bank's own per-customer and per-transfer limits. From which account is the sender's choice of funding account, which must be open, in good standing, and authorized for transfers. To which address is the recipient's email or mobile number, entered or selected from the sender's saved recipients. Accompanying detail is the sender's message to the recipient and, where the transfer needs one, the security question and answer that the recipient will have to supply. Each bank's app arranges these differently, but every bank must capture all of them, because a missing element at initiation becomes an exception later — an insufficient-funds decline, a misaddressed notification, an unanswerable question.
Authentication has two layers, and both must pass before anything moves. Session authentication proves the sender is the account holder: password plus the bank's second factor, device recognition, and behavioural checks operating per the bank's own policy. Instruction authentication proves this particular send is intended: confirmation screens, one-time codes for new or high-risk recipients, and step-up challenges when the device, location, amount, or recipient deviates from the customer's pattern. The distinction matters because account takeover defeats the first layer by stealing credentials, while scams and authorized-push fraud sail through the first layer with the genuine customer sitting at the screen. A bank that authenticates the session but never challenges the instruction will release fraud that a confirmation step would have caught. Generic functional language is deliberate here: the exact factors, thresholds, and challenge rules are per-bank decisions stated in each bank's own policies, not in this chapter.
Validation follows authentication and precedes any network contact. The bank confirms the funding account can bear the transfer, the amount passes the bank's limits for this customer and channel, the address is a usable email or mobile number, and the security question arrangement is coherent. Duplicate and anomaly checks compare the instruction against recent sends. Repair-or-reject happens here: a send rejected in the bank with a clear reason costs the customer a minute, while a send released with bad data costs both banks an investigation.
The control stack sits between validation and release, in an order that matters. Fraud monitoring scores the send against takeover, scam, mule, and velocity signals. Where required by the bank's legal and risk framework, screening checks the parties and payment text the sender supplied. Limits enforce the bank's published per-transfer, daily, and per-recipient ceilings for this customer. Approval logic applies any dual-control or step-up the bank requires for the risk tier. Only after all of these does the bank release — issuing the transfer into the Interac network with the addressing, amount, message, and question arrangement attached. Release is the point of no return for the sender's intent: from here the transfer exists in the network, the notification will go out, and only the defined pre-acceptance paths (Section 8, detail in Chapter 30) can stop it.
Debit and status tracking complete the sender-bank side. The sender funds the transfer — how that appears (immediate debit, pending hold, available-balance effect) is per-bank presentation, and this chapter states no universal mechanics beyond the functional fact: the sender's money is committed, and the recipient is credited on acceptance. From release onward the bank tracks the network status — notified, accepted, declined, expired, cancelled — and reflects it honestly in the sender's history and notifications. "Pending" must mean the recipient has not acted yet, never "probably fine." "Completed" must mean the recipient's bank confirmed the credit, never "we sent it." That vocabulary discipline is a release-gate in its own right: status wording that over-promises creates the double-spend and early-release losses of Section 1.
After release the bank stays active on the sender's behalf until a terminal state. It watches for acceptance confirmation, ages unaccepted transfers toward their window, surfaces cancellable-before-acceptance options where its policy offers them, and keeps the evidence — who sent, to what address, when, with what status transitions — that every inquiry, claim, and reconciliation needs. Amendments after release are narrow by design: an address typo cannot be edited into a different recipient and an amount cannot be adjusted mid-flight. The correction path is cancel-where-permitted and re-send, never silent editing.
Two design principles decide whether all of this survives contact with real customers. First, challenge the instruction, not just the session — the fraud that hurts most arrives from authenticated customers who were deceived, rushed, or impersonated, and only instruction-level checks (new-recipient confirmation, out-of-pattern challenges, callbacks for business sends) catch it. Second, fail visibly and early — a bank that rejects a bad send with a reason and a repair path creates one short call; a bank that releases everything and investigates later creates the caseload Chapter 30 exists to manage.
4. Addressing, notification, acceptance and settlement
If Section 3 is about the sender's bank, this section is about the journey between the banks: how the transfer finds the right person, how that person is told, how they complete the receipt, and how value settles behind the scenes. Addressing, notification, acceptance, and settlement are four different events with four different owners, and blending them is the root of nearly every send-money dispute. This section keeps them separate.
Addressing is the sender's act of naming the recipient with an email address or a mobile number, and it has exactly one rule that matters: the network routes to the address given, not to the person intended. A correct address reaches the right inbox or phone; a mistyped one notifies a stranger; an old address reaches whoever controls it now. Saved recipients reduce retyping risk but introduce staleness risk — the contact that was correct two years ago may belong to someone else today. First-time addresses deserve the sender's full attention: read the address back, confirm it with the recipient through a separate trusted channel, and for meaningful amounts send a small test transfer first and confirm receipt by voice before sending the balance. None of this is network functionality. It is sender discipline, and banks should teach it at the send screen rather than in a brochure nobody reads.
There are two customer-entered notification addresses plus an Autodeposit registration state, and the diagram below compares them side by side. Email addressing sends the notification to an inbox; mobile addressing sends it by text. Either address can be used for a one-off or repeat send, subject to the recipient having a Canadian account at a participating financial institution. Autodeposit is not a third customer-entered address: it is the recipient's prior registration of an email address or mobile number to a designated account. When the registered address matches, Interac says the funds are deposited automatically with no security question and answer. Registration, matching, confirmation, and customer controls are Chapter 28's subject in full — this chapter describes only its functional effect on the send. The same Interac e-Transfer service sits underneath, but the notification and acceptance steps differ.
Notification is the network's act of telling the recipient that money awaits, and bankers must understand what it is and what it is not. It is an email or a text message carrying a secure link and the sender's message — enough for the recipient to know who sent what and where to go. It is not money, not proof of payment, and not a safe object to forward, screenshot into a sale, or act upon blindly. Its security properties are exactly those of its channel: email and text can be delayed, filtered as spam, received on shared devices, and — critically — imitated. A genuine notification never asks the recipient to enter banking credentials on the page it links from; it routes the recipient to sign in at their own bank. Recipients who understand that one rule are immune to the commonest phishing shape in this space; recipients who do not are its victims. Banks own the education task, and Section 7 returns to it.
Acceptance is the recipient's act of completing the receipt inside their own bank, and the flow below shows its shape. The recipient opens the notification, selects their financial institution from the link's routing, signs in with their own credentials, chooses the deposit account, and supplies the security answer — unless Autodeposit applies, in which case the registered address is matched for automatic deposit. The recipient's bank verifies all of it: the session, the answer or registration, the account eligibility. On success it credits the recipient and reports acceptance back through the network; on failure it refuses with a reason the recipient can act on. Three properties of acceptance deserve emphasis. First, the recipient always accepts at their own bank — any message asking them to enter banking credentials anywhere other than their own financial institution is suspicious and should not be followed. Second, acceptance is a decision point with a decline path: a recipient who was not expecting money, who does not recognize the sender, or who suspects the transfer is scam proceeds should decline rather than accept-and-forward, because accepted funds can carry obligations the recipient does not see yet. Third, acceptance is where the customer experience ends and the posting certainty begins: from the recipient's perspective, acceptance is the moment "paid" becomes true.
Settlement is the event customers never see and operations must never forget. Interac's public help says participating financial institutions use existing payment networks to transfer the money, while its terms say the sending financial institution holds funds until deposit, cancellation, or expiry. The public consumer material does not identify a universal clearing file, API, settlement account, cycle, or cutoff for every participant, so this chapter does not invent one. A bank's implementation must use its current participation and network documentation to reconcile its own outbound and inbound records, funding/hold entries, deposit confirmations, and any inter-financial-institution settlement evidence. Customer communication must never call notification "settlement," and availability language to the recipient must be honest: deposited according to the recipient financial institution's confirmation and funds-availability policy.
Read the whole section as one causal chain: accurate addressing causes correct notification; trustworthy notification causes safe acceptance; verified acceptance causes the credit; the credit causes the confirmation.
5. Data, identifiers, messages and references
A send carries remarkably little data compared with a wire or a batch file, and that thinness is both its usability triumph and its operations constraint. Customers do not need to exchange account, transit, or institution numbers. The sender supplies an email address and/or mobile number; Autodeposit adds the recipient's prior registration of that address to a designated account. These customer-facing addresses do not replace the financial institutions' internal account and participant identifiers. This section maps what data a send actually needs, what references must survive the journey, and where thin data limits what the bank can do later.
The addressing data is the minimum routable set: the recipient's email address or mobile number as typed by the sender, plus the sender's own identifying display (typically name) so the recipient can recognize the source. Because the address is the routing, its quality rules are strict in practice even where the screen looks casual: the address must be complete, must be syntactically usable in its channel, and should be confirmed for first-time or high-value sends through a second channel. Saved-recipient stores add a reference layer of their own — nickname, address, history, last-used date — and banks should treat that store as payment data with the same integrity expectations as any payee master: changes to a saved recipient's address deserve confirmation, and dormant recipients deserve re-verification before a large send, because takeover fraud edits payee stores precisely where nobody looks.
The transfer data around the address is small but load-bearing: the amount, the sender's message to the recipient, the security question and the expected answer's verification material where a question applies, the sender's funding-account reference internal to the sender's bank, and the network reference that identifies the transfer end to end. The message field deserves a banker's respect disproportionate to its size: it is the only remittance the recipient sees, the text both banks' screeners read, and the evidence an investigator quotes first. Senders should write messages that identify the purpose plainly — month of rent, item sold, share of what bill — and banks should screen them as payment text, because scam and mule traffic often announces itself in the message while the amount looks ordinary.
The security question arrangement is data with a human failure mode, so this chapter states its functional shape plainly. Where a question applies, the sender composes a question whose answer the genuine recipient knows or has been told, and the recipient must supply that answer at acceptance. The answer must never travel in the notification or the message — that would hand the key to anyone who intercepts the notice, and interception is a named pattern in Section 7. The question must be genuinely selective: questions whose answers are guessable, public, or shared with the notification channel ("what did I just email you") are decoration, not control. And the answer must reach the recipient through a channel the sender trusts independently of the transfer — spoken, in person, or through an established messaging history — because telling the answer in the same email thread as the address hands both halves to an interceptor at once. Where Autodeposit applies, no question is needed at all, which removes the whole failure class; that removal is the strongest practical argument for Autodeposit adoption among repeat counterparties, and Chapter 28 builds the adoption case.
References are what let two banks and two customers agree they are talking about the same transfer. Four must survive the whole journey: the sender bank's internal instruction identifier, the network transfer reference, the status trail (sent, notified, accepted, declined, expired, cancelled with timestamps), and the customer-facing descriptors both sides see (amount, sender display name, message, destination address). Drop any one and a different process breaks: without the internal identifier the sender bank cannot find its own debit; without the network reference the banks cannot correlate across the network; without the status trail nobody can answer "where is it"; without the customer descriptors the recipient cannot recognize what arrived. Reconciliation in Section 9 is largely the discipline of keeping those four linked from initiation to terminal state.
Thin data has two honest limitations bankers must state plainly. First, a send carries no structured remittance — no invoice lines, no account references the recipient's accounting can ingest — which is why business use with reconciliation needs belongs in Block 7's richer flows rather than being stretched onto consumer sends. Second, a send's addressing identifies a channel endpoint, not a verified identity: an email address proves control of an inbox at notification time, not that the controller is the intended person. Every impersonation pattern in Section 7 exploits exactly that gap. The bank that explains both limitations before volume arrives will set the product's boundary correctly; the bank that discovers them during a fraud claim will set it expensively.
6. Rules, service levels, availability and customer impact
Customers experience rules as promises — will it get there today, when can the other side use it, what does it cost, what happens if it fails — and the bank experiences rules as obligations and evidence. This section connects the two without inventing a single number. Amount ceilings, fees, expiry windows, and processing times are set per financial institution and stated in each bank's published schedules; this chapter describes only the functional shape those schedules fill in. Any study note, job aid, or customer script that quotes a specific limit, fee, or hour from this chapter is misusing it.
Initiation availability is the service's signature promise and the one availability statement this chapter makes outright: sends can be started around the clock, because initiation lives in the sender's own online or mobile banking rather than in a staffed channel or a batch window. Evenings, weekends, and holidays all work for starting a transfer. Everything downstream of initiation, however, runs on its own clock. Notification delivery depends on email and text channels the banks do not control. Acceptance depends on a human recipient acting — promptly, eventually, or never. Posting depends on the recipient bank's own credit and availability handling. Inter-financial-institution processing follows the applicable bank and network arrangements; the public consumer sources do not establish one universal cycle. A banker who promises "24/7 everything" from "24/7 initiation" will be wrong on every file where the recipient sleeps, the notification lands in spam, or the acceptance waits until morning. Promise initiation honestly, describe the rest as recipient- and bank-dependent, and the customer can plan.
Service levels bundle four things the customer actually buys: reach, effort, certainty, and recourse. Reach means any participating bank or credit union on either side — the sender never needs to ask where the recipient banks, only for an email or phone number. Effort means no account numbers exchanged and no forms — the addressing choices of Section 4 are the whole routing burden on the customer. Certainty means a defined status trail with a terminal state for every transfer: completed on acceptance, or not completed through decline, expiry, or pre-acceptance cancellation, each with the sender informed. Recourse means a defined path when things go wrong: cancel-where-permitted before acceptance, re-send after addressing errors, claim and investigate after fraud — with the detailed paths in Chapter 30. When a need exceeds that bundle — guaranteed same-day finality, hundreds of payees, structured remittance — the honest answer is a different rail, and the routing chapters say which.
The status vocabulary of Section 3 returns here as a service-level obligation, because status is the product the sender actually consumes after pressing send. Five words must mean the same thing in every channel, every script, and every app screen. "Sent" means the sender's bank issued the transfer. "Pending" or its equivalent means the recipient has not acted yet. "Completed" means the recipient's bank confirmed the credit on acceptance. "Declined," "expired," and "cancelled" each mean their own terminal non-completion with the sender-side handling Chapter 30 defines. "Available" or "deposited" describes the recipient-side credit under the recipient bank's own availability policy. Staff who use those words interchangeably — telling a sender a transfer is "done" when it is merely sent, or telling a recipient money "arrived" when only the notification arrived — manufacture the exact double-spend and early-release losses this chapter warns against. Training every customer-facing colleague on those words prevents more complaints than any system upgrade.
Customer impact concentrates in three moments. At send time, the impact is commitment: the sender's money is spoken for, so the sender must not re-send "just in case" without checking status — duplicate sends from anxious senders are a genuine and common exception source. During the wait, the impact is uncertainty management: the sender needs to know the transfer is visible, pending, and ageing toward its window, and needs to know what to do if the recipient reports no notification — check the address, check spam and the phone number, confirm through a second channel, re-send only after the first transfer's state is known. At completion or non-completion, the impact is closure: the completed sender needs confirmation with enough detail to close their own books (landlord paid, buyer paid), and the non-completed sender needs the next step stated plainly rather than a bare status code. Each of those moments is a design requirement on the sender bank's app and notification copy, not a slogan.
Pricing and limits interact with behaviour in ways bankers should anticipate generically. Because sends feel free or cheap, customers use them for purposes at the edge of the envelope — deposits on large purchases, first payments to strangers, urgent business supplier payments — where the rail's protections (thin data, address-based routing, no structured remittance) fit worst. The bank's product response is not stated here as numbers but as posture: publish limits and fees plainly, enforce them in the hub before release rather than in customer argument after, and advise customers at the send screen when a different rail fits better. A customer told at initiation that a house deposit belongs on a wire will thank the bank; a customer told after interception will not.
7. Fraud, compliance and operational controls
Controls fail when they are complete but misplaced, and nowhere is placement more visible than in a 24/7 send flow where initiation, notification, and acceptance happen in three different places under three different parties' eyes. This section places each control family at the point where it can still change the outcome, describes the fraud patterns at functional level, and leaves investigation procedure, claim handling, and monitoring operations to Chapter 30 and the fraud landscape of Block 13. The placement lesson is this chapter's contribution; the procedure detail belongs downstream.
Fraud monitoring at the sender bank gates release. It scores every send against takeover signals (new device, changed credentials, unusual hour or location for this customer), scam signals (first-time recipient, coaching language in the message, urgency markers, amounts inconsistent with history), mule signals (sends consistent with flow-through rather than genuine payment), and velocity signals (bursts, round amounts, repeated identical sends). Monitoring must run pre-release for every send with a disposition of pass, step-up, or hold — a hold that triggers after the notification goes out is recovery, not prevention, because the recipient side is already in motion. Business sends add the approval dimension: dual control on new recipients, callbacks to known numbers for changed addresses, and segregation between the staff member who enters and the one who releases. Those are generic functional controls; each bank's thresholds, models, and approval matrices are its own policy, not this chapter's text.
Interception is the pattern that belongs to the addressing and notification stages, and bankers must be able to explain it cold. Its shape is simple: the attacker positions between sender and recipient — a compromised inbox, a SIM the recipient no longer controls, a lookalike email address the sender mistypes toward — and either diverts the notification or harvests the security answer from the same channel that carried the address. Its enablers are sender-side (unverified addresses, answers shared in the notification thread, guessable questions) and recipient-side (signing in from untrusted links, ignoring device alerts). Its countermeasures sit at both ends: address verification through a second channel and genuinely selective questions at the sender end; link hygiene and Autodeposit registration at the recipient end; anomaly detection on acceptance (new device, new account, rapid onward movement) at the recipient-bank end. None of those countermeasures lives in the network middle, which is why "the network will keep it safe" is the most dangerous sentence a banker can utter about this product.
Phishing is the pattern that belongs to the notification stage, and its functional shape is imitation of the trust the product teaches. Recipients trained to expect "you have money waiting" emails will click "you have money waiting" emails from attackers. The fake notification's link leads to a sign-in page the attacker controls, harvesting the recipient's banking credentials, or to a page that asks for the security answer directly. The genuine flow's one rule defeats the whole class: the recipient always signs in at their own bank, reached by typing the bank's address or opening the bank's app directly — never by entering credentials on a page arrived at through a notification link. Banks own the teaching of that rule, own the monitoring of credential-reuse fallout, and own the rapid response when a customer reports entering credentials into a fake page: credential reset first, session review second, transfer review third. The order matters because the attacker monetizes credentials across the customer's whole banking relationship, not just the single transfer.
Scams and account takeover complete the functional pattern set. In the scam shape, the transfer itself is technically perfect — authenticated sender, correct address, valid acceptance — but the instruction is a lie the sender was told: the marketplace goods do not exist, the investment returns are fiction, the "bank investigator" on the phone is the attacker, the romance is a script. No network control can defeat a genuine customer instructing their own bank, which is why instruction-level friction (new-recipient delays, amount challenges, explicit scam warnings at the send screen, cooling language for first-time payees) is the control plane's most cost-effective layer. In the takeover shape, the attacker is the sender, operating the victim's session after credential theft; device, behavioural, and velocity signals are the detection surface, and rapid recipient-side observation (does this customer normally receive from this sender, does the credit move onward instantly) is the second net. Mule activity is the receiving-side mirror: credits that arrive and depart with no economic purpose, implicating the recipient account whether its holder understands the role or not.
Compliance controls gate release alongside fraud, in the same pre-release window where the bank's legal and risk framework requires them. Screening checks the parties and payment text against applicable sanctions and policy lists with logged dispositions. Record-keeping captures the complete instruction, relevant authentication evidence, the status trail, and the terminal state in accordance with applicable law and the institution's retention policy. FINTRAC's electronic-funds-transfer reporting guidance is principally about international EFT reporting and must not be read as a blanket domestic Interac e-Transfer reporting rule; regime detail lives in Block 13 and current official guidance.
Operational controls complete the plane and belong to both banks: entitlements and dual approval, limits and velocity, queue and ageing discipline for unaccepted transfers, no silent editing of live transfers, evidence preservation, and segregation of duties. And the release discipline from Section 3 ties them together: no send reaches the network without passing authentication, validation, limits, fraud, and screening in that order, with each decision logged. Exceptions to that order — manual releases, verbal instructions, after-hours overrides — must themselves be controlled, dual-approved, and time-bound, because every major send-money loss involves an override that bypassed the order.
8. Exceptions, expiry, cancellation and recovery
Every send ends in exactly one terminal state — completed on acceptance, or not completed through decline, expiry, or pre-acceptance cancellation — and this section teaches the classification at functional level so bankers, senders, and recipients use the same words for the same outcomes. Procedure, timelines, customer scripts, claim handling, and operations queues are Chapter 30's subject in full; this chapter builds the map Chapter 30 navigates by. The classification discipline carries the whole section: classify first, then act, because acting on the wrong classification — re-sending against a transfer that later gets accepted, refunding a sender whose recipient already holds the credit — creates the duplicate payments and audit breaks that dwarf the original problem.
Start with the taxonomy. A decline happens when the recipient refuses the transfer at acceptance: unexpected money, unrecognized sender, suspicion of scam proceeds, wrong amount. Nothing is credited; the sender is informed and sender-side handling follows the bank's published path. An expiry happens when nobody accepts within the transfer's window: the recipient never saw the notification, the address was wrong, the recipient is travelling, the question was never answered. Nothing is credited; the sender is informed and sender-side handling follows. A pre-acceptance cancellation happens when the sender stops the transfer before acceptance through the sender bank's offered path — typically because the address was mistyped, the wrong amount was entered, or the sender realized the instruction was wrong. Nothing is credited; the transfer leaves the pending population. A post-acceptance problem is categorically different: once the recipient's bank has credited the recipient, there is no unilateral pullback. Recovery needs the recipient's cooperation through a new transfer, or a fraud claim and investigation where wrongdoing is alleged — never a silent reversal of the credit. That asymmetry, cancellable before and final after, is the single most important exception fact in the chapter, and every customer conversation about "just reverse it" must start there.
Each non-completion has a distinct sender-side meaning the bank must communicate plainly. Declined means the recipient acted and said no — re-sending the identical transfer to the identical address without talking to the recipient first will likely produce a second decline, so the next step is contact, not repetition. Expired means nobody acted — the next step is verifying the address and the notification channel (spam folder, phone number digits, inbox access) before re-sending, because re-sending to the same dead address produces the same silence at double the confusion. Cancelled-before-acceptance means the sender acted in time — the next step is confirming the sender-side handling completed and then re-sending correctly. None of those wordings is a procedure; each is the honest classification that makes the Chapter 30 procedure selectable. A status screen that says only "not completed" without distinguishing the three sends every customer down all three paths at once.
Misaddressing deserves its own passage because it is the commonest exception and the least recoverable. A transfer addressed to the wrong email notifies the wrong inbox; if that inbox's holder accepts with the correct answer — and answers travel in the open more often than anyone admits — the credit is genuine to the wrong person and the post-acceptance rule applies. Prevention is therefore the entire strategy: confirm first-time addresses through a second channel, use saved recipients for repeats, test with a small amount where the stakes justify it, and never publish the answer alongside the address. Detection is the sender noticing non-acceptance early and cancelling within the pre-acceptance window where the bank's path offers it. Cure after acceptance is cooperation or claim, not reversal. Banks should state that sequence at the send screen for first-time recipients, because the sender who learns it during a loss learns it too late.
Uncertain outcomes complete the set and test the bank's evidence discipline. The sender reports the recipient "never got it" while status shows notified; the recipient reports "nothing arrived" while status shows accepted; two transfers for the same purpose exist and nobody knows which completed. The investigation walk is always the same chain from Section 2 in reverse: confirm the sender bank's release and reference, confirm the network's notification and status trail, confirm the recipient bank's acceptance or non-acceptance evidence, then communicate state plus next step — never activity alone. Preserve the original references throughout: every re-send, claim, and adjustment links to the original transfer rather than replacing it, so the books show one story with branches instead of two stories that reconcile into a duplicate. Chapter 30 turns that walk into queues, roles, and timeframes; this chapter's contribution is the insistence that the walk exists and starts with classification.
Read the status diagram as the vocabulary contract for the whole block. In-flight states move left to right and only forward; terminal states end the journey; the sender bank's app is the source of truth the sender should check before any re-send. Any customer script, app screen, or investigation note that uses a different word for the same state breaks the contract and should be corrected to it.
9. Posting, accounting, reporting and reconciliation
Posting is where the journey becomes money in accounts, and this section translates the customer-visible events into the bank's books, statements, and reconciliations. The functional posting rule is one sentence: the sender funds the transfer and the recipient is credited on acceptance. Around that sentence sits everything operations must get right — how the sender-side commitment appears, how the recipient-side credit appears, how the interbank legs settle, what the customer sees, and how the bank proves the whole population reconciles.
Sender-side posting reflects commitment from initiation. How that commitment presents — immediate debit entry, pending hold against available funds, memo-posting conventions — is per-bank accounting policy, and this chapter states no universal mechanics. What is universal is the evidence obligation: the sender's statement and history must show the send with amount, destination address, date, reference, and current status, and must update that status through every transition to the terminal state. A sender statement that shows the debit but never the completion forces the sender to call for what the app should say; a history that shows "sent" forever for an expired transfer teaches the sender to distrust every status. The posting requirement is therefore twofold: correct entries and living status, both from the same reference.
Recipient-side posting reflects acceptance. On verified acceptance the recipient's bank credits the recipient's chosen account and reports the deposit to the recipient with the sender's display name, amount, message, and reference — the descriptors that let the recipient recognize what arrived and close their own loop. Availability of the credited funds follows the recipient bank's own funds-availability policy, stated in that bank's schedules, not in this chapter. The honest recipient-side vocabulary is "credited on acceptance, available per your bank's policy" — a sentence that prevents both the "I can spend it this second" assumption and the "the bank is holding my money" complaint, because it names the actual determiner.
Inter-financial-institution value movement sits behind the customer experience, but the public consumer sources do not establish one universal Interac settlement cycle or account model. Customers never see these records and must not be told that notification equals settlement; operations must reconcile the participant's actual network evidence and bank books at the applicable cadence. The reconciliation population is every transfer the bank touched in the window, in both directions: sends issued and their terminal states, incoming transfers accepted and credited, fees where the bank's schedule applies them, funding/hold or debit entries, and adjustments. Breaks have a small set of causes — status mismatches between bank and network records, missing acceptance confirmations, duplicate reference handling, fee-posting errors, cutoff-boundary items — and each break needs owner, ageing, and escalation before it needs heroics. A break aged without ownership becomes a customer complaint or a financial misstatement; a break owned and aged visibly becomes routine operations.
Reporting serves three audiences with three different cuts of the same evidence. Customers get statements, histories, and notifications with the living status this section demands. Operations gets control totals — sends issued versus network acknowledgements, acceptances versus credits posted, terminal-state completeness, ageing of the pending population — that prove the day closed. Oversight gets the aggregates for risk, fraud, and finance: volume and value by direction, non-completion rates by cause, fraud-claim linkage, fee income where applicable, and the suspense and adjustment positions with owners. All three cuts derive from the four references of Section 5; any report that cannot drill from aggregate to individual transfer by reference is decoration, and reconciliation built on it will fail its first audit.
Three-way discipline ties the section together: the customer books (what senders and recipients see), the network evidence (what Interac status and references say), and the bank's books (what was debited, credited, settled, and fee'd) must agree every cycle, with breaks identified, owned, and cleared rather than carried. The practical test is the inquiry test: any sender or recipient question — where is it, what state, what next — must be answerable from linked evidence in minutes, citing the same references the customer sees. Banks that build that linkage handle send-money support at scale; banks that keep status in the app, debits in the core, and network evidence in a separate tool will answer every inquiry three times and reconcile none of them.
10. Bank implementation, testing and resilience
Offering send-money looks like enabling a feature; operating it is running a 24/7 payment pipeline with fraud, status, and support obligations at all hours. This section describes what a bank must build, test, and sustain, staying at functional level throughout — architecture and control expectations, not vendor selections, configurations, or project plans. A bank that implements every paragraph here will still need its own design authority, testing evidence, and operational readiness proof; a bank that skips any paragraph will meet it again as an incident.
Channel and hub integration comes first. The send screen lives in online and mobile banking, but the send pipeline lives in the bank's payment hub alongside every other payment: instruction intake with a durable internal identifier, validation, limits, fraud decisioning, any required screening, release through the bank's Interac integration, status tracking, posting triggers, notification copy, and reconciliation feeds. Public Interac consumer pages do not publish a universal wire-format file, message schema, or API contract for this service; a bank must implement against its current participation documentation rather than infer ISO 20022 or ACSS message semantics. The evidence model should still link the internal instruction ID, the Interac reference, request/response or status events, notification result, hold/debit, deposit confirmation, and terminal outcome. Banks that route sends through a shared hub inherit shared controls, evidence, and monitoring; a channel wired directly to a gateway can duplicate controls and fragment investigations. The hub must enforce the single-clock discipline for status: the app may display only what the bank's confirmed record supports.
Control configuration is per-bank policy expressed in systems. Limits by customer tier, channel, recipient tenure, and risk signal; step-up rules for new recipients and anomalous patterns; screening lists and dispositions; hold and review queues with staffing behind them; status-wording tables binding app copy to hub states; cancellation-before-acceptance paths with their availability rules; evidence-retention rules covering the four references of Section 5 through claim and audit horizons. Each of those is a business decision with a system expression, owned jointly by product, risk, operations, and technology — never by technology alone. The recurring implementation failure is configuring the happy path completely and the exception paths never: sends release beautifully while cancellations, claims, and status corrections run on spreadsheets and memory. Chapter 30's procedures must be system-supported from launch, not documented after the first incident.
Testing must cover the journey, not just the screen. Functional testing walks initiation through terminal states for each addressing choice, including Autodeposit matching behaviour at functional level (mechanics in Chapter 28). Control testing proves limits reject, fraud holds trigger pre-release, screening dispositions route correctly, and overrides require their dual approvals. Exception testing walks decline, expiry, pre-acceptance cancellation, misaddressing, duplicate sends, notification failures, and post-acceptance disputes to their terminal states with correct status wording at each step. Reconciliation testing proves the control totals of Section 9 balance across sends, acceptances, fees, and adjustments, including cutoff-boundary items. And customer-language testing reads every screen, notification, and script against the five-word vocabulary of Section 6 — sent, pending, completed, declined-or-expired-or-cancelled, available — rejecting any copy that over-promises. Test evidence for each of those, retained and re-runnable, is what lets the bank change the product later without relearning it.
Resilience follows from the 24/7 initiation promise. Customers can start sends at any hour, so fraud monitoring, status tracking, and support coverage must span all hours at the level the bank's policy promises — automated decisioning with human escalation, on-call investigation ownership, and communication trees for network or gateway degradation. Contingency covers gateway failover, notification-channel delays, and status-feed interruptions with customer communication that states what is known and what to do, never silence and never invented ETAs. Capacity planning treats peak evenings, month-ends, holidays, and back-to-school and rental-cycle surges as foreseeable rather than exceptional. Incident history — every fraud wave, every notification outage, every reconciliation break — feeds back into limits, monitoring, copy, and training, because a send-money operation that does not learn from its exceptions will repeat them at volume.
Launch and change discipline closes the section. New send capabilities — a redesigned send screen, a new recipient store, changed limits, new notification copy, Autodeposit promotion flows — release behind the same gates as any payment change: control review, test evidence, operations readiness, support briefing, customer communication, and rollback criteria. Post-launch monitoring watches the indicators Sections 6 through 9 define: non-completion rates by cause, fraud-signal rates, status-inquiry volumes, reconciliation breaks, and complaint themes. Drift in any of them is a product signal, not background noise, and the bank that reads it will adjust limits, copy, and controls before the next surge rather than after.
11. Practical Canadian send-money examples
Theory ends where customers begin. This section works three fictional sends end to end — a monthly rent payment to a landlord, a marketplace seller payout to a stranger, and a contractor deposit with a question-answer arrangement — each labelled as fictional, each traced through the seven lifecycle stages, each ending with the control lesson it exists to teach. Names, amounts in generic terms, and details are illustrative only; no bank's limits, fees, or timings are implied.
Example (fictional): the monthly rent to the landlord. Amara pays Mr. Chen on the first of every month. She set him up once as a saved recipient using the email address he gave her in person at lease signing, confirmed it with a small test transfer that he acknowledged by phone, and reuses that saved record every month. On the first she signs in, selects Mr. Chen, enters the month's rent, writes the message "October rent — Unit 4B," answers no security question because Mr. Chen is registered for Autodeposit (the functional effect; mechanics in Chapter 28), and sends. Her bank authenticates her session, validates the instruction against her history — same recipient, same pattern, expected amount — passes its fraud and screening gates, releases the transfer, reflects her commitment, and tracks status. The network routes by the registered address; Mr. Chen's bank matches, credits his account, and confirms. Amara's history moves from pending to completed with the reference, and she closes her month. Control lesson: repeats deserve saved recipients verified once through a trusted channel, and purpose-written messages ("October rent — Unit 4B") turn both sides' records and any future inquiry from archaeology into reading. What would break it: a landlord email change Amara applies from an unverified message without confirmation — the takeover-edit pattern — which is why address changes to saved recipients deserve the same verification as first-time sends.
Example (fictional): the marketplace seller payout. Priya agrees to buy a used kayak from a stranger, Daniel, met through a marketplace app, and they meet in a public parking lot on a Saturday afternoon. Daniel shows the kayak; Priya opens her bank app, enters the mobile number Daniel dictates, enters the agreed price, and — because this is a first-time recipient she has never paid — her bank steps up with an explicit confirmation screen restating the number and a plain-language caution about verifying the recipient. Priya reads the number back aloud; Daniel confirms; she sends. Her bank's monitoring notes the first-time recipient and weekend daylight pattern without blocking a coherent instruction. Daniel receives the text notification, opens it, selects his bank, signs in on his own phone, answers the security question Priya set from a word they agreed aloud ("the lake where we met" — something no inbox snooper holds), chooses his chequing account, and accepts. Priya watches her status move to completed before Daniel loads the kayak into her car. Control lesson: first-time stranger sends compress every risk in the chapter into ten minutes — address read-back aloud, step-up respected rather than rushed past, answer agreed outside the notification channel, goods moving only on completed status. What would break it: Priya sending from the number in a text "from Daniel" that Daniel never sent, or releasing the kayak on "sent" instead of "completed" — the impersonation and premature-release patterns of Section 7.
Example (fictional): the contractor deposit with a question standing in for trust. Sam hires a fencing contractor, Northgate Fencing (fictional), for work starting Monday, with half the quoted price due as a deposit by Friday. The contractor's office emails an address for the transfer and, helpfully, includes the answer to use in the same email. Sam's bank screen warns that answers should not travel with the notification channel; Sam calls the contractor's published business number, confirms the address verbally, agrees a different answer on the call, and sends with the message "Fence deposit — 12 Maple, first half." The contractor accepts Friday afternoon, Sam sees completed status, and Monday's crew arrives with the deposit provably paid. Control lesson: emailed payment instructions are the standing lure of interception fraud — the countermeasure is verifying through an independent channel and never using an answer that travelled with the address, exactly the discipline Section 5 prescribes. What would break it: Sam using the emailed answer verbatim, so anyone holding that inbox could accept; or Sam paying the full price rather than the agreed deposit against a notification alone, converting a deposit dispute into a full-value recovery problem under the post-acceptance rule of Section 8.
Read across the three, the pattern is one sentence: trust the recipient deliberately, verify the address independently, protect the answer separately, and act only on completed status. Rent rewards verification done once and reused. Stranger sales reward verification done aloud under time pressure. Contractor payments reward verification done through a second channel against emailed instructions. The lifecycle never changes; only which link bears the load does.
12. Key takeaways and authoritative references
Ten points carry the chapter. First, a send is seven events in fixed order — initiate, authenticate, address, notify, accept, post, confirm — and acting on the wrong event causes the characteristic losses: double-spends on "sent," early release on "notified," disputes on confused status. Second, the sender owns addressing accuracy absolutely: the network routes to the address given, not the person intended, so first-time addresses are confirmed through a second channel and saved recipients are re-verified after changes. Third, a recipient who is not using Autodeposit deposits the transfer through their own financial institution, signing in directly; any request to enter credentials elsewhere is suspicious. Fourth, the security answer must never travel with the notification, must be genuinely selective, and is unnecessary where directed deposit applies — which is Chapter 28's adoption argument in one line. Fifth, sender-bank controls gate release in order — authentication of session and instruction, validation, limits, fraud, screening — with per-bank thresholds stated in each bank's own policy, never in this chapter. Sixth, interception and phishing are channel-and-human patterns with both-ends countermeasures: address verification and question discipline at the sender end, link hygiene and Autodeposit at the recipient end, anomaly detection at both banks. Seventh, terminal states are final in their own way: cancellable before acceptance through the bank's offered path, cooperatively-or-claim recoverable after — never silently reversible. Eighth, classify before acting on every exception: declined means contact before re-sending, expired means verify the channel before re-sending, misaddressed means prevent first because cure is cooperation or claim. Ninth, posting honesty is a product feature: sender commitment shown with living status, recipient credit on acceptance with availability per that bank's policy, interbank legs reconciled as operations evidence, all four references linked end to end. Tenth, the chapter's boundary is deliberate: Autodeposit mechanics live in Chapter 28, Request Money lives in Chapter 29, exception procedure and fraud operations live in Chapter 30, business and bulk use lives in Block 7, and RTR is a separate modernization system whose current testing and phased launch status must not be presented as today's Interac production path — navigate forward rather than stretching the send beyond its envelope.
Authoritative references (official sources only)
This chapter uses only official sources. Re-check any time-sensitive page before customer or examination use. No amount ceilings, fees, expiry windows, or processing times are stated in this chapter; for binding values use your bank's published schedules. Rules are described functionally throughout; the binding text is the current published network and bank documentation, not this chapter.
- Interac Corp — Interac e-Transfer Help Topics. Official consumer mechanics for notification, participating financial institutions, security questions, decline, 30-day expiry, and the unique reference number. https://www.interac.ca/en/interac-e-transfer-help/
- Interac Corp — How to Send Money with Interac e-Transfer. Official initiation fields, recipient verification, Autodeposit name display, security-question handling, and FI-set limits. https://www.interac.ca/en/how-to-use/interac-e-transfer/how-to-send-money-with-interac-e-transfer/
- Interac Corp — How to Receive Money with Interac e-Transfer. Official notification, Autodeposit, bank sign-in, security-answer, deposit, and completion-notification flow. https://www.interac.ca/en/how-to-use/interac-e-transfer/how-to-receive-money-with-interac-e-transfer/
- Interac Corp — Interac e-Transfer Terms of Use. Provider/facilitator role, FI-held funds, cancellation before deposit, finality after deposit, processing refusals, limits, and records. Last updated August 7, 2021; re-check before binding use. https://www.interac.ca/en/interac-e-transfer-terms-of-use/
- Interac Corp — Your Money. Secure Payments. Our Priority. Official security guidance on encrypted bank networks, Autodeposit, recipient verification, phishing, and reporting fraud. https://www.interac.ca/en/payments/personal/protect-your-payments/
- Bank of Canada — Payment systems the Bank of Canada oversees. PCSA oversight, Interac e-Transfer designation, exchange/clearing/settlement definitions, and RTR modernization context. https://www.bankofcanada.ca/regulatory-oversight/financial-market-infrastructures/payment-systems-the-bank-of-canada-oversees/
- Bank of Canada — Bank of Canada designates Interac e-Transfer as a prominent payment system. Designation effective August 10, 2020, operator, 24/7 statement, risk-management oversight, and consumer-protection boundary. https://www.bankofcanada.ca/2020/08/interac-e-transfer-prominent-payment-system/
- Bank of Canada — Frequently asked questions about retail payments supervision. Current RPAA/PCSA treatment of Interac e-Transfer and bank/PSP scope. https://www.bankofcanada.ca/2026/08/frequently-asked-questions-about-retail-payments-supervision/
- Payments Canada — Real-Time Rail payment system; Testing and launch. RTR is a separate system, targeted Q4 2026 launch, ongoing testing, and phased Interac e-Transfer clearing-and-settlement migration in 2027. https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system and https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/testing-and-launch
- FINTRAC — Reporting electronic funds transfers to FINTRAC. Current EFT reporting scope and international EFT threshold guidance; not a blanket domestic Interac reporting rule. https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng
- OSFI — Operational Risk Management and Resilience Guideline. Critical operations, disruption tolerances, scenario testing, continuity, recovery, and change-management expectations for federally regulated institutions. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/operational-risk-management-resilience-guideline
- Financial Consumer Agency of Canada — Module 7: How to protect yourself from financial fraud. Phishing, vishing, warning signs, credential protection, and response steps. https://www.canada.ca/en/financial-consumer-agency/services/financial-basics/financial-basics-videos/financial-basics-video-fraud.html
- Justice Canada — Payment Clearing and Settlement Act. Current statutory text and designation/oversight framework. https://laws-lois.justice.gc.ca/eng/acts/P-4.4/
- Department of Finance Canada — Government pre-publishes regulations to prevent fraud and facilitate the next phase of consumer-driven banking. 2026 proposed bank fraud-policy, express-consent, limit, and reporting measures; proposed, not a current Interac scheme rule. https://www.canada.ca/en/department-finance/news/2026/06/government-pre-publishes-regulations-to-prevent-fraud-and-facilitate-the-next-phase-of-consumer-driven-banking.html
Diagrams in this chapter: send-money lifecycle; addressing options; notification and acceptance flow; sender/receiver bank processing split; status tracking and confirmation model — all under /diagrams/payment-stories/canada/chapter-27/. Stories, people, and companies are fictional. Autodeposit detail is in Chapter 28, Request Money in Chapter 29, and exceptions, cancellation, fraud operations, and reconciliation procedure in Chapter 30.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.