ACSS Clearing and Exchange Model. Trace payment-item exchange, clearing entries and participant responsibilities across ACSS processing.
Canada Payments & Collections · Block 3: ACSS and Retail Batch Payments · Chapter 12 of 75
This chapter explains how retail batch payments actually move between Canadian banks once customer instructions have left the front door. Chapter 11 introduced ACSS fundamentals — what the Automated Clearing Settlement System is, why batch exists, and where it sits beside Lynx, Interac, cards, USBE and correspondent paths. This chapter goes one level deeper into the working machinery: how payment items are exchanged between members, how validated items become clearing entries, how entries aggregate into participant positions, who is responsible at each handoff, and what evidence must exist so the day can be proved, investigated and reconciled.
The scope set for this chapter is precise: trace payment-item exchange, clearing entries and participant responsibilities across ACSS processing. Settlement lifecycle depth belongs to Chapter 13, which takes positions through funding, default handling and final settlement mechanics. This chapter therefore brings you cleanly to the settlement handoff — a complete, balanced, provable set of positions — and then points forward rather than duplicating Chapter 13.
A note on status dates. Baseline is 5 October 2026. The Automated Clearing Settlement System (ACSS) is the live retail batch system operated by Payments Canada. It is a deferred-net system: Payments Canada says the previous day's net balances settle during the morning of each business day on the books of the Bank of Canada. Lynx has been live since 1 September 2021 and is the high-value real-time gross settlement system; ACSS settlement uses the mechanisms and settlement accounts specified by the current ACSS framework. The Real-Time Rail (RTR) is not treated as production here: Payments Canada's current page says it is launching in Q4 2026 and reports participant solution-assurance testing, while the RTR By-law is already in force. Whenever this chapter says planned for RTR, that distinction is intentional: legal readiness and participant testing do not prove a production launch. No exact cutoff times are stated in this chapter; banks publish their own schedules against the payments.ca business-day and closure calendar, and this chapter speaks only in relative terms such as morning exchange, afternoon windows, initial and final adjustment periods.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain in plain language the difference between a payment item, an exchange event, a clearing entry and a settlement position — and why confusing them causes operating errors;
- describe how intermember exchange works, including exchange at regional exchange points under the Rule B1 family, and what changes when exchange is electronic rather than paper-based;
- map the stream families at family level — paper and government categories, E1–E5 POS/online/EDI items, F AFT, H PAD and bill/remittance items, J contingency or interest processes, and K U.S.-dollar items — and explain what the stream or rule tells an operations analyst about handling, returns and evidence;
- trace the clearing-entry lifecycle from validated item through logging, aggregation, adjustment and final position;
- distinguish direct clearers from indirect clearers and clearing agents, and state who owns exchange, entries, funding, customer service and evidence in each model;
- describe bank-side initiation, validation and processing controls that must pass before anything is exchanged;
- explain what data, identifiers, messages and references travel with batch items and where ISO 20022 coexists with legacy AFT formats;
- explain rules, business-day calendars, relative cutoff windows and service levels and their customer impact without inventing exact times or rule text;
- place fraud, FINTRAC, sanctions and operational controls at the correct point — before release, at clearing, and after posting;
- classify rejects, returns, redirects, reversals, adjustments and investigations, and describe recovery that preserves original transaction identity;
- explain posting, accounting, liquidity, reporting and three-way reconciliation for batch from a bank operations view;
- describe how a bank implements, tests and hardens its exchange and clearing connections, including contingency and manual procedures;
- work through fictional Canadian examples — a payroll batch, a cheque-image day, and a PAD collection with a return — and extract the control lesson from each;
- state what belongs in Chapter 13 on settlement lifecycle and navigate confidently to Blocks 4, 5, 10, 11 and 14 for rail-level depth.
For a roughly 60-minute core session, spend about 10 minutes on this introduction with Sections 1–2 and the exchange-to-clearing diagram, 15 minutes on Sections 3–4 with the clearing-entry lifecycle diagram, 10 minutes on Sections 5–6 with the stream-families map and the direct-versus-indirect diagram, 10 minutes on Sections 7–9 with the evidence-chain diagram, 10 minutes on the fictional examples in Section 11, and 5 minutes on takeaways and the forward map in Section 12. Treat these timings as a study guide. The remaining depth, cases and reference material are follow-up study; completing the whole chapter carefully takes longer.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and system boundaries
- Initiation, validation and bank processing
- Clearing, 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 examples
- Key takeaways and authoritative references
1. Business context and customer need
Every retail batch day in Canada begins with ordinary customer promises that sound simple and turn out to be operationally demanding. A payroll manager promises four hundred employees that pay will be in accounts on Friday morning. A municipality promises benefit recipients that deposits will arrive on schedule. A supplier that collects by pre-authorized debit promises its customers that only the authorized amount will be drawn on the agreed date. A small business that still writes cheques assumes the payee can deposit the cheque and see funds on a predictable timetable. A property manager collecting rents by automated transfer assumes the file sent tonight becomes collected value on the expected day with a clean report for the few items that did not collect. None of these customers thinks about exchange points, clearing logs or net positions. They think about timing, certainty, information and what happens when something goes wrong.
The bank sits between that customer promise and the interbank machinery. Its job is to translate each business event into the correct batch stream, validate it, exchange it with the right counterpart, clear it into accountable entries, fund the resulting position, post it to the right accounts, report it intelligibly, and preserve the evidence to fix the exceptions. When the bank does this well, batch looks boring: files go in, money appears where expected, exceptions are few and explainable, reconciliation closes. When the bank does it poorly, the same batch day produces the most expensive kind of failure — widespread, customer-visible, and labour-intensive to repair. A corrupted payroll file, a duplicated AFT batch, a misrouted bill-payment file, or a misunderstood return timetable does not affect one payment. It affects hundreds or thousands at once.
That is why the exchange-and-clearing model matters to bankers, analysts, product owners and operations staff alike, not only to back-office specialists. The product owner who designs a payroll upload screen is deciding how many validation errors will reach exchange. The analyst who maps remittance fields is deciding whether bill payments can be applied without manual repair. The branch advisor who accepts a large cheque deposit is setting expectations about image exchange, holds and return rights that the customer will hold the bank to days later. The operations manager who staffs the morning exchange window is deciding whether the bank meets its intermember obligations or carries items forward. The finance manager who forecasts funding is depending on positions that are complete and timely. The auditor who asks for the trail from a customer credit back to an exchanged item is testing whether the model in this chapter was actually implemented.
Consider the scale that makes discipline non-negotiable. Payments Canada's 2025 ACSS statistics report 10.607 billion items worth $10.009 trillion. The statistics page notes that direct clearers enter the reported volumes and values, and that the totals cover items exchanged between directly clearing financial institutions. The batch world therefore carries the country's item count and a large customer-experience surface. Payroll, pre-authorized debits, government deposits, bill payments, cheques and automated transfers all pass through the exchange-and-clearing path described here. Lynx, by contrast, carries far fewer payments at far higher average value. That contrast explains the different operational anxieties: a Lynx failure threatens value concentration and same-day finality for individual payments, while an ACSS exchange failure threatens breadth — thousands of customers noticing at once. Both matter. This chapter keeps you in the breadth world and teaches you to run it with the same seriousness as the value world.
Three structural facts shape everything that follows. First, exchange and clearing are distinct from settlement. Exchange moves items and their data between members. Clearing converts validated items into debit and credit entries, recorded in logs and aggregated into positions. Settlement moves value for those net positions across settlement accounts. This chapter covers the first two thoroughly and hands clean positions to Chapter 13 for the third. Second, paper handling and electronic handling differ end to end — in how items are presented, how images substitute for physical movement, how validation works, how quickly returns can come back, and what evidence is kept. The stream family tells you which handling logic applies. Third, responsibility follows participation, not size. A small indirect clearer and a large direct clearer both owe their customers validated instructions, timely exchange through proper channels, accurate entries, funded positions via their settlement path, intelligible reporting and retrievable evidence. The difference is through whom they exchange and settle, not whether they are accountable.
A final framing point before the detail. Batch is deferred by design. Customers often hear deferred and assume slow or inferior. For the banker, deferred means something more precise: items are grouped, exchanged and netted over defined windows, with defined return rights and defined evidence, so that enormous volumes can move at controlled cost with predictable funding. Same-day finality for an urgent supplier payment is what Lynx exists for. Predictable, low-cost, information-rich collection and disbursement at scale is what ACSS batch exists for. The skill is not preferring one over the other in the abstract. It is placing each business event on the rail whose finality, timing, data and return bargain matches the commercial need — and then operating the batch path so the deferred promise is actually kept.
2. Participants, responsibilities and system boundaries
The exchange-and-clearing model involves a small cast with sharply defined responsibilities. Learning who owns what — and where one party's responsibility stops and the next begins — prevents the most common operating confusion: everyone assuming someone else validated, funded, or evidenced the item.
Start with the customer and the originator. The customer — an employer, a biller, a government department, a business collecting by debit, a consumer writing a cheque — creates the underlying business instruction. The bank's customer-facing channels capture that instruction as a file, an image, a payment order or a deposit. The customer owns the commercial truth: whom to pay or collect from, how much, on what date, with what reference, under what authorization. The bank owns everything from validation onward. A frequent failure is treating customer data as already clean. It is not. Names, account numbers, amounts, dates, mandate references and remittance details arrive with errors, duplicates, stale mandates and misunderstood cutoffs. The boundary is clear: the customer asserts intent, the bank proves it is executable before exchanging anything.
The originating bank — sometimes called the sending or delivering institution in operations language — validates the instruction, checks authority and funding, screens for fraud and sanctions, applies the correct stream logic, and presents the item into exchange through its proper channel. The receiving bank — the institution holding the beneficiary or payor account on the other side — receives the exchanged item, validates reachability and account standing, posts or collects accordingly within its return rights, and handles returns, redirects and disputes on its side. Both sides keep evidence. Neither side may assume the other performed its checks. An originating bank that sends an unauthorized debit has created a return and possibly a dispute. A receiving bank that posts without checking account status has created a repair. Exchange does not transfer responsibility for validation; it tests whether each side did its job.
Direct clearers (the formal ACSS term) exchange payment items and make entries into the ACSS on their own behalf. They present and receive at regional exchange points and through electronic feeds, maintain bank-side clearing records, aggregate into clearing balances, and settle through their Bank of Canada settlement account. Direct status is an operating capability and obligation: staffed windows, tested connectivity, balanced logs, funded positions, managed returns and retrievable archives. Indirect clearers participate through a clearing agent — a direct clearer or group clearer appointed to exchange items and effect clearing and settlement or make entries for the indirect clearer. Rule D2 requires the clearing agent to hold and operate a settlement account for each indirect clearer. The indirect clearer keeps customer accountability: mandates, service, customer reporting, authorization evidence and first-line investigation remain with the customer's bank. The agent does not become the customer's bank. The clearing arrangement therefore matters enormously: it allocates funding, cutoffs, fees, return handling, failure and communication duties that customers never see but always feel when something goes wrong.
Payments Canada operates the ACSS as the retail batch system — maintaining the infrastructure, by-laws, rules, standards and procedures under which exchange and clearing occur. It is not a counterparty to customer payments and does not validate commercial truth. Its role is to provide the rail, rulebook, clearing calculation and position reporting. The Bank of Canada provides settlement accounts and final settlement occurs on its books; it also oversees designated systems from a financial-stability perspective. In ACSS terminology, the clearing agent is the direct clearer or group clearer acting for an indirect clearer. Correspondents, agents and service providers appear wherever a bank outsources connectivity, image handling, file processing or archive — but outsourcing never outsources accountability. If a vendor corrupts a file, the bank still owns the exchange outcome.
Three boundaries deserve to be drawn explicitly because analysts and product owners cross them without noticing. First, the customer-bank boundary: everything the customer asserts must be validated before exchange, and everything the bank promises about timing must be expressed in the rail's relative windows, not in channel optimism. Second, the bank-agent boundary for indirects: funding, cutoffs, return handling and failure communication must be written, tested and rehearsed, not discovered during an incident. Third, the clearing-settlement boundary: clearing produces accountable net positions; settlement moves value for those positions. Teams that blur this boundary misdiagnose problems — treating a settlement funding shortfall as a clearing error, or treating a clearing-log imbalance as a settlement-system outage. Chapter 13 will deepen the settlement side; this chapter keeps the clearing side clean so that handoff is meaningful.
A practical test for whether responsibilities are clear in your bank: pick any batch item and ask five questions. Who validated authority and data before exchange? Through whom was it exchanged and in which stream? Which clearing entry records it and in whose log? Through whose position does it settle? Where is the end-to-end evidence linked and retrievable? If any question has two answers or no owner, the responsibility model needs repair before volume or modernization tests it.
3. Initiation, validation and bank processing
Nothing should reach intermember exchange unexamined. Initiation, validation and bank processing are where the bank earns the right to exchange — and where most batch exceptions are either prevented cheaply or created expensively.
Initiation takes many shapes. An employer uploads a payroll file through a business portal or host-to-host channel. A corporate treasury system sends an AFT credit file for supplier payments. A biller sends a PAD file to collect monthly invoices. A consumer deposits a cheque at a branch, ATM or mobile app, creating an image and data record. A government department sends a benefit file. A small business keys a handful of transfers into online banking. Different channels, same obligation: capture the instruction completely, authenticate the originator, timestamp receipt against the bank's published schedule, and preserve the source exactly as received. Source preservation matters because investigations and disputes always return to what the customer actually sent, not what downstream systems inferred.
Validation then applies in layers, and the order matters. Format validation asks whether the file and its items are structurally sound: correct record layouts, valid characters, sensible amounts and dates, required fields present, batch totals that foot to item detail. Reachability validation asks whether each item can actually be routed: valid institution and transit detail where required, reachable beneficiary or payor institution, eligible stream for the item type. Authority validation asks whether the bank is entitled to move the money: a signed or consented mandate for a debit, a valid delegation for a file submitter, signing authorities for a corporate batch, endorsement logic for a paper item. Funding and limit validation asks whether the originator can cover the batch and whether per-item and per-batch limits, velocity checks and purpose controls are satisfied. Duplicate validation asks whether this batch, or items within it, have been seen before — the cheapest control against the most embarrassing failure, the double payroll. Sanctions, fraud and amplifying-risk screening runs before release, not after exchange, because post-exchange screening is recovery rather than prevention. Each layer that fails should reject or hold with a specific, actionable reason, not a generic failure code that forces the customer to guess.
Bank processing converts validated instructions into exchange-ready items. This includes stream assignment — placing each item in the correct family and processing path based on instrument, direction, currency and eligibility. It includes value-date and window assignment — deciding which exchange window and which business day each item belongs to, given receipt time, the bank's published schedule, and the payments.ca closure calendar. It includes aggregation into batches and cash letters or electronic equivalents — grouping items for efficient exchange with balanced totals. It includes image handling for paper-origin items — capturing, quality-checking and retaining images so that physical movement is minimized while legal and operational equivalence is preserved at family level here, with full image-clearing detail in Block 10. It includes authorization to release — the human or system approval that confirms all prior layers passed and accepts accountability for exchange. Release is a decision, not a default. Banks that treat release as automatic discover that their controls were advisory rather than gating.
Paper-origin and electronic-origin processing diverge in ways operations staff feel daily. Paper-origin items require image quality, MICR-line readability, endorsement handling, and decisions about what travels — image and data rather than physical paper in modern practice — plus longer-tailed return awareness because the underlying instrument carries its own dispute characteristics. Electronic-origin items require file integrity, field-level data quality, mandate linkage for debits, and remittance completeness for credits, with faster machine validation but larger blast radius when a file-level error slips through. Both paths converge at the same exchange discipline: only validated, authorized, correctly streamed items are presented, with balanced totals and retrievable source.
Two operating habits separate strong banks from fragile ones. First, they validate early and specifically, pushing clear repair guidance back to the originator while there is still time to fix and resubmit in-window. A payroll file that fails at 9 a.m. with item-level reasons can be repaired. The same file failing silently until after the window becomes a customer incident. Second, they separate duties and preserve evidence at release: who submitted, who approved, what was checked, what was overridden and why, and where the source and validation record live. That record is what makes the evidence chain in Section 7 and the audit view in the diagrams real rather than aspirational.
Product owners and analysts should note where design decisions become operations outcomes. A file-upload screen that enforces field formats, warns on duplicate file hashes, surfaces value-date consequences in plain language, and confirms the release window prevents more exceptions than any downstream repair queue. A mobile cheque-deposit flow that guides image capture, confirms amount entry, and sets hold and availability expectations honestly prevents more disputes than any call-centre script. Initiation design is exchange design, one step removed.
4. Clearing, exchange, settlement and finality
With validated items in hand, the bank enters the three-stage sequence that this chapter exists to make unmistakable: exchange, clearing, settlement. Each stage has its own actors, records, timing and finality meaning. Collapsing them into one word — clearing as a synonym for everything — is the root of half the misunderstandings in batch payments.
Exchange is the intermember movement of payment items and their data. In functional terms, the originating side presents items and the receiving side receives them, directly or through agents, across the channels the system provides — including presentation at regional exchange points under the Rule B1 family alongside electronic exchange feeds. Regional exchange points are best understood functionally rather than geographically memorized: they are the defined places and procedures where members meet — physically for residual paper needs and logically for electronic flows — to present, receive, log and confirm what changed hands. The Rule B1 family governs that meeting: what is presented, how logs accompany items, how receipt is acknowledged, how timing windows apply, and how contingency is handled when normal exchange is interrupted. Paper and electronic exchange differ in medium but share the same accountability: what was sent, what was received, when, between whom, and with what totals. A clean exchange ends with both sides agreeing on what moved. An unclean exchange — missing items, unbalanced totals, late presentation — is detected here, not three days later in reconciliation.
Clearing is the reconciliation of exchanged payment items and the calculation of clearing balances. At bank level, each item remains linked to a clearing record; the ACSS receives the applicable entries, volumes and values through the prescribed logs and calculates the balances. Computer-generated logs are the norm; manually prepared logs and online update of manual data exist for contingency and manual-balancing situations covered functionally in Section 10. Entries aggregate by stream and direct clearer into clearing balances. Aggregation is where the stream and rule families from Section 5 earn their keep — paper and electronic totals remain distinguishable so that handling, returns and evidence follow the correct path. Adjustments for returns, redirects, errors and disputes adjust entries with linkage to originals rather than overwriting history. Clearing ends with balanced, agreed balances ready for settlement. Chapter 13 takes those balances through funding, settlement mechanics, default handling and the precise meaning of final settlement; this chapter's responsibility is to deliver positions that are complete, balanced and provable.
Settlement, summarized here and deepened in Chapter 13, is the movement of value for net positions across settlement accounts at the Bank of Canada. It is deferred relative to exchange and clearing — positions accumulate over the cycle and settle on the system's timetable, not item by item as customers experience their postings. Finality in batch therefore has a layered meaning that bankers must explain honestly. Customer posting is not settlement. Exchange is not settlement. A balanced clearing position is not settled value. Settled means the position has moved across settlement accounts under the system's rules with the protections those rules provide, subject to the return and adjustment rights that batch instruments carry on their own timetables. A cheque credit subject to return, a PAD subject to dispute rights, and an AFT credit to a closed account each have different post-settlement lives even though all three passed through the same clearing calculation. Promise finality only in the sense the rail supports, and always separate the settlement event from the customer-availability event.
The lifecycle diagram above gives analysts a single mental model to carry into every investigation: item to exchange to entry to log to aggregation to adjustment to position to settlement handoff. When something goes wrong, locate the stage first. Missing items point to exchange. Wrong amounts or missing entries point to clearing. Unfunded or unsettled value points to settlement. Posted-but-unexpected customer balances point to posting and return handling. Stage-first diagnosis is faster and kinder to customers than re-sending, re-posting or re-assuring without evidence.
Two forward pointers keep this chapter in its lane. First, for the full settlement lifecycle — cycle definition, initial and final adjustment concepts, funding, settlement-agent mechanics, failure and default handling, and the exact handoff from positions to settled value — study Chapter 13 next. This chapter summarizes; Chapter 13 owns. Second, for stream-level processing depth — AFT credits and payroll in Block 4, PAD mandate-to-cash in Block 5, bill and cheque image detail in Block 10, USBE dollar handling in Block 11 — follow the stream family, not the urge to cover everything here. This chapter maps the families; those blocks operate them.
5. Data, identifiers, messages and references
Batch moves data as much as it moves value. The quality of that data decides whether items clear straight through, whether beneficiaries can apply credits, whether debits can be defended, and whether investigations close in minutes or weeks.
At the item level, every exchanged item carries the functional essentials: who sends, who receives, how much, in what currency, for what value date, in which stream, with what references, and under what authority where authority is required. Institution and account identification routes the item; stream identification determines handling; amount and value-date determine the position effect; references determine reconcilability. References deserve special attention because they are the cheapest source of straight-through success and the most common source of manual repair. A supplier credit without an invoice reference becomes a research project in accounts receivable. A bill payment without correct creditor and account detail becomes an unapplied suspense item. A PAD without mandate reference becomes indefensible on dispute. Design references as if the beneficiary's reconciliation clerk is the real customer — because functionally, they are.
File and batch references provide the second layer. AFT, EDI, bill-payment and government formats have stream-specific fields and control totals; the bank must preserve the identifiers and control data required by the applicable rule, standard or bilateral interface rather than assuming one universal schema. This lets the receiving side validate completeness and detect duplication or truncation. Clearing logs add the third layer: the system's record of what was claimed by whom, in which stream, for which cycle. Position reports add the fourth: the netted outcome per participant. Settlement confirmations add the fifth: proof that positions settled. Customer statements and advices add the sixth: what the customer sees. The evidence-chain diagram in Section 7 shows how these layers link. The design principle is uniform: every downstream record must reference its upstream source, so any entry can be walked backward to the exchanged item and forward to the customer posting.
Legacy and ISO 20022 coexistence shapes bank implementation throughout this chapter's horizon. Payments Canada maintains legacy AFT rules and a separate ISO 20022 AFT onboarding path; Rule F4 and the AFT ISO guidance cover registration, testing and implementation, including payment-return and reversal messages. Banks therefore map legacy batch fields and ISO-structured data, preserve references across the mapping, validate that truncation or padding does not destroy reconcilability, and test that what the originator sent is what the beneficiary can use. Mapping risk is a data-quality risk, not merely an IT conversion task. A reference that survives transport but loses meaning on mapping has still failed the customer.
Paper-origin data carries its own considerations. The MICR line, amount entry, payee, date, signature and endorsement logic, plus image quality and image-reference linkage, form the data set that lets an imaged cheque clear without physical movement. This chapter stays at family level: images and data substitute for paper movement under defined handling, with return and dispute characteristics that differ from electronic debits and credits. Full image-clearing mechanics — capture standards, quality, holds, returns, and duplicate-presentment controls — live in Block 10. The point here is architectural: paper-origin data must be captured, linked and retained with the same retrievability as electronic files, because investigations do not accept the excuse that the paper is elsewhere.
Government, EDI, POS, bill and USD families each add data nuances at family level. Government flows emphasize schedule discipline and program identification. EDI emphasizes inter-company remittance detail and reconciliation automation. POS emphasizes authorization linkage even though the batch leg clears later. Bill flows emphasize creditor identification and account-detail accuracy. USD batch items emphasize currency, eligibility and the distinct dollar-settlement path detailed in Block 11. Product owners should treat each family's data profile as a design input: the fields the bank demands at initiation should mirror the fields the stream needs for straight-through clearing and the fields the beneficiary needs for application. For Interac Debit and shared-ABM items, keep the network layer distinct from ACSS: Interac describes direct and indirect connectors, issuers, acquirers and settlement agents on the Inter-Member Network, while ACSS is the clearing and settlement system used for the applicable obligations. Authorization, network routing and ACSS batch settlement are related but not the same event.
A closing data discipline for analysts: never invent identifiers, never reuse references across unrelated items, never truncate without confirming downstream impact, and never treat a customer memo field as a substitute for a structured reference the stream requires. Data that cannot be matched cannot be reconciled, and unmatched batch value always becomes someone's manual queue.
6. Rules, cutoffs, service levels and customer impact
Rules, calendars, windows and service levels turn the functional model into daily commitments. This section explains how they work functionally without quoting rule text or stating exact times — both of which belong to the current official publications and each bank's schedules, not to a course chapter.
The rulebook is layered. The Canadian Payments Act establishes Payments Canada and the framework within which systems operate. Association by-laws — notably By-law No. 3 governing payment items and ACSS — set system-level obligations. The current ACSS rule centre includes A rules for acceptable/returned items and images; B rules for regional exchange, logs, balancing and errors; D rules for direct, group, clearing-agent and indirect-clearer arrangements; E1–E5 rules for POS, online, EDI and related electronic items; F rules for AFT and ISO AFT; G rules for government items; H rules for PADs, bill payments and other specialized items; J rules for force majeure and interest claims; and K rules for U.S.-dollar batch. Standards and procedure documents complete the picture with operational detail. Standards, procedure documents and service-level descriptions complete the picture with operational detail. Nothing in this chapter paraphrases binding language. For binding obligations, consult the current Rules Centre publications and your bank's compliance guidance. The functional reading is sufficient for bankers, analysts, product owners and operations staff to do their jobs: each family tells you what may be exchanged, how it must be presented and logged, what timing applies, what returns are available, and what evidence is required.
Business-day calendars drive everything. ACSS operates on business days defined by the system calendar, excluding weekends and defined holidays, with a published closure schedule. Items received on a closure day belong to the next business day's processing. Value dates, return clocks and customer-availability promises all key off the business-day calendar, not the channel calendar. A file uploaded on a Friday evening, a cheque deposited on a holiday Monday, and an Interac refund sent on a Sunday each have different relationships to the batch business day — and the bank must translate honestly rather than letting channel immediacy imply batch immediacy. Operations staff live by the closure calendar; customer-facing staff must be able to explain it without jargon.
Cutoffs and windows are best understood as a daily rhythm rather than a list of times. Exchange windows admit items for the cycle. Validation and release gates close progressively as windows approach. Clearing calculation aggregates what was accepted. Adjustment periods admit corrections and defined returns. Final locking produces positions for settlement handoff. Late items carry forward rather than forcing the day open. Contingency and manual-balancing procedures exist for days when normal rhythms break, and they are rehearsed rather than improvised. Because exact times vary by stream, participant type and bank schedule — and because they change — this chapter speaks only relatively: morning versus afternoon presentation, in-window versus late, initial versus final adjustment. For the binding time on any given day, use your bank's published operations schedule with the payments.ca closure calendar. Any training material, customer promise or product copy that hard-codes a clock time without citing the current schedule is already out of date.
Service levels and customer impact follow directly. Payroll credits promise morning availability on payday because the file was validated, released, exchanged and cleared on the prior business day's rhythm — not because batch is instant. PAD collections promise predictable debit dates because mandates were verified and files released in-window, with return rights disclosed rather than hidden. Cheque deposits promise availability on a hold-aware timetable because image exchange plus return rights require it. Bill payments promise application within the biller's cycle because creditor detail was correct and the file met the window. Government deposits follow program schedules. USD batch items follow their eligibility and dollar-path timing. In each case the service level is a chain: customer instruction plus bank validation plus exchange window plus clearing plus posting plus return awareness. Break any link and the promise fails even though every other link held.
Three practical habits make rules and windows livable. First, publish and teach relative cutoffs in customer language — what must arrive by when for which value date — with pointers to the authoritative schedule rather than copied times. Second, staff and system-gate progressively: nudge originators before windows, hard-stop invalid items at validation, and never let commercial pressure re-open a locked position without defined carry-forward handling. Third, monitor window adherence as a service metric, not merely an operations statistic: the share of files validated first time, the share exchanged in-window, the share requiring adjustment, and the reasons for each. Those metrics are where product design, customer education and operations staffing meet.
7. Fraud, compliance and operational controls
Controls in batch must be placed where they can still change the outcome. Prevention lives before release. Detection lives at clearing and posting. Recovery lives after settlement with beneficiary cooperation. A control in the wrong position is not merely late; it converts a preventable reject into an expensive investigation.
Fraud controls start with initiation integrity. Authenticate the originator and the submitter. Verify mandates for debits and delegations for files. Check payee and amount plausibility against history and purpose. Screen for duplicate files and anomalous batches — the sudden payroll twice the size, the new supplier file paid outside pattern, the PAD file from a dormant originator. Image-origin flows add duplicate-presentment detection across channels: the same cheque deposited by mobile and ATM, or a cheque image re-presented after a prior return. Electronic flows add file-integrity and tampering checks. None of these controls requires inventing typologies; they require applying the bank's fraud standards to batch with stream awareness. Paper-origin and electronic-origin frauds differ in technique but share the same gate: nothing exchanges without passing.
Compliance controls run in parallel. Sanctions and watchlist screening gates release, using complete payment data and maintained lists, so that a prohibited or high-risk item is stopped before exchange rather than chased afterward. FINTRAC obligations are activity- and entity-specific. For example, financial entities must report an international electronic funds transfer of $10,000 or more at initiation and at final receipt, subject to the applicable regulations and exceptions; required records and client-identification controls must remain retrievable. Do not turn that international-EFT rule into a claim that every domestic ACSS item automatically generates a FINTRAC EFT report. The evidence chain is nevertheless a compliance asset rather than an archival nicety. RPAA supervision context matters for product owners planning broader participation: as eligibility and access evolve, the same control order — validate, screen, approve, release, evidence — applies to new participants and paths. Cross-border and USD batch items add travel-rule and correspondent-standard data completeness, detailed in Block 11. The principle is uniform: incomplete payment data is itself a compliance finding, not merely an operations inconvenience.
Operational controls protect the clearing record. Balanced exchange — items foot to totals, logs match claims — is verified at presentation and receipt. Stream assignment is verified so that paper handling, electronic handling, government handling and dollar handling do not mix. Duplicate detection runs at file, batch and item levels. Release authority is enforced with separation of duties and override logging. Clearing-log integrity is protected from creation through aggregation to position reporting, with access controls and change records. Position readiness is confirmed — complete, balanced, reconcilable — before handoff to settlement. Each control produces evidence that the evidence-chain diagram expects: who checked, what passed, what failed, and where the record lives.
The evidence chain deserves emphasis because auditors, supervisors and customers all test it. From instruction through exchange log, clearing entry, position report, settlement confirmation and customer posting, every downstream record must point back upstream with retrievable identifiers. Authorizations, images, files, logs, reports and confirmations must be retained and retrievable by item, batch, stream, date and participant for returns, disputes, audits and supervision. Retention is not storage alone; it is indexed, access-controlled, tested retrieval. Banks that test retrieval quarterly experience audits as confirmation. Banks that discover retrieval gaps during an incident experience audits as findings.
A final control note for product owners: channel promises are controls. A screen that implies immediate finality for a batch item, a confirmation that omits return rights, or a cutoff display that ignores holidays creates the very disputes the control plane must then resolve. Honest, relative, schedule-linked customer language is a first-line control.
8. Exceptions, investigations and recovery
Batch exceptions are normal. Returns, rejects, redirects, reversals, adjustments and disputes are designed into the system because batch instruments carry different authority and timing bargains. The operational goal is not zero exceptions — it is fast, accurate, customer-intelligible handling that preserves original identity and never creates a second problem while fixing the first.
Start with vocabulary discipline, because misnamed exceptions are mishandled. A reject stops an item before exchange — invalid format, unreachable destination, failed validation, duplicate file. A return sends an exchanged item back under defined rights — insufficient funds, closed account, unauthorized or disputed debit, stopped cheque, unapplied bill detail. A redirect forwards an item to the correct institution or account under defined handling rather than returning it outright. A reversal or correction creates a linked offsetting entry that neutralizes the economic effect of an original entry while preserving both records. An adjustment corrects clearing totals with linkage to the original entries. A dispute or claim asserts that an item should not stand — unauthorized debit, duplicate presentment, misapplied payment — and triggers evidence gathering under the applicable family. An investigation is the process of locating the item across the evidence chain and determining the correct recovery. Each category has its own clock, evidence standard and customer communication. Treating a return as a reject, or a dispute as a simple reversal, misroutes the work and misleads the customer.
Investigations follow the evidence chain in either direction. From a customer query — missing payroll credit, unexpected debit, unapplied bill payment, stale cheque credit — operations locates the customer posting, walks back to the clearing entry and stream, checks the exchange log and source file or image, verifies validation and release records, confirms position and settlement-handoff status, and determines whether the item never exchanged, exchanged but returned, exchanged and adjusted, or exchanged and posted elsewhere. From a rail signal — an unbalanced log, a returned file, a counterpart query — operations walks forward to affected customers and postings. In both directions the questions are the same: what was exchanged, what was logged, what changed, by whom, and what is the linked recovery? Recovery always preserves original identity: corrections and reversals reference originals; re-presentment respects authority and return clocks; new payments to make a beneficiary whole are linked to the original failure rather than disguised as fresh value. Duplicated recovery — returning and reversing the same item, or re-sending while an investigation is open — is the classic self-inflicted second incident. When in doubt, investigate before re-sending.
Paper and electronic exceptions differ in rhythm. Electronic batch exceptions — file rejects, AFT returns, PAD disputes, bill-application failures — arrive as structured records that operations can automate, categorize and report at scale, but they arrive in volume when a file-level cause is shared. Paper-origin exceptions — image-quality rejects, duplicate presentment, stopped or stale cheques, endorsement issues — arrive individually with image and instrument evidence that must be reviewed case by case, and their return tails require hold-aware customer communication. Government and USD batch exceptions follow their program and dollar-path handling. In every family, the customer communication standard is the same: what happened, in plain language; what it means for value and timing; what the customer should and should not do next; and when the bank will update again. A return notice that explains nothing creates a call. A call that explains without evidence creates a complaint. Evidence-linked explanation closes the loop.
Aging and ownership complete the discipline. Every exception gets an owner, a next action and a due date derived from the applicable clock. Unowned breaks age into write-offs, compensation claims and supervisory findings. Daily exception huddles review new breaks, aged breaks, pattern breaks suggesting file-level or fraud causes, and customer-impacting breaks requiring proactive outreach. Metrics track reject rates by cause, return rates by stream, dispute outcomes, recovery times and repeat causes feeding back to validation and customer education. That feedback loop — exceptions teaching initiation to prevent recurrence — is what makes Section 8 and Section 3 one system rather than two departments.
9. Posting, accounting, liquidity, reporting and reconciliation
Posting, accounting, liquidity, reporting and reconciliation prove that the day's exchange and clearing actually happened correctly in money, books, funding and customer understanding. Teams that treat these as afterthoughts discover that customers, finance and auditors disagree.
Posting translates clearing outcomes into account balances. Customer credits — payroll deposits, supplier payments received, government benefits, bill-payment credits to billers — post with value-date and availability logic that reflects the stream's return characteristics, not merely the clearing calculation. Customer debits — PAD collections, bill-payment debits, cheque debits — post with mandate, hold and return awareness. Internal suspense and clearing accounts hold in-transit and unapplied value with daily proof and clearance discipline; unapplied bill payments, unmatched remittances and image-exception holds must never become permanent residents. Posting rules must separate the clearing event from the availability event in customer communication: a credit can be posted yet still subject to return, and the bank must say so where the stream requires it. Posting without linkage to clearing entries creates unauditable balances. Every posting references its clearing source.
Accounting records the same day in the general ledger with stream-aware granularity. Batch debits and credits, fee income, intermember clearing balances, settlement-account movements, suspense positions and adjustment entries each post to owned accounts with daily proof. Error handling follows the same linkage rule as operations: corrections are new entries referencing originals, never overwrites. Period-end close then becomes a review of an already-proved daily record rather than a reconstruction. Finance and operations share one vocabulary: stream, cycle, business day, position, adjustment, return. When finance and operations use different day definitions or different stream groupings, reconciliation breaks that are really taxonomy breaks consume weeks.
Liquidity in batch is forecasting and funding discipline for deferred net positions. Even though batch settles net rather than item by item, the resulting funding requirement is real and must be met through the bank's settlement path — directly across Bank of Canada accounts for direct clearers or through agency arrangements for indirects. Treasury needs timely, complete position forecasts by cycle, visibility of late adjustments and carry-forwards, and honest communication when exchange or clearing delays shift funding between days. Intraday surprises in batch usually originate upstream: a large file released late, a counterpart's delayed exchange, a contingency day's manual balancing. Liquidity management therefore starts with window discipline and position-report timeliness, not with treasury heroics at day-end. Chapter 13 will deepen funding, collateral where relevant, and default handling; this chapter's contribution is clean, timely positions that treasury can actually fund.
Reporting gives customers and internal users an intelligible account of the day. Originators need file-acceptance confirmations, item-level status, return notifications with actionable reasons, and collection reports that map to their receivables. Beneficiaries need credits with references they can apply. Billers need application-ready remittance detail. Government clients need program-schedule reporting. Operations and treasury need window-adherence, position and funding reports. Management needs exception, aging and repeat-cause trends. Good batch reporting shares three traits: it is timely enough to act on, it carries references that match the customer's system, and it explains what needs doing next. A return report without a reason code the customer can act on is merely bad news delivered efficiently.
Reconciliation closes the day with three-way proof: customer instructions versus rail evidence versus postings. What the bank accepted from originators must match what was exchanged and logged. What was exchanged and logged must match what aggregated into positions. What aggregated into positions must match what was handed to settlement and what posted to customers and ledgers. Breaks are owned, aged and investigated through the evidence chain, never left idle. Volume and value need different rhythms under one standard: high-volume AFT and bill flows reconcile by automated matching with exception queues, while paper-origin and high-risk items get closer human review. Merchant, remittance and nostro-style matching for dollar legs complement the core three-way proof. The reconciliation that matters is daily, owned and evidenced — not month-end, diffuse and narrative.
10. Bank implementation, testing and resilience
Implementing exchange-and-clearing capability is a systems, operations and governance project — not merely a connectivity purchase. Banks that treat it as plumbing defer the controls, evidence and resilience work that determines whether batch survives its first bad day.
Architecture starts with the payment hub. Channels — branches, business portals, host-to-host, mobile, government interfaces — feed a hub that validates, screens, approves, releases, streams, batches and tracks. The hub connects to exchange gateways for electronic feeds and regional-point procedures, to image systems for paper-origin flows, to clearing-log and position-reporting services, to settlement-path interfaces, to posting and ledger services, to reporting and archive, and to fraud, sanctions and case-management tooling. Each connection needs defined data contracts, timeout and retry behaviour, duplicate protection, and evidence capture. Coexistence mapping between legacy AFT fields and ISO-structured data lives in the hub with version-controlled rules and regression tests, because mapping changes are a leading cause of silent reconciliation breaks. Vendor and agent connections get the same rigour as owned systems: the bank owns the outcome regardless of who operates the pipe.
Testing must prove the model before volume does. Functional testing covers stream assignment, validation layers, window and value-date logic, exchange presentation and receipt, log balancing, aggregation, adjustment handling, position reporting, posting linkage and customer reporting — for each stream family the bank uses. Negative testing covers the failures that matter: corrupted files, duplicate files, unreachable destinations, unauthorized debits, closed accounts, unbalanced totals, late presentation, image-quality failures, duplicate presentment, mapping truncation, and counterpart returns. Intermember and end-to-end testing with agents and counterparts proves that what the bank sends is what the system and receivers accept. Cutoff and calendar testing proves that holidays, late files and carry-forward behave as designed. Evidence and retrieval testing proves that every test item can be walked end to end through the chain. Performance testing proves that peak payroll and collection days clear within windows. No test plan is complete without proving that rejects and returns produce intelligible customer communications, not merely correct internal codes.
Resilience prepares for the day normal exchange breaks. Contingency procedures — including manual log preparation and manual balancing situations referenced functionally here — must be documented, staffed, access-controlled and rehearsed, not discovered during an outage. Roles must be clear: who declares contingency, who prepares manual records, who verifies them, who communicates with counterparts and Payments Canada channels, who authorizes carry-forward, and who proves the day afterward. Communication templates must exist for originators, beneficiaries, agents and internal treasury so that a bad day produces coordinated action rather than conflicting reassurance. Backup connectivity, backup staffing, backup sites and backup archive retrieval each need owners and test dates. Resilience metrics — time to detect exchange failure, time to invoke contingency, time to balance manually, time to return to normal, and evidence completeness after each event — turn rehearsal into capability.
Change management and modernization readiness complete the picture. Every hub change, mapping change, stream onboarding, agent change or vendor upgrade follows the same path: impact assessment across validation, exchange, clearing, posting, reporting and reconciliation; rule and schedule review against current publications; regression and negative testing; rehearsed rollback; controlled release with enhanced monitoring; and post-implementation proof that the evidence chain still links. Readiness for the planned RTR and for retail-batch modernization initiatives follows the same discipline: track the programme through official sources, prepare adapters and settlement-path readiness without treating planned rails as live, and never route production value to a rail that is not live. Banks that hold one hub architecture with per-rail adapters absorb modernization as configuration. Banks that hard-wire each product to its rail rebuild every time.
A short implementation checklist for sponsors: hub with gating release, not advisory controls; stream-aware validation and evidence; tested exchange and log balancing including contingency manual paths; position-report timeliness treasury can fund; posting with linkage and hold-aware availability; intelligible customer reporting; daily three-way reconciliation with owned breaks; rehearsed resilience; version-controlled mapping; and a forward plan that respects live-versus-planned status. If any item is missing, batch is running on optimism.
11. Practical Canadian examples
Three fictional examples show how the model behaves on real business days. Companies, people, amounts and outcomes are invented to teach operating logic. They carry no rule authority and no timetable authority. Read each for the control lesson, then apply the lesson to your bank's schedules, agreements and procedures.
Example (fictional) — A Mississauga payroll file that almost missed the window
Northline Staffing, a fictional Mississauga staffing firm with about 400 weekly-paid employees, uploads its Friday payroll file through its bank's business portal on Thursday morning. The file contains AFT credits — the F family — totalling a little over half a million dollars, with employee account details, amounts and a payroll reference per item. The portal's first validation passes format and totals. The hub's deeper validation flags fourteen items: six with account details that fail reachability checks, five duplicates of items from a corrected earlier upload, two with amounts that breach the firm's per-item soft limit set after a prior error, and one file-hash duplicate suggesting the payroll manager uploaded the same file twice after a browser timeout.
Operations does not exchange the file as-is. The portal returns item-level reasons within the morning, in time to repair: the six reachability failures map to two employees who changed banks without telling payroll and four keying errors; the five duplicates are confirmed as already accepted and excluded; the two limit breaches are confirmed legitimate after a supervisor approval with evidence; the duplicate file is acknowledged and suppressed. The firm repairs and re-releases before the bank's published in-window cutoff. Exchange presents clean F-family items, clearing logs balance, entries aggregate into the bank's position, customer credits post for Friday-morning availability, and the firm's collection report shows every employee with references payroll can match. The two corrected employees are paid by a linked same-day alternative the bank offers for exactly this situation, with the cost and evidence explained upfront.
The control lesson is initiation discipline. Format checks at the portal, reachability and duplicate checks in the hub, limit checks with approval paths, and item-level repair guidance returned while the window is still open turned a potential mass failure into a routine repair. Had the bank exchanged the file unexamined, Friday would have brought six misdirected credits, five duplicates, two held items and a duplicated file — hundreds of affected employees and a reconciliation week. Validate early, explain specifically, and release only clean items.
Example (fictional) — A Calgary cheque-image day with a duplicate and a stop
Harbourview Supply, a fictional Calgary distributor, deposits fifteen customer cheques at a branch on Monday morning — paper A-family items in modern image handling. The branch captures images, confirms amounts with the depositor, and sets hold-aware availability expectations honestly: credit timing reflects image exchange plus return rights, not merely the deposit receipt. By midday exchange, images and data flow through electronic feeds while the handling logic remains paper-aware: image quality, MICR readability and endorsement completeness are validated before presentation.
Two exceptions surface. One cheque image fails quality validation — a folded corner obscures part of the MICR line. Operations holds that item from exchange, notifies the branch the same day, and the branch re-captures a clean image from the retained paper under its paper-handling procedure. The second exception is sharper: one cheque was also deposited by mobile on Sunday by the same payee in error, creating a duplicate-presentment signal. The bank's duplicate detection across channels flags the second presentment before exchange, holds it, and contacts the depositor to confirm which presentment stands. The original mobile presentment proceeds; the branch duplicate is suppressed with evidence. On Wednesday a third event arrives: the drawer of a fourth cheque issues a stop. The receiving side honours the stop under paper return handling, returns the item with linkage to the original entry, reverses the provisional credit with explanation, and notifies Harbourview with what to do next — contact the drawer, do not re-present without authority.
The control lesson is paper-aware electronic discipline. Image quality gates, cross-channel duplicate detection, hold-aware customer language, and return handling with linkage and explanation kept a routine deposit day from becoming three disputes. Image exchange at family level, as this chapter presents it, is sufficient to set expectations; the full capture, quality, hold and return mechanics belong to Block 10. The operating point stands here: paper-origin items exchanged electronically still carry paper's return and evidence logic.
Example (fictional) — An Ottawa PAD collection with an unauthorized return
Capital Fitness Collective, a fictional Ottawa gym chain, collects monthly memberships by PAD — an AFT debit flow subject to Rule H1 PAD requirements and the mandate discipline detailed in Block 5. Its February file contains about two thousand debits drawn on the agreed collection date, each with mandate references the gym's system maintains. Validation confirms mandates exist, amounts match plan tiers, and no duplicate file is present. Exchange and clearing proceed cleanly; entries aggregate; positions fund; member accounts debit; the gym's collection report shows collected value with a small set of structured returns for insufficient funds and closed accounts, each with next-step guidance the gym's agreement terms already disclose.
One return differs. A member asserts a debit was unauthorized after cancelling in January — a dispute, not a simple insufficient-funds return. Operations walks the evidence chain: the clearing entry references the exchanged item; the exchanged item references the gym's file; the file references a mandate the gym claims is current; the gym's mandate record shows a cancellation request the gym mishandled. The dispute is upheld under the applicable handling: the debit is returned with linkage, the member is made whole with explanation, and the gym is notified with the mandate evidence gap identified. The gym corrects its cancellation process, re-trains front-desk staff, and offers the former member a consented immediate alternative for the genuinely owed final balance rather than re-presenting the disputed debit. No re-presentment without authority, no second dispute, no write-off queue.
The control lesson is authority before volume. Mandate verification at initiation, mandate-reference discipline in data, dispute handling that starts from evidence rather than assertion, and recovery that preserves original identity turned a dispute into a process fix. Collections at scale live or die on mandate hygiene. Returns are not revenue problems to re-present aggressively; they are authority signals to read correctly.
12. Key takeaways and authoritative references
Hold the exchange-and-clearing model as five sentences. Validated customer instructions become exchange-ready items through layered validation and gating release. Members exchange items — including at regional exchange points under the Rule B1 family — with balanced logs and acknowledged receipt, handling paper-origin and electronic-origin items differently. Validated exchanged items become clearing entries by stream family, logged, aggregated and adjusted with linkage into net direct-clearer positions. Direct clearers exchange and position on their own behalf while indirects act through clearing agents under written agreements, with customer accountability staying at the customer's bank. Positions hand to settlement as complete, balanced and provable — and the full settlement lifecycle, funding, default handling and final-settlement mechanics belong to Chapter 13.
Carry five behaviours into your next batch day. Validate early and specifically, returning item-level repair guidance while windows are open. Release only clean, authorized, correctly streamed items through a real approval gate. Exchange in-window with balanced logs, distinguishing paper and electronic handling and respecting the business-day and closure calendar. Evidence every stage with linked, retrievable records from instruction through settlement handoff. Investigate before re-sending, recover as linked events preserving original identity, and reconcile daily with owned, aged breaks.
Where to go next follows the stream, not the urge to re-read. For the settlement lifecycle that completes the positions built here — cycle mechanics, adjustment windows, funding, clearing-agent operation, failure handling and finality — study Chapter 13 next. For AFT credits, direct deposits, payroll and supplier payments, study Block 4. For PAD mandates, collections, returns, retries, cancellation and disputes, study Block 5. For bill payments, Interac debit, cards, cheque image clearing with holds and returns, and government payments, study Block 10. For USD batch, correspondent paths and cross-border settlement, study Block 11. For cutoffs, calendars, investigations, posting, accounting and reconciliation operations, study Block 14. For the planned instant rail, study Block 12 remembering that, as of this audit, Payments Canada still describes RTR as launching in Q4 2026 and reports participant testing; do not treat the legal framework or test activity as proof of production availability.
Authoritative references (official sources only, baseline 5 October 2026)
This chapter uses only official sources and functional descriptions. It quotes no rule text and states no exact times. For binding obligations use the current publications below with your bank's schedules and the payments.ca closure calendar. Re-check any time-sensitive page before customer or examination use.
- Payments Canada — Retail batch payment system. ACSS/USBE scope, direct-clearer model, previous-day net settlement and payment categories. https://www.payments.ca/systems-services/payment-systems/retail-batch-payment-system
- Payments Canada — ACSS statistics (January 20, 2026). 2025 volume/value totals, category definitions and reporting notes. https://www.payments.ca/automated-clearing-settlement-system-acss-statistics
- Payments Canada — Rules & documentation. Current ACSS rule centre and July 27, 2026 effective update. https://www.payments.ca/systems-services/rules-documentation
- Department of Justice — By-law No. 3 — Payment Items and Automated Clearing Settlement System. Definitions of exchange, clearing, settlement, direct clearer, indirect clearer, clearing agent, ACSS cycle and business day. https://laws.justice.gc.ca/eng/regulations/SOR-2003-346/FullText.html
- Payments Canada — Rule B1, Intermember Exchange and Clearing at Regional Exchange Points. Exchange, logs, cutoffs, closings and contingency responsibilities. https://www.payments.ca/sites/default/files/b1eng.pdf
- Payments Canada — Rule D2, Clearing Agent Requirements. Clearing-agent appointment, notices, obligations, attestations and settlement accounts for indirect clearers. https://www.payments.ca/sites/default/files/d2eng.pdf
- Payments Canada — Rule B9, Manual Balancing for the Purpose of Settlement. National-failure manual balancing, forms, Bank of Canada participation and resumption. https://www.payments.ca/sites/default/files/b9eng.pdf
- Payments Canada — Rule A10, Image Rule. Image creation, archives, electronic image exchange, testing and disaster-recovery requirements. https://www.payments.ca/sites/default/files/a10eng.pdf
- Payments Canada — Automatic funds transfer / ISO 20022. AFT onboarding, testing, implementation and message portfolio. https://www.payments.ca/payment-resources/iso-20022/automatic-funds-transfer
- Bank of Canada — Settlement account policies for Payments Canada payment systems. Direct ACSS clearer settlement accounts and settlement on the Bank's books. https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/
- Bank of Canada — Oversight of designated clearing and settlement systems. ACSS as a prominent Canadian deferred-net retail payment system. https://www.bankofcanada.ca/regulatory-oversight/financial-market-infrastructures/oversight-designated-clearing-settlement-systems/
- Department of Justice — Canadian Payments Act. Payments Canada objects, membership and rule-making framework. https://laws.justice.gc.ca/eng/acts/C-21/FullText.html
- Payments Canada — Real-Time Rail payment system. Current Q4 2026 launch statement and participant-testing status. https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- Department of Justice — By-law No. 10 — RTR. RTR legal definitions, participants, exchange, clearing, settlement and current status. https://laws.justice.gc.ca/eng/regulations/SOR-2026-133/FullText.html
- FINTRAC — Reporting electronic funds transfers. International-EFT reporting triggers and record/report fields. https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng
- OSFI — Operational Risk Management and Resilience Guideline. Scenario testing, continuity, change, third-party and recovery expectations. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/operational-risk-management-resilience-guideline
- Interac — Network Participants. Direct/indirect connectors, issuers, acquirers and settlement-agent roles for the Inter-Member Network. https://www.interac.ca/en/company/about/network-participants/
- Financial Consumer Agency of Canada — Pre-authorized debits (PAD). Authorization, cancellation, stop-payment and unauthorized-debit consumer guidance. https://www.canada.ca/en/financial-consumer-agency/services/banking/preauthorized-debit.html
- Financial Consumer Agency of Canada — Depositing a cheque with your mobile device. Eligibility, hold periods, original-cheque retention and double-presentment guidance. https://www.canada.ca/en/financial-consumer-agency/services/banking/depositing-cheque-with-mobile.html
Diagrams in this chapter: exchange-to-clearing flow; stream families map; clearing-entry lifecycle; direct-versus-indirect roles in exchange; evidence and audit-trail view — all under /diagrams/payment-stories/canada/chapter-12/. No exact cutoff times are shown. ACSS is shown as the live retail batch system. RTR is shown as planned. Image exchange for cheques is shown at family level with detail in Block 10. Settlement lifecycle depth is in Chapter 13. Stories and companies are fictional.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.