Interac e Transfer for Business. Apply Interac e-Transfer to business payment and collection journeys, controls and reporting.
Block 7 · Chapter 31 of 75
This chapter applies Interac e-Transfer to real business life: paying suppliers and contractors, collecting rent and invoices, paying staff outside the payroll file, and reconciling every one of those movements without drowning the finance team. Chapters 26 to 30 taught you the consumer journey — send, address, notify, accept, Autodeposit, Request Money, cancel, and recover. This chapter keeps that foundation and adds the business layer: roles and entitlements, dual approval, FI-set limits, bulk files, ISO 20022 remittance data, Request Money as a collection tool, fraud patterns that target businesses, and reporting that feeds the ledger. It stays at the journey level. File-format depth for high-volume payables belongs to Chapter 32, high-volume receivables to Chapter 33, and remittance-to-cash-application mechanics to Chapter 35. Here you learn to run a business on e-Transfer safely, and to know exactly when a payment needs a different rail.
A note on status dates. Baseline is 5 October 2026. Interac e-Transfer operates 24/7 as a near-instant customer experience run by Interac Corp, which is separate from Payments Canada. Settlement between participating financial institutions follows separate settlement legs and is not the same event as customer credit. Interac's current business page advertises up to $25,000 per transaction and up to 10,000 payments in one file, while stating that limits and implementation vary by participant and account type; confirm the business's actual entitlement before promising a customer anything. Product availability, daily limits, fees, channels, and file features vary by financial institution. Every time this chapter says "higher limits" or "bulk capable," read it as a capability with FI-specific configuration, not a promise that every account receives the advertised maximum.
What you will be able to do after this chapter
After working through this chapter, you should be able to:
- explain when a business payment or collection belongs on Interac e-Transfer for Business and when it belongs on AFT, Lynx, PAD, or cards instead;
- describe the two business directions — pay (disburse) and collect (receive) — and trace each from initiation through notification, acceptance or Autodeposit, posting, settlement between financial institutions, and reporting;
- name the participants in a business e-Transfer — the business originator or collector, its financial institution, Interac Corp as operator, the counterparty and its financial institution — and state what each owns;
- set up business onboarding functionally: enrolment, user roles, maker-checker approval, and FI-set limits, and explain why no payment moves before entitlement is correct;
- walk a bulk payables file from build through upload, validation, dual approval, release, per-item notification and acceptance, and per-item status reporting, and route file-format depth to Chapter 32;
- walk a business collection from invoice or Request Money through payer action, Autodeposit credit, reference capture, and receivables matching, and route high-volume receivables depth to Chapter 33;
- describe remittance data functionally — invoice-level references and structured data suitable for ERP ingestion — and explain how it differs from a consumer memo, with full cash-application mechanics forward-pointed to Chapter 35;
- explain service behaviour in plain language: 24/7 initiation and acceptance, expiry and decline handling, cancellation before acceptance, and what "deposited" does and does not prove about interbank settlement;
- recognise business-targeted fraud — business email compromise, supplier impersonation, change-of-payment-details scams, Autodeposit-registration abuse, and Request Money deception — and place the preventive control before release;
- classify exceptions correctly — reject, expiry, decline, cancellation, fraud claim, misdirected payment — and describe recovery that preserves the original transaction identity;
- explain posting, accounting, fee treatment, statement evidence, and three-way reconciliation for business e-Transfer activity;
- work through two fictional stories — a property manager collecting rent and a distributor running supplier payments — and extract the control lesson from each.
For a roughly 60-minute core session, spend about 10 minutes on this introduction with Sections 1–2, 15 minutes on Sections 3–4 with the bulk and settlement diagrams, 10 minutes on Sections 5–6 with the reporting and comparison diagrams, 10 minutes on Sections 7–8 on fraud and exceptions, 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
- Initiation, validation, approval and bank processing
- Clearing, settlement between financial institutions and finality
- Data, identifiers, remittance and references
- Rules, service levels, limits and customer impact
- Fraud, compliance and operational controls
- Exceptions, investigations and recovery
- Posting, accounting, reporting and reconciliation
- Bank implementation, testing and resilience
- Practical business examples
- Key takeaways and authoritative references
1. Business context and customer need
Every Canadian business day, money needs to move in amounts too large for petty cash and too urgent for the next batch window, with proof attached. A property manager needs forty rents in before the mortgage debit goes out. A distributor needs eleven suppliers paid today or Monday's deliveries do not load. A dental clinic needs yesterday's patient balances collected without hiring a collections clerk. A landscaping company needs its Saturday crew paid on Saturday, not in Thursday's payroll file. A food wholesaler needs a short-paid invoice chased with a reference the customer's bookkeeper can actually match. None of these customers asked for a rail. They asked for timing, certainty, information, and a way to prove what happened when the bookkeeper, the auditor, or the counterparty asks.
Interac e-Transfer for Business answers that cluster of needs with a proposition businesses already understand from consumer life, extended for commercial use. The sender initiates from business banking, the recipient is notified and accepts or receives by Autodeposit, the sender's account is debited and the recipient's account is credited in a near-instant 24/7 customer experience for most payments, and the transaction can carry rich remittance data. The business product advertises up to $25,000 per transaction and up to 10,000 bulk payments, subject to the participant and account type. It also supports account-number routing, Business Request Money, and ISO 20022 data; roles, maker-checker approval, per-item reporting, and API or file delivery are implementation features to confirm with the financial institution and ERP provider, not universal Interac UI promises.
Position in the ecosystem matters because e-Transfer for Business is one instrument among several, and choosing it well is the banker's core skill. Payroll for hundreds of employees belongs on AFT credit through ACSS, where Chapter 32's bulk discipline and the payroll chapters' file controls govern cost and certainty. Time-critical, large-value, same-day-final obligations belong on Lynx, where real-time gross settlement in central-bank money gives finality no retail rail can promise. Pull collections under signed mandate belong on PAD, where Rule H1 allocates authority and recourse. Till and online card acceptance belongs on the card rails, where authorization, interchange, and chargeback economics apply. E-Transfer for Business owns the middle ground: push payments and request-led collections of moderate commercial size where speed, 24/7 availability, remittance quality, and low friction outweigh the need for batch scale or RTGS finality. A supplier payment run of a dozen invoices due this week, a contractor paid on job completion, a rent roll collected across the month, a customer deposit taken at booking — these are the natural territory. The misplacement errors are equally clear: forcing a thousand-line payroll through single sends, pushing a settlement-critical house payment through a retail rail, or pulling recurring fees by e-Transfer when a PAD mandate is the correct authority. Section 6 gives you the selection language; carry it into every customer conversation.
Scale changes the control question without changing the rail. One supplier payment approved by the owner on a phone is a consumer-shaped event with a business account behind it. Fifty supplier payments released from a file by two authorized users, with per-item remittance and per-item status feeding the ERP, is a treasury operation that happens to ride the Interac path. The bank must serve both through the same business banking channel with different entitlement: single-send authority for small ad-hoc needs, file-prepare and file-approve separation for runs, daily and per-user limits that reflect the business's real exposure, and reporting that distinguishes the file from its items. Chapters 32 and 33 teach the deep file mechanics for payables and receivables respectively; this chapter teaches you to recognise which customer situation needs a file at all, and to set the surrounding controls so the file cannot become a fraud vehicle.
The cash-flow argument is what sells the service honestly. Cheques tie up working capital in mail time, hold policy, and reconciliation detective work, and they expose the business to alteration and counterfeit risk that digital payments remove. AFT credits are economical and correct for scheduled bulk, but they run on business-day windows with cutoff discipline — miss the window and value moves a day. E-Transfer for Business moves on the customer's clock, including evenings and weekends, with confirmation per payment and structured data per payment, so the bookkeeper closes the day knowing what cleared rather than waiting for the morning statement to explain yesterday. That working-capital and certainty story must always be paired with its boundary: near-instant customer experience is not interbank settlement, deposited is not reconciled, and higher FI-set limits are not unlimited. Sections 4 and 6 make those boundaries precise so advisors promise the experience without overstating the guarantee.
Three running characters will recur through this chapter to keep the operating view concrete. Harpreet manages a 60-unit rental portfolio and collects most rents by e-Transfer into an Autodeposit operating account. Daniel runs a regional food distribution company paying ten to forty suppliers a week from the same account that receives customer payments. Priya operates a dental clinic collecting patient balances and paying a rotating roster of hygienists and suppliers. Each is fictional. Each faces one pay journey and one collect journey per month, which is exactly why the business service exists: too commercial for consumer habits, too varied for a single batch file, too urgent for cheques.
The diagram above is your anchor for the chapter. Read the left lane for every disbursement and the right lane for every collection. Both lanes share the same centre: the business's financial institution controls release, Interac Corp operates the addressing and notification path, and settlement between financial institutions follows behind the customer moment. Every later section is a deeper pass over one row of that picture, and Chapters 32, 33, and 35 are deeper passes over the bulk, receivables, and remittance boxes.
2. Participants, responsibilities and system boundaries
A business e-Transfer involves more parties than the two businesses who think of it as "we paid them." The bank professional must keep five layers straight: the business customer and its users, the business's financial institution, the network operator, the counterparty and its financial institution, and where applicable the software and service providers that touch initiation or reporting. Confusing any two creates the classic errors this academy corrects — treating Interac as part of Payments Canada, treating notification as settlement, treating an accounting package as the payment approver, or treating Autodeposit as a guarantee of identity.
Start with the business customer, which is never a single actor. A sole proprietor may be preparer, approver, and bookkeeper in one person, and the control model must still separate initiation from record-keeping well enough to catch that person's own errors. A small company typically has an owner or controller who approves, an administrator or bookkeeper who prepares, and front-desk or site staff who may request money but must never release payments. A larger company adds treasury or accounts-payable roles, ERP-driven file preparation, and segregation between vendor-master maintenance and payment approval so the person who can add a payee cannot also pay that payee. The operating lesson is that "the business" authorises nothing; specific users with specific entitlements authorise each action, and every payment must be traceable to the user who prepared it and the user who released it. When a fraud or error is investigated, those two names are the first evidence requested.
The business's financial institution owns the banking relationship and the control perimeter. It enrols the business, verifies the business identity and the signing authority behind it, provisions users with roles and limits, authenticates each session, validates each instruction, screens where required, releases payments to the Interac path, posts debits and credits, pursues settlement with the counterparty institution, reports status and statements, and evidences every decision for audit. The institution also sets the commercial terms functionally: which business packages include e-Transfer for Business, what per-transaction and daily limits apply, whether bulk file upload is enabled, how Request Money and QR collection are configured, and what fees attach. Because those terms vary by institution, this chapter never quotes them; the advisor's job is to know the home institution's current schedule and to confirm counterparty-institution behaviour only through observed status, never by assumption.
Interac Corp operates the e-Transfer service itself: the addressing and notification path, the acceptance and Autodeposit flow, Request Money orchestration, the risk-detection model and analyst support described by Interac, and calculation of participant settlement obligations. Its boundary is as important as its function. Interac Corp does not hold the business's account, does not set the business's FI limits, does not approve individual business payments, does not exchange the settlement funds, and does not reconcile the business's ledger. In the current model, Interac supplies settlement and reconciliation advice; participating institutions settle their obligations through Lynx under the service's governing arrangements.
The counterparty — supplier, contractor, customer, tenant, or staff member — and its financial institution complete the circuit. The counterparty's institution authenticates its own customer, presents notifications or Autodeposit credits, applies its own holds and screening policies, and posts to its customer's account. Neither the sending business nor its institution controls the counterparty institution's posting timing, memo rendering, or limit treatment of inbound transfers. That boundary explains half of all business e-Transfer support calls: the sender did everything correctly and the recipient's experience still differed, because acceptance behaviour, Autodeposit registration, and inbound screening belong to the other side. Advisors must explain the sender's responsibility as ending at correct addressing, correct amount, correct remittance, and confirmed release — and the recipient's institution as owning everything from notification presentation to credit posting.
Software and service providers orbit the payment without becoming parties to it. An ERP or accounting package builds the payables file, prints the invoice that carries the Request Money link, or ingests the bank's status export for matching — but it does not release value. A property-management platform may generate rent reminders with QR codes — but the payment still moves between the tenant's institution and the manager's institution across the Interac path. A payment-service provider supervised under the Retail Payment Activities Act may touch initiation or reporting — but the settlement institutions remain the financial institutions. The boundary that matters operationally is release authority: whatever the software prepared, a duly entitled user at the financial institution released it, and the investigation starts there.
Responsibility is a chain with no gaps. The business owns the economic obligation, the correctness of payee addresses and amounts, the maintenance of its vendor and customer masters, and the staffing of preparation and approval. The sending institution owns validation, screening, release, debit posting, status reporting, and settlement pursuit. The operator owns the addressing, notification, acceptance, and risk-detection path. The receiving institution owns notification presentation, acceptance handling, credit posting, and recipient reporting. Supervisors and rulebooks set the surrounding obligations. Every investigation in Section 8 walks that chain backwards, which is why this section teaches the walk once, generically, before any failure occurs.
The diagram above compresses enrolment into five gated steps, and the gate metaphor is deliberate: each step must pass before the next opens. Identity before roles, roles before limits, limits before approval rights, approval rights before test payments, test payments before live volume. Banks that let volume precede entitlement spend the next year investigating what their own customers released.
3. Initiation, validation, approval and bank processing
Every business e-Transfer starts in the same place: an entitled user instructing the business's financial institution through business banking, and the institution's hub validating and controlling that instruction before anything reaches the Interac path. The channel may be online or mobile banking, a file upload, an ERP integration, or another FI-provided interface; the exact channel is implementation-specific. The control sequence converges: authenticate the user, check entitlement for this action, validate the instruction completely, apply limits and screening, obtain the required approval, then release. Banks that enforce one sequence for single sends and bulk files scale safely. Banks that let urgent singles skip the sequence teach every fraudster and every rushed employee exactly which door is unlocked.
Single-send initiation is the ad-hoc journey: pay this supplier now, refund this customer tonight, send this contractor's completion payment from site. The preparer enters or selects the payee address — email, mobile number, or account-routed details where the institution supports it — enters the amount within the user's and the business's FI-set limits, attaches the remittance the recipient needs (invoice number, job reference, unit number), and submits for approval where the business requires it. Validation at this point must be complete, not cosmetic. The hub confirms the debit account is open and authorised for e-Transfer origination, the amount sits within the per-transaction and remaining daily entitlement, the address is well-formed and routable, the remittance is present and within length and character rules, and the instruction is not a duplicate of a payment already released — the classic double-click, back-button, or impatient-resubmit duplicate. Repair or reject happens here, in seconds, with a reason the user can act on. A payment rejected in the hub costs a correction. A payment released with a wrong address costs an expiry cycle, a rework, and possibly an awkward call to the intended recipient explaining the delay.
Approval is where business payments diverge from consumer payments categorically. Consumer sends are self-authorised: the account holder decides and authenticates. Business sends should separate preparation from release wherever the business has more than one authorised user, so that at least two people attest — one that the obligation is real and correctly stated, one that the release is authorised. The maker-checker pattern is the minimum: the preparer builds, a different approver releases, and the system enforces the difference even when both users are in the same office and one asks the other to "just approve it quickly." Larger businesses add tiered authority — supervisors approve above a threshold, treasury releases files — and separation between vendor-master maintenance and payment approval so a fictitious payee cannot be created and paid by the same hands. Sole proprietors cannot separate duties across people, so the control compensates elsewhere: notifications on every send, daily limits sized to survivable loss, and bookkeeper review of the statement the same week.
Bulk initiation extends the same sequence to files, and the file is where Chapters 32 and 33 take over in depth. Functionally, the business or its ERP builds a file of many payment items — each with payee address, amount, and remittance — the file is uploaded through business banking, the hub validates the file header and every item, totals are balanced against the control record, duplicates against recent files are flagged, limit and funding checks run across the whole file, an authorised approver reviews and releases the file, and each item then travels its own notification and acceptance journey with its own status. Two disciplines decide whether bulk succeeds. First, item identity: the file is a container, but every item keeps its own reference so one expired or failed item can be reworked without re-releasing the other ninety-nine. Second, whole-file gating: if the totals do not balance, if funding is insufficient for the file, or if the approver lacks file-release authority, nothing releases — partial release of an unbalanced file is how duplicates and shortfalls are manufactured. This chapter teaches those two disciplines; the layout, mapping, acknowledgement, and error-code mechanics live in Chapter 32 for payables, and the receivables-file counterpart lives in Chapter 33.
Collection initiation is the mirror journey and the one businesses underuse. Instead of waiting for tenants, patients, or customers to remember, the business sends a Request Money or an invoice carrying a payment address or QR code, the payer approves in their own institution's channel, funds travel the same Interac path in reverse, and the business's Autodeposit account is credited with the payer's reference attached. Functionally this converts chasing into workflow: requests issued per invoice, reminders before expiry, Autodeposit eliminating the accept step for the business, and per-request status — viewed, paid, expired, declined — visible to whoever owns the receivable. Request Money also reaches naturally into the business's own website, app, or invoice template, where the payer authorises without retyping addresses. The control caution runs both ways: staff who may issue requests must be entitled narrowly so a compromised login cannot invoice the world, and every request must carry the business's verifiable identity so payers learn to distrust lookalike requests, as Section 7 explains.
Validation and screening complete the processing picture before release. Beyond the format, limit, and duplicate checks already described, the hub applies fraud scoring — device, behaviour, velocity, new-payee, and after-hours signals tuned for business patterns rather than consumer ones — and sanctions and watchlist screening of parties and text where the institution's programme requires it. Cutoff logic in the batch sense does not gate e-Transfer release, because the service operates around the clock, but funding logic still applies: the debit account must bear the payment, and bulk files must be fundable in full. The hub records release time, per-item reference, and remittance exactly as sent at release, because every inquiry, every exception, and every reconciliation starts from that record. Release commits the instruction to the Interac path; everything after release is tracking, acceptance, posting, settlement, and reporting — never silent editing.
The diagram above is the file journey you must be able to whiteboard from memory: build with per-item remittance, upload and validate completely, approve under maker-checker, release once, track per item, settle institution to institution, and rework failures as new linked items. If you can draw it, you can operate it; if you cannot draw it, do not release a file until you can.
4. Clearing, settlement between financial institutions and finality
If Section 3 is about the business's decision, Section 4 is about the system's promise — and the promise has two halves that must never be blended. The customer half is near-instant and 24/7: send, notify, accept or Autodeposit, confirm. The interbank half is settlement between the sending and receiving financial institutions through bank and network settlement legs that follow their own cycles. The recipient sees good funds quickly; the institutions settle behind that experience. Every misunderstanding in business e-Transfer support — "the money arrived so settlement is done," "settlement is pending so the credit will reverse," "the notification is the payment" — comes from collapsing those halves. This section keeps them apart.
Walk the customer leg first, because it is what the business experiences. The sender's institution debits the sender or earmarks the funds at release, the recipient is notified through the Interac addressing path, the recipient accepts — selecting the deposit account and answering any required authentication — or the transfer lands directly where Autodeposit is registered, and both sides receive confirmation with the reference the sender attached. Request Money adds the prequel: request issued, payer approves in their own channel, then the same send-notify-accept sequence runs with the business as recipient. Expiry and decline handling belong to this leg: an unaccepted transfer lapses after its expiry window and the funds return to the sender, a declined transfer returns similarly, and cancellation before acceptance stops the journey while cancellation after deposit is not available — recovery then needs the recipient's cooperation, as Section 8 explains. None of these states describes interbank settlement. They describe the customer handshake, and reporting must label them as such.
Settlement between financial institutions is the second leg and the one the business never sees directly. Interac's April 30, 2026 PPS disclosure says the current service does not support real-time settlement: it calculates obligations and provides settlement and reconciliation files, and participants settle through Lynx on the next business day after the settlement file is created. Interac defines a 24-hour Eastern Time settlement cycle; weekends and holidays can extend the cycle, with settlement up to four days after the transaction value date. This explains how a recipient can receive customer-facing credit before participant settlement completes. It does not make a bank's internal status a customer guarantee: a confirmed customer credit, a participant settlement file, and a ledger reconciliation are separate evidence. Completed e-Transfer value is not unilaterally recalled through a batch return; recovery needs recipient cooperation or the institution's fraud/investigation process. A timed-out or uncertain status is investigated as potentially successful before re-issue.
Finality language must therefore be disciplined. "Sent" means the sender's institution released the instruction. "Notified" means the recipient was told. "Accepted" or "Autodeposited" means the recipient's leg completed addressing. "Deposited" or "credited" means the recipient's institution posted the credit and the recipient may generally use the funds. "Settled" means the institutions completed value movement between themselves. "Reconciled" means the business matched the bank evidence to its invoice or payable. Each word answers a different question — where is it, whose books show it, what can be done with it — and using them interchangeably in customer communication or incident tickets manufactures confusion. Train every customer-facing colleague on those six words before letting them touch a business e-Transfer queue.
Availability follows the same discipline. Interac says most business payments land within seconds and the service is available 24/7, but the onboarding guidance notes that the experience varies by participating FI and account type. A Saturday-night supplier payment can therefore be initiated and accepted outside a Lynx or ACSS business-day window, while participant settlement still follows its current cycle and deadline. The receiving institution's posting, screening, and account policies remain relevant. Advisors must promise the clock honestly: initiation and customer acceptance are available around the clock; most credits are fast but not an unconditional seconds guarantee; participant settlement follows the current cycle; and reconciliation follows bank reporting.
Compare briefly with neighbouring rails so placement stays sharp. Lynx is a Payments Canada RTGS wire system: payments cleared and settled in real time with settlement finality, and the system operates Monday to Friday except statutory holidays. ACSS is a retail batch system whose previous-day net balances settle on the next business-day morning. E-Transfer for Business provides a near-instant customer experience 24/7 while current participant settlement is deferred; do not describe today's e-Transfer as RTR or as RTGS-final at the customer moment. Payments Canada currently describes RTR as launching in Q4 2026. Interac's 2026 disclosure says e-Transfer transactions will migrate to RTR clearing and settlement, but that is planned modernization, not current production behavior at this baseline.
5. Data, identifiers, remittance and references
Addressing and remittance are the routing data and payment information inside the transaction. A wrong address or useless reference increases repair and matching work. The business's data discipline — capture completely, validate early, preserve identity end to end — determines whether payment, collection, posting, and reconciliation succeed on first pass or generate exception queues. This section maps what the service needs, what the business should attach, and which references should survive the whole journey.
Addressing routes the payment without exposing account numbers at every step. Consumer addressing uses email address or mobile number matched through the Interac path, with Autodeposit binding an address directly to a specific account so acceptance becomes automatic. Business addressing adds functional range: the same email and mobile addressing for ad-hoc payments, Autodeposit registration on operating and collections accounts so inbound funds land without manual acceptance, account-routed options where the institution supports sending directly to account details, and Request Money links and QR codes that carry the business's payment identity into invoices, websites, apps, and storefront signage. Each form suits a situation. Email suits invoiced suppliers with stable contacts. Mobile suits field contractors paid from site. Autodeposit suits any recurring recipient — the same supplier monthly, the same tenant roster, the business's own collections account — because it removes the accept step and its expiry risk. Account routing suits payees who prefer it and institutions that support it. QR suits storefront and invoice-present collection. The hub must validate whichever form is used before release: well-formed, routable, and — for first-time or changed addresses — confirmed through a channel independent of the instruction that supplied it, as Section 7 requires.
Remittance is where business use justifies its price. A consumer memo says "thanks for dinner." A business remittance can carry an invoice number or other rich data for accounting workflows. Interac states that Business is ISO 20022 compliant; its 2026 PPS disclosure says Interac e-Transfer for Business uses the latest ISO standard in its entirety, while legacy products have mixed implementations. This supports ERP integration, but exact fields, mappings, truncation, and exports remain FI and provider-specific. Use one clear reference set; carry invoice numbers exactly as issued; reference adjustments to the credit note; and explain short payments in the payment data rather than a separate email.
References should let humans and systems agree on the same payment. At minimum, preserve the business's internal identifier, the bank's confirmation or transaction reference, the transaction or item identifier returned by the FI or service, and the remittance shown to the counterparty. The exact reference names and propagation are FI/API-specific; do not invent a universal four-ID contract. For bulk, retain the file reference and each item's reference so one item's failure never obscures another item's success. Chapters 32, 33, and 35 build the file-level and matching-level mechanics; this chapter's rule is to capture the identifiers at release and never retype them downstream.
Two data boundaries deserve explicit warning because they generate the most expensive errors. First, truncation and retyping: remittance retyped by hand between the ERP, the banking session, and the recipient's books degrades with every transcription, so the business should generate references once in the system of record and carry them untouched. Second, sensitive data in free text: remittance is operational data, not a secure channel — account numbers, passwords, and personal identifiers do not belong in payment messages, and anything the business would not print on the invoice should not ride the payment. Privacy and data-minimisation discipline from the compliance programme applies to every character attached to value.
The diagram above separates what moves people from what moves reconciliations. Notifications tell humans to act; references let systems agree. Design every business process so the human sees enough to act once and the system keeps enough to prove it forever.
6. Rules, service levels, limits and customer impact
Customers experience rules as promises: will it go tonight, when can the recipient use it, what reference will they see, what does it cost, and what happens if nobody accepts. Interac's current business page advertises up to $25,000 per transaction and up to 10,000 bulk transactions per file, but its footnote and FAQ say sending limits vary by participant and account type. Daily limits, fees, file formats, approval rules, and availability details also vary by FI. Quote the published product maximum only with that qualification, then open the institution's current schedule.
Service behaviour starts with the clock. Interac describes Business as available 24/7 and says most payments land seconds after they are sent or received. A business can initiate and a recipient can accept outside ACSS or Lynx business-day windows, but the current participant settlement cycle still applies. Autodeposit removes the manual acceptance step; posting and screening remain FI responsibilities. Expiry bounds an unaccepted transfer, cancellation is available before deposit, and uncertain outcomes are investigated rather than assumed, per Section 8.
Limits are functional before they are numerical. Interac advertises up to $25,000 per transaction and up to 10,000 transactions per bulk file, while the actual limit varies by participant and account type. Daily, per-user, per-account, approval and file-validation dimensions are bank-implementation controls, not universal product rules. Ask whether the largest supplier invoice fits the actual entitlement, whether the busiest day fits the daily limit, whether the rent roll fits the file and Autodeposit configuration, and what clean reject or approval queue appears when a limit is exceeded.
The consumer-versus-business comparison in the diagram below deserves a slow read because it prevents the most common advisory error: describing the business service as "consumer e-Transfer with a bigger cap." Addressing widens to include account routing, QR, and Request Money embedded in commercial documents. Remittance deepens from memo to structured, ERP-consumable references. Approval hardens from self-authorisation to roles with maker-checker and audit. Reporting graduates from notification history to per-item status exports and three-way matching. Support changes from household troubleshooting to bookkeeper-grade inquiry with references ready. The cap is larger, but the cap is the least interesting difference; the control plane and the data plane are the product.
Pricing and value complete the customer impact honestly. Interac says fees are set by financial institutions. The value case is speed outside business hours, confirmation, remittance data, and reduced cheque handling; the cost case is FI pricing, possible limits, and payer action. Request Money invites payment but cannot compel it. A dozen supplier invoices, a weekend contractor payout, a rent roll with Autodeposit, or a deposit taken at booking can fit. A high-volume payroll, a settlement-critical house payment, or a recurring pull authorised by mandate belongs on the rail designed for that obligation.
7. Fraud, compliance and operational controls
Controls fail when they are complete but misplaced. A payee verification that runs after release, a fraud score nobody reads until Monday, an approval obtained by the fraudster along with the instruction, a sanctions consideration deferred because "it is only Interac" — each is a control that exists and still loses. This section places each control family at the point in the business e-Transfer flow where it can still change the outcome, with emphasis on the deception patterns that specifically hunt businesses: business email compromise, supplier impersonation, and change-of-payment-details fraud.
Business email compromise targets trust in business payment instructions. An attacker may compromise or spoof an owner, controller, supplier, or bookkeeper and request a changed payee address or urgent release. The defence is procedural before it is technical: no change of payment address on email authority alone. Verify each new or changed address through a known-good channel independent of the request, and log who confirmed, when, and how. Separate vendor-master changes from payment approval. Interac's business security guidance also recommends verifying account details, using available multi-factor and dual authorization, and stopping to scrutinize unusual requests.
Supplier impersonation and change-of-details fraud generalise the same attack beyond compromised mailboxes. A lookalike domain differs by one letter. A PDF invoice carries genuine line items with substituted payment instructions. A "supplier portal migration" message moves all future payments to attacker-controlled addresses. A text message from "the contractor" confirms the new details the email just supplied — same attacker, two channels, false independence. Controls that survive contact with these patterns share three properties. First, address whitelisting with change discipline: established payees carry verified addresses, new addresses start untrusted, and trust is granted only through the independent verification above. Second, Autodeposit preference for recurring payees: where the supplier's Autodeposit address is registered and verified, payments address it directly and deviations flag automatically. Third, first-payment restraint: a new or changed address earns a small test payment with telephone confirmation of receipt before the full invoice follows, and bulk files never debut a new address inside a large run.
Request Money deception and inbound fraud attack the collect lane. A fraudulent request wearing the business's name tells the payer to authorise urgently; a payer who does not check the sender's true identity funds the attacker. Businesses must therefore make their legitimate requests unmistakable — consistent sender identity, invoice numbers the payer can verify, links that resolve to the institution's genuine flow rather than lookalike pages — and must teach regular payers what a real request looks like. Inbound, the business faces overpayment and refund scams: a "customer" overpays by e-Transfer, asks for the excess back by a different method, and the original credit may later be found fraudulent or become subject to the institution's applicable process. The control is refund discipline: refunds return by the same path to the same party, never onward to a new address on urgency authority, and overpayments are held until the institution confirms the credit's status. Autodeposit-registration abuse — an attacker registering the business's published address at another institution — is countered by registering business addresses promptly, monitoring registration notices, and treating any unexpected registration or re-registration alert as an incident, not an IT quirk.
Transaction controls complete the plane around those deception patterns. Authentication and entitlement confirm the user may prepare, approve, or release, with step-up authentication for new payees, limit changes, and after-hours release. Functional limits — per-transaction, daily, per-user, per-account — bound the blast radius of any single compromise; they are set by the institution in consultation with the business and reviewed whenever staffing, volumes, or fraud experience changes. Velocity and anomaly monitoring flags the deviations that indicate account takeover or insider abuse: a bookkeeper who never sent evening payments suddenly releasing a file at midnight, a pay run whose payee mix diverges from history, a burst of new addresses before month-end. Dual approval on payables and file releases means the attacker must compromise two users or one user plus the approval path — materially harder than fooling one rushed person. Cutoff-style discipline has no batch meaning here, but funding and timing rules still apply: the debit account must bear the payment, and after-hours release policy should reflect that fraud teams and counterparty contacts are thinner at night.
Compliance obligations attach to business e-Transfer activity without becoming payment approvals. Record-keeping must preserve who prepared, who approved, what address and amount were instructed, what remittance was attached, what reference was issued, and what status each item reached — the evidence set auditors, investigators, and FINTRAC-relevant processes draw on. FINTRAC's EFT guidance applies to reporting entities and defines electronic funds transfers, but it excludes direct deposits and PADs and does not turn every domestic e-Transfer into an automatic report; the FI or other reporting entity must apply the current Act and Regulations to the actual transfer. Client identification and beneficial-ownership discipline at onboarding determine whether the business behind the payments is who it claims to be. Sanctions and watchlist screening applies per the institution's programme; "domestic and small" is not an exemption from screening design. The RPAA has applied to subject PSPs since September 8, 2025 and requires registered PSPs to manage operational risk, respond to incidents, safeguard end-user funds, and report; it does not make every business customer a PSP. Where a PSP touches initiation or reporting, responsibilities must be allocated among the PSP, FI, and business before volume arrives. Detail for each regime lives in Block 13; the operating lesson here is that compliance data is captured at initiation and preserved through reporting, never reconstructed after the fact.
8. Exceptions, investigations and recovery
Every exception is managed the same way: detect fast, classify correctly, contain within the service's actual rights, recover as a new linked event, and reconcile with evidence. Businesses that classify first recover cheaply. Businesses that act first — re-sending on assumption, manually crediting, editing a released payment — manufacture duplicates, double credits, and audit breaks that dwarf the original error. This section teaches the classification and the recovery discipline; Block 14 teaches each mechanism at operations depth.
Start with the taxonomy, because each word means something different and using them interchangeably guarantees confusion. A reject happens before release to the Interac path: the hub refuses the instruction for an invalid address, a limit breach, insufficient funds, failed validation, or an entitlement gap. Nothing left the business; the preparer repairs and resubmits. An expiry happens after release without acceptance: the recipient never accepted within the window, and the funds return to the sender — the most common business exception, usually caused by a stale address, a recipient who missed the notice, or a notice that went to spam. A decline is the recipient's active refusal, returning value similarly. A cancellation is the sender stopping an unaccepted transfer through their institution — available before acceptance, not after deposit. A misdirected payment reached the wrong address and was accepted: there is no unilateral pullback of completed value, and recovery needs the recipient's cooperation or a formal process through the institutions. A fraud claim invokes the institution's fraud handling with evidence burdens and timelines. An investigation tracks an uncertain outcome — a confirmation that never arrived, a status stuck between sent and deposited, a debit without a matching credit confirmation — through reference tracing and institution-to-institution confirmation. Each word routes to a different queue; the first job on every exception is to name it.
Rail rights constrain recovery, so classify before acting. Expired and declined transfers return to the sender and are reworked as new payments with corrected addresses — never by editing the original, which no longer exists as a live instruction. Cancelled-before-acceptance transfers similarly end; the business re-issues when ready. Misdirected-but-accepted value requires contact with the recipient and institution assistance; the business asks, the institutions facilitate, and the recipient's cooperation decides — advisors must say this plainly at the start rather than implying a reversal mechanism that does not exist. Fraud outcomes follow the fraud process with preserved evidence: original instruction, approval record, address history, notification path, acceptance detail. Duplicate sends — the double-click, the file re-uploaded after a timeout, the "it didn't confirm so I sent it again" — are contained by confirming original state before re-issuing; every timeout is investigated as potentially successful until proven otherwise, because the re-send is what creates the double payment.
Investigations walk one path with references in hand. Confirm release: the bank reference, the item reference within a file, the exact address and amount and remittance as released. Confirm network acceptance: notification delivered, accepted or Autodeposited, with timestamps. Confirm posting: sender debit, recipient credit, with statement evidence. Confirm settlement posture only where relevant to the inquiry — the customer-leg evidence almost always answers the business's question without reaching the interbank leg. Preserve the original identifier through every rework: the replacement payment references the original, the original references the reason, and the ledger shows one obligation satisfied by the successful attempt with the failed attempts closed as expired, declined, or cancelled — never as value that vanished. Communicate state plus next action, not activity: "the transfer to the old address expired this morning and the funds are back; the corrected payment to the verified address releases after your approver confirms" closes the loop where "we're looking into it" does not.
Bulk exceptions deserve their own paragraph because files fail partially and partial failure tempts whole-file remedies. A file of forty supplier payments where thirty-seven deposit, two expire, and one declines is a success with a rework list, not a failed file. The correct response releases two corrected items and follows up the decline with the supplier — as new linked items carrying the original references — while the thirty-seven successes reconcile normally. Re-releasing the whole file "to be safe" pays thirty-seven suppliers twice. Releasing corrections without linking them to the originals leaves the ledger with forty obligations and forty-three payments. The file report is therefore the primary control document for bulk: per-item status reviewed by someone other than the preparer, rework authorised as its own release, and the file closed only when every item is deposited or formally reworked. Chapter 32 builds the full payables-exception mechanics; this discipline is its foundation.
9. Posting, accounting, reporting and reconciliation
If Sections 3 through 8 move the money, Section 9 proves it — in the ledger, on the statement, and in the reconciliation the auditor re-performs. Business e-Transfer accounting is straightforward per payment and demanding in aggregate: each transfer is a debit and a credit with a reference, but a month of rents, supplier runs, contractor payouts, and customer collections is hundreds of lines that must each land on the correct invoice, the correct period, and the correct evidence trail. The businesses that thrive on e-Transfer treat reporting as part of the payment product rather than a back-office afterthought, and the institutions that serve them design reporting a bookkeeper can actually match.
Posting follows the customer legs directly. On the pay side, the sender's institution posts the debit at or shortly after release, with the payee identification and reference the business will see on its statement and transaction history. On the collect side, the business's institution posts the credit on acceptance or Autodeposit receipt, with the sender identification and remittance the payer attached. Expiry, decline, and pre-acceptance cancellation post reversing or release entries returning value to the sender, each referencing the original so the statement tells a coherent story rather than showing a debit and a mysterious credit days later. Fees post per the institution's business pricing — per payment, per file, or within a package — and must be separately identifiable so the business expenses payment costs correctly instead of burying them in the transfer amounts. None of this requires exotic accounting: cash or operating account debited or credited, payables or receivables relieved, fees expensed, with the bank reference on every line.
Reporting is what converts postings into matchable evidence, and business reporting must exceed consumer history in four ways. Per-item status reporting shows every transfer's current state — pending, deposited, expired, declined, cancelled, failed — with timestamps, so the bookkeeper works from status rather than from hope. Remittance carriage preserves the invoice and job references exactly as sent and as received, in an export the ERP can ingest rather than a screen the bookkeeper must retype. File-level reporting for bulk runs shows the file reference, its totals, and every item beneath it, so the payables run reconciles as one controlled event with individually evidenced members. And notification and confirmation records — send confirmations, deposit confirmations, Request Money histories — are retained as the customer-facing half of the evidence, complementing the statement's posting half. Institutions vary in export formats and retention windows; the business should confirm both during onboarding and calendarise downloads so month-end never depends on a portal's memory.
Reconciliation closes the loop in three matches performed continuously, not heroically at month-end. First, instruction to bank report: every payment the business released and every collection it expected appears in the institution's status and statement evidence with matching amount and reference. Second, bank report to ledger: every evidenced debit and credit lands on the correct payable, receivable, payroll, or expense line with the correct date and reference. Third, ledger to counterparty agreement: the supplier's statement, the tenant's receipt, the patient's balance all agree with the business's books, with short payments, overpayments, and unapplied credits sitting visibly in an exception queue rather than hiding inside lumped postings. Unmatched items age with ownership: an expired supplier payment reworked but not yet confirmed, a tenant payment without a unit number, a customer credit that matches no invoice — each has a named owner and a next action. Full cash-application mechanics for high-volume receivables live in Chapter 35; the operating rule here is that no business e-Transfer is finished when it deposits. It is finished when it matches.
10. Bank implementation, testing and resilience
Offering e-Transfer for Business is not a marketing decision with some IT attached; it is an operating commitment that touches onboarding, entitlement, fraud, support, settlement operations, reporting, and audit. This section describes what the institution builds and the business configures, so both sides recognise a serious implementation and spot a thin one.
Institution implementation starts with product definition: which business segments are served, what single-send and file capabilities each package carries, how limits are structured and who may change them, how Request Money and QR collection are provisioned, how Autodeposit is supported for business accounts, and how pricing presents. Around that product sits the control build: role definitions with least privilege, maker-checker enforcement that cannot be bypassed by shared logins, limit engines spanning per-transaction, daily, per-user, and per-account dimensions, duplicate and anomaly detection tuned for business patterns, fraud scoring with a staffed case queue covering 24/7 initiation, screening per the institution's programme, and evidence logging that captures preparer, approver, instruction, reference, and status for every item. Reporting must be built alongside release, not after: per-item status, file summaries, remittance-preserving exports, confirmation records, and retention that survives the audit cycle. Support must be built alongside both: staff who can trace by bank reference, explain expiry and decline without blaming the network, initiate misdirection assistance, and tell a bookkeeper exactly which export closes which break.
Business-side configuration mirrors the institution's build at smaller scale. The business enrols with correct signing authority, registers the addresses its counterparties will use — including Autodeposit on collections accounts — defines who prepares, who approves, and who maintains payee masters, sets internal thresholds that sit inside the institution's limits, documents the verification ritual for new and changed addresses, and assigns the reconciliation ownership from Section 9 by name rather than by hope. ERP and accounting integration is configured deliberately: which system generates payment files, which reference is the matching key, how status exports are ingested, and where exceptions queue. The property-management platform, the clinic system, the distributor's ERP — each is a preparation and matching tool, never a release authority, and the configuration must make that visible so no staff member believes "the software sent it" without an entitled human releasing it.
Testing before live volume is the gate both sides must respect. Connectivity and entitlement tests confirm each user can perform exactly their role and no more. Small-value end-to-end tests prove the full path — prepare, approve, release, notify, accept or Autodeposit, confirm, post, report, match — with real references the bookkeeper can follow. Bulk tests prove file validation, whole-file gating, per-item status, and rework linkage before the first real pay run. Collection tests prove Request Money issuance, payer experience, Autodeposit credit, and reference capture. Limit tests prove that exceeding entitlement routes to an approver or a clean reject, never to a silent partial release. Fraud-scenario walkthroughs prove that a changed-address instruction and an urgent-approval request both hit the verification ritual rather than sailing through. Each test is evidenced and signed; go-live is a decision with a record, not a date that arrives.
Resilience for a 24/7 service differs from batch resilience in one crucial respect: the initiation clock never stops, so staffing, monitoring, and incident response cannot be business-hours functions with an answering machine after dark. Fraud monitoring covers nights and weekends because initiation does. Support covers the hours the business's customers pay and get paid, with at least a defined path for urgent after-hours cases — stuck pay run, suspected compromise, misdirection discovered at night — even where full staffing is daytime. Contingency planning names the fallback per situation: batch AFT for the next scheduled run if file upload is degraded, wires for settlement-critical value if the retail path is impaired, and honest customer communication that states what is moving, what is queued, and what the next confirmation looks like. Change management protects the entitlement base: every product, limit, or reporting change is communicated before it binds, with dual control over the change itself. The businesses that trust e-Transfer for Business with their rent roll and their supplier base are trusting the institution's nights and weekends as much as its technology; implementation must earn that trust explicitly.
11. Practical business examples
Theory settles when it is walked through a month. The two stories below are fictional and labelled as such; any resemblance to real businesses is coincidental. Each follows one business through a pay journey and a collect journey, naming the control that mattered and the section that teaches it. Read them as rehearsals: the situation will recur in your portfolio with different names and the same shape.
Example (fictional): Harpreet's rent collection and furnace repair
Harpreet manages sixty rental units across six small buildings. Most tenants pay by e-Transfer into an Autodeposit operating account; a handful of older tenants still pay by cheque. On the first of the month, Harpreet's administrator sends Request Money messages to the tenants who agreed to request-based billing, each carrying the unit number and month as the reference, while the Autodeposit tenants simply send with the same reference format printed on their lease summary. By the evening of the third, per-item status shows fifty-two rents deposited, three requests viewed but unpaid, two expired where tenants sent to a stale address from an old lease, and one declined with a note that the tenant will pay half now and half on the fifteenth. The administrator re-issues the two expired requests to the verified current address, calls the viewed-but-unpaid tenants, and logs the split-payment agreement against that unit's receivable. Come the fifth, fifty-seven rents have matched automatically to unit-month lines by reference; three need human eyes — one tenant paid without any reference, one paid the wrong amount with "sorry, will top up" in the message, and the split payer's first half arrived correctly. Each sits in the owned exception queue from Section 9 with a next action and a name.
Mid-month the furnace in one building fails. The repair contractor quotes and completes the work the same day, then asks for immediate payment with an emailed invoice carrying payment instructions. The invoice total fits Harpreet's single-send authority, but the payment address differs from the contractor's established Autodeposit address on file — and the email arrived in a thread Harpreet recognises. The administrator prepares the payment and routes it for approval; Harpreet, remembering the verification ritual, calls the contractor's number on file rather than replying to the email. The contractor confirms the email was spoofed and the address is unknown to them. Harpreet pays the verified Autodeposit address, logs the spoof attempt, and reports it through the institution's fraud channel. The control lesson spans Sections 7 and 3: address changes verify through independent channels before approval, urgency never waives verification, and maker-checker meant the spoof had to survive two pairs of eyes. The month closes with every rent matched or owned, the furnace paid to the right party the same day, and one incident report that cost an hour instead of a five-figure loss.
Example (fictional): Daniel's supplier payment run and customer deposits
Daniel's food distribution company pays ten to forty suppliers weekly and receives customer payments daily. Thursday is payables day. The bookkeeper builds the week's file in the ERP: each line carries the supplier's verified address, the invoice numbers being paid, and any discount or short-pay explanation in the reference the supplier will see. Upload validates cleanly except two items: one address fails format checks — a typo transposed two letters — and one amount exceeds the bookkeeper's per-transaction preparation authority. The bookkeeper corrects the typo against the vendor master, splits nothing, and leaves the large item flagged; the controller reviews the file, confirms the large invoice against the receiving record, and approves the file for release with both the correction and the flag visible. Release runs Thursday afternoon. By Friday morning, per-item status shows thirty-one deposited including all Autodeposit suppliers, two expired where suppliers had changed addresses without telling Daniel, and one declined where a supplier disputes the short-pay. The controller calls the two expired suppliers, verifies new addresses by callback to numbers on file, and re-issues as linked replacement items; the short-pay dispute goes to the buyer with the receiving evidence attached. No item is re-released blindly, the file is not re-uploaded whole, and every replacement references its original.
Collections run continuously underneath. Regular customers pay against invoices by e-Transfer to Daniel's Autodeposit collections account, most quoting invoice numbers correctly because the invoice template prints the payment address, the reference format, and a QR code carrying the same. Request Money accelerates the slow payers: the bookkeeper issues requests for balances past agreed terms, each with the invoice reference embedded, and per-request status tells the collector who viewed, who paid, and whose request expired. One Friday a new "customer" overpays significantly and asks for the excess refunded to a different address urgently. The bookkeeper holds, the controller confirms the original credit's standing with the institution, and the overpayment proves suspect — held, reported, never forwarded. The control lesson spans Sections 5, 7, and 9: references generated once in the system of record and carried untouched, refund discipline returning value only along its original path, and three-way matching that leaves no credit unowned. Daniel's week ends with suppliers funded, exceptions linked and closed, and one fraud attempt converted into a staff story retold at every onboarding.
12. Key takeaways and authoritative references
Carry twelve sentences from this chapter into every business conversation. E-Transfer for Business extends the familiar send-notify-accept experience with FI-set limits, bulk files, ISO 20022 remittance data, account routing, and Request Money collection. Pay and collect are mirror journeys sharing one control sequence: authenticate, entitle, validate, screen, approve, release, track, match. Interac Corp operates the addressing and notification path and calculates settlement obligations; the financial institutions own validation, release, posting, participant settlement, and reporting — never confuse the operator with the settler. The customer experience runs 24/7 while current participant settlement is deferred, so promise the clock honestly and never equate notification with settlement. Interac advertises up to $25,000 per transaction and 10,000 per bulk file, but the participant and account type govern the actual entitlement. Remittance quality decides reconciliation cost, so generate references once in the system of record, carry them untouched, and confirm the FI's mappings. Business email compromise and change-of-details fraud require independent address verification, separate vendor-master duties, and no urgency waiver. Expired, declined, and pre-acceptance-cancelled transfers return value and are reworked as new linked items; accepted value recovers only with recipient cooperation or a fraud process. Accounting is ordinary double-entry made demanding by volume: match instruction to bank report, bank report to ledger, and ledger to counterparty agreement, continuously, with every exception owned. Bulk payables depth continues in Chapter 32, bulk receivables in Chapter 33, and remittance-to-cash-application mechanics in Chapter 35. Test every role, limit, file, and collection path with small value before live volume, and staff monitoring for the 24/7 clock you promise. The advisor's first question is placement: payroll scale belongs to AFT, same-day finality to Lynx, mandated pulls to PAD, and the commercial middle to e-Transfer for Business.
The most common misunderstandings, corrected in one place: that deposited means interbank-settled — it means the recipient institution credited its customer while institution settlement follows; that Autodeposit proves identity — it proves an address binding the business must still verify; that Request Money compels payment — it invites and tracks, and the payer still decides; that cancellation works after deposit — it works before acceptance, and recovery after deposit needs cooperation; that a dollar cap remembered from an article governs today's pay run — only the business's institution's current schedule governs; that the ERP released the payment — an entitled user released it, and the evidence names them; that re-sending fixes everything — confirming original state first fixes things, and blind re-sends create duplicates.
Authoritative references below are official sources only. Product behaviour, limits, and availability vary by financial institution; confirm current terms with the business's institution alongside these operator-level references.
- Interac Corp — Send and receive money with Interac e-Transfer for Business (limits, bulk, ISO 20022 and FI variability): https://www.interac.ca/en/payments/business/send-receive-money-with-interac-e-transfer-for-business/
- Interac Corp — Interac e-Transfer Business Request Money (website, app, QR and invoice collection): https://www.interac.ca/en/payments/business/interac-e-transfer-business-request-money/
- Interac Corp — How to Get Started with Interac e-Transfer for Business (account routing, timing and FI-specific implementation): https://www.interac.ca/en/how-to-use/interac-e-transfer/how-to-get-started-with-interac-e-transfer-for-business/
- Interac Corp — Keep your business payments secure with Interac e-Transfer for Business (updated August 19, 2025): https://www.interac.ca/en/content/business/keep-your-business-payments-secure-with-interac-e-transfer-for-business/
- Interac Corp — Interac e-Transfer Disclosure (current participant and service overview; linked 2026 PPS disclosure): https://www.interac.ca/en/interac-e-transfer-disclosure/
- Interac Corp — Interac e-Transfer PPS Self-Assessment Disclosure as at April 30, 2026 (current settlement cycles, files, Lynx and planned RTR migration): https://www.interac.ca/wp-content/uploads/2026/07/Interac-e-Transfer-PPS-Self-Assessment-Public-Discloser-2026.pdf
- Interac Corp — Interac e-Transfer participation (DEP, IEP, CSP and settlement arrangements): https://www.interac.ca/en/company/about/interac-e-transfer-participation/
- Payments Canada — Real-Time Rail payment system (launching Q4 2026; current planned status): https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- Payments Canada — High-value payment system: Lynx (RTGS, finality and operating days): https://www.payments.ca/systems-services/payment-systems/high-value-payment-system-lynx
- Payments Canada — Retail batch payment system (ACSS exchange, netting and next-business-day settlement): https://www.payments.ca/systems-services/payment-systems/retail-batch-payment-system
- Bank of Canada — Retail payments supervision (RPAA supervision, operational risk and safeguarding): https://www.bankofcanada.ca/regulatory-oversight/retail-payments/
- Justice Canada — Retail Payment Activities Act, S.C. 2021, c. 23: https://laws-lois.justice.gc.ca/eng/acts/R-7.36/FullText.html
- FINTRAC — Reporting electronic funds transfers to FINTRAC (definition, reporting entities and exclusions): https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng
Forward map: continue to Chapter 32 for bulk payables file mechanics, Chapter 33 for bulk receivables and collection-at-scale reporting, Chapter 34 for Interac Direct and pay-by-bank checkout contrast, and Chapter 35 for remittance-to-cash-application reconciliation. Block 8 then moves time-critical value to Lynx, and Block 13 deepens fraud, AML, sanctions, and RPAA supervision across every rail in this chapter.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.