Direct and Indirect Clearing Participants. Differentiate direct and indirect participation, sponsorship, clearing responsibility and settlement responsibility.
Canada Payments & Collections · Block 2: Canadian Accounts, Routing and Infrastructure · Chapter 9 of 75
This chapter answers one question that decides almost everything else in Canadian payments: when money moves between two institutions, which institution actually faces the clearing system, and which one is being carried by someone else? The answer determines who funds settlement, who is liable when something fails, who the operations desk calls at 4 p.m., and what a banker can honestly promise a customer about timing and finality. A direct clearer answers for itself. A group clearer answers for itself and its group. An indirect clearer answers to its clearing agent, and the agent answers to the system. A Lynx non-participant partner moves high-value payments only because a Lynx participant agrees to settle them as its own. None of these is a better or worse kind of institution. Each is a different allocation of responsibility, cost, control, and risk — and every banker, analyst, product owner, and operations specialist who touches a Canadian payment needs to read that allocation the way an electrician reads a wiring diagram.
Canada concentrates settlement in very few places. Payments Canada owns and operates the two core systems — the Automated Clearing Settlement System (ACSS) for retail batch and Lynx for high-value gross settlement — but is not the settlement-account provider. The Bank of Canada provides settlement accounts and operates HABS, the secure application through which account services are accessed; it operates neither ACSS nor Lynx. It separately oversees Lynx as a systemically important payment system and ACSS as a prominent payment system under the Payment Clearing and Settlement Act (PCSA). For the current ACSS/Lynx model, institutions that hold a Bank of Canada settlement account, meet the collateral, technical, and operating requirements, and accept direct responsibility to the system can face it directly. Other institutions participate through someone who does; RTR has its own direct- and indirect-settlement-participant model. That single fact explains why a small credit union's payroll file, a corporate credit union's settlement flow, and a fintech's ambitious real-time plan all pass through the same narrow question: whose account at the Bank of Canada actually moves, and whose promise backs it?
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- differentiate a direct clearer, a group clearer, an indirect clearer, and a Lynx non-participant partner, and state for each who holds the Bank of Canada settlement account;
- separate clearing responsibility (entering items, warranting them, answering for errors) from settlement responsibility (funding the obligation in central-bank money on time);
- describe what current Rule D3 requires of an indirect clearer: a clearing arrangement, a Settlement Account and loan facility with each Clearing Agent, designation of at least one eligible Clearing Agent, annual attestation/reporting, and the important AFT/EDI exceptions for other direct/group-clearer or non-member PSP arrangements;
- explain how direct clearers meet ACSS settlement obligations through Lynx payments and what that implies for cutoffs and failure handling;
- list what Lynx participation functionally requires — settlement account, collateral and credit arrangements, technical and operational readiness including SWIFT connectivity — and contrast it with correspondent use;
- explain Bank of Canada oversight of Lynx (systemic) and ACSS (prominent) under the PCSA, and why oversight is not operation and not a customer guarantee;
- describe the PSP path under the Retail Payment Activities Act (RPAA) — registration and supervision, membership eligibility, system access — as separate gates with different owners;
- state the Real-Time Rail (RTR) position at the October 2026 baseline: not in production, By-law No. 10 in force 24 August 2026, and launch targeted for Q4 2026 with sequenced onboarding;
- trace an indirect participant's daily flow end to end and name the owner and evidence at each step;
- explain tiering and concentration risk and what contracts, limits, and oversight do about it;
- advise a new bank, credit union, or PSP on the access-path choice, and handle validation, exceptions, posting, liquidity, reconciliation, testing, and resilience mapped to the right responsible party.
For a roughly 60-minute core session, spend about 15 minutes on Sections 1–2 with the participation-tiers diagram. Spend about 20 minutes on Sections 3–4, tracing one indirect clearer file from instruction to settlement. Spend about 15 minutes on Section 11, working the credit-union and fintech examples and testing yourself on who you would call at each failure point. Spend the final 10 minutes on Section 12, rehearsing the five sentences you must be able to say to a customer without hesitation. The remaining sections are follow-up study; completing the whole chapter takes longer, and that is intentional.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and 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
- Implementation, testing and resilience
- Practical Canadian examples
- Key takeaways and authoritative references
1. Business context and customer need
Start with three phone calls that arrive in the same week, because they show why participation models are a customer problem before they are a technical one.
The first reaches a small Ontario credit union on a Thursday morning. A local manufacturer ran its bi-weekly payroll through the credit union: 340 employees, about 620,000 dollars in AFT credits, value date Friday. The payroll officer wants one sentence: will the money be there? The banker knows the file left the credit union on time. What she does not yet know is whether it entered the ACSS in the right cycle through the credit union's clearing agent, whether the agent's position will settle normally on the next-business-day settlement cycle, and whether anything will come back as a reject after the agent's cutoff. The honest answer depends entirely on the participation chain: the credit union is an indirect clearer, its agent is a direct clearer, and "we sent it" means "we delivered it to our agent before its cutoff and the agent accepted it," not "it has settled." Payments Canada says the previous day's retail-batch net balances settle in the morning of the next business day, in the agent's Bank of Canada settlement position; the credit union does not touch that central-bank account directly.
The second reaches the treasury desk of a corporate credit union acting as group clearer. A member caisse noticed its Friday settlement advice arrived nearly an hour later than usual. Nothing broke: the group clearer moved its internal submission or funding cutoff by thirty minutes to protect its position on a heavy day, and every member felt the shift as later availability. This is a fictional, contract-specific operating choice, not a Payments Canada timetable. The group clearer manages one combined settlement position for the whole group, and its liquidity decisions propagate to every member. The member's question is legitimate, and the answer is a participation answer: you settle inside our position, so our funding discipline is your funding discipline, and here is the evidence showing where the hour went.
The third reaches a fintech product owner in Toronto. Her company will register as a payment service provider under the RPAA, and her board approved a plan promising "real-time payments at launch, direct RTR participant by year two." She asks whether customer messaging can promise instant settlement now, since the RTR by-law is in force. The banker who understands participation gives the only safe answer: no. At the October 2026 baseline, RTR is not in production. By-law No. 10 came into force on 24 August 2026, while Payments Canada targets a Q4 2026 launch with sequenced onboarding — the legal framework exists, but that does not make a production RTR path available to this fintech today. The fintech must launch on what exists and plan the RTR as a future gate with its own membership, technical, funding, and supervision requirements. Confusing a by-law coming into force with a system going live is one of the most expensive mistakes a product plan can make.
These calls share one lesson: the customer sees one relationship — my institution — while the money moves through two or three. The indirect clearer's customer sees the credit union; the system sees the agent. The group member's customer sees the caisse; the system sees the group clearer. The fintech's customer sees the app; the system sees the sponsoring member. Every status message, cutoff promise, investigation update, and fee disclosure has to respect that gap. When institutions describe participation honestly — who does what, who funds what, who answers for what, and what evidence proves each step — customers can plan and operations can investigate. When they blur it, every delay becomes a dispute about what "sent," "processing," and "completed" meant.
Participation is also a buying decision. Direct access buys control, timing precision, and independence at the price of settlement accounts, collateral, liquidity operations, extended-hours staffing, certification, and continuous oversight. Sponsored access buys simplicity and lower fixed cost at the price of dependence: earlier cutoffs, agent fees, exposure limits, and the reality that the agent's outage is your outage. Group membership buys scale at the price of shared timing and governance. Correspondent use for wires buys reach without a Lynx investment at the price of per-payment fees and no direct finality of your own. The cost of a payment is never the network fee alone — it is the liquidity, operations, risk, and resilience cost of the tier that carries it. And one routing rule governs support: the end customer always deals with its own institution, never with the agent, Payments Canada, or the Bank of Canada. The institution that holds the relationship holds the communication and must carry enough evidence from its agent to speak accurately.
2. Participants, responsibilities and boundaries
The Canadian participation map has fewer boxes than newcomers expect. Learn five roles, two responsibilities, and three boundaries, and you can place almost any institution you meet.
A direct clearer is a Payments Canada member that exchanges and clears ACSS items directly and settles its own position directly at the Bank of Canada. It holds its own Bank of Canada settlement account, accessed through HABS, enters its own items into the right ACSS streams, answers for those items to the system, funds its net settlement obligation through a Lynx payment directly or through a Lynx participant, and manages its own liquidity, collateral, and operating presence. When people say "a big bank settles directly," this is what they mean.
A group clearer is a direct clearer with an additional job: it clears and settles for its group members as well as itself. In practice these are centrals, federations, and similar bodies aggregating smaller institutions into one operational and settlement presence. The group clearer enters the group's items, includes group positions in its own net settlement calculation, funds the combined obligation, and allocates results back through internal accounts and advices. The member does not face the ACSS; the group clearer faces it for the member. Members gain scale and professional operations and accept that the group's timetable and risk discipline bind them.
An indirect clearer participates in the ACSS through a clearing arrangement under current Rule D3. The rule requires the indirect clearer to maintain a Settlement Account and a loan facility with each Clearing Agent, designate at least one eligible Direct Clearer or Group Clearer as its Clearing Agent, accept returned items, provide notice of arrangements, and submit an annual attestation and volume/value report. For AFT and EDI, D3 also permits an indirect clearer to use a Direct Clearer or Group Clearer without a Clearing Agent relationship, or a non-member PSP to process and exchange items; those alternatives do not remove the indirect clearer's rule obligations. In the usual agent model, the agent receives and enters the items, the system sees the agent, and the agent controls its bilateral acceptance, funding, limits and suspension processes. Do not turn the functional summary into invented rule text.
A Lynx participant holds a Bank of Canada settlement account and accesses its account services through HABS, meets the collateral and credit arrangements the Bank requires, meets the technical and operational readiness Payments Canada requires including SWIFT-based connectivity, and settles its own Lynx payments payment-by-payment in central-bank money. Lynx has no indirect-clearer concept mirroring the ACSS. Institutions wanting direct high-value settlement become participants; the rest use a Lynx participant as correspondent — sometimes called a non-participant partner arrangement. The correspondent sends the payment through Lynx as its own, settlement occurs between the correspondent's and the receiving participant's Bank of Canada accounts with immediate finality, and the partner's relationship is with the correspondent: fees, cutoffs, confirmations, investigations, and recourse all run through it. The partner never holds Lynx finality of its own; it holds the correspondent's promise, evidenced by the correspondent's confirmation.
Retail PSPs under the RPAA sit across this map rather than beside it. RPAA registration and Bank of Canada supervision are one gate. Payments Canada membership eligibility is a second gate under a different statute. System access — the technical, financial, and operational requirements of the ACSS, Lynx, or in future the RTR — is a third. A settlement-account arrangement, where required, is a fourth. Each gate has a different owner, test, and timetable. A PSP that clears RPAA registration has not thereby joined Payments Canada and has not gained a settlement account. Bankers who keep the gates separate give fintech partners honest plans; bankers who merge them create launch dates that cannot hold.
Two responsibilities run across all roles, and merging them is the most common operational error. Clearing responsibility is the promise about items: the right items entered in the right streams, warranted as required, with errors, duplicates, and adjustments answered for. Settlement responsibility is the promise about money: the obligation funded in Bank of Canada money, in full, on time, even if someone upstream failed to fund. A direct clearer carries both for itself; a group clearer carries both for the group; a clearing agent carries both to the system for its indirect clearers and recovers through its own account agreements. A Lynx correspondent carries settlement responsibility for every partner payment it releases — once sent, the system treats it as the correspondent's irrevocable funding act. Contracts should name each responsibility separately, because the failure modes differ: item-entry failure needs repair and re-entry, funding failure needs money, and calling the wrong owner wastes the critical first hour.
Three boundaries complete the map. The system boundary: Payments Canada operates the systems and makes by-laws, rules, and standards but holds no customer accounts and settles nothing; the Bank provides settlement accounts and collateral mechanics, oversees designated systems, and supervises PSPs, but operates neither ACSS nor Lynx as a customer payment system; the Department of Finance legislates and approves by-laws but touches no payment. The agency boundary: for current ACSS/Lynx paths, the system sees the direct clearer, group clearer, or Lynx participant. Everyone else is volume inside someone else's position, so investigations always travel up the chain — customer to institution, institution to agent or correspondent, agent to the system — never skipping a layer. The customer boundary: status, timing, fees, and problem ownership always sit with the customer's own institution, which must hold enough agent evidence to speak accurately. Two tests catch most misunderstandings: whose Bank of Canada account moves when this payment settles, and if funding fails, who still owes the system? The answer to both is always the settlement-account holder — which is why agents demand prefunding, caps, cutoffs, and suspension rights.
3. Initiation, validation and bank processing
Follow one indirect clearer file through its morning, because initiation and validation are where sponsored participation either earns its keep or quietly creates the exception that surfaces at 5 p.m.
The day starts with the customer, not the system. An employer's payroll officer uploads a 340-line AFT credit file at 8:40 a.m.; a property manager drops a PAD batch for condo fees at about the same time. Each is an instruction to the indirect clearer, which owns every validation step that follows even though it enters nothing directly into the ACSS. The credit union checks signing authority and portal entitlements, file structure and totals, account and transit details, duplicate and reasonability signals (has this payroll already been submitted, does the total match the normal range, is the value date a business day), screens the parties it is responsible for, and confirms the customer's balance or credit cover. None of this is delegated by sponsorship. The agent runs its own acceptance checks, but those protect the agent and the system; the indirect clearer’s checks protect its customer and itself. An invalid transit number catchable at 8:40 becomes an agent reject at 1 p.m. and a missed payroll if nobody owns the first validation.
Processing then splits into two tracks staff must not confuse: the customer track and the agent track. On the customer track, the indirect clearer earmarks funds, issues an acceptance (file received, passed validation, scheduled for today's exchange), and sets expectations against the agent's timetable — your file passed our checks at 9:05, our agent's cutoff is 12:30, agent acceptance will be confirmed this afternoon, settlement completes this evening, beneficiary posting follows the receiving institution's cycle. On the agent track, the credit union transforms validated instructions into the agent's required format, transmits through the agreed channel, and waits for the acceptance response: accepted, accepted with warnings, or rejected with reasons. Only agent acceptance moves items into the clearing story. A file sitting in the outbox, however valid, has entered nothing.
Group members live a similar morning with one difference: the group clearer often provides the processing platform, so validation rules, formats, and clocks arrive as group standards. The member still owns its customer relationship and first-line validation — authority, PAD mandate evidence, own-customer account validity — while the hub performs central validation and delivery. Members must understand which rejections come from the hub's central checks and what each requires: fix and resubmit before the hub cutoff, or hold for next cycle. Hub rejections misread as system rejections produce the classic group complaint — "the system rejected us" — when the truth is "our hub held us for a correctable error and we missed the window." Direct clearers, meanwhile, validate and deliver straight to the system with production-grade controls, because they warrant their items directly and have no agent to catch a late file or absorb a funding gap.
Lynx-side initiation is a different discipline, and treating wires like batch files creates the most painful errors in this chapter. Each Lynx payment is validated, screened, authorized, and released individually into RTGS settlement, final the moment it settles. A non-participant partner initiates under its correspondent's cutoffs, format, and authorization rules; the correspondent re-validates, screens, and releases the payment as its own. The partner's customer cutoff must therefore sit well before the correspondent's release cutoff, which sits before system close. Partners publishing customer cutoffs equal to the correspondent's cutoff guarantee failure on any day with a screening hit or slow authorization. Partner cutoff, correspondent cutoff, and system close are three different times, and the earliest governs.
Validation failures deserve a short taxonomy, because correct naming means faster repair. Format failures are fixed by correcting and resending before the agent or hub cutoff. Reference failures (unknown transit, closed account, wrong stream code) are fixed by repairing the instruction with the customer. Authority failures (missing mandate, expired authorization, inadequate signer) stop the payment until evidence exists — resending changes nothing. Acceptance failures (duplicate file, over-limit, late delivery) follow the agent's procedure, never a second channel that creates tomorrow's duplicate adjustment. Screening holds follow the compliance procedure, not the operations clock; releasing a held payment to meet a cutoff is never acceptable. Each category has a different owner, evidence requirement, and next cutoff, and procedures must state all three with the agent's escalation path on the same page.
4. Clearing, exchange, settlement and finality
Clearing, settlement, and finality are three events, not three words for the same event, and participation determines who performs each and when the customer may rely on it.
In the ACSS world, clearing is the exchange and netting of retail items among direct participants across the system's streams, followed by calculation of each direct participant's net position. For an indirect clearer, every step happens inside its agent's presence: the agent delivers the items as its own, counterparties see only the agent, and debits and credits accumulate in the agent's net position. The indirect clearer has no net position at the system level — it has a position at its agent, tracked in its settlement account there and reconciled against the agent's reports. At the system, the agent is the principal; the indirect clearer is the agent's customer. Re-read that sentence if needed; it carries half this chapter.
Settlement is the funding of those net positions where the Bank of Canada accounts live. Direct clearers meet their ACSS settlement obligations through Lynx payments — the net debtor sends a Lynx payment covering its ACSS obligation, and system settlement completes when those movements complete. Group clearers fund the combined group position the same way, which is why the group clearer’s treasury desk is the most consequential desk most members never see. Indirect clearers settle with their agents, not the system: the agent debits the indirect clearer’s account at the agent for its share and funds the total at the Bank of Canada. Timing stacks — the indirect clearer must fund its agent before the agent funds the system. Late funding by the indirect clearer does not delay the system; the agent funds anyway and pursues the shortfall under the agreement, through interest, fees, reduced limits, or suspension.
Finality in the ACSS is the point the rules designate as completion of settlement for the cycle — a system-level event about participant positions, not a per-item guarantee that each beneficiary has been credited. The beneficiary's available balance still depends on the receiving institution's posting cycle and exception handling. "ACSS settled, so your employee has the money" skips that step and will be wrong often enough to damage trust. The accurate chain names four events with four owners: our agent accepted the file, the items entered today's exchange, the agent's previous-day net position settled the following morning, and receiving institutions post under their own cycles for the quoted availability date.
Lynx works on the opposite principle — gross, immediate, per-payment. A participant's payment settles individually in central-bank money with finality at settlement: no batch, no netting, no evening unwind. Once settled it is irrevocable, and recovery of a misdirected payment generally depends on the receiving participant's cooperation and the applicable Lynx rules. A partner's payment settles identically in technical terms — the correspondent settles it as its own — but the partner experiences finality second-hand, learning of it only from the correspondent's confirmation with reference and timestamp. Partner agreements must never say "your wire is final when we send the message to our correspondent." The message is not the money. The wire is final when the correspondent's Lynx payment settles, and every procedure and customer page should say exactly that.
The RTR, when it launches, will add a third finality model — but at the October 2026 baseline it is not a production rail. This chapter treats it as planned infrastructure (By-law No. 10 in force 24 August 2026; Payments Canada target launch Q4 2026 with sequenced onboarding) and discusses access paths in Section 10 as planning, not live procedure. Any cutoff table or disclosure presenting RTR access as available to this institution today is unsupported. Plan the RTR in the project room; operate the ACSS and Lynx on the floor. The working summary for incidents: ACSS indirect means items enter through the agent, counterparties see the agent, funding flows indirect-to-agent then agent-to-system, finality is a cycle event, and availability follows receiving-institution posting. ACSS group follows the same logic through the group clearer. ACSS direct means the institution is the face, funder, and answerable party. Lynx direct means each payment settles with immediate finality; Lynx partner means the correspondent's settlement is final and the partner holds its confirmation. Ask which sentence describes the payment, and the investigation routes itself.
5. Data, identifiers, messages and references
Participation runs on data, and the data that matters most tells each party who is acting for whom. Get the identifiers right and the chain is traceable. Get them wrong and the payment rejects at the agent's door — or worse, enters clearing attributed to the wrong party.
Start with institutional identification. Canadian routing rests on the institution number, transit or branch number, and account number, with the Financial Institutions File as the authoritative reference for which institutions and numbers are valid. For participation, two further identities matter though customers never see them: the clearing identity the system recognizes (the direct clearer, group clearer, or agent code under which items are entered) and the settlement identity the Bank of Canada recognizes (the settlement-account holder; account services are accessed through HABS). In sponsored flows these deliberately differ from the originator: the indirect clearer’s items carry its institutional identity for beneficiary purposes but enter clearing under the agent's identity and settle under the agent's account. Files, reports, and reconciliation keys must therefore carry both the originator's identity and the entering party's identity, or the indirect clearer cannot match customer totals to agent clearing totals on adjustment days — when they will differ.
File and batch references are where indirect operations most often break. The indirect clearer assigns its own file, batch, and item references; the agent assigns exchange and clearing references on entry; the system and counterparties generate acknowledgements, rejects, returns, and adjustments keyed to the agent's entry. Traceability demands a three-way chain preserved in both institutions' stores: customer instruction reference to agent-delivery reference to system-entry reference, with every exception linked back down. Institutions that overwrite the customer reference with the agent's, or store file totals without item-level keys, can prove the file was sent but cannot answer which item the counterparty is asking about. Preserve all three layers, keyed and searchable, for the full retention period.
Message standards need a functional map, not a format manual. ACSS-adjacent batch traffic moves in structured files whose layouts the agent specifies; the agent transforms or forwards into exchange formats the system requires. Lynx supports ISO 20022 financial messaging, and Swift is its financial-message service provider; current published specifications cover customer transfers (pacs.008), FI transfers (pacs.009), returns (pacs.004) and reporting (camt.053). Use the current Lynx rules and message specifications for the applicable release rather than assuming every traffic type or legacy message is ISO 20022. The participation consequence is practical: the indirect clearer must meet its agent's validation exactly, because agent rejections for format defects are the indirect clearer’s to fix. A Lynx partner faces the same discipline one level up: data must satisfy the correspondent's pre-validation, screening, and repair queue before its cutoff, with buffer for repair.
Two reference disciplines always surface in audits. Where the applicable rail or message standard provides an end-to-end transaction reference, preserve it from originator instruction through intermediary processing and beneficiary reporting; do not assume every legacy batch or bank statement carries it unchanged. The settlement reference identifies the funding act itself: the Lynx payment covering an ACSS net obligation, the Lynx confirmation for a high-value payment, the agent's advice line for an indirect clearer’s share. Customer references prove what was instructed; settlement references prove what was funded. Reconciliation matches them — instructed versus entered versus funded, reference to reference, total to total. Build five artefacts as a designed set and reconciliation stays daily: delivery, acknowledgement keyed to delivered references with coded reasons, clearing report by stream and value date with item detail, settlement advice with amount, value date, account, and funding reference, and customer reporting translated back into customer references without dropping the underlying keys. Build them as afterthoughts and reconciliation becomes monthly, painful, sometimes never.
6. Rules, cutoffs, service levels and customer impact
Rules set the frame, cutoffs set the rhythm, and service levels translate both into promises a banker can keep. This section describes each functionally — what it requires of whom — and never quotes invented rule text. Staff must work from authoritative sources, not from a course chapter's paraphrase.
The frame has four layers, each binding different parties. Payments Canada by-laws, rules, and standards govern exchange, clearing, settlement, capacities, and what each capacity owes the system and counterparties — including the current Rule D3 framework for indirect clearers (Settlement Account and loan facility with each Clearing Agent, designation and notice, annual attestation/reporting, plus specified AFT/EDI alternatives) and the group-clearer frame (acting for the group, combined settlement, allocation to members). Lynx rules govern participation, release, queuing, settlement, and finality, with correspondent use governed bilaterally. Above sit the statutes: the Canadian Payments Act for the system's legal basis and membership, the PCSA for designation and oversight (Lynx systemic, ACSS prominent), and the RPAA for PSP supervision. No layer is optional, none can be contracted away, and each audit asks for its layer by name.
Cutoffs are where rules become operations, and sponsored institutions live under stacked cutoffs that must be published as a stack, never a single time. The system has its close and stream and settlement cutoffs; the agent sets acceptance earlier to leave validation and entry time; the agent sets its funding cutoff for the indirect clearer earlier than its own settlement funding moment; the indirect clearer sets its customer cutoff earlier than the agent's acceptance. Group clearers publish the same stack for members; Lynx correspondents publish partner instruction, validation and screening, release, and system close times. Every layer needs buffer belonging to the party acting inside it — not spare time for later customer submission. Institutions publishing only the system time mislead every customer. Institutions publishing the full stack with consequences (before this time means today's cycle, after means next, value-date effects stated) earn fewer complaints and faster repairs.
Service levels translate cutoffs into differentiated promises, shaped by tier. AFT payroll through an indirect clearer promises agent acceptance today, next-business-day settlement of the prior-day net position, and beneficiary availability on the quoted morning — with the receiving-posting caveat explicit. Lynx through a correspondent promises same-day release before the correspondent's cutoff with confirmation evidencing finality, and next-business-day handling after, with fees and repair-queue language stated. Group members promise the group's timetable and say so. PSP partners promise only what sponsor timing plus their own processing allows, with RTR language strictly future-tense until live. Write each promise as a tested sentence with three elements — the time, the evidence the customer receives, and the missed-cutoff consequence — and ensure operations can produce that evidence from stored acknowledgements and advices without a manual hunt.
Three impact patterns recur. The missed cutoff: a valid instruction arrives late for today's cycle, so value moves a day with payroll dates and supplier terms shifting alongside. Respond with early detection, immediate notice stating next-cycle time and value date, and a documented choice — hold, upgrade a time-critical payment to a correspondent wire with its own cutoff and fee, or split the file. The funding shortfall: the sponsored institution cannot fully fund its agent or group, so the agent funds the system and manages the gap bilaterally. Contain it by prior agreement — prefunding large files, caps preventing one customer from endangering the position, escalation reaching treasury before the funding cutoff. The system event: agent outage, hub delay, or Lynx extension changes everyone's timing at once. Respond with the pre-written line naming the event functionally, the revised expectation, and the next update time. And keep language honest: "same-day" names its cycle and cutoff; "settled" names whose position and its proof; "final" is reserved for Lynx settlement finality (cycle-settlement in ACSS only with the posting caveat); do not use RTR, real-time or instant to imply a live RTR path at the October 2026 baseline; tie any such descriptor to a named service and verified production status.
7. Fraud, compliance and operational controls
Controls follow responsibility. Each party controls what it can see and stop, and agreements must state who screens, who holds, who decides, and who proves it.
As a recommended control design (not Payments Canada or FINTRAC rule text), the edge — indirect clearer, group member, PSP — should own the customer relationship, onboarding, mandate evidence for PADs, initiation authorization and authentication, channel fraud signals, first-line monitoring, and screening duties applicable to the parties it introduces. The gateway — agent, group clearer, correspondent — should own acceptance validation, duplicate and limit enforcement, its own screening on traffic it enters or releases, exposure management against the sponsored institution, and the accept, hold, or refuse decision. Neither layer may assume the other screened. Dual screening is the design, not a duplication to optimize away: the edge sees the relationship and mandate, the gateway sees aggregate flow and cross-customer patterns.
Fraud controls map to payment type. For AFT credits such as payroll, the dominant patterns are originator impersonation, altered beneficiary details redirecting files, and compromised-credential batch submission. The edge defends first — callback verification for changed beneficiary details, dual authorization for new or amended payees above thresholds, file-hash matching against the authenticated submission, behavioural monitoring for out-of-pattern files — because the agent cannot know whether a well-formatted payroll is genuinely authorized. The agent complements with velocity and volume limits, duplicate-file detection, and aggregate anomaly monitoring. For PADs, authorization evidence is the control: valid agreement, correct category, proper notice, retrievable proof, held by the collector's institution and producible on dispute — sponsorship dilutes nothing, and the agent may demand that evidence when an inquiry arrives. For correspondent wires the stakes are highest because Lynx settlement is irrevocable: pre-release verification (callbacks on new high-value beneficiaries, invoice matching, four-eyes release, cooling logic for first-time payees) and precise data validation before release. A partner pressuring its correspondent to release a held wire to meet a promise asks the correspondent to absorb a permanent loss. Correspondents must be empowered to refuse, and partners must present refusal as protection, not obstruction.
Sanctions, AML, and FINTRAC-related obligations follow the same shared-but-named logic. Each institution screens what it is responsible for under law and its own programme, holds and investigates matches under its own procedures, and produces its own evidence. Do not assume an agent's control or reporting discharges the other institution's own legal obligations; applicable FINTRAC, sanctions and other requirements must be assigned by entity and payment activity. That supports screening at both layers with tuned lists and versioned matching logic, hold-and-release authority able to stop a file or single item without stopping the cycle, false-positive repair capacity staffed through cutoffs, and audit trails showing what was screened, against which lists at which version, with what outcome decided by whom. Cross-border wires add the information dimension: the partner must supply complete originator and beneficiary data in the correspondent's format, because truncation at the edge becomes a release failure or post-settlement inquiry at the gateway.
Operational controls complete the plane: authenticated channels with totals, hash, sequence, and duplicate detection at both layers; entitlements with dual control above thresholds; verified change procedures for beneficiary details, limits, and cutoffs; access controls on settlement accounts at the agent; intraday monitoring of acceptance rates, reject and screening queues, positions against caps, and correspondent release queues — each with thresholds, owners, and escalation reaching decision-makers before cutoffs. Logs must preserve the three-layer reference chain tamper-evident, because investigations reconstruct authority and timing from logs, not memory. Customer communication needs control too: pre-written hold language explaining delay without exposing screening logic, callbacks staff actually follow under pressure, and recourse language matching the rules rather than inventing unfundable generosity. Oversight frames all of this without replacing it: Bank of Canada PCSA oversight sets system-level expectations, RPAA supervision sets PSP-level expectations, and neither examines any indirect clearer’s fraud queue nor guarantees any payment. Agents review their indirect clearers, groups review members, correspondents review partners — with evidence, not assertions. Institutions welcoming those reviews keep their sponsorship.
8. Exceptions, investigations and recovery
Every participation model is tested by exceptions, and quality shows in the first hour — staff who know the chain investigate in minutes, staff who guess take days.
Name the failure correctly first, because the name selects the procedure. Rejects happen before clearing entry: the agent refuses the file or items (format, duplicate, over-limit, late, failed validation), the hub refuses a member submission, or the correspondent refuses a wire instruction. Rejects never entered clearing, never touched a settlement position, and are fixed by correcting and resending before the governing cutoff — never by duplicating through another channel. Returns happen after clearing in batch flows: the receiving institution returns the item (NSF, closed or invalid account, PAD dispute, image or duplicate defect), travelling back through clearing to the originator's institution for customer handling. Adjustments correct clearing errors — duplicates, wrong amounts, wrong streams — with the agent acting for the indirect clearer. Recalls and return requests in wires are requests, not reversals: once a Lynx payment settles it is final, and recovery depends on the receiving participant's cooperation. Mixing categories — treating a reject as a return, a recall request as a reversal — is the fastest way to mishandle an exception.
Investigations follow the chain upward, never skipping a layer, with evidence at each handoff. An unpaid beneficiary's institution checks its own posting first: did the item arrive, is it held for repair, was it returned, or did nothing arrive? If nothing arrived when the value date says it should have, the inquiry goes to the originator's side: the indirect clearer checks agent acceptance and clearing reports for the item reference. Never accepted means the case closes at the edge as a reject with the correction path. Accepted and entered means the agent confirms entry and settlement cycle, and attention turns to receiving-side posting with the entry reference as key. Wire investigations compress the same logic: the partner asks its correspondent for settlement confirmation or repair-queue status; the correspondent traces its release reference, settlement timestamp, and receiving-participant acknowledgement using structured investigation messaging with end-to-end references preserved. The rule throughout is evidence before assertion — acceptance logs, clearing reports, settlement advices, hold records, confirmations travel with the inquiry, because counterparties act on proof, not recollection.
Recovery depends on where the money sits. Before batch settlement, recovery is correction: fix, resend, adjust, stop a duplicate before next cycle. After settlement, recovery is a new movement: returns and adjustments create their own entries with their own value dates, and the customer impact is managed as its own event with its own communication. After Lynx settlement, recovery is cooperation: the sending correspondent requests, the receiving participant decides, the partner's customer waits. That is why pre-release verification is a control rather than a courtesy — finality makes prevention the only reliable recovery. Agreements should state plainly what the agent or correspondent will do, within what time, with what customer communication, and at what fee, so no investigation opens with a debate about duties.
Three disciplines separate institutions that recover well. Clock discipline: every exception has a next action time — repair cutoff, return deadline, adjustment window, inquiry response target — shown on the case record, counting down, escalating before expiry. Communication discipline: the customer's own institution owns every update, translates chain events without exposing other institutions' internals, states the next update time, and meets it even with no change. Pre-written status lines per exception type prevent over-promising improvisation. Record discipline: the full reference chain preserved, every decision logged with decider, evidence, and time, every customer message recorded. Audits, ombudsman cases, and reimbursement disputes turn on these records months later, when nobody remembers the afternoon but the log does. Contingency exceptions — agent outages, hub delays, missed correspondent cutoffs, system extensions — follow the same chain at scale: name the failed layer, confirm actual item state (never accepted, accepted but not entered, entered but not settled, settled but not posted), communicate the revised expectation with the next update time, and preserve the evidence. Customers forgive delays they understand; they do not forgive silence.
9. Posting, accounting, liquidity, reporting and reconciliation
Money not posted, accounted, funded, reported, and reconciled has not finished moving, whatever the system says. This section follows the back half of the indirect clearer’s day — invisible to customers, examined by auditors — and assigns each job.
Posting translates clearing and settlement events into customer balances, and the owner is always the customer's own institution acting on agent or system evidence. The indirect clearer posts from its agent's clearing reports and settlement advices, never from its outbox file. Receiving institutions post incoming credits under their own availability and hold policies. Group members post from group advices. Wire beneficiaries are posted on final settlement; a partner's customer is posted on the correspondent's confirmation. Four errors recur: posting from the sent file before acceptance (phantom credits reversed on reject), posting gross instead of net of returns and adjustments (compounding day-end breaks), posting to suspense without a repair clock (ageing unreconciled balances), and posting wires on message receipt before settlement confirmation (confusing promise with finality). Prevention is uniform: post only on the evidence your tier defines, keyed to Section 5 references, with repair and reversal procedures attached to every posting rule.
Accounting records the same events in two ledgers that must agree: the customer ledger and the position ledger (what the institution holds at its agent, group, or correspondent). The settlement account at the agent is the hinge — customer activity accumulates against it intraday, agent advices move it at cycle end, fees, shortfall interest, and adjustments post to it under the agreement. Suspense, fee, and adjustment ledgers must clear to the hinge daily with ageing breaks escalated, never carried. Finance, operations, and treasury must share one intraday position view, because the funding decision cannot wait for books to close.
Liquidity funds those hinges on time and is the responsibility the system cares about most. Direct and group clearers fund Bank of Canada positions through the Bank's mechanisms, with collateral and credit arranged before needed and treasury monitoring intraday against limits and cutoffs. The indirect clearer funds its agent account before the agent's funding cutoff, in amounts the pre-advice or limit framework requires, with large or unusual files pre-announced and prefunded. The partner funds its correspondent before release of high-value payments. Liquidity failures are never systemic surprises; they result from missing collateral, prefunding, or monitoring, and agreements arm the funder with caps, throughput limits, earlier cutoffs, collateral calls, and ultimately suspension. Procedures must name the funding owner, monitoring cadence, escalation triggers, and backup funder — incidents happen at the worst hour, and improvisation then turns small shortfalls into embarrassments.
Reporting converts internal events into understanding, each report with a producer and consumer. The agent produces clearing reports (entered items by stream and value date with detail), settlement advices (what funded, in which position, under which reference), and exception reports for the indirect clearer; groups and correspondents produce equivalents including release and settlement confirmations with timestamps and finality language. The edge institution produces customer reports — payroll confirmations with value dates and exception lists, PAD reports with return coding, wire confirmations with settlement evidence, fee statements matching agreements. Management reporting sits above: daily position and break summaries, weekly exception and fraud-hold trends, monthly sponsor-performance reviews covering acceptance rates, reject reasons, cutoff performance, and fees. Reports that will not reconcile to each other are findings with owners and due dates, not inconveniences.
Reconciliation proves the story — three-way by design in sponsored flows: customer instructions versus agent clearing evidence versus settlement movement, matched by reference and total every cycle, breaks aged and owned. Match sent files to acceptances (catching rejects), acceptances to clearing reports (catching entry failures), clearing reports to settlement advices (catching funding breaks), and advices to postings (catching posting errors), with returns and adjustments matched as their own entries rather than netted invisibly. Escalate unmatched items toward investigation with thresholds from operations to treasury to executive, coded by root cause — reference defect, cutoff miss, funding gap, counterparty return, system event — feeding back into validation, cutoff, and limit decisions. Daily reconciliation with coded breaks improves monthly; monthly reconciliation with uncoded breaks repeats the same incident quarterly and discovers it at audit.
10. Implementation, testing and resilience
Joining a participation tier is a programme, not a form. This section states what each path functionally requires so bankers, analysts, and product owners plan honestly and test before promising.
The indirect path is fastest but still a controlled programme. Select first: evaluate candidate agents on stream coverage, cutoffs, file specifications, fees, funding and limit terms, reporting quality, contingency support, and reputation, and negotiate the agreement Rule D3 functionally requires — delivery mechanics, acceptance and funding cutoffs, account and prefunding terms, caps, fee and interest schedules, reporting formats, exception duties, suspension rights, exit provisions, audit rights. Build next: file generation to spec, secure transmission, acknowledgement ingestion with automated reject handling, report and advice ingestion with automated matching, customer posting and reporting from agent evidence, funding automation, edge screening and authorization, and full reference preservation. Certify with the agent — connectivity, format acceptance, repair handling, funding simulation, report matching, contingency contacts — then run parallel through at least one full cycle including an exception day before cutover, with hypercare staffing, the agent's desk on standby, and new cutoffs communicated to customers before they bind.
The group path substitutes group standards for bilateral negotiation: adopt hub formats, cutoffs, funding terms, and reporting; build edge validation and customer communication to the group timetable; certify against the hub; run parallel through a representative cycle. Test the three days sales material never demonstrates: the heavy day (payroll plus PAD plus bills together), the shortfall day (funding an hour late and its escalation), and the hub-delay day (late advices, lit-up customer lines). How the group behaves on those days is the membership decision, more than the fee schedule.
The direct path — ACSS direct clearer or Lynx participant — is measured in quarters. Functionally: Payments Canada membership and admission; a Bank of Canada settlement account accessed through HABS, with the Bank's collateral and credit arrangements; technical connectivity and operational readiness including SWIFT-based messaging for Lynx with queue management to operate it; staffed operations through required hours with trained release, funding, investigation, and contingency authority; certified testing of entry, funding, exceptions, and recovery; and the treasury, risk, audit, and compliance frameworks direct responsibility demands. Lynx adds intraday liquidity management and the culture to treat each release as irrevocable. Pursue this path for control, timing, and scale — and fund the operations control requires, because a direct clearer staffed like an indirect clearer fails its first heavy day.
The correspondent path for high-value needs without Lynx participation is a bilateral programme: instruction formats, authorization and callback standards, screening-information requirements, buffered cutoffs, prefunding or limit terms, confirmation and investigation service levels, fees, and contingency when the correspondent itself faces a system event. Drill three scenarios live before relying on the arrangement: a repair-queue hold (incomplete data before cutoff), a screening hold past the customer cutoff with the customer conversation it forces, and a misdirection caught before release versus after settlement with their different recoveries. Partners skipping these drills conduct their first drill during a live incident, with the customer listening.
The planned RTR path is planning, not implementation, at the October 2026 baseline. The real planning work: track By-law No. 10 (in force 24 August 2026) and the initial launch timetable (planned Q4 2026) from authoritative sources; assess direct versus sponsored RTR access under the published model; map the RPAA, membership, technical, funding, and 24/7 operational gates; redesign fraud, screening, and customer communication for instant irrevocable payments; and keep every customer and board statement future-tense with the legal baseline cited. Never commit production resources, customer dates, or marketing language to RTR availability before the system is live and the institution admitted. Anchor board papers to the Canada Gazette entry for SOR/2026-133 and operations to the Payments Canada and Bank of Canada pages — any vendor claim contradicting those anchors loses. Show the RTR as a gated dependency — law in force, system live, institution admitted, operations certified — with commitments attached to the last gate, not the first.
Resilience underpins every tier's promise. Each institution needs documented contingency for sponsor failure and for its own failure as the sponsor sees it: backup connectivity, queued resubmission with duplicate protection, funding fallbacks with named authorities, pre-approved customer-hold language, and tested recovery objectives — rehearsed at least yearly with the sponsor participating, because a plan rehearsed alone is a hypothesis. Agents, groups, and correspondents need mirror procedures: prioritization when a sponsored institution cannot fund, consistent suspension and reinstatement criteria, and communication informing affected institutions without exposing any position. Direct and Lynx participants need system-level contingency: alternate staffing and connectivity, queue management under extensions, and stress-time decision authority to fund, hold, or release. Auditors will ask for test dates, participants, findings, and remediation. Customers will simply judge whether the last bad day looked managed or surprising.
11. Practical Canadian examples
The three examples below are fictional, built from common Canadian patterns. Names, numbers, and institutions are invented. Responsibilities, flows, and failure handling reflect the functional model in this chapter. Each is labelled as fictional and ends with the lesson to carry onto the floor.
Example (fictional): a credit union payroll through a clearing agent. Mapleview Credit Union in Kitchener serves about 18,000 members and clears indirectly through a large direct clearer as agent. On Wednesday morning a manufacturing customer uploads a 340-employee payroll file totalling 618,400 dollars, value date Friday. Mapleview validates authority, format, and totals by 9:05, screens under its own programme, earmarks the employer's account, and confirms receipt honestly: received and passed our checks, scheduled for today's exchange through our agent, agent cutoff 12:30, acceptance confirmation to follow. The file transmits at 10:15 with Mapleview's references and item-level keys preserved. At 11:40 the acknowledgement returns 338 accepted and two rejected for invalid transit numbers on new hires. Operations phones the payroll officer before noon, receives corrections by 12:05, resubmits keyed to the original file reference, and wins acceptance at 12:20 — inside the cutoff. The next-business-day settlement advice, after the prior exchange, shows the agent's position settled through its Lynx funding act (or Lynx settlement intermediary, if applicable); Mapleview's account at the agent is debited for its share; the employer's debit posts. Friday morning one employee reports her credit missing. Mapleview checks evidence before speculating — acceptance confirmed, entry confirmed, funding confirmed — so the inquiry goes receiving-side with the entry reference, where the credit is found held for name repair and posted within the hour. Lesson: the customer saw Mapleview, the system saw the agent, and evidence bridged the two. Post from agent reports, never the outbox; repair before the agent's cutoff; investigate with references, not reassurance.
Example (fictional): a corporate credit union funding its group on a heavy Friday. Prairie Central group-clears for 42 member caisses and credit unions. One Friday brings nearly double normal clearing value: payroll credits, utility PAD collections, and a large government disbursement file. Treasury starts with tightened intraday monitoring, collateral headroom confirmed overnight, and member funding cutoffs published a week earlier with a thirty-minute earlier ask for the three largest members — communicated as group protection with reasons, not surprise. Midday, a member's PAD file arrives 40 minutes late at 18 percent above its normal range. Hub validation flags the velocity and value anomaly; operations holds for callback rather than auto-entering, reaches the member in twenty minutes, and confirms it is genuine — a semi-annual billing catch-up never pre-announced. The file enters the next exchange with a revised value date the member communicates to billers, and the pre-announcement failure becomes a service review item. The following morning the previous-day combined position settles through Prairie Central's Lynx funding act; advices carry the slight timing shift; one CFO phones about the hour's difference and receives the full chain with references. Lesson: one treasury desk, one Bank of Canada position, one funding act, 42 members' value dates. Earlier cutoffs on heavy days, anomaly callbacks before entry, and advices explaining timing rather than stating totals are what make concentration safe rather than merely efficient.
Example (fictional): a fintech PSP planning its path under the RPAA without over-promising. Northpay Labs in Toronto offers supplier payments for small businesses and plans RPAA registration. Its September 2026 board deck promises real-time supplier payments at launch and direct RTR participation in year two. Its bank partner returns three corrections. First, RPAA registration plus supervision does not admit Northpay to any payment system — membership eligibility and system access are separate gates with their own tests and timetables. Second, the RTR is not live: By-law No. 10 in force 24 August 2026, initial launch planned Q4 2026, so no launch copy or contract may imply RTR availability today. Third, launch must run on sponsored rails — ACSS batch through the partner as agent with its cutoffs, limits, fees, screening requirements, and confirmation language, plus correspondent wires for urgent payments with per-payment fees and confirmation-evidenced finality. Northpay revises: launch on sponsored ACSS with honest timing plus a wire upgrade path; run RPAA registration in parallel; track membership eligibility as a gate; design ledger, screening, and support toward future RTR sponsorship first and direct participation later, with commitments gated to system-live plus admission plus certification. Months later a prospect asks why a competitor promises instant settlement today, and Northpay's sales lead answers with evidence: no Canadian institution can settle an RTR payment today, here is what our sponsored timing provably delivered last month, and here is our gated RTR plan with the legal baseline cited. The prospect signs — partly on product, partly on honesty. Lesson: plan the RTR in gated stages, sell only what sponsored rails provably do today, and let acceptances, advices, and confirmations carry the credibility superlatives cannot.
12. Key takeaways and authoritative references
Carry five sentences onto the floor and you will handle nine out of ten participation questions correctly. First: whose Bank of Canada account moves decides who faces the system — direct clearers, group clearers, and Lynx participants face it; indirect clearers, group members, and Lynx partners face their sponsor. Second: clearing responsibility (right items, warranted, answered for) and settlement responsibility (funded in full, on time, in central-bank money) are different promises the agreement must name separately — item failures need repair, funding failures need money. Third: the system sees only the settlement-account holder, so investigations travel the chain — customer to institution, institution to agent or correspondent, agent to the system — with evidence at each step and communication owned throughout by the customer's own institution. Fourth: cutoffs stack — customer before agent before system, partner before correspondent before close — and only the earliest applicable time may be promised, with evidence and missed-cutoff consequences stated. Fifth: at the October 2026 baseline the RTR is not live — By-law No. 10 in force 24 August 2026, initial launch planned Q4 2026 — and every plan, page, and promise must reflect that.
Add five habits and the sentences become behaviour. Preserve the three-layer reference chain — customer instruction to agent delivery to system entry — because investigations without references are guesses. Post only on your tier's evidence — agent reports and advices, group advices, correspondent and system confirmations — never the outbox file or sent message. Fund before the funder's cutoff with intraday monitoring, because the agent funds the system whether you funded the agent or not. Screen at your layer without assuming the other layer screened, hold past cutoffs when compliance requires, and record what was screened, against what, decided by whom. Rehearse the bad days — rejects, shortfalls, hub delays, correspondent holds, misdirected wires before and after settlement — with your sponsor in the room, because the incident is the wrong time to meet your escalation contact.
The references below are the only sources staff should use for rule, legal, and timetable claims. This chapter describes the functional model; these sources govern it. Check them before publishing any cutoff, customer promise, board date, or procedure naming a requirement.
- Payments Canada — Retail batch payment system, current ACSS/USBE participant and next-business-day settlement description.
- Payments Canada — Rule D1, Direct Clearer / Group Clearer Requirements (2026); Rule D2, Clearing Agent Requirements (2025); and Rule D3, Indirect Clearer Requirements (2026).
- Payments Canada — Rules & documentation, current versions and effective dates (ACSS rules updated July 27, 2026).
- Payments Canada — Lynx, participation criteria, Swift message service, RTGS finality and non-participant partners.
- Bank of Canada — Settlement account access policy for Lynx and ACSS, including HABS, collateral, loan and operational requirements.
- Bank of Canada — Regulatory oversight of designated clearing and settlement systems and payment systems overseen (Lynx systemically important; ACSS prominent).
- Bank of Canada — Retail payments supervision FAQ and RTR settlement-account policy.
- Payments Canada — Payment service providers and the Real-Time Rail, current RPAA, membership, settlement-agent and onboarding gates.
- Payments Canada — RTR testing and launch, Q4 2026 target and sequenced onboarding.
- Canada Gazette — Canadian Payments Association By-law No. 10 — RTR, SOR/2026-133, registered June 18, 2026 and in force August 24, 2026.
- Justice Laws — Canadian Payments Act and Payment Clearing and Settlement Act.
- FINTRAC — Money services businesses: FINTRAC's requirements, for entity-specific AML/ATF applicability.
- OSFI — Guideline B-10: Third-Party Risk Management, for FRFI outsourcing, concentration and contingency expectations.
- FCAC — Guideline on Complaint-Handling Procedures for Banks, for bank complaint-handling duties.
Uncertainties and boundaries observed while authoring: this chapter describes participation functionally and does not quote rule text, so procedures enforcing a specific clause must verify current language on payments.ca. Thresholds, fees, and exact bilateral cutoffs are intentionally unstated — they vary by agreement and operating calendar, and the governing agreement plus current circulars control. ACSS rules and rule versions are current as posted on Payments Canada (including the July 27, 2026 update); this chapter does not reproduce them. RTR access and onboarding detail continues to evolve toward the Q4 2026 target; this chapter states only the October 2026 baseline and points planning to the authoritative pages above. Where any statement here appears to conflict with payments.ca, Bank of Canada policy pages, or the Canada Gazette, the authoritative source prevails and this chapter should be corrected to match.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.