Payment Instruments, Clearing and Settlement. Separate customer payment instruments from the clearing, exchange and settlement mechanisms that move value.
Canada Payments & Collections · Block 1: Canada Payments Foundations · Chapter 4 of 75
This chapter separates two things that bankers, corporate clients and even experienced operations staff routinely blur: the payment instrument the customer touches, and the clearing, exchange and settlement machinery that actually moves value between banks. A payroll file, a pre-authorized debit, an Interac e-Transfer, a tapped debit card, a cheque, a bill payment, a Lynx wire instruction and a cross-border payment with foreign exchange attached can all feel like "a payment" to the customer. Inside the bank they ride different rails, obey different rules, carry different data, settle in different forms of money, become final at different moments, and fail in different ways.
If you take one sentence from this chapter into the rest of the programme, make it this one: the instrument is the promise and the customer experience; clearing is the exchange and sorting of obligations between banks; settlement is the final movement of value that discharges those obligations. Posting to a customer account, showing funds as available, and achieving legal finality are further separate events. Confusing any of them is how bad advice, bad cutoffs, bad liquidity planning and bad customer conversations happen.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain why the instrument is not the rail, using Canadian examples such as payroll by AFT versus payroll by wire;
- name the Canadian instrument families and the clearing and settlement mechanism each one normally uses;
- describe who does what for each family: originator, beneficiary, their banks, Payments Canada systems, Interac Corp and card networks, correspondents and the Bank of Canada;
- walk through initiation, validation and bank processing for AFT credits, PADs, Interac e-Transfer, Interac debit, credit cards, cheques and images, bill payments, Lynx wires, USBE items, cross-border payments, and cash and government items;
- compare ACSS deferred net settlement, Lynx real-time gross settlement, card network clearing with later interbank settlement, and Interac arrangements in plain language;
- explain settlement in central-bank money via Bank of Canada accounts versus settlement in commercial-bank money between banks, and why the distinction matters for risk;
- read a payment's data requirements — legacy AFT records, bill remittance data, Lynx ISO 20022 messages, UETR and PCRN references — and explain what breaks when data is wrong;
- apply rules, cutoffs, service levels and customer-impact language per family without promising what the rail cannot deliver;
- name the fraud and compliance controls per family and where they sit before release;
- use the exceptions vocabulary correctly: rejects, returns, recalls, reversals, chargebacks, cheque returns, PAD recourse and reimbursement;
- explain posting, accounting, liquidity, reporting and reconciliation per family;
- advise a client on instrument and rail choice, testing and resilience at an overview level;
- correct the four classic misunderstandings: e-Transfer equals the Real-Time Rail, card authorization equals payment, SWIFT equals settlement, and cheque deposit equals final funds.
For a roughly 60-minute core session, spend about 30 minutes on Sections 1–4 (the instrument-versus-rail mental model, participants, processing and settlement), 15 minutes on Sections 5–6 (data and cutoffs, using the push-versus-pull and message-versus-money diagrams), 10 minutes on one worked story in Section 11 (the payroll choice or the utility PAD-versus-bill-pay story), and 5 minutes on the takeaways and the four misunderstandings in Section 12. Treat these timings as a study guide. The remaining sections, second and third stories, and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and system boundaries
- Initiation, validation and bank processing
- Clearing or exchange, settlement and finality
- Data, identifiers, messages and references
- Rules, cutoffs, service levels and customer impact
- Fraud, compliance and operational controls
- Exceptions, investigations and recovery
- Posting, accounting, liquidity, reporting and reconciliation
- Bank implementation, testing and resilience
- Practical Canadian end-to-end example
- Key takeaways and authoritative references
1. Business context and customer need
Every business day in a Canadian bank starts the same way: customers want obligations discharged and cash applied, and they describe what they want in business language, not rail language. "Pay my staff on Friday." "Collect 40,000 utility bills on the 15th." "Take cards at my till and see the money tomorrow." "I wired the supplier — did they get it?" "The cheque is deposited — can I use the funds?" The bank's job is to translate each business need into the right instrument, the right clearing path, the right settlement moment and the right evidence trail, and then to speak about timing and finality honestly.
The translation matters because the same business need can legally and operationally travel by more than one route, and the routes behave differently. Payroll is the classic Canadian example. A company with 800 employees can pay them through Automated Funds Transfer (AFT) credits — direct deposits exchanged in batch through the Automated Clearing Settlement System (ACSS) — or, for a late executive top-up or an emergency payment, through a Lynx wire. Both put money into employee accounts. Only one is economical at volume, only one settles in real time with immediate finality, and only one carries the cutoffs, fees, data and exception behaviour the payroll manager needs to hear about before Friday. Telling a client "it is all electronic, it is all the same" is how missed paydays happen.
Collections show the mirror image. A utility collecting monthly bills can pull money with pre-authorized debits (PADs) under Rule H1, or it can wait for customers to push bill payments from their own banking apps under the bill-payment rules. The cash-flow difference is enormous. PAD gives the biller control of timing and amount within the mandate; bill-pay gives the customer control and leaves the biller dependent on thousands of individual decisions. Both clear through ACSS batch on the back end, but the authority model, the return profile, the remittance data and the reconciliation workload are completely different. Choosing between them is a business decision first and a rail decision second.
Retail commerce adds a third pattern: instant customer experience with delayed interbank economics. When a customer taps an Interac debit card or a Visa card at a Toronto café, the authorization decision arrives in seconds and the till receipt prints. No interbank value has moved. Clearing happens later in batch, interbank settlement between the merchant's bank and the customer's bank happens later still, and the merchant is funded net of fees. The barista's experience ("approved") and the accountant's experience ("funded Tuesday, net of fees, one refund reversed Thursday") live on different clocks. Staff who conflate them over-promise availability and then cannot explain the statement.
Cross-border business completes the picture with a fourth pattern: messages and money travel separately. A Canadian importer paying a euro supplier instructs its bank, the bank sends ISO 20022 messages over SWIFT under the CBPR+ programme, and actual value moves through correspondent accounts or domestic high-value systems at each leg. SWIFT never settles a dollar. The UETR reference tracks the instruction end to end, but settlement proof comes from account debits and credits.
Underneath all of this sits the question of what "final" means, and it means different things for different families. A Lynx payment is final between Lynx participants when it settles in real time across Bank of Canada accounts — that is settlement in central-bank money. An ACSS batch item reaches interbank settlement after exchange, netting and settlement of net positions across Bank of Canada accounts on the applicable business-day cycle. A card payment's interbank outcome follows network clearing and settlement between the acquirer's and issuer's banks, while the merchant's exposure to a cardholder dispute follows scheme chargeback rules, a different finality question entirely. A cheque deposit shown in online banking is a posting decision by the deposit-taking bank, not finality; the item can still return for insufficient funds, stop payment or fraud. Each family needs its own finality sentence, and this chapter gives you one per family. As of 5 October 2026: Lynx has been live since September 2021 (replacing the LVTS) and Payments Canada says it fully transitioned from MT to ISO 20022 on 22 November 2025; the ACSS/USBE retail batch system remains live; Interac Corp operates e-Transfer and the debit network; and the Real-Time Rail is not in production — its By-law and Rules were approved on 30 June 2026 and come into force on 24 August 2026, ahead of the planned Q4 2026 launch. So an e-Transfer is the live near-real-time experience, while the RTR is a separate forthcoming rail. Payments Canada: Lynx fully adopts ISO 20022 Payments Canada: RTR legal milestone
The practical payoff of the layering habit is operational. Once you separate instrument, clearing, settlement, posting and finality, the rest of the programme slots into place: cutoffs make sense (each clearing has its own clock), exceptions make sense (each family has its own return vocabulary), data makes sense (each clearing validates its own identifiers), liquidity makes sense (RTGS needs intraday funding; batch needs net-position funding), and reporting makes sense (each stage produces its own evidence). Sections 2 through 10 walk each layer family by family; Section 11 grounds the model in three fictional but realistic Canadian stories.
2. Participants, responsibilities and system boundaries
Canadian payments look crowded until you sort participants by what they are responsible for. Four questions place almost anyone: who owes the customer a duty, who exchanges with whom, who settles with whom, and who operates the system they all share. The answers differ by instrument family, but the cast is stable.
The originator and beneficiary — employer and employee, biller and payer, merchant and cardholder, importer and foreign supplier — own the underlying commercial obligation and the instruction data. Their responsibility is accuracy: correct account and routing details, correct amount and date, valid authority where a pull is involved, and complete remittance references where the receiver must apply cash. Most retail exceptions in Canada trace back here, not to the rails: a wrong biller account number, a stale PAD agreement, a mistyped transit number, a missing invoice reference. Banks spend a large share of operations effort proving that the instruction they received is the instruction the customer meant.
The originator's bank and the beneficiary's (or receiver's) bank — sometimes called the sending and receiving participants — own validation, clearing participation, settlement funding and customer posting. The sending bank checks authority, limits, sanctions and fraud signals before release; it formats and submits the item to the right clearing; it funds its settlement obligation; it reports status back to its customer. The receiving bank validates incoming items, posts or returns them, applies holds where permitted, and reports to its customer. Where a bank is an indirect clearer, a direct clearer acting as clearing agent performs ACSS or Lynx settlement on its behalf — the indirect participant keeps the customer relationship while the direct participant bears the settlement-account responsibility at the Bank of Canada. Block 1's later chapters and Block 2 unpack direct and indirect participation; for this chapter the point is that "our bank" may act through another bank's settlement account, and that agency must be visible in reconciliation and incident handling.
Payments Canada operates the ACSS and Lynx, maintains the rules that govern exchange, clearing and settlement (including the AFT, PAD, bill, cheque and government stream rules referenced throughout this chapter), and is delivering the Real-Time Rail programme. The Bank of Canada provides settlement accounts for Lynx and ACSS, oversees designated systems and supervises accordingly. Its published perimeter lists Payments Canada's Lynx and ACSS, Interac e-Transfer, Interac's Inter-Member Network (IMN), VisaNet, and Mastercard's Global Clearing Management System (GCMS) and Single Message System (SMS). The practical meaning for a banker: these systems matter enough to the financial system that their risk, access and resilience standards are set above ordinary commercial outsourcing, and participant banks must meet them. Bank of Canada: payment systems it oversees
Interac Corp operates the consumer e-Transfer service and the domestic debit network rails, connecting participating financial institutions. Responsibility splits in a way newcomers find surprising: the customer's own bank authenticates the customer, applies limits and fraud controls, debits or credits the account and shows status; Interac's arrangements move the notification, addressing and interbank clearing logic between institutions; settlement between the institutions follows the applicable interbank arrangements.
Card networks and their participants follow a four-party pattern most bankers know but few can explain under pressure. The cardholder and issuer (the customer's bank), the merchant and acquirer (the merchant's bank or processor), and the network (Visa, Mastercard and the domestic debit arrangements) each own a slice. The issuer owns the authorization decision and the cardholder relationship; the acquirer owns merchant underwriting, funding and chargeback pass-through; the network owns clearing rules, message standards and the multilateral sorting of obligations; interbank settlement between acquirer and issuer banks discharges the network obligations. Processors, gateways and payfacs may sit inside the acquirer or merchant slice, but they do not change the settlement boundary: the merchant is paid by its acquirer relationship, not by the network directly.
Billers, payroll vendors, PAD collectors and their service providers form the corporate-user layer. A payroll provider building AFT files, a utility managing 40,000 PAD mandates, a municipality receiving property-tax bill payments — each owns mandate or account-reference quality, file accuracy, timing relative to cutoffs, and receivables matching on the way back. Their banks own validation and submission. When a bill payment is "paid at the bank but not applied at the biller," the boundary question is precise: did the bank's clearing leg complete, and did the biller's remittance leg carry the right account reference? Both must be checked; blaming "the system" resolves nothing.
Correspondents, intermediaries and FX providers complete the cross-border cast. A Canadian bank without a direct account in the payment currency settles through a correspondent that holds the currency account; intermediaries may sit in the chain where routing requires it; the FX provider (often the same bank) owns rate, value date and disclosure. SWIFT carries the standardized instruction and tracking data between them but settles nothing itself. The United States Bulk Exchange (USBE) items covered later in this chapter add a domestic-batch twist: small US-dollar items drawn on Canadian banking offices exchange in Canada through dedicated ACSS K-series streams rather than through US clearing.
System boundaries can be stated as five lines that every banker should be able to draw on a whiteboard. First, the customer-to-bank boundary: instruction, authentication, authorization and reporting. Second, the bank-processing boundary: validation, sanctions and fraud screening, formatting, cutoff management and release. Third, the clearing and exchange boundary: the multilateral or bilateral exchange of items and the calculation of who owes whom. Fourth, the settlement boundary: the final movement of value in central-bank or commercial-bank money. Fifth, the posting and reconciliation boundary: customer-account entries, statements, receivables matching and exception handling. Instruments live above the first line; rails live between the second and fourth; customer trust is won or lost at the fifth. The rest of this chapter walks each instrument family across all five lines.
3. Initiation, validation and bank processing
Bank processing is where a customer wish becomes a bank obligation, and each instrument family enters the bank differently. The families share a common control spine — authenticate, authorize, validate, screen, check funds or limits, format, hold or release against cutoffs — but the inputs, the evidence and the failure modes are family-specific. This section walks each family in the order a practitioner meets them, from the highest-volume batch instruments through cards, paper, bills, wires, cross-border and the brief cash-and-government corner.
AFT credits and direct deposit begin with a file, not a single payment. An employer, pension payer, government disburser or corporate AP team — directly or through a payroll bureau — builds a batch of credit instructions carrying each beneficiary's routing and account details, amount, intended pay date and identifying references, formatted to the legacy AFT specifications (commonly discussed under Rule F1 with the F4 push toward ISO 20022 data, covered in Section 5). Initiation channels include host-to-host file delivery, treasury workstations and bureau uploads. Bank validation is batch discipline: authenticate the submitter, check signing and entitlements, validate file structure and totals, confirm value dates against the ACSS calendar, duplicate-check against recent submissions, and verify routing data where the bank's tooling supports it. Funds validation is about the originator's account and exposure, not each employee's account — the bank debits the originator and warrants the batch into clearing. Items failing validation are rejected back to the originator before exchange. Later blocks trace AFT file anatomy field by field; here the operating rule is that payroll quality is decided at file build and bank validation, long before settlement day.
Pre-authorized debits (Rule H1) begin earlier still — at the mandate. Before any money moves, the biller (payee) must hold a valid PAD agreement meeting Rule H1 requirements: the right agreement type (personal versus business), required terms, amount or variable-amount language, timing, cancellation rights and notices. Initiation is the biller submitting a debit instruction against the payer's account on the due date. Bank processing on the collector's side validates the collector's authority to originate, file quality and timing; on the payer's side it is the debit decision — pay, or return for insufficient funds, account closed, or dispute. Because one collector reaches into thousands of accounts, validation weight falls heavily on mandate evidence and anomaly monitoring: a new collector suddenly debiting large amounts or heavy re-presentment after NSF returns deserves holds and callbacks.
Interac e-Transfer (Interac Corp) begins with addressing, not account numbers. The sender, authenticated in their own bank's app or online banking, addresses the transfer by email, mobile number or, increasingly, registered Autodeposit details; the sender's bank applies authentication step-up, limits (per-transaction, daily, holds for new payees), fraud scoring and sanctions screening, then debits the sender subject to the service flow. Interac's arrangements carry the notification and deposit-routing logic; the recipient, authenticated at their own bank, accepts and designates the deposit account (or is auto-credited under Autodeposit), and the recipient's bank posts the credit and reports status. Request Money inverts the initiation without changing the settlement character: the request is a message seeking consent, and only the resulting e-Transfer moves value. Operationally, the sender's bank must make cancellation and expiry behaviour clear (an unclaimed transfer is not a completed payment), and fraud teams must treat first-time payees, changed contact details and impersonation pressure as high-risk markers.
Interac debit and shared point-of-sale begin at the till, the pump or the checkout page. The cardholder presents the card or device credential; the merchant's terminal routes to the acquirer; the domestic debit network carries the authorization request to the issuer; the issuer checks authentication, account standing, funds and fraud signals and returns approve or decline in seconds, placing a hold on the customer account. Clearing of the resulting transaction data and interbank settlement between the institutions follow later through the applicable Interac clearing and settlement arrangements — not inside the authorization message. Issuers own real-time decisioning and cardholder alerts; acquirers own merchant boarding, terminal configuration, batch capture hygiene and funding. The key processing sentence for client conversations: the receipt proves the issuer approved; it does not prove the merchant has been funded.
Credit cards (VisaNet and GCMS-SMS family) extend the same separation with richer economics. Authorization — cardholder to merchant to acquirer to network to issuer and back — checks credit standing, velocity, token or cryptogram validity for device and ecommerce transactions, and fraud scores, then returns a decision and places a shadow on available credit. Clearing follows in batch: the acquirer submits finalized transaction records, the network sorts multilateral positions and applies interchange and fee logic, and interbank settlement between acquirer and issuer banks discharges the network obligations. Merchant funding is a separate acquirer-to-merchant entry, net of discount, interchange pass-through and other fees, on the acquirer's funding schedule. Programme-level accuracy note, kept deliberately generic as instructed: card obligations clear through the networks and settle interbank between the banks — client-facing staff should not overclaim a specific central-bank settlement mechanism for cards.
Cheques and images (ACSS paper A-series streams) begin with paper or its image. Capture happens at branch, ATM, remote-deposit capture or mobile: MICR-line data, amount and the front-and-back image are recorded, duplicates are checked (the same cheque photographed twice is a perennial loss source), and a deposit receipt or acknowledgement is issued. The deposit-taking bank validates endorsement, date, payee consistency, amount-image agreement and fraud markers, applies holds per its policy, and posts a provisional or held credit according to its funds-availability practice. Image exchange then carries the image and data to the drawee bank instead of the physical paper; ACSS paper-stream clearing builds the interbank positions; net settlement follows on the ACSS cycle via Bank of Canada accounts. The sentence that prevents most cheque complaints: the deposit credit and the hold expiry are the bank's customer-service decisions; finality arrives only when the drawee bank has honoured the item and the return window has passed.
Bill payments (Rules H6 and H3 at introduction level) begin with the payer choosing a biller and entering the biller account reference — the most error-prone keystroke in Canadian retail banking. Initiation channels include online and mobile banking, ABM, branch and telephone-assisted entry. Bank validation centres on the biller directory (is this a biller the bank recognizes, with the right account-format rules), reference check-digits where billers provide them, amount and limit checks, and cutoff presentation (when the biller will see the payment). Clearing carries funds through ACSS batch streams while remittance data travels to the biller; the biller's bank credits the biller and the biller applies cash against the referenced account. Failure concentrates exactly where the model predicts: the funds leg succeeds while the remittance leg names a wrong, closed or mistyped account, producing the "bank says paid, biller says not received" investigation.
Lynx wires — customer versus interbank — begin with a payment instruction that names the beneficiary bank, beneficiary account, amount, value date, charges and purpose with enough precision for sanctions screening and straight-through processing. Customer wires (the corporate treasurer paying a supplier, the lawyer moving closing funds) ride as customer credit transfers; interbank wires (bank-to-bank settlement, treasury funding, financial-market legs) ride as bank-to-bank transfers. The sending bank retains the full customer instruction, but Payments Canada says Lynx receives only a partial copy needed for routing and settlement, not client information, account numbers or transit numbers. Bank validation is the heaviest in this chapter: complete beneficiary data, sanctions and fraud screening with false-positive handling, funds and daylight-limit verification, dual authorization and callback discipline for new or changed beneficiaries, and cutoff awareness (a request after the participant's or Lynx operating window may wait until the next business day). Release into Lynx settles each accepted payment individually across Bank of Canada accounts — no netting — but customer recalls, holds and beneficiary posting are separate processes. Payments Canada: Lynx wire payments and PCRN
USBE US-dollar items begin like small cheques and debits and credits drawn in US dollars on Canadian banking offices — but they clear in Canada. Dedicated ACSS US-dollar K-series streams (K1, K4, K5 and K8 at programme level, detailed in Block 11) exchange these items between Canadian participants in batch, with US-dollar positions settling through the applicable US-dollar settlement arrangements rather than through Canadian-dollar Lynx settlement. Operations must keep the bright line visible: a USBE item is a batch retail item with batch timing and return rights, not a same-day US wire and not a Lynx payment in disguise.
Cross-border payments (SWIFT CBPR+, correspondent serial and cover, FX) begin with a currency, a country and a value date. The Canadian sender's bank captures beneficiary details (including the beneficiary bank identifier where required), amount and currency, charge option, purpose and supporting information, then validates, screens and prices the payment: FX rate, spread disclosure where applicable, fees, value dating and the expected correspondent path. Message initiation follows the SWIFT CBPR+ ISO 20022 standards; routing follows either the serial method (instruction and funds travel together down the chain) or the cover method (the instruction goes direct to the beneficiary's bank while the funds travel a separate cover leg). Actual settlement at each hop is an account debit and credit — correspondent nostro/vostro entries or domestic high-value settlement in the relevant currency — each governed by that system's finality rules.
Cash and government items, briefly, complete the inventory. Cash initiation is physical tender with a control slip; validation is note authentication, teller balancing and dual custody; settlement is vault and Bank of Canada note-inventory accounting. Government disbursements and collections ride their designated G-series streams with their own calendars and return conventions, detailed in Block 10.
4. Clearing or exchange, settlement and finality
Clearing answers "how do the banks sort out who owes whom," settlement answers "how is that obligation finally discharged," and finality answers "when can nobody unilaterally take it back." Canada runs three settlement characters — deferred net batch, real-time gross, and network-cleared commercial-bank settlement — plus messaging-only arrangements that are not settlement at all. Each instrument family maps to exactly one of them, and the mapping is the heart of this chapter.
ACSS deferred net settlement is the batch workhorse. Throughout the business day, direct participants exchange payment items across the streams — AFT (F-series), PAD debits under H1, bill payments under H6/H3, EDI items under E3, point-of-sale under the E-series, paper and image items under the A-series, government items under the G-series, and US-dollar USBE items under the K-series. Exchange builds each participant's multilateral net debit or credit position; at the appointed settlement time, those net positions settle across Bank of Canada accounts in central-bank money. Finality for the interbank obligation therefore arrives on the ACSS settlement cycle, not when the customer presses send and not when the batch file is acknowledged. Customer posting may precede or follow interbank settlement depending on the bank's funds-availability and pay-date practices — which is why payroll files are dated forward and cheque holds exist. Operations consequences are concrete: respect stream windows, monitor net positions, fund the settlement account, and never describe an ACSS item as "settled" before the cycle completes.
Lynx real-time gross settlement is the opposite design. Each payment instruction accepted for settlement in Lynx settles individually across the participants' Bank of Canada accounts — no netting or batch cycle. Settlement is in central-bank money and, once applied, is final and irrevocable between Lynx participants. The price of that certainty is intraday liquidity: participants must hold or obtain sufficient Lynx balances or collateralized intraday credit, manage queues and priorities through the operating day, and coordinate large payments with treasury.
Card network clearing with later interbank settlement is the third character. Visa, Mastercard and domestic debit arrangements clear in batch: acquirers submit finalized transaction records, networks sort multilateral obligations, interchange and fees are calculated, and interbank settlement between acquirer and issuer banks follows. Merchant funding is yet another step — the acquirer's net payment to the merchant on its funding schedule. Finality therefore has two faces that must never be merged in customer talk. Interbank finality between the banks follows the network settlement; the merchant's practical finality against cardholder disputes follows scheme rules with chargeback and representment windows stretching weeks or months. An "approved" authorization is neither. Operations consequences include the three-date reconciliation discipline (authorized, cleared, funded), careful refund handling (refunds are new clearing records, not cancellations of settlement), and fee transparency (the merchant receives net, never gross). The programme keeps the settlement-mechanism language generic at this level — network clearing, then interbank settlement between the banks — and reserves precise settlement-account mechanics for the card blocks.
Interac arrangements blend a near-real-time customer experience with distinct network and bank-processing steps. Interac's public material says e-Transfer uses email or text notification and participating financial institutions' existing payment networks; it does not publish a customer-visible interbank settlement cycle in the material used here. Debit authorization feels instant at the till, but the Inter-Member Network and ACSS boundaries must not be collapsed into the authorization event. Practical finality language for staff: a deposited e-Transfer or approved debit is usable only according to the relevant bank's posting decision, and speed is not evidence of RTR finality or irrevocability. An unclaimed e-Transfer expires after 30 days under Interac's help material; a deposited transfer cannot be cancelled by the sender. Interac: e-Transfer help Bank of Canada: payment systems it oversees
Cheque and image finality deserves its own paragraph because it is the most misdescribed in branches. Provisional posting plus hold expiry is not the same thing as an honoured item or a closed return exposure. A drawee decision is normally made by the next business day under Payments Canada's system description, but the deposit-taking bank's customer-facing availability is governed by its hold policy and, for federally regulated institutions, the Access to Funds Regulations. Federal guidance says cheque holds can be 4 to 8 days depending on the instrument and deposit conditions; exceptions and non-federally regulated institutions must be checked separately. Image exchange accelerated the paper without changing the principle: faster images mean faster returns too, and mobile-captured duplicates mean the same item can appear twice. Payments Canada: retail batch payment system Justice Canada: Access to Funds Regulations
Bill-payment finality splits across the two legs introduced in Section 3. The funds leg between the payer's bank and the biller's bank finalizes on the ACSS cycle; the remittance-application leg at the biller finalizes when the biller matches the reference and posts to the customer account. A payment can be interbank-final and still unapplied at the biller for days if the account reference was wrong. Customer-impact language must carry both dates: "debited and sent on X, biller confirmation Y, applied per the biller's cycle." Biller-direct debit arrangements and card-paid bills follow their own finality on top.
Cross-border and USBE finality close the section with a two-clock rule. For SWIFT-instructed payments, each settlement hop finalizes under its own system's rules — Lynx finality for a Canadian-dollar leg, the foreign system's finality for the foreign leg, correspondent-account finality when the books are posted. No overarching "SWIFT final" moment exists. Tracker and UETR status describe the instruction's journey; account entries prove value moved. For USBE items, settlement is through the Canadian retail batch system with U.S.-dollar positions settled through correspondent banks in New York, not through Canadian-dollar Lynx. FX value dating overlays both: the rate and the date on which value is deemed delivered are contractual on top of the settlement mechanics, and investigations must check all three (message, money, value date) before declaring anything complete. Payments Canada: retail batch payment system
5. Data, identifiers, messages and references
Payment data is the rail's native language, and each Canadian family speaks its own dialect. Getting identifiers right is not administrative tidiness — it is what makes straight-through processing possible, what screening engines match against, what reconciliation keys join on, and what investigators search for when money goes astray. This section introduces each family's data envelope at overview level; later blocks dissect message anatomy field by field.
AFT: legacy records meeting ISO 20022. The AFT world most banks still operate daily is a fixed-format world: logical records carrying originator identification, destination routing data (institution, transit and account), amounts, due dates and reference fields, wrapped in file and batch headers and trailers with hash totals. The programme's shorthand — Rule F1 for the established AFT exchange conventions with Rule F4 introducing the ISO 20022-based evolution — marks a coexistence every operations team must manage: legacy files from long-standing originators alongside ISO 20022-mapped data with longer names, structured addresses, richer remittance and end-to-end references. Coexistence controls are practical: maintain the mapping tables, validate both formats at intake, truncate nothing silently, preserve the originator's reference through to the beneficiary statement, and prove during testing that a reference surviving in one format survives in the other. The most expensive AFT data failures are mundane — a transposed transit number, a closed beneficiary account, a due date on a holiday — so validation against current routing data and calendar-awareness at file build save more money than any downstream repair process.
Lynx: ISO 20022 MX since the transition. Wire data entering Lynx is ISO 20022 native following the completed 22 November 2025 migration: customer credit transfers in the pacs.008 family, interbank transfers in the pacs.009 family, returns in pacs.004, and cash-management and status reporting in the camt family. Two references must be kept distinct. The UETR (Universally Unique End-to-End Transaction Reference) is a SWIFT cross-border tracking reference and is not a promise that every domestic wire has one. The PCRN (Payment Confirmation Reference Number) is generated by Lynx for a Lynx wire payment that has settled; not every wire has a PCRN, including same-institution wires. Validation consequences are immediate: an incomplete agent chain, a missing purpose where the corridor requires it, or a character-set violation can delay a payment the customer considers urgent. Payments Canada: Lynx wire payments and PCRN
PAD and bill data: mandates and remittance. PAD data is authority data first and payment data second. The agreement type, payer identity, account to be debited, amount or variability formula, frequency, start conditions and cancellation terms must be retrievable as evidence, not merely present at origination. Each presentment then carries the collector identifier, the payer account, amount, due date and a reference binding it to the mandate. Bill-payment data inverts the emphasis: the payer's instruction carries the biller identifier and the biller account reference, and the remittance advice to the biller must reproduce that reference faithfully plus the payer identity, amount, date and bank confirmation number. EDI-bearing AFT items extend the same idea to corporate payables with structured invoice references. Reconciliation in all three families joins on references, so reference discipline — no reuse, no silent truncation, no free-text invoice numbers where a structured field exists — is a cash-application control, not paperwork.
Interac and card data: addressing versus account data. Interac e-Transfer data centres on addressing and status: sender and recipient contact handles or registration IDs, Autodeposit bindings, notification state, acceptance state, expiry and cancellation markers, amount and memo. The underlying account numbers stay inside each bank; the network moves the addressing and deposit instruction. Card data centres on the authorization-cleared-settled chain: PAN or token, cryptogram, merchant identifier, authorization code, clearing record identifiers and dispute reason codes. Tokens and device credentials add a binding the bank must preserve — a tokenized transaction's dispute evidence differs from a keyed one's. Both families share one operational lesson: status vocabularies must be quoted exactly. "Notified," "accepted," "deposited," "expired" and "cancelled" are different states with different money consequences, just as "authorized," "cleared," "settled," "refunded" and "charged back" are.
Cheque and image data: MICR plus image plus decision. The MICR line (institution, transit, account, cheque number), the encoded and confirmed amount, the front-and-back image, the endorsement record and the deposit-channel metadata travel together. The drawee's decision data — honour, return with reason, hold — closes the loop. Image quality is data quality: a blurred amount field or a cropped MICR line forces manual repair and delays the return clock. Duplicate-detection fingerprints (channel, amount, MICR, image hash) are reconciliation data in their own right and the cheapest fraud control in the family.
Cross-border data: CBPR+, UETR, charges and FX. SWIFT CBPR+ standardizes cross-border instructions as ISO 20022 messages with structured parties, agents, purpose, charges and the UETR that follows the transaction across every hop. Tracker data reports the instruction's progress; it does not prove settlement. Charges options, FX rate confirmations and value dates travel as data with contractual force — a dispute about fees or value dating is resolved from these fields, not from memory.
Across all families, three data habits distinguish strong banks. First, preserve end-to-end references untouched from intake to statement to reconciliation file — every truncation is a future investigation billed by the hour. Second, validate against authoritative sources at intake (Financial Institutions File data, biller directories, beneficiary-bank identifiers, mandate registries) rather than discovering defects in clearing. Third, keep message, money and status evidence together: the instruction copy, the clearing record, the settlement entry and the status trail for each payment should be retrievable by one reference. Section 9 turns these habits into reconciliation design.
6. Rules, cutoffs, service levels and customer impact
Rules tell each participant what it must do; cutoffs tell the customer when "today" ends; service levels translate both into dates and commitments a front-line employee can state without qualification. This section gives the per-family language that keeps promises accurate.
The rulebook layering is consistent across Canada. Federal law and Bank of Canada oversight set the perimeter; Payments Canada rules govern ACSS and Lynx exchange, clearing and settlement (the F-series for AFT, H1 for PADs, H6/H3 for bills at introduction level, the A-series for paper, G-series for government, K-series for USBE, E-series for POS/EDI, and the Lynx rules for high-value settlement); Interac Corp rules and network standards govern e-Transfer and debit participation; card-network operating regulations govern authorization, clearing, funding and disputes; bilateral correspondent agreements and SWIFT usage rules govern cross-border legs. A single customer payment can sit under several layers at once — a cross-border wire is simultaneously a Lynx payment, a SWIFT CBPR+ message, a sanctions-screened transaction and an FX contract. Staff need not memorize rule numbers for every conversation, but they must know which rulebook owns each promise: amount and timing authority for PADs lives in H1; biller obligations live in the bill rules; wire irrevocability lives in the Lynx framework; dispute windows live in scheme regulations.
Cutoffs are where service is won or lost, and each family keeps its own clock. AFT files carry release cutoffs ahead of the ACSS exchange windows and value-date deadlines — payroll for Friday is built days earlier, not Friday morning. PAD presentments carry lead-day conventions so payer banks can apply debit decisions. Interac e-Transfer and debit authorizations run near-continuously from the customer perspective, but back-end clearing, limits and fraud-review queues still create effective availability boundaries. Card batches carry merchant submission cutoffs that determine which funding run a sale joins. Cheques carry branch, ATM and mobile capture cutoffs plus hold schedules that separate "credited" from "available." Bill payments carry bank-to-biller delivery cutoffs and biller-cycle posting dates — paying late in the evening may mean the biller sees it next business day. Lynx carries operating-day windows and participant release disciplines — a request accepted after the participant's or Lynx cutoff may wait until the next business day. Cross-border adds correspondent and foreign-system clocks on top: a payment released Friday afternoon in Toronto may wait for Monday morning in the beneficiary's market, plus an FX value-date convention. USBE items follow batch cycles, not wire clocks. The universal customer-impact sentence is: the cutoff that matters is the earliest cutoff in the chain — intake, screening, clearing, settlement and beneficiary-market availability — and the bank must quote that one.
Service levels translate clocks into commitments. For AFT credits, the commitment is pay-date crediting for valid items received by the file cutoff, with a defined reject-and-repair path for the rest. For PADs, it is presentment on the due date with defined NSF and dispute recourse — the biller's cash forecast must carry a returns assumption, never zero. For e-Transfer, it is notification speed and deposit availability per the bank's posting practice, with expiry and cancellation behaviour stated upfront. For debit and credit cards, it is authorization in seconds, funding on the acquirer's schedule net of fees, and dispute windows measured in weeks. For cheques, it is acknowledgement at deposit, availability per the hold schedule, and return exposure until the window closes. For bills, it is debit timing plus biller-delivery timing plus the biller's application cycle — three dates, not one. For Lynx wires, it is same-day value for instructions accepted with complete data before the release cutoff, with finality at settlement. For cross-border, it is value-date commitment with corridor-dependent delivery ranges and explicit charge disclosure. For USBE, it is batch timing with batch returns. Every service level needs its exception clause in the same breath; Section 8 supplies the vocabulary.
Customer-impact language is the skill being tested. Weak language promises rail behaviour the bank does not control ("the supplier will have it today" for a cross-border payment, "the funds are final" for a fresh cheque deposit, "approved means paid" for a card sale). Strong language names the stage, the date and the evidence: "your file was accepted for Friday pay date; two items rejected for invalid transit — repair by Wednesday cutoff"; "the wire settled in Lynx at 14:03 with UETR …; the beneficiary bank posts per its own clock"; "the bill payment debited today reaches the biller tomorrow; keep confirmation … until the biller applies it"; "the cheque credit shows today with a hold until …; it is final after the return window." Operations teams should script these sentences per family and test that new hires can produce them without improvisation.
7. Fraud, compliance and operational controls
Controls sit before release wherever possible, because every Canadian family gets harder and more expensive to reverse after the settlement boundary. The control spine is shared — authenticate the actor, authorize the instruction, validate the data, screen sanctions and watchlists, score fraud, check funds or limits, enforce dual control and callbacks for high-risk changes, and preserve evidence — but each family's fraud concentrates where its authority model is weakest.
AFT credits are attacked through origination compromise: stolen treasury credentials, a substituted beneficiary file, an insider changing payee accounts. Controls therefore guard the file channel — credential hygiene, segregation between file creation and release, dual authorization above thresholds, payee-account change callbacks to known contacts, and duplicate and anomaly detection (a first-time foreign beneficiary in a domestic payroll run deserves a hold).
PADs are attacked through mandate abuse: debits without agreement, amounts above what was agreed, cancelled mandates still presented. Controls guard authority — mandate capture standards, retrievable evidence, new-collector monitoring, amount-drift alerts, and fast handling of payer disputes with reimbursement per the rules.
Interac e-Transfer is attacked through impersonation, takeover and social engineering: the "landlord's new email," the intercepted notification, the pressured sender, the compromised inbox. Controls guard addressing and session integrity — new-payee holds and step-up authentication, contact-detail change alerts, Autodeposit registration discipline, and transaction monitoring tuned to first-contact and round-amount patterns.
Interac debit and credit cards are attacked at authorization and at dispute: stolen credentials, counterfeit and card-not-present testing, account takeover, friendly-fraud disputes and refund abuse. Controls split across the two stages. At authorization: chip and device-cryptogram validation, token assurance levels, velocity and geolocation scoring, merchant-category and amount controls, step-up for ecommerce, and stand-in limit discipline. At clearing and disputes: compelling-evidence capture (authorization data, delivery proof), refund-to-original-instrument enforcement, and chargeback-reason-code literacy so representments carry the right evidence the first time.
Cheques and images are attacked through forgery, alteration, duplication and kiting: the same image deposited at two banks, an altered payee or amount, a counterfeit business cheque, funds floated between accounts on return timing. Controls guard capture and decision — duplicate-detection fingerprints across channels, amount-image agreement checks, stop-payment matching, and new-account and large-amount holds.
Bill payments are attacked through misdirection rather than classic theft: account-takeover bill-pay set up to a mule biller account, or socially engineered "pay this overdue bill" instructions. Controls guard payee setup — biller-directory discipline (no free-text billers where a directory entry exists), first-time-biller step-up, reference validation, and velocity review on new bill-pay profiles. The quieter operational risk, misapplied remittance, is controlled by double-entry of the biller account reference and confirmation-number preservation.
Lynx wires face the highest single-item stakes: business-email compromise redirecting a supplier payment, a changed-beneficiary instruction arriving by email, an insider releasing above authority. Controls are uncompromising because settlement is irrevocable — dual authorization, callback to independently sourced contacts for any new or changed beneficiary, purpose and country plausibility review, sanctions screening with documented false-positive resolution, amount-threshold escalation, and release-queue discipline against the operating window. No wire desk should be able to release a first-time large beneficiary on email authority alone; that sentence belongs in policy, in training and in testing.
Cross-border and USBE add screening depth and corridor awareness: full transmitted-party data, sanctions screening at origination and at each hop, and FX-rate and charge transparency.
Compliance overlays run across all families: client identification and record-keeping, prescribed transaction reporting to FINTRAC, sanctions compliance, and payment-information requirements where the PCMLTFA and Regulations apply. FINTRAC requires financial entities to report an international electronic funds transfer of $10,000 or more at initiation or final receipt, and its travel-rule guidance specifies information that must accompany covered EFTs; these are not blanket claims that every domestic batch item is an international EFT. Later blocks detail FINTRAC, sanctions and consumer-protection regimes; this chapter's contribution is placement: compliance controls live inside the processing boundary, before clearing. FINTRAC: reporting electronic funds transfers FINTRAC: travel rule
8. Exceptions, investigations and recovery
Every family has its own word for "it did not go as planned," and using the wrong word sends investigators down the wrong path. This section fixes the vocabulary and the recovery rhythm per family.
Rejects happen before exchange: the bank refuses the instruction — malformed AFT record, missing beneficiary field on a wire intake, invalid biller reference, failed authentication. The item never enters clearing; the originator repairs and resubmits. Returns happen after exchange or posting: the receiving side sends the item back — NSF or account-closed PAD, dishonoured cheque with a reason (insufficient funds, stop payment, stale, frozen), invalid-account AFT credit, biller-rejected remittance. Returns follow rule-defined reason codes and time windows and may carry fees. Recalls and reversals are sender-initiated recovery attempts after release: a wire recall request after Lynx settlement (which needs the beneficiary's cooperation because settlement was final), an AFT file recall for a duplicate payroll run, a PAD reversal within permitted conditions. Reimbursement is the PAD-specific consumer protection: a payer disputing an unauthorized or non-conforming debit is reimbursed with recourse up the chain to the collector. Chargebacks and representments are the card world's dispute cycle: issuer pulls back on the cardholder's behalf under a reason code, acquirer represents with compelling evidence, and the cycle repeats within scheme deadlines. Cheque returns carry their own reason-code and timing discipline with image evidence attached. E-Transfer cancellation and expiry are status-driven: an unclaimed transfer can be cancelled or expires back to sender availability; a deposited transfer is complete and needs recipient cooperation to move back. Cross-border investigations use message-based inquiry and tracker updates alongside account-entry proof — asking "where is the SWIFT" without checking each hop's settlement entry answers half the question.
Recovery rhythm follows a consistent five-step cadence whatever the word. First, identify precisely: quote the UETR, PCRN, AFT batch and item references, cheque image and return reason, card authorization and clearing identifiers, or bill confirmation number — never "the payment from Tuesday." Second, place the item on the timeline: was it rejected pre-exchange, returned in clearing, settled finally, or posted provisionally? The answer determines which recovery tool exists. Third, act within the window: stop-payment before presentment, PAD dispute within recourse periods, card representment before scheme deadlines, wire recall requests immediately even though cooperation is required. Fourth, make the customer whole per the rules: reimburse where the regime requires it, re-present where permitted (PAD retry discipline matters — repeated NSF hammering debits fees without collecting cash), re-originate where the instruction was defective. Fifth, preserve evidence: mandate copies, authorization logs, screening dispositions, image copies, message copies, settlement entries and customer communications together, because the same file answers the customer, the auditor and, occasionally, the regulator.
Three investigation habits prevent most escalations. Quote references exactly and in writing. State the stage honestly ("settled in Lynx, awaiting beneficiary-bank posting" rather than "sent"). And separate the funds leg from the data leg in every update — bill-pay repairs need the remittance copy, cross-border traces need both tracker and ledger proof, payroll repairs need the reject listing not a re-sent duplicate file. Teams that do these three things close cases in one contact; teams that do not re-investigate their own investigations.
9. Posting, accounting, liquidity, reporting and reconciliation
Posting turns system events into customer balances; accounting turns them into bank books; liquidity makes release possible; reporting tells the customer what happened; reconciliation proves the whole story joins end to end. Each family exercises this machinery differently, and the differences explain most month-end breaks.
Posting follows family-specific timing. AFT credits post to beneficiaries on the pay date for valid items, with the originator debited under the bank's debit-timing practice. PADs debit payers on presentment (or return for NSF) and credit collectors after the applicable availability. E-Transfer credits post on acceptance or automatically under Autodeposit, with sender debits applied in the send flow. Debit and credit card authorizations place holds that convert to posted debits or charges on clearing; merchant credits post on the acquirer's funding schedule. Cheque credits post provisionally with holds; drawee debits post on honour. Bill payments debit the payer at initiation and credit the biller's bank for biller posting per its cycle. Lynx settlement is final between participants when it occurs, but the end-user beneficiary posting can be later because of participant cutoffs, intermediary processing, AML review or incomplete information. USBE items post on batch timing with return exposure. Cross-border beneficiary credits post per the receiving market's clock and the FX value date. The discipline is uniform: every posting needs a narrative the statement reader can understand — what it was, who it was with, which reference to quote — because unexplained postings generate the calls that cost more than the payments earned. Payments Canada: Lynx wire payments and PCRN
Accounting mirrors the five boundaries from Section 2 in ledger form: customer accounts, internal suspense and clearing accounts per stream, settlement accounts at the Bank of Canada for Lynx and ACSS positions, nostro and vostro accounts for cross-border legs, and interchange and fee accruals for cards. Strong designs clear suspense daily by stream and by date. Unreconciled suspense carried forward is how small defects become large write-offs, so ownership (who clears which suspense account by when) belongs in job descriptions, not in folklore.
Liquidity is the quiet constraint behind every release decision. Lynx RTGS needs intraday funding for each payment — balances or collateralized intraday credit plus queue management. ACSS needs settlement-account funding for net debit positions on the cycle. Cross-border needs currency-account funding with value-date awareness. Treasury, operations and the customer-facing desk must share one liquidity calendar.
Reporting serves three audiences. Customers need status and proof: reject listings for AFT originators, return reports for PAD collectors, deposit confirmations for e-Transfer senders, funding reports for merchants, biller confirmations for bill payers, PCRN/settlement confirmation for a settled Lynx wire, and UETR/tracker status where a cross-border SWIFT payment has one. Operations need control reports: cutoff compliance, screening holds, suspense aging, dispute deadlines. Finance and risk need position reports: net settlement obligations, intraday liquidity usage, and return-rate trends by family.
Reconciliation matches instruction to clearing evidence to settlement entry to customer posting, and investigates the unmatched remainder daily. Per-family match keys: AFT — file, batch and item references plus hash totals against stream positions and beneficiary-posting files; PAD — presentment references against payer debits, collector credits and return files; e-Transfer — send references against deposit and expiry states; cards — authorization log versus clearing file versus settlement credit versus merchant payout; cheques — deposit records versus honour or return reasons; bills — payer debits versus biller application confirmations; Lynx — PCRN and participant settlement confirmations; cross-border — UETR/tracker states versus nostro debits and beneficiary advices. Automate the matched middle, staff the edges.
10. Bank implementation, testing and resilience
Knowing the model is not the same as running it, and this section covers what a bank must build, prove and keep alive to offer each instrument family responsibly. It stays at Block 1 overview level — later blocks go deep on access, formats and operations — but the checklist here is what managers use to judge readiness.
Which stream and rail for which need is the first implementation decision, and it should be written down as a routing guide, not held as tribal knowledge. Volume payroll and disbursements default to AFT credits; urgent, large or time-critical value defaults to Lynx wires; recurring collections with mandates default to PAD; customer-initiated bill settlement defaults to bill-pay rails with remittance; consumer person-to-person defaults to e-Transfer; till and checkout defaults to debit or card acceptance; paper received defaults to image capture; US-dollar cheques and small USD debits drawn on Canadian offices default to USBE streams; foreign-currency or foreign-beneficiary needs default to SWIFT-instructed correspondent payment with FX. Each default needs its documented exception path (when payroll uses a wire, when a collection uses card-on-file instead of PAD) with authority thresholds, because exceptions are where losses concentrate.
Channel and limit design implements the risk appetite per family: per-transaction, daily and new-payee limits for e-Transfer and wires; file and item limits with dual release for AFT; collector exposure limits for PAD originators; merchant floors and velocity rules for acquiring; deposit limits and hold matrices for cheques; biller-setup controls for bill-pay. Limits must be explainable to customers in one sentence each and changeable through a governed process with evidence — ad-hoc limit overrides by phone are a fraud finding waiting for its audit.
Testing must prove each family across all five boundaries before launch and after every material change: intake formats, stream windows and duplicate handling, position funding and value dating, and every exception word in Section 8 with its window and reason code. Test data must be fictional and sanitized. Sign-off needs operations, treasury, fraud, compliance and customer-service voices — a rail that settles correctly but cannot be explained at the call centre is not ready.
Resilience plans for the day each layer fails: alternate file channels for payroll, wire-queue playbooks for Lynx incidents, card stand-in procedures, e-Transfer status-lookup drills, biller-confirmation backlogs with repair capacity, and correspondent awareness for key corridors. Each playbook needs detection (which report shows the failure first), customer language (what to say before the fix exists), and recovery ordering.
Risks register per family so they can be owned. Credit and return risk concentrates in PAD, cheque and card-dispute families. Liquidity risk concentrates in Lynx intraday funding and cross-border value dating. Operational risk concentrates in AFT file handling and bill remittance accuracy. Fraud risk concentrates in origination compromise, mandate abuse, impersonation and business-email compromise. Naming each risk with its owner, metric and limit turns this chapter from study material into operating reality.
11. Practical Canadian end-to-end example
Three fictional Canadian stories carry the whole chapter's model. Names, amounts and institutions are invented for training; any resemblance to real persons or clients is coincidental. Work each story by naming the instrument, the clearing, the settlement, the posting and the finality moment before reading the walkthrough.
Story A — payroll by AFT versus a late top-up by wire. Northpine Fabrication, a fictional Ontario manufacturer with 800 employees, runs bi-weekly payroll through its bank's AFT channel. Tuesday: the payroll bureau builds the credit file — 800 beneficiary records with institution, transit, account, amount and a Friday pay date — and uploads it through the bank's file channel. The bank authenticates the bureau, validates structure and hash totals, checks two transposed transit numbers against current routing data and rejects those items back to the bureau with a repair deadline ahead of the release cutoff. Thursday: the cleaned file releases into ACSS AFT exchange; net positions build through the cycle. Friday: positions settle across Bank of Canada accounts and 798 employee accounts post on pay date; the two repaired items ride the next valid cycle. Contrast the same week's executive episode: a missed bonus approval for one vice-president, discovered Friday at 3 p.m., cannot ride any batch and still meet "today." The bank takes a wire instruction with full beneficiary data, dual authorization and a callback to the CFO on a known number, screens and releases it into Lynx, and it settles gross in real time with the Lynx-generated PCRN on the confirmation. AFT is the payroll product and the wire is the emergency product — confusing their cutoffs, costs and finality is how paydays are missed.
Story B — utility collection: PAD pull versus customer bill-pay push. Lakeside Power, a fictional mid-size utility with 40,000 residential accounts, collects on the 15th. Under the PAD model, the utility holds signed agreements, submits a debit file against payer accounts for the billing amounts, sees roughly 39,000 debits pay, 700 return NSF and 300 return for account changes or disputes, re-presents eligible NSF items once within 30 days for the exact same amount, pursues mandate repairs for the rest, and forecasts cash at 97 percent collected within terms. Timing is controlled, returns are predictable, and reconciliation joins presentment references to mandate records to bank return files. The figures are fictional training assumptions, not Canadian market statistics. Under the customer-push alternative the same utility waits for 40,000 individual bill payments — amounts right, dates scattered, references occasionally mistyped — with cash arriving across two weeks and a repair queue of "paid at bank, unapplied at biller" cases. Both families clear through ACSS batch; the economics differ because authority differs.
Story C — the café card purchase: authorized in seconds, funded days later. A fictional Toronto café sells a $6.40 flat white paid by tap with a credit card. Seconds: the terminal routes the authorization through the acquirer and network to the issuer, which approves; the receipt prints; the customer leaves with the coffee. The issuer places a shadow on available credit; no interbank money moves. Overnight: the café's terminal batches the day's approved sales; the acquirer submits clearing records; the network sorts obligations and calculates interchange and fees. Next schedule: interbank settlement between the acquirer and issuer banks discharges the network obligation, and the acquirer funds the café net of fees. Thursday: the customer disputes a duplicate charge from a double-tap; a chargeback debit arrives with a reason code, and the café's representment carries the authorization code and batch record. Contrast with the debit tap beside it: same seconds-long approval, different economics through Interac clearing and settlement arrangements, different fee line, same three-date discipline. The lesson for every new merchant and every new teller: the receipt is an approval, the batch is the claim, the funding run is the cash, and the dispute window is the tail.
12. Key takeaways and authoritative references
Takeaways to carry into every later block. First, name the five events for every payment: instrument, clearing, settlement, posting, finality — and add funds availability and reporting before speaking to a customer. Second, place each family on its rail without hesitation: AFT, PAD, bills, cheques, EDI, POS, government and USBE items through ACSS batch streams; wires through Lynx RTGS; e-Transfer and debit through Interac arrangements; credit through card-network clearing with interbank settlement; cross-border instructions through SWIFT CBPR+ with settlement at each hop's accounts. Third, speak settlement money correctly: Lynx and ACSS positions settle in central-bank money across Bank of Canada accounts; card and Interac interbank obligations settle between banks through their own arrangements; SWIFT settles nothing. Fourth, correct the four misunderstandings every time they appear: an e-Transfer is not the Real-Time Rail; a card authorization is not a payment; a SWIFT message is not settlement; a cheque deposit credit is not final funds. Fifth, quote references exactly — UETR where a cross-border SWIFT payment has one, PCRN for a Lynx-settled wire, batch and item references for AFT, mandate bindings for PAD, confirmation numbers for bills, authorization-to-clearing-to-funding identifiers for cards, image and return reasons for cheques — because investigations run on references, not on recollection. Sixth, promise only the earliest cutoff in the chain and state the evidence each stage produces. Seventh, control before release: authentication, mandate, callback, screening and dual authorization are cheaper than any recovery. Eighth, reconcile instruction to clearing to settlement to posting daily by stream, and staff the unmatched remainder. Ninth, keep the RTR boundary clean — its By-law and Rules came into force 24 August 2026, but the rail is still planned for Q4 2026 launch — and do not cite future rail behaviour for live payments.
Authoritative references (official sources only). Consult the current pages at each site; rule numbers and stream details evolve and the primary source governs.
- Payments Canada — Rules documentation (AFT, PAD Rule H1, bill, cheque, government and USBE stream rules): https://www.payments.ca/systems-services/rules-documentation
- Payments Canada — Lynx high-value system overview and operating information: https://www.payments.ca/systems-services/payment-systems/high-value-payment-system-lynx
- Payments Canada — Automated Clearing Settlement System (ACSS) overview: https://www.payments.ca/systems-services/payment-systems/retail-batch-payment-system
- Payments Canada — Real-Time Rail programme pages (design, By-law and Rules status, initial launch timing): https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- Bank of Canada — Payment systems it oversees (Lynx, ACSS, Interac e-Transfer, IMN, VisaNet and Mastercard GCMS/SMS): https://www.bankofcanada.ca/regulatory-oversight/financial-market-infrastructures/payment-systems-the-bank-of-canada-oversees/
- Bank of Canada — Settlement account policies for Lynx, ACSS and planned RTR: https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/
- Interac Corp — Corporate pages describing e-Transfer and debit network operations: https://www.interac.ca/en/
- Interac Corp — e-Transfer help (notification, Autodeposit, expiry and decline): https://www.interac.ca/en/interac-e-transfer-help/
- SWIFT — CBPR+ and ISO 20022 migration for cross-border messaging (message-versus-settlement distinction): https://www.swift.com/standards/iso-20022
- Justice Canada — Access to Funds Regulations: https://laws-lois.justice.gc.ca/eng/regulations/SOR-2012-24/index.html
- FINTRAC — Electronic funds transfer reporting and travel rule: https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng and https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/travel-acheminement/1-eng
- Visa Canada — Visa rules and VisaNet prominent-payment-system disclosure: https://www.visa.ca/en_CA/support/consumer/visa-rules.html
Where this chapter introduces rule families (F1/F4, H1, H6/H3, A/K/G/E series), pacs.008/pacs.009/pacs.004/camt messaging, UETR/PCRN carriage, and settlement-money characterisation, later blocks provide the field-level and rule-level depth with direct primary-source citations. If any detail here appears to conflict with a current Payments Canada rule, Bank of Canada oversight statement, or network operating regulation, the primary source prevails — raise it through programme feedback so the chapter can be corrected.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.