Autodeposit. Understand registration, recipient matching, deposit processing, confirmation and customer controls.
Block 6 · Chapter 28 of 75
This chapter is about the quietest Interac e-Transfer experience in Canadian banking: money that arrives without anyone clicking a link, answering a question, or choosing an account. A recipient registers an email address or mobile number to one account at their own bank, confirms they control that address, and from then on every matching transfer deposits automatically. There is no acceptance step. There is no per-payment decision. The deposit simply happens, subject to the routine fraud checks both banks run, and both sides are told it happened. That simplicity is the product — and it is also the risk. Everything in this chapter follows from one operating truth: Autodeposit moves the control point forward, from the moment of receipt to the moment of registration. Get registration, matching, and change control right, and Autodeposit is among the safest ways to receive money in Canada. Get them wrong, and a single hijacked registration silently diverts every future payment until someone notices.
This chapter stays at the operating-table level: how a recipient turns Autodeposit on, how a sender's address is matched, how the straight-through deposit works behind the near-instant customer moment, how confirmation proves what happened, which customer controls matter, where fraud concentrates, and how posting, reconciliation, and implementation hold together. Baseline is 5 October 2026. Interac describes the domestic service as offered through participating financial institutions, and the Bank of Canada describes Interac e-Transfer as a 24/7 service operated by Interac Corp, separate from Payments Canada. Exact bank availability, eligibility, controls, fees, limits, and delivery timing remain institution-specific, so this chapter states no dollar limit, fee, or minute-count.
What you will be able to do after this chapter
After working through this chapter, you should be able to:
- explain what Autodeposit is in one plain sentence — a recipient registers an address to an account at their bank so matching transfers deposit automatically — and say how that differs from a standard e-Transfer that needs acceptance and a security answer;
- walk a customer through registration end to end — sign in, find the e-Transfer settings, link an email address or mobile number to a chosen account, confirm ownership through the message sent to that address — and explain why each step exists;
- describe sender-address matching precisely — exact match against active registrations, legal-name display before send, automatic path when matched, standard accept path when not — and explain why a typo or changed address fails safe;
- trace a matched transfer from sender debit through Interac messaging, routine bank fraud checks, automatic credit, bank settlement legs, and dual notification without confusing the customer moment with interbank settlement;
- state which data is strongest for investigating an Autodeposit payment — sender receipt, recipient deposit record inside authenticated banking, Interac reference, completion advice, and statement entries — and why a notice or screenshot needs corroboration;
- explain the public service rules and the bank-specific controls — setup confirmation, account association, sender name display, change safeguards, and timing limits — and translate them into honest customer promises;
- place fraud and compliance controls at the correct point — prudent verification at registration and change, sender vigilance at send time, monitoring of suspicious changes, and phishing resistance in notifications — and describe a high-impact registration-hijack scenario;
- classify exceptions correctly — mismatched address, deactivated mapping, held transfer, misdirected deposit, hijacked registration — and describe recovery that preserves the original transaction identity without promising unilateral reversal of deposited funds;
- explain posting, accounting, reporting, and reconciliation for Autodeposit, including how automatic credits reconcile against bank-leg settlement evidence;
- describe what a bank must build, test, and monitor to offer Autodeposit safely;
- work through two fictional Autodeposit stories — a landlord's rent collection and a community club's hijacked mailbox — and extract the control lesson from each;
- correct the ten most common misunderstandings about Autodeposit and navigate confidently to official Interac guidance for anything this chapter deliberately leaves to the participating institution.
For a roughly 60-minute core session, spend about 10 minutes on this introduction and Sections 1–2, 15 minutes on Sections 3–4 with the registration and matching diagrams, 10 minutes on Sections 5–6 with the data and rules material, 10 minutes on the fraud and exceptions treatment in Sections 7–8 with the hijack diagram, 10 minutes on the fictional stories in Section 11, and 5 minutes on takeaways and references in Section 12.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and system boundaries
- Registration: initiation, validation and bank processing
- Matching and deposit processing: clearing, settlement and finality
- Data, identifiers, messages and references
- Rules, service levels, availability and customer impact
- Fraud, compliance and operational controls
- Exceptions, investigations and recovery
- Posting, accounting, reporting, liquidity and reconciliation
- Bank implementation, testing and resilience
- Practical Autodeposit examples
- Key takeaways and authoritative references
1. Business context and customer need
Every Canadian bank serves recipients who are tired of the last mile of getting paid. A landlord collects rent from six tenants on the first of the month and spends the first week chasing acceptances, re-sending security answers, and answering "which account did I pick" messages. A freelance designer invoices three clients and waits days because one client never clicks the notification link buried in a promotions folder. A parent sends a monthly allowance and fields a call every single time because the security question agreed three years ago no longer makes sense to anyone. A small retailer refunds a customer in the evening and wants the matter closed tonight, not after a three-day accept window. None of these people has a settlement problem. They have a friction problem at the moment of receipt, and it repeats with every payment, consuming goodwill out of proportion to the dollars involved.
Autodeposit exists to remove that friction for repeat, trusted flows. The recipient does the work once — inside their own banking, at a calm moment, choosing deliberately which address maps to which account — and every later payment to that address skips the acceptance chore entirely. No link to click. No question to answer. No account to pick while standing in a checkout line or half-reading a notification on a phone. The sender's life improves symmetrically: no security question to invent, agree, and communicate; a registered legal name displayed before send that answers "am I paying the right person" far better than any question ever did; and a completion advice that closes the loop. For regular payments between people who know each other — rent, allowance, stipends, gig payouts, family support, club dues — that mutual simplification is the whole value proposition, and it explains why adoption concentrates in exactly those corridors.
Consider a fictional Ontario landlord — call her Priya — who recurs throughout this chapter. After registering one email address to her rental operating account, five of six tenants' payments arrive automatically and her statement shows every credit with a consistent reference her bookkeeping can match. That transformation — from monthly acceptance-chasing to one standing instruction — is what this chapter teaches you to deliver and to defend.
The defence matters because the same automatic behaviour that removes friction removes the recipient's per-payment vote. In a standard transfer, the recipient examines the notification, logs in, answers the question, and picks the account — four moments where something wrong can be noticed. In Autodeposit, none of those moments exists, by design. The recipient's protection therefore has to live elsewhere: in the care taken at registration, in the sender's verification of the displayed name, in the alerts fired on every mapping change, and in the speed with which an unexpected alert is treated as an emergency. A bank that sells Autodeposit as pure convenience without teaching those compensating controls is not simplifying the customer's life; it is moving the customer's risk from a place where it was visible to a place where it is silent. The rest of this chapter shows how to keep it visible.
Staff who learn that sentence — automatic, checked, then credited, timing varies — prevent more complaints than any status page.
The diagram above is your anchor for the registration half of the chapter. Read it top to bottom as the recipient's one-time journey, and notice where the control sits: authentication at the start, ownership proof in the middle, and strong verification repeated on every later change. Every later section is a deeper pass over one box in that picture, and the matching diagram in Section 4 is its mirror image on the sender's side.
2. Participants, responsibilities and system boundaries
An Autodeposit payment looks like two people and a phone screen. Operationally it involves five parties with distinct responsibilities, and confusing any two produces the classic errors this chapter corrects — treating the email as the money's carrier, treating Interac as part of Payments Canada, treating the sender's bank as able to reverse a deposit, or treating a notification as proof of payment.
Start with the two customers. The sender instructs the payment from online or mobile banking at a participating institution, chooses the recipient address, checks the displayed legal name, and authorises the debit. The recipient registered the address beforehand at their own bank, linked it to one chosen account, proved control of the address, and now receives matching transfers without further action. The boundary that matters is this: the sender owns the instruction and the funding; the recipient owns the standing instruction that determines where matching funds land. Neither customer operates the directory, moves interbank value, or can rewrite the other's standing instruction. When a payment goes to the wrong place, the first question is therefore always whose instruction was wrong — the sender's one-time address entry or the recipient's standing mapping — because the recovery path differs completely.
The two banks divide the work along the same line. The sender's bank authenticates the sender, validates the instruction, performs its screening, debits the sender, issues the Interac transfer instruction, and reports completion. The recipient's bank owns the registration — it authenticated the registrant, verified address ownership, recorded the account linkage, and presents the mapping to the directory — and it owns the automatic credit, the recipient notification, the statement entry, and the change-verification discipline. A receiving bank that treats registration as a self-service preference page with email-only verification has abdicated the core of its Autodeposit responsibility. A sending bank that hides the legal-name display behind a collapsed detail, or that lets senders skip past it, has weakened the only per-payment check the Autodeposit flow retains. Block-level control expectations from the ecosystem chapter apply here in miniature: authentication and entitlement before action, validation before release, evidence after completion, with no gaps between the two institutions.
Interac Corp operates the service layer connecting the two banks: its public materials describe address-based routing, messages and notifications, while participant agreements govern the non-public directory and integration details. It is not the customer’s deposit-taking bank. Email and text carry notifications, not the funds themselves; the service terms say funds are held in a participating institution’s clearing account until deposit, cancellation or expiry. Interac is separate from Payments Canada, with its own participation framework, and the Bank of Canada oversees Interac e-Transfer as a prominent payment system.
The address and notification carriers — email providers and mobile networks — are participants in a weaker but still load-bearing sense. They deliver the registration-confirmation message and the deposit notices, and their compromise is a standard opening move in hijack patterns. But they are not payment parties: they hold no mandate and keep no payment record. That is why every procedure in this chapter treats inbox evidence as untrusted by default.
Responsibility, in short, is a short chain with no gaps. The recipient registers carefully and guards the registered address and banking credentials. The sender verifies the displayed name every time, especially the first time and especially for larger amounts. The recipient's bank verifies ownership, verifies changes strongly, alerts promptly, and credits only mapped accounts. The sender's bank shows the name honestly, screens before release, and evidences completion. Interac Corp resolves, routes, and notifies per its service design. Every investigation in Section 8 walks that chain in order, and every implementation decision in Section 10 assigns each link an owner, a test, and a metric.
3. Registration: initiation, validation and bank processing
Registration is the single most consequential journey in this chapter, because every later automatic deposit inherits the trust established — or skipped — here. Bank professionals must treat registration as the underwriting event for all subsequent Autodeposit value.
Interac’s published setup flow starts in the customer’s online or mobile banking. The customer signs in, opens the Interac e-Transfer section, selects Autodeposit, enters an email address and/or mobile number, selects the account, and completes the confirmation sent by email or SMS. The authenticated channel binds the request to the bank’s customer and eligible-account controls. Additional device, behavioural, step-up, contact-change and agent-assisted controls are bank implementation choices; they are recommended for risk management, but are not a single public Interac rule. A registration link in an unsolicited message is not a safe substitute for opening the bank channel directly.
The customer then supplies the address to register — an email address, a mobile telephone number, or both where the institution supports it — and nominates the account that matching transfers will be deposited into. Two validations run immediately, before anything is stored or confirmed. Format validation checks the address is structurally usable for notification and matching: a well-formed email, a diallable mobile number, no leading or trailing whitespace surprises, no lookalike-character games that the interface should normalise or reject visibly. Ownership-of-account validation checks the nominated account exists, is open, is denominated and enabled for incoming e-Transfer credits, and belongs to the authenticated customer with authority to receive. A joint account, a business operating account, or an account with a deposit restriction each carries its own policy question the bank must have answered in advance: who may register a shared address, whether a business name or a person's name will display to senders, and what happens when the account is closed or converted. Repair-or-reject happens here, in the session, with plain-language reasons — never downstream as a mysteriously uncleared transfer.
Interac’s setup guidance says the bank sends an email or SMS asking the customer to confirm registration and that “Complete Registration” activates the feature. This confirms control of the contact channel at that time; it does not prove that the contact and bank user are the same person. Token expiry, replay protection, wording, step-up authentication and support procedures are bank controls that should be specified and tested rather than presented as a universal Interac specification.
Activation means the directory now resolves that exact address string to this receiving bank and mapping. It does not mean funds are waiting, and it does not mean near-miss spellings now match. The bank's activation evidence should record who registered, when, which address and account were bound, and which legal name will display.
Deactivation, address change and account change redirect future payments, so a safe bank implementation should treat them as high-risk profile changes: authenticated session, authority on the new account, ownership proof for any new contact, proportionate step-up, versioned audit evidence and independent alerts where the bank supports them. Interac’s public setup page does not prescribe one change workflow, alert set, effective-time rule or cross-institution move procedure. This chapter therefore labels those as implementation controls, not scheme-wide rules. Re-registration and hijack investigations must preserve the mapping version that was active when a payment was sent.
A customer who loses access to the registered email must update the mapping before the address decays, and a customer closing the mapped account must pick a successor mapping or deactivate — front-line scripts should treat "I changed my email" as an Autodeposit review trigger.
4. Matching and deposit processing: clearing, settlement and finality
If registration is the standing instruction, matching and deposit processing are the per-payment execution — the moment a sender's typed address meets the directory and the transfer either flows straight through or falls back to the human accept step. Bank professionals must hold this mechanism precisely, because nearly every customer explanation, every exception classification, and every fraud lesson in this chapter reduces to one question: did this payment match an active Autodeposit registration at send time, or did it not. This section traces both branches, then separates the customer experience from the bank settlement reality that runs behind it.
The sender's journey starts unremarkably: sign in, choose to send, enter amount and recipient address, and review. Interac’s published send guidance says that a recipient registered for Autodeposit is shown by full legal name; an unregistered recipient requires a security question. The sender-facing result is therefore a registered Autodeposit path or the standard acceptance path. Matching and normalisation details are service and financial-institution implementation details; the chapter does not claim a particular case, whitespace or alias algorithm.
The legal-name display deserves emphasis because it is the only per-payment control the automatic path retains, and its effectiveness depends entirely on sender behaviour the bank must actively teach. A match between expectation and display is a proceed signal. Anything else — an unfamiliar name, a subtly altered spelling — is a stop signal requiring verification through a different channel before sending. In the hijack pattern of Section 7, the name display is the last honest signal: every sender who checks it breaks the attack.
Once sent to a matched address, the transfer follows the Autodeposit path with no recipient acceptance step. The sender’s bank debits the sender and issues the Interac instruction. Interac’s service resolves the registered contact to the receiving institution; email and SMS do not carry the value. Interac’s setup guidance says the automatic deposit follows routine fraud checks by the financial institution, and its terms allow decline for incorrect or unverifiable information, suspected wrongful activity or an exceeded limit. The public material does not specify whether every check runs at both institutions or the exact hold decision point, so this chapter leaves that to the participant implementation. The receiving institution’s posting and availability rules determine when the mapped account is credited and usable; the recipient receives a notice but does not accept the payment.
Behind the customer moment, current Interac participant settlement is not a real-time settlement leg. Interac’s 2026 public PPS disclosure says the service calculates participant obligations, provides a settlement advice and reconciliation file, and expects participants to settle through Lynx by the next business day after receiving the settlement file; it also describes participant bilateral settlement under Lynx and agreed cut-off times. That is the current production model described by the source, not a promise that each customer credit waits for or proves Lynx settlement. Reconcile the instruction and address outcome, customer posting or suspense, Interac settlement advice, reconciliation file and Lynx settlement evidence. A notification or available balance is not settlement evidence.
The planned modernization is different. Payments Canada currently describes the RTR as launching in Q4 2026 and as a new real-time exchange and clearing-and-settlement system; Interac’s 2026 disclosure describes a planned migration to a pre-funded real-time gross-settlement model. RTR is not the current production settlement model for this chapter’s live Autodeposit story.
Once Interac’s records show an automatic deposit, the Interac terms treat the transfer as final. FCAC says a deposited Interac e-Transfer cannot be cancelled; a bank may still facilitate investigation and a return request under its own process, but the chapter must not promise an automatic reversal or a guaranteed cooperative return.
The matching diagram above compresses the section into a sender-side poster: registration lookup, name display, automatic path or standard path, and bank-controlled exception handling. Keep it beside the registration diagram from Section 1. Together they state the core mechanism supported by the public guidance: the recipient selects an account during setup, the sender sees the registered legal name when applicable, and the recipient does not accept an Autodeposit transfer.
5. Data, identifiers, messages and references
Autodeposit fails far more often from thin or mishandled data than from any service outage, so the bank professional must know exactly which data matters, where it lives, and which piece proves what. This section maps the addressing, identity, message, and reference data for a matched transfer, distinguishes authoritative records from informational ones, and states the retention and privacy expectations that let investigations succeed months after the fact.
Domestic addressing for Autodeposit has two layers. The outer layer is the registered email address or mobile number the sender supplies. It is a routing and notification key, not an account identifier. The inner layer is the receiving institution’s selected account, held inside that institution’s systems. Interac’s public guidance says the contact is associated with the account selected during setup; it does not publish the directory’s case, whitespace or alias-normalisation algorithm. Banks should define and test that behaviour, keep lifecycle metadata (created, confirmed, changed, actor and session), and revalidate the account when their own controls require it.
Identity data centres on the registered legal name — the display string Interac says the sender sees for an Autodeposit recipient. Its source, format and update behaviour are bank policy. A bank should show the registrant what will be displayed, version displayed-name changes with the mapping, and retain the historical name shown at send time; the public Interac pages do not prescribe the business/joint-account format or change workflow.
Messages in an Autodeposit transfer have different trust levels. Bank and participant records, customer account history and the unique Interac reference are the primary records for investigation; exact fields and retention are bank and participant obligations. Email and SMS notifications announce a transaction or registration event. Interac tells recipients to stay vigilant and to check their account, so a notice or screenshot should be corroborated in authenticated banking before action. Training that distinction — banking record first, inbox second — is a practical fraud control.
References are what let humans and systems agree they are discussing the same payment. Interac publicly documents a unique Reference Number for each e-Transfer for identification and tracking. Sender-bank, receiving-bank posting, mapping-version and settlement-advice references are useful additional correlation fields, but their names, visibility and retention are participant implementation matters, not four published Autodeposit identifiers. Case tooling should preserve the Interac reference, sender instruction, displayed name, address used, mapping version or equivalent audit evidence, posting result, hold/decline disposition and settlement-advice or reconciliation-file correlation where available.
Public Interac material reviewed for this audit does not publish customer-facing API names, message schemas, ISO 20022 message types or settlement-file formats for Autodeposit. A bank implementation may use proprietary gateways, APIs and files, but this chapter does not invent those names; the participant agreement and current bank integration documentation govern them.
Retention and privacy complete the picture. Registration records, mapping-change histories, displayed-name histories, transfer references, notification logs, and screening dispositions must be retained long enough to answer disputes, fraud claims, and inquiries that arrive months after the event. Access to the mapping store must be entitled narrowly: front-line staff need to see that a mapping exists and when it changed; only defined roles need the full history; nobody needs bulk export. The registered address itself is personal information with phishing value, so it must never appear in marketing extracts, screen-share defaults, or verbose error messages.
6. Rules, service levels, availability and customer impact
Customers experience scheme rules as promises — will it arrive, when can I use it, what will I see, what happens if it fails — while the bank experiences them as obligations, windows, and evidence. This section connects the two for Autodeposit without inventing a single number the service does not publish. Exact amount thresholds, fees, and minute-level timings vary by participating institution and by the screening outcome on each transfer; this chapter states none, and any customer script or study note that quotes one from this chapter is misusing it. What the chapter states instead are the structural rules that hold across institutions, the availability posture that customers can rely on, and the honest language that turns both into trust.
The evidence-supported service rules are narrower than a bank’s ideal control design. Interac’s setup flow requires a participating Canadian account, a contact address and authenticated online banking, followed by email/SMS completion. Its send guidance says a registered Autodeposit recipient is shown by full legal name, while an unregistered recipient uses a security question; its terms restrict deposits to the account holder or legal signatory and allow decline for incorrect or unverifiable information, suspected wrongful activity or limits. One-address semantics, re-registration behaviour, mapping-change authentication, alert channels and exact matching rules must be confirmed in the participating institution’s current terms and integration controls rather than stated as universal scheme rules.
Availability is the service’s headline promise and must be stated with precision. The Bank of Canada describes Interac e-Transfer as operating 24 hours a day, 7 days a week, while Interac’s terms disclaim a guaranteed delivery time and say financial-institution rules affect timing. Thus: customers can use the service through participating institutions at all hours, a registered Autodeposit payment does not require recipient acceptance, and credit timing, holds, outages and availability follow the participant’s current terms and controls. Do not turn “24/7” into a same-minute or unconditional-credit promise.
Service levels bundle timing with certainty, information and recourse. A transfer that has been automatically deposited does not wait for recipient acceptance; the Interac terms then treat it as final. A standard, unaccepted transfer remains subject to the service’s cancellation and expiry rules. Interac’s receive guidance says both sender and recipient receive a completion notification, but notification is not a substitute for the account record. A deposited transfer cannot be cancelled through the service, and any investigation or return request follows the institutions’ processes. Pricing, limits, holds and mapping-change alerts remain participating-bank terms.
Customer communication must therefore separate five words the way the ecosystem chapter demands: sent, matched, deposited, available, and settled. Sent means the sender's bank accepted the instruction and debited the sender. Matched means the directory resolved the address to an active Autodeposit registration with the displayed name the sender saw. Deposited means the recipient's bank credited the mapped account. Available means the recipient may use the funds under the account's normal terms. Settled means the interbank obligations behind the transfer completed through bank and network arrangements. A recipient's deposit notice truthfully asserts the middle of that chain; it does not assert the end of it, and operations reconciles accordingly. Training every customer-facing colleague on those five words — with a one-line Autodeposit example for each — prevents more escalations than any brochure, because most Autodeposit complaints are vocabulary failures wearing the costume of service failures.
The operational calendar concept that matters is the mapping’s effective time. A bank should tell customers when a registration change becomes active and should treat an unexpected change alert as urgent, including outside normal business hours; the public Interac guidance does not prescribe one change window or alert SLA.
The notification diagram above is the chapter's communication contract: what each party is told, which record proves it, and which messages must never be trusted for action. Keep it beside every customer script the bank publishes for Autodeposit. If a script asks a customer to act on an email link to receive Autodeposit funds, the script is wrong and the diagram is the authority to correct it.
7. Fraud, compliance and operational controls
Controls fail when they are complete but misplaced, and Autodeposit punishes misplacement more severely than most services because the automatic credit removes the recipient's per-payment vote. A verification that runs weekly instead of at registration, a change alert that arrives as a digest instead of immediately, a name display the sender is trained to skip — each is a control that exists and still loses. This section places each control family at the point in the Autodeposit flow where it can still change the outcome, gives the registration-hijack pattern the full treatment the chapter brief demands, and covers phishing, screening, and operational discipline without duplicating the rail-level depth that lives in the controls block.
Start with placement, because it organises everything else. A prudent bank control design has three gates. Gate one is registration and change verification at the recipient's bank: authentication, account authority, contact-channel confirmation, proportionate step-up and independent alerts where supported. Gate one decides where future money goes. Gate two is the sender's name check at send time: compare the displayed legal name against expectation and verify by another channel when anything is unfamiliar. Gate three is the participant’s documented fraud and compliance decisioning; Interac’s public material confirms routine financial-institution fraud checks but does not prescribe one bank-by-bank sequence. Everything after credit is detection, investigation and recovery, and a deposited transfer cannot be cancelled through the service. These gates are implementation controls, not a published universal Autodeposit rule set.
The registration-hijack pattern is a high-impact scenario for this chapter, not a published statistic about all Autodeposit loss. It unfolds in three acts. Act one is access: the attacker gains control of the victim's registered inbox — through credential phishing, password reuse, or a SIM swap — or a foothold in the victim's banking session through credential theft. Act two is re-registration: the attacker links the victim's public receiving address to an account the attacker controls and approves the ownership confirmation from the compromised inbox. Act three is harvest: the next legitimate senders enter the familiar address, see a name they may not scrutinise, send, and watch their transfers deposit straight into the attacker's account with no accept step and no signal to the victim until money fails to arrive downstream.
The defences that break this chain map onto its links. First, strong verification on every mapping creation and change, with step-up for new devices, unusual hours, and rapid re-registration. Second, immediate alerts to both the old and new contact points, including in-app banners that survive a compromised inbox. Third, velocity monitoring that flags rapid successive changes and moves followed immediately by large inbound transfers. Fourth, sender name-check discipline: confirm the displayed legal name by a second channel before the first payment and before any large payment. Fifth, fast freeze and investigation paths that preserve the full registration and transfer evidence while the trail is warm.
Phishing around Autodeposit includes fake deposit notices and fake registration or security alerts. Autodeposit receipt itself does not require the recipient to answer a security question; Interac’s receive guidance says email notifications contain the sender’s full legal name and use notify@payments.interac.ca, while still warning recipients to stay vigilant. Customers should open banking directly rather than act on a message link, and should never disclose passwords or security answers in response to an unsolicited notice. Treat sender address and message appearance as clues, not proof.
Fraud and compliance treatment is institution-specific. Interac’s setup guidance says automatic deposit follows routine financial-institution fraud checks, and its terms permit decline for suspected wrongful activity. A bank should apply its documented fraud, sanctions and AML/ATF controls at the applicable decision points and retain the decision evidence. FINTRAC’s electronic-funds-transfer reporting guidance is focused on reportable international EFTs and must not be copied as a domestic Autodeposit threshold; suspicious-transaction duties depend on the reporting entity’s facts and reasonable grounds to suspect. This chapter therefore states no filing threshold or universal “pre-credit” screening sequence.
And communication discipline ensures change alerts, deposit notices, and completion advices use consistent sender identification and wording, so customers learn one authentic pattern and distrust deviations.
The hijack diagram above belongs on the operations wall and in every front-line training deck: attack pattern on top in red, layered defences below in green, with the irreversibility warning that justifies the entire arrangement. Teach it as a story — access, re-register, harvest; verify, alert, monitor, check, freeze — and test staff by asking them to narrate both directions without notes.
8. Exceptions, investigations and recovery
Every Autodeposit transfer either deposits automatically to the right account, deposits automatically to the wrong account, falls back to the standard path, or is held — and each of those outcomes has a name, a cause, an owner, and a clock. Banks that classify first recover cheaply. Banks that act first — re-sending on assumption, manually crediting from a screenshot, editing a mapping mid-investigation — create duplicates, destroy evidence, and turn a one-payment incident into a week-long reconciliation break. This section teaches the taxonomy, the investigation walk, and the recovery discipline at the depth a banker, agent, or operations analyst needs before the controls block adds enterprise procedure.
Start with the taxonomy, because Autodeposit incidents are routinely mislabelled and every mislabel sends the investigation to the wrong queue. A non-match fallback is not a failure: the sender typed an address with no active registration — typo, changed domain, new number, deactivated mapping — and the transfer correctly continued as a standard e-Transfer requiring acceptance. A held transfer is a screening outcome: routine checks flagged the payment and it waits for review. A misdirected deposit is a correct-system, wrong-instruction outcome: the directory matched an active registration, but the mapping was not where the sender intended. A hijacked registration is misdirection with criminal agency: the mapping was changed by or for an attacker. A notification-only confusion is not a payment event at all: the customer received or acted on a message with no corresponding transfer inside banking.
Rail and service rights constrain recovery, so classify before acting — the ecosystem chapter's rule in Autodeposit dress. A non-match fallback is recovered by correction: fix the address, confirm the name display, re-send as a new instruction with its own reference, never by "completing" the old standard transfer toward an Autodeposit outcome it was never on. A held transfer is recovered by review: the screening owner dispositions it — release, decline, or escalate — and nobody outside that ownership promises the customer a time. A misdirected deposit cannot be cancelled through the service. The sender’s bank may identify the receiving institution and facilitate an investigation or return request, but the response, recipient cooperation and any new payment are governed by bank procedures and applicable law; do not promise a pull-back or successful recovery. A hijacked registration adds urgency and evidence to the same shape: apply the bank’s available freeze or change controls, preserve the registration and transfer record, pursue each diverted deposit through the institution’s recovery process, and run the fraud case alongside rather than instead of the funds path. A notification-only confusion is recovered by verification inside banking, phishing reporting where applicable and credential remediation where compromise is suspected.
Investigations walk one path regardless of category: confirm instruction, confirm matching, confirm credit, confirm settlement evidence, then communicate state. The investigator starts from the sender's receipt — reference, amount, address entered, name displayed, timestamp — and establishes what was instructed. The matching record then answers whether the address resolved to an active Autodeposit registration at send time, which mapping identifier governed, and which name was shown. The recipient-side record answers whether the automatic credit posted, to which account, under which posting reference, and when memo became hard post. The bank-leg evidence answers whether the interbank obligations completed behind the customer moment. Only with all four in hand does the investigator communicate: state what happened, where the funds are in those terms, what the next step is, who owns it, and when the customer will hear next. The two questions that most often unblock a stuck case are the matching question ("which mapping was active at send time, not today") and the evidence question ("which reference inside banking proves the credit, not the message"). Teams whose tooling surfaces both on the first screen resolve in one contact what others resolve in four.
Never edit a mapping mid-investigation except to freeze it against further diversion, and log even the freeze as a versioned change. Never re-send on assumption while the original's state is unknown, or timeout-plus-retry becomes duplicate payment. Never accept inbox material as the investigation's foundation: re-establish every claim from banking records. And never close a hijack-adjacent case on funds recovery alone: the mapping, the session, the credentials, and the notification channel all need remediation.
Communication during exceptions follows the five-word vocabulary from Section 6 with one addition: next-contact commitment. Tell the customer what is known in sent-matched-deposited-available-settled terms, what remains unknown and who is resolving it, what the customer should and should not do meanwhile, and exactly when the bank will report back. For hijack victims, add the protective broadcast: the legitimate recipient should tell expected senders immediately, through a channel independent of the compromised address, to pause and verify by voice before sending further.
9. Posting, accounting, reporting, liquidity and reconciliation
Posting is the customer-money event, accounting is the bank's record of it, reporting is what each party sees, and reconciliation is the proof the three agree — and Autodeposit's silence on the receiving side makes that proof more important, not less. When a recipient actively accepts a standard transfer, the acceptance itself generates attention, memory, and a mental bookmark the statement later confirms. When a credit arrives automatically overnight, the statement line is the first time many recipients learn it happened, which means the statement line must be complete, intelligible, and matchable without the recipient remembering anything. This section describes the posting, accounting, reporting, and reconciliation chain from the bank operations view, with the settlement-leg separation kept explicit throughout.
Posting of a matched Autodeposit credit follows the receiving bank's normal electronic-credit rules with one distinctive input: the destination account comes from the standing mapping, not from a per-payment customer choice. The credit progresses from memo to hard post under the bank's standard memo and funds-availability policy; availability follows the account's terms for electronic credits rather than any Autodeposit-specific promise. The posting must carry the full data the recipient needs to recognise the payment without context: sender name as the service provides it, amount, date and timestamp, the transfer and posting references from Section 5, and ideally the receiving address or a masked form of it so a recipient with two registered addresses can tell which corridor the money used. Partial postings — amount without sender, credit without reference, timestamp without date — are the leading cause of mystery-deposit contacts, and each one costs the bank a call that complete data would have prevented. On the sending side, the debit posts with the entered address, the displayed legal name, the amount, and the sender reference, giving the sender a self-sufficient record for bookkeeping and inquiry alike. Fee or charge entries, where the institution applies any, must post as separate, clearly described lines rather than as adjustments buried inside the principal — a statement that nets silently is a statement that cannot be reconciled.
Accounting behind the postings records the same event in the bank's books with the double-entry discipline every electronic credit obeys: debit the sender or recognise the interbank receivable as each side requires, credit the recipient, recognise fee income separately where applicable, and clear suspense the same cycle rather than carrying unexplained balances. Autodeposit introduces no novel accounting theory, but it introduces one novel volume shape that accounting design must absorb: many small automatic credits arriving without per-item human review, including outside business hours. That shape argues for straight-through posting rules with explicit exception exits — closed account, restricted account, mapping under freeze, screening hold — rather than manual review queues that cannot be staffed at midnight and should not gate routine credits at noon. Suspense treatment must be equally explicit: a matched transfer that cannot be credited automatically parks in a defined suspense with an owner and an ageing clock, resolves by re-credit, return, or redirection under policy, and never sits as an unowned balance that month-end discovers. Every suspense entry carries the full reference set so its resolution links back to the original instruction without forensic effort.
Customers need intelligible transaction history, statements, and alerts. Businesses need batch-usable exports with per-item references stable enough for invoice matching. Operations and finance need control reporting: volume and value, fallback and hold rates, mapping-change velocity, suspense inventory, and the cooperative-return pipeline.
The customer credit and the interbank settlement legs are separate events on separate clocks. Under the current Interac participant model, settlement evidence comes from the settlement advice, reconciliation file and Lynx settlement process, not from a customer notification. Whether a bank makes a credit available before participant settlement is an institution policy; this chapter does not promise it. There is no public Autodeposit customer cutoff to publish; forecasting should still recognise rent-cycle peaks, post-holiday surges and donation spikes.
For each settlement cycle, operations matches three populations: the transfer instructions and directory outcomes, the customer postings including fee lines and suspense entries, and the bank-leg settlement evidence. No match, no claim of completion.
10. Bank implementation, testing and resilience
Offering Autodeposit looks, from outside, like enabling a toggle. Operating it safely is a multi-quarter programme across digital journeys, directory integration, screening, alerting, staff capability, and customer education — and the institutions that treat it as configuration inherit exactly the incidents this chapter catalogues. This section describes what a bank must build, test, and monitor, in the order a responsible implementation follows, without prescribing any vendor's architecture or any institution's org chart.
The registration and mapping journey comes first because it is the product's foundation and its highest-risk surface. Digital teams must build the in-session flow — authenticated entry, address capture with visible normalisation, account nomination constrained to eligible accounts, plain-language display-name preview, confirmation dispatch and completion, and symmetric flows for change and deactivation with step-up woven in.
Directory, messaging and screening integration comes second, with the straight-through path tested as a chain rather than as components. The bank should validate the participant-defined address lookup, display the registered legal name faithfully, route the Autodeposit and standard paths without cross-contamination, apply its documented fraud/compliance decisions, and emit the available references into posting, reporting and case tooling. Public Interac material does not disclose a customer API or exact message schema. Screening tuning should test ordinary recurring credits against anomalous re-registration and inbound behaviour without assuming that one institution’s thresholds apply to another.
Alerting and notification infrastructure comes third. A bank choosing alerts for registration, change, deactivation or re-registration should define the trigger, channel, delivery monitoring, retry/fallback and after-hours response; Interac’s public guidance does not promise an immediate alert to old and new contacts. Deposit notices and completion advices should use consistent identification, and authenticated account records remain the source of truth. Alert copy should name the event, account outcome, unexpected-event action and bank contact route without training customers to click unsolicited links.
Staff capability comes fourth, ahead of launch rather than after the first incident. Front-line staff must narrate registration, matching, timing, and recovery in the honest sentences this chapter provides, and must recite the two phishing rules without hesitation. Operations analysts must work the Section 8 taxonomy fluently: classify on first contact, freeze mappings on hijack suspicion, preserve evidence before editing anything, and communicate in the five-word vocabulary with next-contact commitments. Fraud teams must own re-registration velocity monitoring with defined thresholds, dispositions, and feedback into screening models. And every role must know the escalation path for the after-hours hijack report, because harvests do not respect business hours and the mapping frozen late at night saves the payments that a morning response reclassifies as losses. Training that ends with a narrated hijack drill retains what slide decks do not.
Testing must cover the journeys attackers and edge cases actually use: confirmation expiry, concurrent registrations of one address, cross-institution moves, near-miss fallback correctness, held-transfer ageing and release, suspense clearance, and the cooperative-return workflow end to end with a partner institution.
Resilience, sixth, treats Autodeposit as 24/7 customer experience on top of bank systems that still have maintenance windows, incident modes, and degraded states. The bank must define what happens when each dependency is unavailable: directory unreachable at send time means sends wait or proceed down a defined safe path, never guess; notification delivery failing means the credit still posts with the banking record as truth and notices retry visibly; mapping store read-only means changes queue honestly rather than appearing to succeed. Maintenance communication must say which Autodeposit functions are affected in customer terms — can I send, will it deposit automatically, will I be told — rather than naming internal systems. Contingency playbooks cover the hijack surge (accelerated freeze capacity, sender-broadcast templates, extended fraud hours), the peak-volume evening (fundraiser nights, rent Mondays), and the settlement-leg incident (customer credits protected while legs catch up, with communication that distinguishes the two). Chaos-style exercises — directory timeouts injected in test, alert pipelines severed, a simulated cross-institution hijack — validate the playbooks before reality does.
11. Practical Autodeposit examples
Theory states the mechanism; stories teach the judgement. The two examples below are fictional — invented landlords, clubs, tenants, and fraudsters with no real customer, account, or institution behind them — but each follows the live service behaviour this chapter describes and each ends with the control lesson a banker should carry into the next customer conversation. Read them as rehearsals: the first shows Autodeposit working as designed across a full rent cycle including its one graceful failure; the second shows the hijack pattern end to end and the response that contained it.
Example (fictional): Priya's rent cycle, including the typo that proved the safety property.
Priya collects monthly rent from six tenants, each paying a different amount under a written lease that names her registered rental email and prints her registered legal name beside it. On the last Sunday of the month she sends a short reminder message with the email address, the expected amount per tenant, and three lines that have become her standard text: pay the same address every month and it deposits itself; check the name shown before your first payment and tell me if it ever changes; if a payment ever asks you a security question, you typed the address wrong, so stop and check it. Five tenants pay on the first of the month. Each enters the familiar address, sees the familiar name, sends, and receives a completion advice within the experience their banks provide. Priya's phone announces five deposit notices through the morning; her transaction history shows five credits, each with sender name, amount, and reference; her bookkeeping matches five references to five leases before lunch. No logins, no questions, no account choices, no calls.
The sixth tenant, new that quarter, types the address from memory and transposes two letters of the domain. The directory finds no active registration for the mistyped string, so the flow continues as a standard e-Transfer: the tenant sets a security question, sends, and calls Priya saying the payment "asked for a question this time." Priya recognises the signal from her own script, reads back the correct address character by character, and the tenant cancels the unaccepted standard transfer per their bank's process and re-sends to the correct address — this time seeing the legal-name display, this time depositing automatically. The month's reconciliation shows six correct credits plus one cancelled standard attempt, each with its own reference, and Priya's notes record the corrected spelling for the tenant's contact book. Nothing was lost, nothing was pending, and the failure mode taught the new tenant more than the welcome message had: the security question was not a bug but the system failing safe, exactly as designed.
The control lessons are durable. The standing instruction plus the name-check sentence scaled across six payers with zero bank contacts. The typo validated the binary matching property in production: near-miss delivers the human accept step, not a near-right account. And Priya's ability to diagnose the report in one call came from knowing the vocabulary — matched versus standard path.
Example (fictional): the community club mailbox hijack and the evening that contained it.
A suburban sports club publishes its treasurer's email address on its website for seasonal dues — several hundred members paying the same amount in the same fortnight. The address is registered for Autodeposit to the club's operating account, and for two seasons the drive runs smoothly: members pay to the familiar address, see the club's registered name, and receive completion advices while the treasurer reconciles references to the membership list. Between seasons, an attacker compromises the mailbox through reused credentials, signs into the treasurer's banking profile with previously phished credentials, re-registers the published address to an attacker-controlled account, and approves the confirmation from the compromised inbox. In this fictional bank-control scenario, a change alert lands in the same compromised mailbox and an in-app banner the treasurer does not open for days. Every sender-side artifact still looks right except the one signal that matters.
Early dues payments open the harvest. The first few members enter the long-familiar address, are shown a legal name that is not the club's, and — out of habit, hurry, or small-screen inattention — send anyway. Their transfers deposit automatically into the attacker's account; their completion advices truthfully report deposited status; the club's operating account shows nothing. On the third evening, a member who knows the treasurer personally pauses at the unfamiliar name, calls instead of sending, and reaches the treasurer within the hour. The treasurer opens the banking app directly, sees the unauthorised mapping change, and calls the bank's fraud line. The bank freezes the mapping, preserves the registration and transfer evidence, and opens the fraud case and the per-payment cooperative-return requests in parallel. The treasurer broadcasts through independent channels telling members to stop sending, verify any displayed name by phone, and report sent transfers with references.
The control lessons are worth memorising in order. Strong verification would have challenged the cross-posture change before the mapping moved. Alerts reaching an uncompromised channel would have told the treasurer on day one instead of day four. Sender name-check discipline would have stopped every harvest payment at the review screen. Rapid freeze plus evidence preservation made the formal recovery possible. And the customer's independent broadcast — pause, verify by voice, report with references — broke the harvest faster than any institutional process could. Note what does not appear: any unilateral reversal or promise the bank could have made after the credits posted.
Read together, the two stories state the chapter's practical ethic. Autodeposit rewards the organised recipient — one correct registration, one clear instruction to senders, one monthly reconciliation — with near-zero per-payment effort. It punishes the inattentive mapping owner — stale addresses, shared credentials, ignored alerts, skipped name checks — with silent, automatic, accelerating loss. The banker's job is to move every customer from the second posture to the first before the rent cycle or the dues fortnight teaches the difference at full price.
12. Key takeaways and authoritative references
Ten misunderstandings account for most Autodeposit pain, so this chapter closes by correcting each in the plain language to use with customers, colleagues, and auditors — followed by the only references this chapter recognises: official Interac guidance, each verified as resolving at the time of writing.
First, Autodeposit does not send money by email. Email and text carry notifications and registration confirmations; funds move between bank accounts over banking networks. Any explanation, script, or mental model with money "in the email" is wrong and must be replaced before it meets a customer.
Second, automatic does not mean instant, unconditional, or unreviewed. Autodeposit removes the recipient acceptance step, while Interac says routine financial-institution fraud checks and institution-specific timing still apply. Promise the automatic path and the variation together, never a minute-count.
Third, the service is available around the clock through participating institutions, but availability is not a minute-count. A midnight send is accepted at midnight; its crediting follows screening and posting rules, not the clock. Staff who conflate the two manufacture the escalations they then have to defuse.
Fourth, the selected contact is associated with the account chosen during setup. The public Interac pages do not specify cross-institution re-registration or duplicate-mapping behavior; customers with several accounts should confirm those rules with their institution before changing a registration.
Fifth, the displayed legal name is a security control, not a formality. Confirm it by a second channel before the first payment and before any large payment, and treat any unexpected name as a stop signal. In a hijack, the name display is the last honest signal in the chain.
Sixth, Autodeposit never needs a link click, a login from email, or a security answer to receive money. Any message demanding those to complete receipt is fraudulent until authenticated banking proves otherwise. Customers who hold this one rule are protected against the entire fake-notice family.
Seventh, registration changes redirect future payments and deserve strong bank controls. Step-up verification, versioned evidence, independent alerts and freeze capability are prudent implementation controls, but Interac’s public pages do not prescribe one change workflow or alert SLA.
Eighth, deposited Autodeposit funds cannot be cancelled through the service. A bank may investigate or facilitate a return request under its process, but recovery, recipient cooperation and any new payment are not guaranteed. Promise follow-up, never reversal.
Ninth, the banking record decides and the inbox merely announces. Registration views, transaction history, statements, and advices prove; forwarded emails and screenshots point at best. Investigations that start from banking references close; investigations that start from inbox material wander.
Tenth, Autodeposit is operated by Interac Corp and offered through participating financial institutions — separate from Payments Canada’s current systems — while the Bank of Canada oversees Interac e-Transfer as a prominent payment system. Each institution’s schedules, eligibility, controls and experience govern details this chapter deliberately leaves unstated. RTR is a planned modernization with a Q4 2026 launch target as of this audit date, not the current Autodeposit settlement model.
Carry those ten into every customer conversation, and the operational habits follow: register carefully inside authenticated banking, complete the confirmation, preview the displayed name, teach senders the name check, use the bank’s available change alerts, apply documented screening, reconcile credits against settlement advice and bank-leg evidence, preserve evidence before editing, and communicate in sent-matched-deposited-available-settled terms with a named next contact.
Authoritative references — current primary sources verified as resolving:
- Interac — How to set up Interac e-Transfer Autodeposit (registration steps, what to prepare, confirmation): https://www.interac.ca/en/how-to-use/interac-e-transfer/how-to-set-up-interac-e-transfer-autodeposit/
- Interac — How to receive money with Interac e-Transfer (Autodeposit versus standard accept path): https://www.interac.ca/en/how-to-use/interac-e-transfer/how-to-receive-money-with-interac-e-transfer/
- Interac — How not having a security question can be just as secure (why Autodeposit without questions is safe, direct-deposit behaviour): https://www.interac.ca/en/content/life/how-not-having-a-security-question-can-be-just-as-secure-as-having-one/
- Interac — Send and receive money with Interac e-Transfer (Autodeposit feature overview): https://www.interac.ca/en/payments/personal/send-receive-money-with-interac-e-transfer/
- Interac — Interac e-Transfer help topics (how transfers work, Autodeposit registration notes): https://www.interac.ca/en/interac-e-transfer-help/
- Interac — Interac e-Transfer Disclosure (operator, participants and service scope): https://www.interac.ca/en/interac-e-transfer-disclosure/
- Interac — Interac e-Transfer PPS Self-Assessment Public Disclosure 2026 (current settlement, reconciliation, liquidity and planned RTR migration): https://www.interac.ca/wp-content/uploads/2026/07/Interac-e-Transfer-PPS-Self-Assessment-Public-Discloser-2026.pdf
- Bank of Canada — Payment systems the Bank of Canada oversees (exchange, clearing, settlement, Interac e-Transfer and RTR scope): https://www.bankofcanada.ca/regulatory-oversight/financial-market-infrastructures/payment-systems-the-bank-of-canada-oversees/
- Bank of Canada — Interac e-Transfer designated a prominent payment system (operator, 24/7 service and oversight boundary): https://www.bankofcanada.ca/2020/08/interac-e-transfer-prominent-payment-system/
- Payments Canada — Real-Time Rail payment system (Q4 2026 launch status and current testing; future modernization): https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- FCAC — Paying with your mobile phone (Autodeposit, fraud precautions and no cancellation after deposit): https://www.canada.ca/en/financial-consumer-agency/services/payment/mobile-payments/paying-with-mobile.html
- FINTRAC — Reporting electronic funds transfers (international EFT reporting scope and records): https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng
- FINTRAC — Reporting suspicious transactions (reasonable grounds to suspect and attempted/completed treatment): https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/str-dod/str-dod-eng
Where this chapter and an institution’s current experience differ on screens, eligibility, mapping changes, settlement evidence or timing, the institution’s published terms and participant documentation govern, followed by the official sources above. This chapter teaches the mechanism and control design; Interac Corp and the participating bank own the binding service detail. RTR statements are explicitly future-state as of the audit date.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.