Request Money. Separate the request from the resulting payment and trace consent, payment execution and status.
Block 6 · Chapter 29 of 75
This chapter is about a nudge that is not money. When a roommate, a contractor, a small business, or a friend uses Interac e-Transfer Request Money, the requester sends a request with an amount and the payer approves or declines. If the payer approves, the request is fulfilled by an e-Transfer travelling in the opposite direction — from the payer to the requester. Until that moment, nothing has moved. No account has been debited, no account has been credited, no interbank settlement has happened, and no return or reversal concept applies because there is nothing to return or reverse. The single most important sentence in this chapter is this: the request is not money movement until the payer consents and pays. Everything else — creation, delivery, reminders, expiry, decline, cancellation, fraud control, posting, and reconciliation — hangs off that principle.
This chapter sits inside Block 6 with the rest of the Interac family. The send-money path was covered in the e-Transfer send-money chapter, Autodeposit in its own chapter, and business use in the e-Transfer for business chapter. This chapter does not repeat that material at depth. It separates the request from the resulting payment and traces consent, payment execution, and status from end to end, so that a banker, a product manager, an operations analyst, or a small-business owner can explain what a request can do, what it cannot do, and what evidence each state leaves behind.
A note on status dates, limits and evidence boundaries. Baseline is October 2026 (audit date 2026-10-05). Interac Corp operates the Interac e-Transfer service, which its disclosure describes as a domestic, low-value service integrated into participating financial institutions. Public Interac material does not publish the service's internal message schemas, API/file formats, settlement-account cycles, or a universal Request Money state vocabulary. This chapter therefore labels bank implementation recommendations as recommendations and does not assign the post-consent settlement route to Payments Canada's Lynx or ACSS without a source. It states no dollar limits, fee amounts, or exact request-expiry hours because those vary by participating institution and terms. Check the institution's current terms for the numbers that bind you.
What you will be able to do after this chapter
After working through this chapter, you should be able to:
- explain why a request for money is a pre-payment instruction and not a payment, and why that distinction controls everything from fraud advice to reconciliation;
- name the participants in a request-money flow — requester, payer, requesting bank, payer bank, and Interac Corp as operator — and state what each owns;
- walk a customer through creating and delivering a request: contact, amount, destination account, message or invoice reference, confirmation, and notification;
- trace payer consent and fulfillment as a new e-Transfer in the opposite direction, with standard send-money execution from the point of consent onward;
- describe the three non-payment endings — payer decline, expiry per bank handling, and requester cancellation while pending — and what each leaves in history and status;
- list the data a request carries and the identifiers that must link the request record to the fulfillment payment record;
- explain service expectations honestly: near-instant fulfillment after consent, pending waits before consent, and reminders that nudge but never debit;
- place fraud and compliance controls correctly, including how to handle unsolicited requests and request-based scams, without confusing a request with an authorized debit;
- classify exceptions without inventing rights: what can be cancelled, what cannot be reversed, and where normal e-Transfer recovery begins;
- explain posting, accounting, reporting, and three-way reconciliation so that pending requests are never treated as cash or collected receivables;
- describe what a bank must build, test, and support to offer request money safely, including status, notifications, preferences, and accessibility;
- work through fictional examples — a roommate expense split and a contractor invoice nudge, plus a small-business case — and extract the control lesson from each;
- navigate to the five authoritative Interac references at the end of the chapter for the current how-to and product detail.
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 separation and fulfillment diagrams, 10 minutes on Sections 5–6 with the data and rules material, 10 minutes on Sections 7–8 with fraud and exceptions, 10 minutes on the examples 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 and bank processing
- Consent, payment execution and settlement
- Data, identifiers, messages and references
- Rules, expiry, service levels and customer impact
- Fraud, compliance and operational controls
- Exceptions, investigations and recovery
- Posting, accounting, reporting and reconciliation
- Bank implementation, testing and resilience
- Practical Canadian request-money examples
- Key takeaways and authoritative references
1. Business context and customer need
Every banker knows the awkward conversation this chapter removes. Someone paid for dinner, covered the plumber, fronted the cottages deposit, or finished a contracting job, and now they must ask to be paid back. A phone call feels pushy, a text is easy to ignore, and cash is increasingly not the answer. The requester wants three things: a polite but firm nudge, certainty the nudge reached the right person with the right amount, and a way for the payer to pay in a couple of taps without anyone retyping account numbers. The payer wants three things as well: to see who is asking and how much, to decide freely whether to pay, and to pay through the banking app they already trust. Request money exists to satisfy both sides at once, and it works precisely because it separates asking from taking.
That separation is the business context. In a pre-authorized debit, the payee pulls funds under a signed agreement. In a cheque, the payer has already signed an instruction to pay. In a request for money, nobody has authorized anything yet. The requester has expressed a wish; the payer has not answered. Treating the request as if it were already a payment — recording it as income, spending against it, reporting it as received, or telling a supplier the money is on its way — is the single most common and most expensive misunderstanding in this product. The operating discipline of this chapter is therefore simple to state and worth repeating to every customer: a pending request is information, not value. Value appears only when the payer consents and the resulting e-Transfer executes.
Consider how often the need arises in ordinary Canadian life. Roommates split rent, utilities, and groceries every month. Friends split restaurant bills, concert tickets, and road-trip fuel. Parents advance money to students and ask for documentation. Tradespeople finish small jobs and want a nudge that carries the invoice number. Landlords collect shared laundry or parking top-ups. Sports teams collect registration shares. Community groups collect event contributions. Small businesses chase a handful of late invoices that are too small for a collections process but too large to write off. In each case the amounts are modest, the relationship matters, and the administrative overhead of a formal invoice-to-cash process would dwarf the payment. Request money fills that gap: it attaches an amount, a destination account, and an optional message or invoice number to a notification, delivers it to the payer's email address or mobile number, and lets the payer fulfill it from their own bank.
The product also solves a quietly important addressing problem. To send an e-Transfer, the sender needs the recipient's contact. To request money, the requester needs the payer's contact — and the payer never has to share account details. The requester names their own destination account for receiving, and the payer pays from whichever of their own accounts they choose at fulfillment time. Account numbers never cross between the parties. That design keeps the barrier low: two people who know each other's email address or mobile number can settle up without exchanging transit numbers, institution numbers, or void cheques. It also explains why contact accuracy matters so much. A mistyped email address sends the nudge to a stranger, and a stale mobile number sends it to whoever holds that number now. Section 3 returns to verification discipline; here the business lesson is that the contact is the address, so the contact deserves the same care as an account number.
Timing expectations complete the context. Customers often assume that because e-Transfer fulfillment is typically fast — often within minutes, depending on the banks involved — the request itself must also be fast in the sense of compelling payment. It is not. The request waits. The payer may pay immediately, pay later, decline, or ignore it until it expires under the bank's handling. Reminders may nudge, but they do not debit. A requester collecting rent shares on the first of the month must therefore plan around human behaviour, not system speed: send early, state the due date in the message, follow up through normal channels, and never promise a landlord or supplier that requested funds are already available. Bankers who set that expectation at the counter prevent the disappointed call a week later.
There is also a business-side context that has grown in importance. Interac's Business Request Money page describes collection through a participating financial institution, including direct payment from a website, app, QR code or invoice, with examples such as storefront, donation, utility and credit-card payments. The underlying principle is identical: the business asks, the customer consents, and fulfilment is an e-Transfer payment to the business. The current public page does not establish a universal due-date, reminder or tracking schedule; those are product and bank implementation questions. A business request is still not a debit or a guarantee, and it should not be reported as received until the customer pays and the institution confirms the payment. Section 2 and Section 10 touch the business variant where it differs; the consumer flow taught here is its foundation.
Finally, place this chapter in the academy map so it is not confused with its neighbours. The send-money chapter teaches the payment lifecycle that fulfillment reuses. The Autodeposit chapter teaches the registration that lets fulfilled funds land without a security question. The business chapter teaches the bulk, invoicing, and reconciliation surface. The fraud chapters teach the scam and mule patterns that request flows attract. This chapter teaches the one thing none of those chapters owns: the request lifecycle itself, its link to the payment lifecycle, and the status model that keeps the two straight. Read the separation diagram below as the chapter's anchor. Everything that follows is a deeper pass over one part of that picture.
Read the diagram left to right for sequence and top to bottom within each lifecycle for depth. Lifecycle A costs nothing and moves nothing. Lifecycle B moves money under the payer's authorization. The consent arrow between them is the only bridge, and it runs one way. When staff and customers can draw that picture from memory, the rest of the chapter is detail.
2. Participants, responsibilities and system boundaries
A request-money flow involves fewer parties than a cross-border wire but more roles than customers usually see. Keeping five roles straight — requester, payer, requesting bank, payer bank, and Interac Corp — prevents nearly every support dispute this product generates. Each role owns a defined slice, and no role can perform another role's slice.
The requester is the person or business asking to be paid. The requester owns the accuracy of the request: the correct payer contact, the correct amount, the correct destination account among their own accounts, and a message or invoice reference the payer can recognize. The requester also owns follow-up discipline: stating due dates, watching status, re-requesting after expiry or decline where the relationship allows, and never treating a pending request as received funds. A requester who mistypes the amount owns the correction. A requester who sends to the wrong contact owns the cancellation and the apology. Banks can help with status visibility and easy cancellation, but they cannot verify that the underlying obligation — the shared dinner, the finished drywall job, the invoiced design work — is real or correctly priced. That obligation lives outside the payment system, between the two people.
The payer is the person asked to pay. The payer owns the decision. Nothing in a request authorizes a debit, places a hold, reports to a credit file, or obligates payment by a date. The payer may pay in full through the fulfillment flow, decline explicitly, ignore the request until it expires, manage notification preferences including opting out of requests from a sender or of the service, and review every request inside their own bank's app before acting. That last point deserves emphasis for fraud handling: the payer should never act on a request purely from an email or text. The payer should open their own banking app, find the request there, and decide there. If the request is not visible in the bank, the notification should be treated as suspect. Section 7 expands this into full scam guidance.
The requesting bank — the requester's financial institution — owns authentication of the requester, capture and validation of the request instruction, handoff of the request to the Interac network, presentation of request status to the requester, delivery of status changes including fulfillment, decline, expiry, and cancellation, and enforcement of its own published handling including expiry clocks and any applicable fees. The requesting bank does not hold payer funds, does not debit the payer, and cannot compel the payer's bank to do anything beyond presenting the request. Its boundary ends at the network handoff plus status reporting back.
The payer bank — the payer's financial institution — owns presentation of the incoming request to the payer, preference management including opt-out handling, authentication of the payer at decision time, and, if the payer consents, full execution of the resulting e-Transfer as a new send-money payment: validation, screening, debit, notification, settlement legs, posting, and confirmation. Critically, the payer bank's payment obligations attach to the fulfillment payment the payer builds, not to the incoming request. A payer bank that cannot find the request, that shows different details than the email notification, or whose customer denies expecting the request must guide the customer to decline or ignore rather than to pay and hope.
Interac Corp operates the e-Transfer service that links participating institutions. Its public disclosure identifies Request Money as an in-scope service and describes direct and indirect connectors, while its consumer pages describe banking-platform integration and notifications. Those sources do not expose the internal owner of each pending-state record, the message/API/file formats, the fulfilment-reference mapping, or the settlement accounts and cycles. Treat those as bank/connector implementation questions, not as published Interac rules. In particular, do not state that the resulting payment settles through Lynx, ACSS, or a particular Interac settlement leg unless the participating institution documents that route. Request how-to and product behaviour come from Interac; expiry, fees, limits, screens and support remain institution-specific.
Two further participants appear in business usage. A participating financial institution offering the business variant owns onboarding, invoicing integration, and tracking surfaces for the collecting organization. The collecting business itself owns invoice accuracy, due-date communication, and reconciliation of fulfilled payments to open receivables. Neither changes the consent model. A business request carries more structure — invoice number, due date, scheduled follow-up — but it still waits for the customer to pay, and it still expires or is declined without moving money.
Responsibility is therefore a short chain with no gaps and no overlaps. The requester asks accurately. The requesting bank carries the ask faithfully and reports status honestly. Interac Corp routes the ask and holds its state. The payer bank presents the ask safely and executes only what the payer authorizes. The payer decides. Every investigation in Section 8 walks that chain in order, and every control in Section 7 sits on exactly one link.
3. Initiation, validation and bank processing
Initiation of a request looks deceptively like initiation of a payment, because both start in a banking app with an amount and a contact. The resemblance ends at the confirmation screen. A payment confirmation commits funds; a request confirmation commits only a nudge. Training staff and customers to feel that difference — to slow down on contacts for requests the way they slow down on account numbers for wires — is the operational heart of this section.
The requester journey, as published by Interac, follows a stable sequence across participating institutions even though screens differ by bank. The requester signs in to online or mobile banking at a participating institution, navigates to the request-money option within Interac e-Transfer, and selects or adds the payer as a contact using an email address or mobile number. For a first-time payer, the requester adds the contact with a name and the email or mobile destination, taking care to verify both. The requester enters the amount being asked for, selects which of their own accounts should receive the funds, and adds an optional personal message or invoice number. The requester reviews the details on a confirmation screen and sends. The money request is then on its way, and the request appears in the requester's history as pending.
Each field in that journey carries a processing consequence. The payer contact determines delivery: email notifications go to the email address, text notifications to the mobile number, and in-app presentation to whatever the payer's bank can match. A contact that the payer no longer monitors produces a request that sits pending until expiry, generating reminders nobody reads and a reconciliation orphan on the requester side. The amount determines the fulfillment default: the payer who consents pays the requested amount through the fulfillment flow rather than retyping it, which removes a transcription-error class that plagues manual bill payments. The destination account determines where fulfilled funds land, including straight-through deposit where the requester uses Autodeposit. The message or invoice number determines recognizability and matchability: a payer who sees "plumbing repair, invoice 214" decides faster and disputes less than one who sees a bare amount, and a business that embeds the invoice number reconciles fulfillment without manual matching. Banks should therefore validate early and helpfully: confirm the contact format, confirm the amount is present and well-formed, confirm a destination account is selected, and warn before sending when the contact is new or recently changed.
Validation at the requesting bank covers identity, instruction completeness, and policy. Authentication confirms the requester is entitled to use request money from the selected account. Completeness checks confirm the payer contact, amount, destination account, and any bank-required fields are present. Policy checks apply the bank's own published handling — for example, availability of the feature for the account type, any applicable fee disclosure, and status-tracking enrolment. What the bank does not check is the truth of the underlying obligation. The bank cannot know whether the roommate really owes sixty dollars or whether the contractor's invoice is accurate. That boundary must be explicit in staff training: the bank warrants carriage of the request, not the validity of the debt.
Delivery is the handoff from the requesting institution through the Interac service to the payer's institution and payer. Interac's how-to says the request is sent after confirmation, and its FAQ says a fulfilled request generates a text or email notification; public pages do not specify which component owns every pending-state transition or whether reminders are universal. A bank may expose the request inside online/mobile banking and may generate reminders, but those are implementation and product-terms questions. Treat the bank's authenticated status as authoritative and the email/SMS as a notification pointer. Two delivery subtleties deserve attention. First, notification and presentation are different events: an email delivered to a spam folder is not the same as a request presented in the banking app, and status should reflect the network state rather than inbox behaviour. Second, reminders are bounded: they repeat the ask, they do not escalate it into an obligation, and they stop when the request closes for any reason.
Status begins at send time. From the moment the request is accepted by the network, both sides need a visible state: pending on the requester side with the ability to cancel, and actionable pending on the payer side with the ability to pay or decline. Good status design shows the amount, the counterparty name as each bank knows it, the message or invoice reference, the send date, and what remains possible. Poor status design shows a bare amount with no context, which is exactly the surface that scammers exploit. Section 10 returns to status, notification, and preference implementation; the processing point here is that status is a first-class output of initiation, not an afterthought, because the request may live for days while the parties decide.
Edge handling at initiation is a bank implementation and testing question, not a published universal rule. A bank should make duplicate submissions, unreachable contacts, new contacts, wrong amounts and wrong recipients visible and recoverable, and should prevent a stale request from remaining actionable after the service or institution closes it. Whether duplicate requests are merged, whether cancellation is exposed, and exactly how the payer view changes must follow the institution's implementation and terms. The requester should re-issue only with a fresh request reference after a terminal outcome. The creation-and-delivery diagram below compresses the journey into five steps that staff can walk a customer through at the counter.
Use the diagram as a teaching script. Steps 1 through 3 belong to the requester and deserve contact-care emphasis. Steps 4 and 5 belong to the network and the payer's bank and deserve expectation-setting: the payer is notified, nothing is debited, and the request waits. When a customer asks why the money has not arrived, start at Step 5 and work backwards: is it still pending, was it declined, did it expire, or was it fulfilled — and only in the last case does a payment exist to trace.
4. Consent, payment execution and settlement
Consent is the hinge of the entire product. Everything before it is messaging; everything after it is money movement. This section traces the hinge in both directions: what valid consent looks like, how fulfillment executes as an ordinary e-Transfer in the opposite direction, and where settlement and finality actually occur.
For a bank control model, valid consent should be explicit, informed, authenticated by the payer's institution, and limited to the displayed request. Silence or receipt of a notification should not be treated as consent. The payer should see the requester, amount and message before deciding, and the institution should apply its normal authentication and payment controls after the payer chooses to pay. This is a control design for separating a request from a payment; it is not a public Interac rulebook definition of consent. Staff should be able to state the negative with equal clarity: no consent means no payment, no debit, no hold, and no settlement entry of any kind. A request that sits pending for its entire life ends that life having moved nothing.
Fulfillment, once consent is given, is a new e-Transfer from the payer to the requester. Direction reverses: the payer becomes the sender and the original requester becomes the recipient. From this point the flow reuses the standard send-money path taught in the companion chapter. The payer's bank validates the payment — funds, limits, authentication, fraud and sanctions screening under its normal payment controls — debits the payer's chosen account, and issues the transfer through the Interac network. The requester is notified, accepts or receives by Autodeposit, and the requester's bank credits the destination account the requester originally named. Both sides receive confirmation, and the original request's status advances to fulfilled with a link between the request reference and the payment reference.
That linkage deserves careful handling because it is where reconciliation either works or breaks. The request record and payment record should be treated as separate objects with separate references, created at different times and potentially at different institutions. A bank offering this feature should retain a durable mapping from the request reference to the fulfilment payment reference and expose enough context for support and reconciliation. Public Interac pages reviewed here do not specify the identifier format or guarantee that both customer histories expose a bidirectional link; those are implementation requirements to confirm with the institution. The requester's history should distinguish a fulfilled request from the incoming payment, and the payer's history should distinguish the outgoing payment from the request that prompted it. Where Autodeposit applies on the requester side, fulfillment can land without a security question, which removes a friction point that historically slowed roommate and family repayments. Where it does not apply, the requester accepts in the normal way, and the payer's experience is unchanged: from the payer's perspective, paying a request feels like sending money, because that is what it is.
The request itself has no debit, credit or settlement event. After consent, the resulting transaction is an Interac e-Transfer payment and must be traced through the participating institutions' normal payment processing. Interac says funds do not travel by email or text, and its current FAQ says transfers are almost instant but can take up to 30 minutes depending on the bank; its 2025 explainer says recipients typically see funds within minutes or seconds after acceptance, with timing varying by institution. Public Interac pages reviewed here do not specify settlement accounts, clearing/exchange windows, cycles, finality language, or a universal 24/7 service-level promise. Do not infer those mechanics or map them to Lynx/ACSS from the Request Money feature alone. Anyone who promises settlement timing for a request before consent is promising something the system has not yet been asked to do.
Two boundary cases clarify the model. First, partial payment is not described in the public Interac Request Money material reviewed. Unless the participating institution's terms explicitly support it, staff should not describe a different-amount payment as partial fulfilment; treat it as a separate payment and confirm how the original request is displayed. Second, multiple requests between the same parties should be tracked separately by the bank's request and payment records; whether any batching or netting is offered is an institution-specific product question, not a published Request Money rule. A roommate who receives three monthly requests for three different shares consents three times and generates three payments, each separately traceable. Batching, netting, or setoff across requests is not part of this product.
The fulfillment diagram below is the section's working poster. Walk it with customers from Step 1 to Step 5 without skipping the reversal box in Step 3: direction reversal is the moment the mental model clicks, because it explains why the requester's account details never travel to the payer and why the payer's bank performs full payment controls on an instruction the payer's bank did not originate.
Close every consent conversation with the control sentence at the bottom of the diagram. The request never debits the payer. Only the payer-built payment does. Customers who internalize that sentence are protected against the most damaging request-money scams, which depend on blurring exactly that line.
5. Data, identifiers, messages and references
Request money is a light-data product by design, and its lightness is both its usability and its reconciliation limit. This section inventories what a request carries, what it deliberately does not carry, and which references must survive from request through fulfillment to posting.
A request carries five data groups. First, party identification: the requester as known to the requesting bank and the payer as a contact — an email address or mobile number — rather than as an account. Second, the amount: a single fixed figure in Canadian dollars asked for in the notification. Third, the destination: the requester's chosen receiving account at the requesting bank, recorded as account identification inside the bank and never exposed to the payer beyond the requester name. Fourth, the human context: an optional personal message or invoice number that tells the payer what the money is for. Fifth, the lifecycle metadata the network and banks need: send date, status, reminder state, expiry clock, and the request reference itself. These are the minimum customer-visible groups documented by Interac's how-to and FAQ material; the internal service payload is not public. A Request Money notice should not be treated as a PAD mandate or as a payment instruction that debits the payer. Internal routing, risk, retention and reconciliation fields may exist beyond the fields shown to customers, and the bank should document those separately.
Each group has a failure mode that bank validation and staff coaching should target. Party identification fails when the contact is mistyped, stale, or shared: the notification reaches a stranger, an ex-partner holding a recycled number, or a family inbox nobody checks. Amount fails when the requester transposes digits or includes costs the payer disputes, which converts a two-tap payment into a negotiation. Destination fails when the requester selects a closed, restricted, or unintended account, so that fulfillment succeeds as a payment but lands where the requester did not intend. Human context fails when the message is blank or cryptic: a bare amount from a half-remembered name is the exact shape of both a mistaken request and a scam, and payers presented with it cannot decide safely. Lifecycle metadata fails when status is invisible: a requester who cannot see pending, fulfilled, declined, expired, and cancelled states separately cannot manage follow-up and cannot reconcile.
The identifier architecture must keep two objects distinct and linked. The request reference identifies the ask from creation to closure and is the key the requester uses for status, cancellation, and follow-up. The payment reference identifies the fulfillment e-Transfer once consent creates it and is the key both banks use for posting, settlement-leg tracking, investigation, and return handling under e-Transfer rules. The binding between them — the map that says this payment fulfilled that request — must be recorded by the network or the banks and surfaced in both histories. Without that binding, the requester sees a fulfilled request and a separate incoming payment with no visible connection, and the payer sees an outgoing payment with no visible reason. With it, three-way matching in Section 9 becomes mechanical rather than forensic.
Message content deserves its own paragraph because businesses consistently overload it. Interac's business guidance notes that the invoice number can travel in the message area when a business uses request money as an invoice nudge, while also noting that message characters are limited. That limit is a design signal, not a defect. Request money carries a pointer to an obligation, not the obligation's documentation. Invoice line items, tax numbers, business addresses, payment terms, and remittance detail belong on the invoice the business already sends; the request carries the invoice number that ties the two together. Businesses that stuff full invoice text into the message discover truncation, payer confusion, and reconciliation pain. Businesses that keep the invoice as the record and the request as the nudge — same invoice number in both — reconcile cleanly and get paid faster, which is the outcome the business variant is built for.
Format and channel notes complete the section. Requests are created and acted upon inside participating banks' online and mobile banking, not inside a standalone Interac app, so the bank owns the input screens, the validation messages, the status surfaces, and the accessibility of the flow. Notifications travel by email or text to the payer contact, which makes them inherently out-of-band: the authoritative record is what each bank shows its own customer, not what an email says. Autodeposit registration on the requester side changes fulfillment behaviour — funds route directly without a security question — and should be presented at request-creation time as a choice with fraud implications explained, consistent with the Autodeposit chapter. And throughout, the original request reference must be preserved verbatim across reminders, status changes, fulfillment linkage, and history, because every investigation in Section 8 starts by asking which request a disputed payment belongs to.
6. Rules, expiry, service levels and customer impact
Customers experience this product as a set of promises about speed, persistence, and cost. This section states each promise in the bounded form a banker can defend: what is fast, what waits, what ends automatically, and what varies by bank.
Speed promises attach to fulfillment, not to requesting. Once the payer consents and pays, Interac e-Transfer behaviour applies: Interac's current FAQ says transfers are almost instant but can take up to 30 minutes depending on the bank or credit union, while its 2025 explainer says recipients typically see funds within minutes or seconds after acceptance and that timing varies by institution. These are general descriptions, not a guaranteed SLA, and the statement begins with "once the payer consents" deliberately. Before consent, the product has no speed; it has patience. The request waits while the payer decides, reminders repeat the ask at network or bank cadence, and nothing about the underlying obligation changes. A requester who needs funds by Friday must therefore send in time for human decision plus fulfillment, not in time for fulfillment alone. Staff should translate every urgency question into two clocks — decision time plus payment time — and refuse to collapse them.
Persistence promises attach to the pending state and end in one of three ways described fully in Section 8 and summarized here for service-level purposes. A pending request can be declined by the payer, cancelled by the requester while still pending, or left to expire under the handling set by the bank. This chapter states no exact expiry period because expiry handling is per bank: the participating institution's published terms govern how long a request remains actionable, how reminders behave, and what each side sees when the clock runs out. The service-level point is structural rather than numeric. Expiry is automatic, terminal, and money-neutral: it closes the request, stops reminders, notifies as the bank's design provides, and moves nothing. A request that expires has not been refused in the human sense and has not been paid in any sense; it has simply lapsed, and the requester who still needs payment builds a fresh request.
Cancellation is institution-specific at the Request Money layer. The public Interac how-to page documents creation but does not publish a universal request-cancellation window. Where a participating institution exposes requester cancellation while a request is still pending, the requester can use that control; the payer's equivalent decision is to decline or not pay. After the payer has paid, Interac's consumer FAQ says a deposited e-Transfer cannot be reversed through the service and the sender must arrange recovery directly with the recipient. Never promise that a pending-request cancellation control exists at every institution. That asymmetry confuses customers who expect symmetric controls, so state it plainly at setup: the asker can withdraw the ask; the decider can refuse the ask; nobody can un-pay the payment through the request.
Cost promises are short because the product's cost surface belongs to the banks. Interac's consumer guidance notes that a participating bank or credit union may charge a fee for request money and directs customers to their institution. This chapter therefore states no fee figure and teaches instead the disclosure discipline: before first use, the requester should know whether their bank charges for sending a request, and the payer should know whether their bank charges for fulfilling one. For the small amounts this product typically carries — the roommate share, the dinner split — even a modest fee changes behaviour, so fee transparency at enrolment and at send time is a service-level item, not a footnote.
Availability and preference promises round out the section. Request money is available to customers whose institutions participate, reaching payers who hold accounts at participating institutions and can be addressed by email or text. Payers can manage preferences including opting out of requests from a particular sender or of the service, and opting back in, through their bank or the network preference surface, with exact experience varying by institution. Notifications, reminders, fulfilment confirmations, decline notices, expiry notices, and cancellation effects should each be visible in-app rather than inferable from email alone. And customer communication should use five honest words consistently: sent means the request was delivered for decision, pending means the payer has not decided, fulfilled means the payer paid and a payment exists, declined means the payer refused, and expired or cancelled means the ask ended with no payment. The status-model diagram in Section 9 makes those words visual; the vocabulary here makes them verbal.
7. Fraud, compliance and operational controls
Request money concentrates a paradox that fraud teams must hold steadily. The product is safe by construction — a request cannot take money — and dangerous by persuasion, because a well-crafted request convinces the payer to take their own money and send it. Every control in this section addresses persuasion, impersonation, or error rather than unauthorized debit, because unauthorized debit is not what this product does.
Start with placement. Controls sit in two different places for the two lifecycles. Request-side controls govern creation, delivery, and presentation: authenticating the requester, validating contacts, presenting the request with full context, supporting decline and opt-out, and expiring stale asks. Payment-side controls govern fulfillment: authenticating the payer, validating funds and limits, scoring fraud signals, screening sanctions where the bank's payment controls require, and executing only on explicit consent. The most damaging design error is placing payment-grade reliance on request-grade data — treating an email notification as proof of who asks, or treating a request as proof that payment is due. Train the hierarchy instead: the banking app is authoritative, the notification is a pointer, and the underlying obligation must be verified out-of-band whenever the request is unexpected.
Unsolicited-request scams are the pattern this chapter must teach functionally, without inventing statistics or case law. The shape is consistent. The payer receives a request from a name they half-recognize or a business they never engaged, often with urgency language in the message, sometimes for an amount calibrated to look routine. The notification looks plausible because notifications are easy to imitate and because genuine requests also arrive by email or text. The payer who taps the notification link rather than opening their own banking app lands wherever the scammer built. The payer who pays without verifying the underlying obligation sends a genuine, authorized, difficult-to-recover e-Transfer to the wrong party. Defence is therefore procedural rather than technical, and every staff member should be able to recite it. Open the banking app directly, never through the notification link. Find the request in the bank's own pending list; if it is not there, treat the notification as suspect. Verify the obligation through a known channel — call the contractor at the number on the signed quote, ask the roommate in person, check the business invoice independently — before paying any unexpected request. Decline or ignore what cannot be verified, use opt-out where harassment recurs, and report suspected impersonation to the bank promptly. None of this requires new technology. It requires the payer to decide inside the bank rather than inside the inbox.
Adjacent patterns reuse the same persuasion with different dressing. Overpayment-and-refund hybrids pair a request with a story about money already sent. Directory-harvest requests go to stale or recycled contacts hoping someone pays reflexively. Business-impersonation requests borrow a real supplier's name with a new contact the business never published. Invoice-number dressing adds a plausible reference to make the ask look documented. Mule-adjacent behaviour appears where a compromised account issues requests to contacts who trust the account holder. Each variant is defeated by the same three questions: is the request visible in my bank, do I recognize the obligation through an independent channel, and am I being rushed. A yes, a yes, and a no are required before consent. Anything else is decline-and-verify.
Do not turn the no-value principle into a blanket compliance conclusion. A pending request creates no customer debit or credit, but FINTRAC defines an electronic funds transfer by the transmission of instructions for transfer of funds, and suspicious-transaction reporting can apply when a transaction occurs or is attempted. Whether a Request Money event is reportable, recordable or screenable depends on the reporting entity, the PCMLTFA/PCMLTFR definitions and thresholds, the facts, and the institution's compliance interpretation. A completed fulfilment is a value movement and must receive the bank's applicable AML/ATF, sanctions, fraud, recordkeeping and reporting treatment. Request contacts, messages, opt-outs and status should be retained as operational and fraud evidence; suspected misuse should enter the bank's investigation process. The exception is information handling: request messages, contacts, and status records are customer records subject to the bank's privacy, retention, and access disciplines, and suspected fraud or impersonation reports arising from requests must enter the bank's fraud intake with the request reference preserved. Operations teams should also watch the harassment boundary: repeated unsolicited requests can constitute misuse of the network even where no payment occurs, and preference, opt-out, and conduct handling must be available without requiring the target to pay anything.
Operational controls complete the plane and belong mostly to the banks. Entitlement should confirm who may issue requests from which accounts, including business roles for the invoicing variant. Velocity and anomaly monitoring should watch request issuance as well as fulfillment: a sudden burst of requests from a previously quiet account, requests to large numbers of unrelated contacts, or requests whose messages show urgency templates are request-side signals worth queuing for review even though no money has moved. Notification integrity — consistent sender naming, no actionable credentials inside notifications, and in-app presentation as the decision surface — reduces both successful phishing and mistaken payment. Status honesty — pending never displayed as paid, fulfilled always linked to its payment — prevents the internal fraud class where a request screenshot is offered as proof of payment. And segregation holds throughout: the person who builds a business request should not be the person who confirms its fulfillment as received without an independent match to the payment record.
8. Exceptions, investigations and recovery
Exceptions in request money are gentler than exceptions in wires or batch debits, because the worst pre-consent outcome is an unanswered ask rather than misdirected value. That gentleness must not breed vagueness. Each terminal state has a distinct meaning, a distinct evidence trail, and a distinct next step, and using the words interchangeably in customer communication or incident tickets guarantees confusion.
Decline is the payer's explicit refusal. The payer finds the request in their banking app and declines it. The request closes as declined, the requester is notified according to the bank's design, and no payment exists. There is nothing to return, reverse, or re-credit. The requester's next step is relational rather than operational: contact the payer through normal channels, resolve the disagreement about the obligation, and, if appropriate, issue a fresh request. The bank's next step is record-keeping: both histories should show the decline for audit, and the payer's history should show the decision as the payer's own act. Staff should never describe a decline as a failed payment. It is a successful decision with a negative answer.
Expiry is the clock's refusal. The request remained pending past the handling set by the bank and closed automatically. Reminders stop, the payer's actionable item is removed or marked expired per the bank's surface, and the requester's history shows expired rather than pending. No payment exists, so no return is generated and no funds move. The requester's next step is to re-issue if the obligation stands: expiry is never resurrected, so a fresh request with a fresh reference and a fresh clock replaces the lapsed one. The operations lesson is queue hygiene. Aged pending queues that never clear teach requesters that silence means maybe, when the product means silence followed by lapse. Automatic expiry with clear status is what keeps follow-up honest.
Cancellation is the requester's withdrawal. While the request is pending and has not been accepted, the requester selects it in payment history and cancels. The institution records the cancellation, should stop offering the request for payment after confirmation, and no payment exists. Cancellation after acceptance is not available, because after acceptance the request is fulfilled and the resulting payment has its own lifecycle. That boundary produces the section's hardest customer conversation: the requester who sent to the wrong contact and noticed too late. If the institution exposes cancellation and the request is still pending, cancel promptly and confirm the institution no longer offers the item for payment. If the payer already paid, the matter is no longer a request exception at all; it is a misdirected e-Transfer requiring recipient cooperation under normal e-Transfer handling, and staff must pivot chapters without promising recovery.
Investigations should split at consent. Pre-consent investigations ask request questions: was the request built with the right contact and amount, was it delivered or presented, what state does the institution show, and which party closed it. A bank should retain the request reference, parties as recorded, amount, message, dates, notices, state transitions and preference markers in accordance with its retention and privacy requirements; Interac's public pages do not prescribe a universal request-record schema. Post-consent investigations ask payment questions and belong to the e-Transfer send-money path: was the payment authenticated and validated, was it accepted or Autodeposited, did the institution complete its processing, and where did posting land. Use the linked payment record where the institution supports that mapping. The single most common investigation error is searching payment systems for a pending request. Pending requests are not in payment systems. They are in request status, and the correct answer to "where is my money" for a pending request is that no money exists yet.
Recovery follows the same split. Pre-consent recovery is always a new ask: correct the contact, correct the amount, and send a fresh request, cancelling the defective one while it remains pending. There is no amendment of a pending request's amount in the payer's favour by editing; the requester replaces rather than revises, so that the payer always decides on exactly what the record shows. Post-consent recovery is always a payment matter: misdirected fulfillment, mistaken amount consented in error, or fulfillment induced by scam follows the e-Transfer recovery path with recipient cooperation, bank assistance, and fraud intake where applicable — never a request-side undo. And scam-induced fulfillment, however sympathetic, is an authorized payment the payer built, which is why prevention in Section 7 outranks recovery here by an order of magnitude.
The outcomes diagram below compresses the section into the three endings staff must distinguish without hesitation, plus the two rules that close the common loopholes: acceptance ends cancellation, and re-request replaces rather than revives.
Keep the operations rule at the bottom of the diagram as the section's sign-off. None of these outcomes debits, credits, returns, or reverses anything. When every colleague can say that sentence to a worried customer without reaching for a manual, the exception model is working.
9. Posting, accounting, reporting and reconciliation
Accounting for request money rewards those who respect the separation principle and punishes those who do not. The rule fits in one line: requests do not post; only fulfillment payments post. Every reporting, reconciliation, and control consequence in this section flows from that line.
At the customer-account level, the control model is simple: creating, declining, expiring or cancelling a request must not be represented as a completed debit or credit, while a fulfilled request is reconciled to the resulting e-Transfer posting. Banks may still create internal non-value events, audit records, holds or disclosed fees under their own terms, so this chapter does not claim that no memo record or fee accrual can ever exist. A fulfilled request should reconcile to the payer debit and requester credit shown by the participating institutions; the underlying settlement-account entries and cycles are not publicly specified in the Interac Request Money material reviewed. Any other customer-account posting — such as a provisional credit on sending a request or a hold on receiving one — would be outside this control model and must be investigated. Finance, audit, and product teams should verify this property explicitly during every release: build a request in test, confirm zero balance impact on both sides, then fulfill it and confirm exactly one debit and one credit for the requested amount.
Reporting must keep the same boundary visible to customers and to the business. Customer-facing history should show requests and payments as distinct object types with distinct states. The requester's view needs pending requests with cancel actions, fulfilled requests linked to their incoming payments, and declined, expired, and cancelled requests retained as history rather than deleted. The payer's view needs actionable pending requests with pay and decline actions, outgoing fulfillment payments linked back to their requests, and a decision record for declined items. Statements and exports must never merge a pending request into payment activity, balances, or totals. A customer who exports activity to a spreadsheet should find requests clearly labelled as requests, so that no downstream formula mistakes an ask for cash.
Reconciliation for individuals is mostly visual: match each fulfilled request to its incoming payment and confirm the amount and counterparty. Reconciliation for businesses using the invoicing variant is structural and deserves the three-way match illustrated below. The business holds three records for each collection: the request record with payer contact, amount, and invoice number; the payment record with sender, recipient, amount, and network confirmations; and the posting record with the actual account debit and credit. All three must tie before the invoice closes. A request without a payment is an open receivable being nudged, not a collection. A payment without a matching request is a collection that arrived by another path and must not close the invoiced request automatically. A posting without a payment record is an exception demanding investigation, not a rounding difference. Businesses should run this match on the invoice number — the same number on the invoice, in the request message, and, where supplied by the institution, in the fulfilment reference mapping. Businesses that treat fulfilled status alone as proof of posting reconcile quickly and wrongly whenever a payment's credit leg is delayed.
Status-model discipline is what makes reconciliation auditable. The five-state model used in this chapter — pending, fulfilled, declined, expired and cancelled — is a proposed bank-facing teaching and control model, not a universal public Interac state taxonomy. Institutions should map their actual statuses and terminal-state rules to this model before exposing it to customers. In the proposed model, pending is actionable, fulfilled is the only state reconciled to a payment posting, and the other three are no-value terminal outcomes; the institution's terms and records control where those states differ.The reconciliation diagram below maps each state to its accounting and follow-up consequence so that operations, audit, and customer support share one vocabulary.
End every reconciliation discussion with the warning at the bottom of the diagram. Pending requests are not receivables collected and not funds expected tonight. Only fulfilled payments post and report. Teams that hold that line survive month-end. Teams that blur it explain variances.
10. Bank implementation, testing and resilience
Offering Request Money looks like a small feature and behaves like a small payments platform. The controls in this section are bank implementation recommendations, not a published Interac API or certification specification. A bank must confirm its connector contract, institution terms and actual service states, then build request capture, network integration, status and notification services, preference management, fulfilment linkage, history and reporting, fraud and support tooling, and tests that prove separation under failure.
Capture and validation come first. The bank's digital surfaces need a request-money journey distinct from send money, with its own entry point, its own confirmation language, and its own history. Confirmation screens must say the customer is sending a request, not sending money, with the amount, payer contact, destination account, and message shown for review. Validation must check contact format, amount presence and form, destination-account eligibility, and new-or-changed-contact warnings before the request leaves the bank. Fee disclosure, where the bank charges for the feature, must appear before send rather than on the statement afterwards. Accessibility must be designed in rather than patched later: screen-reader-compatible status, sufficient contrast, touch targets that separate pay from decline by more than colour, and plain-language states that survive translation.
Network integration and status services come second. The bank must hand requests to the Interac network with durable references, receive and apply status transitions including fulfillment linkage, decline, expiry, and cancellation, and present a coherent state on both sides even when the counterparty bank's customer acts while the requester's app is closed. Notifications — send confirmations, payer notices, reminders, fulfillment confirmations, decline and expiry notices, cancellation effects — must be generated from system state rather than composed optimistically, so that a notification always describes a state the record already holds. Preference handling including opt-out from a sender or from the service, and opt-in reversal, must be reachable from both the request surface and the fulfillment surface, with exact behaviour following the institution's published design. Fulfillment linkage must bind each payment to its request and render the binding in both histories, because support calls about fulfilled requests always ask the same question: which payment closed this ask.
Fraud, support, and operations tooling come third. Request issuance needs velocity and anomaly monitoring even though issuance moves no money: bursts, unrelated-contact breadth, urgency-template messages, and newly opened accounts issuing at scale are reviewable signals. Presentation needs impersonation resistance: consistent requester naming as the bank knows the requester, full amount and message display before any pay action, and a decline path as prominent as the pay path. Support consoles need the full request record — reference, parties, amount, message, send date, reminder log, status transitions, preference markers — plus the linked payment record after fulfillment, with role-based access and audit. Dispute intake needs a request-aware script that classifies at consent: pre-consent matters are status, cancellation, contact correction, and re-issue; post-consent matters are e-Transfer payment matters. Misclassification here is the operational defect Section 8 warns against, and tooling should make the correct classification the easy one.
Testing must prove the separation principle rather than assume it. Subject to the connector contract and the institution's actual states, core test cases include: build with each contact type and confirm delivery and presentation; build with invalid, stale, and new contacts and confirm visible failure or warning; send and confirm zero balance impact on both sides while pending; fulfill and confirm exactly one correct debit and credit with linked references; decline and confirm terminal declined status with no postings; expire under the bank's handling and confirm automatic closure, reminder stop, and no postings; cancel while pending and confirm immediate removal from the payer's actionable view; attempt cancellation after fulfillment and confirm refusal with guidance to payment recovery; re-issue after expiry, decline, and cancellation and confirm fresh references rather than resurrection; exercise opt-out and opt-in and confirm presentation behaviour; verify Autodeposit fulfillment lands as the Autodeposit chapter describes; verify fee disclosure and history labelling; and verify accessibility and bilingual presentation where the bank offers it. Regression suites should rerun the zero-impact-while-pending assertion on every release, because it is the property most likely to be broken by well-meaning payment-reuse refactors.
Resilience for this product is mostly about degraded-mode honesty. If notifications are delayed, status must still be correct in-app. If status sync lags, the bank must not offer pay on a request the network already closed, nor offer cancel on a request already fulfilled. If fulfillment rails degrade, the request must remain pending with truthful messaging rather than failing into an ambiguous state. And incident communication must preserve the vocabulary of Section 6: sent, pending, fulfilled, declined, expired, cancelled — never "processed" as a blanket term that hides which lifecycle advanced. None of this requires exotic infrastructure. It requires treating request state with the same seriousness as payment state while never confusing the two.
11. Practical Canadian request-money examples
Theory earns its keep when it survives contact with roommates, contractors, and month-end. This section works through three fictional scenarios that together cover the product's centre of gravity: a peer split, a trades invoice nudge, and a small-business collection routine. Each is labelled as fictional, each names its control lesson, and none invents limits, fees, or clocks.
Example (fictional): the roommate expense split. Amara and Jonas share a Toronto apartment. Amara pays the full internet bill of ninety dollars and the full electricity bill of one hundred and ten dollars, then opens her banking app and builds two requests to Jonas: one for forty-five dollars with the message "internet, March share" and one for fifty-five dollars with "hydro, March share." She verifies Jonas's mobile number before sending — it changed last autumn — selects her chequing account as the destination, reviews both confirmations, and sends. Jonas receives two text notifications that evening, ignores the links inside them, opens his own banking app directly, and finds both requests with Amara's name, the two amounts, and the two messages. He recognizes both shares, pays the first immediately, and leaves the second pending until payday two days later, when he pays it from the app's pending list. Amara's history shows the first request fulfilled with a link to the incoming payment and the second pending until it too shows fulfilled. Control lesson: verify the contact before sending, decide inside the bank rather than inside the notification, and treat each request as independent — paying one does not affect the other, and pending is a legitimate state rather than a system delay.
Example (fictional): the contractor invoice nudge. Daniel, a self-employed painter in Winnipeg, finishes a two-day interior job for a homeowner, Priya, and emails a one-page invoice numbered 214 for eleven hundred dollars with payment terms stated on the invoice itself. A week later the invoice is unpaid, and a phone call feels premature. Daniel opens his banking app, builds a request to Priya's email address for the invoiced amount, selects his business chequing account, and puts "Painting labour and materials, invoice 214" in the message. Priya receives the email notification during a busy workday and does not act from the email. That evening she opens her own banking app, finds the request with Daniel's name, the amount, and the invoice reference, and compares it against the emailed invoice 214 she already holds. The numbers match, the name matches the contractor she hired, and nothing pressures her beyond Daniel's polite message. She consents and pays; Daniel's business account is credited through the fulfillment e-Transfer, his request shows fulfilled with a link to the payment, and he closes invoice 214 on the strength of the posting, not the request. Control lesson: the invoice is the record and the request is the nudge, tied by a shared invoice number; the payer verifies the obligation independently before consenting, and the business closes its books on posting rather than on sent status.
Example (fictional): the small studio's collection routine. Sofia runs a five-person design studio in Montreal with about a dozen small client invoices outstanding at any time, most under two thousand dollars. Her routine, built with her accountant, runs weekly. On Monday she reviews open receivables in her accounting tool. For clients whose invoices carry an email address on file and whose terms allow electronic payment, she issues business-variant requests through her bank carrying the invoice number and due date, keeping full invoice detail on the invoice itself. During the week she watches two lists separately: the receivables list in her accounting tool and the request-status list in her bank. Fulfilled requests with matched postings close their invoices. Pending requests get one direct follow-up referencing the invoice, not the request. Declined requests go to a phone call to understand the dispute. Expired requests are re-issued once with a fresh reference where the relationship supports it, then escalated to normal collections language. Cancelled requests — issued in error or superseded — are verified as removed from the client's actionable view. At month-end her three-way match ties request, payment, and posting by invoice number before anything is reported as collected. Control lesson: pending is pipeline, not cash; status hygiene plus invoice-number matching is what converts nudges into closed books without ever mistaking an ask for a receipt.
Read across the three examples, the pattern is stable. The requester invests care up front in contacts, amounts, and messages. The payer invests verification at decision time inside the bank. Both sides read status literally. And the business among them reconciles three objects rather than one. Teach those four habits and the product pays for itself in fewer awkward conversations and fewer month-end surprises.
12. Key takeaways and authoritative references
The chapter reduces to ten sentences that every colleague who touches this product should be able to say without notes. The request is not customer-account money movement until the payer consents and pays. The requester sends an ask with an amount, and the payer chooses whether to fulfil it. Fulfilment is an Interac e-Transfer payment from payer to requester, subject to the participating institutions' normal processing and terms. A pending request is not proof of collection. Expiry, cancellation and any decline outcome depend on the institution's actual product states and terms; none should be treated as a completed payment. Re-request after a terminal state should use a fresh request record. The authenticated bank view is the operational source of truth, not an untrusted notification. Unexpected requests are verified through an independent channel before consent. Businesses should reconcile request, payment and posting with the references their bank actually supplies, and close invoices only on confirmed payment posting. Interac Corp operates the e-Transfer service; this chapter does not infer a Lynx or ACSS settlement route.
Carry those sentences into the rest of Block 6 and they compose correctly with their neighbours. Send money teaches the payment the request becomes. Autodeposit teaches the landing the fulfillment can use. Business teaches the invoicing surface the request can carry. Fraud teaches the persuasion patterns the request attracts. None of them changes the hinge. Consent is the only bridge between asking and moving, and it runs one way.
Authoritative references follow. Interac publications establish the customer-facing feature and operator boundary. FINTRAC sources are included because a bank must not infer AML/ATF reporting treatment from the fact that a request has no customer-account posting. Bank-specific handling including expiry periods, fees, limits, cancellation controls, states, and screen-level behaviour is governed by each participating institution's current terms and implementation.
- Interac — How to use Interac e-Transfer Request Money (consumer how-to: contacts, amount, destination account, message and confirmation; cancellation and expiry remain institution-specific): https://www.interac.ca/en/how-to-use/interac-e-transfer/how-to-use-interac-e-transfer-request-money/
- Interac — Send and receive money with Interac e-Transfer (personal product page including the Request money feature summary): https://www.interac.ca/en/payments/personal/send-receive-money-with-interac-e-transfer/
- Interac — Interac e-Transfer Business Request Money (business collection through website, app, QR code or invoice, with institution setup and use cases): https://www.interac.ca/en/payments/business/interac-e-transfer-business-request-money/
- Interac — Interac e-Transfer 101: everything you need to know about sending and receiving money (Autodeposit, timing, and Request Money in context): https://www.interac.ca/en/content/life/interac-e-transfer-101-everything-you-need-to-know-about-sending-and-receiving-money/
- Interac — Business frequently asked questions, Request Money section (invoice-number message use, message limits, billing use): https://www.interac.ca/en/resources/business-resources/business-faq/
- Interac — Interac e-Transfer Disclosure (operator, participating institutions, direct/indirect connectors, Request Money in scope; current disclosure): https://www.interac.ca/en/interac-e-transfer-disclosure/
- Interac — Interac e-Transfer consumer FAQ (Request Money opt-out, fees, timing, support and no-reversal guidance): https://www.interac.ca/en/resources/personal-resources/personal-faq/interac-e-transfer/
- Interac — Interac e-Transfer Terms of Use (institution terms, cancellation/finality, limits, records and delivery-time disclaimers): https://www.interac.ca/en/interac-e-transfer-terms-of-use/
- Interac — Protect your payments (secure-network, no banking-details sharing, phishing and fraud-reporting guidance): https://www.interac.ca/en/payments/personal/protect-your-payments/
- FINTRAC — Reporting electronic funds transfers (EFT definition, reportability and reporting-entity obligations): https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng
- FINTRAC — Reporting suspicious transactions (transactions or attempts, reasonable grounds to suspect and required party/context information): https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/str-dod/str-dod-eng
- Payments Canada — Real-Time Rail payment system (RTR planned Q4 2026 launch; exchange, clearing and settlement system): https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- Payments Canada — RTR testing and launch (testing, sequenced onboarding and planned migration phases): https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/testing-and-launch
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.