ACSS Settlement Lifecycle. Follow clearing positions through settlement obligations, funding and completion.
Canada Payments & Collections · Block 3: ACSS and Retail Batch Payments · Chapter 13 of 75
This chapter follows one business date from exchanged totals to extinguished positions. Earlier chapters taught you how Canadian payments are initiated, validated and routed, and how clearing differs from settlement in principle. Here you watch the settlement half of the ACSS lifecycle do its work: direct clearers enter what they exchanged, bilateral obligations net into single positions, each net obligation settles in central-bank money across Bank of Canada accounts, and completion leaves evidence that posting, reporting and reconciliation can trust. Nothing in this chapter moves at wire speed, and that is the point. ACSS settlement is deferred, netted and deliberate — liquidity-efficient for the country's retail volume, conditional where a wire is final, and utterly dependent on discipline at every handoff.
A working rule for this chapter is simple: clearing establishes what is owed, settlement discharges it, posting applies it to accounts, availability lets the beneficiary use it, and finality makes it irrevocable — five events, five timestamps, five proofs. Most settlement confusion in banks comes from collapsing two or more of these into one word like "completed" or "done." This chapter never lets you do that. Every section asks which of the five you are looking at and what evidence proves it happened.
- Clearing is the calculation. Items exchanged between direct clearers are offset and netted until each clearer has one net position for the date. Proof: entered totals and the resulting position.
- Settlement is the discharge. Net obligations are extinguished through Bank of Canada settlement accounts, with each net debit funded via a Lynx payment. Proof: settlement confirmation for the date.
- Posting is the bookkeeping. The bank debits and credits customer and internal accounts to reflect what settlement decided. Proof: balanced ledger entries keyed to the settlement reference.
- Availability is the customer promise. The beneficiary can use the funds — withdraw, spend, or see them as usable balance. Proof: the bank's availability policy applied to the posted item.
- Finality is the point of no return. The payment can no longer be unwound unilaterally between participants. Proof: the rail's finality rule plus settlement evidence for the item.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- narrate the full ACSS settlement lifecycle for one business date, from totals entry through clearing, settlement, funding and completion, naming the evidence each stage leaves;
- separate clearing, settlement, posting, availability and finality crisply, with the correct timestamp and proof for each;
- explain who does what among Payments Canada, the Bank of Canada, direct clearers, clearing agents and indirect clearers, and where each responsibility boundary sits;
- describe how bilateral obligations become one multilateral net position per direct clearer, and why debits must equal credits before anything settles;
- explain how net obligations settle in central-bank money via Bank of Canada accounts, with direct clearers funding net debits through Lynx payments;
- distinguish B2 manual clearing-log preparation from B9 National-Failure manual balancing without inventing procedural detail;
- interpret business days, relative exchange and settlement windows, and value dates as customer-impact promises;
- place fraud, sanctions, AML and operational controls at the correct gates of the settlement lifecycle;
- use reject, return, adjustment, recall and investigation precisely in a settlement context, with every recovery linked to its original;
- explain settlement accounting, liquidity forecasting, settlement advices and three-way reconciliation as the proof layer;
- describe what a bank must build, test and staff before it can settle safely, including fallback and re-drive capability;
- correct common misunderstandings such as "exchange equals settlement," "a funded position means customers are paid," and "Lynx and ACSS settle the same way."
For a roughly 60-minute core session, spend about 25 minutes on Sections 1–4 (business context, participants, processing, and the core clearing-to-completion walkthrough with the first two diagrams), 15 minutes on Sections 5–7 (data, windows, controls), 10 minutes on Sections 8–9 with the remaining three diagrams (imbalance handling, funding, completion evidence), and 10 minutes on Section 11 (the three fictional Canadian stories) plus Section 12 takeaways. Treat these timings as a study guide. The remaining depth — exception mechanics, posting nuance, implementation checklists — is 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 fictional Canadian examples
- Key takeaways and authoritative references
1. Business context and customer need
No customer ever asked for "settlement." They asked for payroll that lands before the weekend, a supplier paid on the value date the contract demands, a government benefit available on the promised morning, a rent collection that clears without surprises. Settlement is how the banking system keeps those promises at scale — and ACSS settlement keeps them for the overwhelming bulk of Canadian retail volume. Canada's retail batch payment system, made up of ACSS and the US-dollar USBE application, carries about 99 per cent of daily transaction volume across Payments Canada systems. In 2025, ACSS alone processed about 10.6 billion items worth about CAD 10 trillion, while Payments Canada systems together cleared and settled about CAD 103 trillion — roughly CAD 411 billion every business day. When you read those numbers, read them as promises: billions of individual expectations that Friday means Friday, each one depending on positions balancing and funding completing the next business morning.
The customer need this chapter serves is certainty about value dates. A value date is the date on which money is contractually considered to have moved — the date interest starts or stops, the date a supplier considers an invoice paid, the date payroll counts as received. Everything in the settlement lifecycle exists to make value dates real rather than aspirational. When an employer releases payroll for Friday, the settlement lifecycle is what converts "we sent the file" into "every receiving bank's obligation for Friday value was discharged in central-bank money." When a property manager collects a thousand pre-authorised debits, the lifecycle is what converts a batch of pulls into collected funds the business can actually disburse against — after returns have had their say. Product owners who internalise this stop writing requirements like "payments settle same-day" and start writing "obligations for value date D are discharged during the settlement window for D, evidenced by completion confirmation, with customer availability per receiving-bank policy and returns monitored per stream rights." The second version can be built, tested and defended. The first cannot.
Deferred net settlement is an economic choice, and bankers should be able to defend it in plain language. Canada could settle every retail payment individually in real time, the way Lynx settles each wire gross with immediate finality — and indeed Lynx did settle about CAD 93.3 trillion across only 13.6 million items in 2025, which tells you exactly what gross settlement costs in liquidity per payment. Retail payments invert that ratio: enormous counts, modest individual values, heavy return rights. Netting thousands of bilateral obligations into one position per clearer per date means each direct clearer funds a single net debit or receives a single net credit instead of moving every item's value individually. The liquidity saving is what makes payroll, PAD collections, bill payments and cheque clearing affordable at national scale. The price is timing and conditionality: obligations discharge the next business morning rather than instantly, and many retail items carry return rights that a settled wire simply does not have. Neither model is better in the abstract. The skill is matching the obligation to the model — and this chapter teaches you what the deferred-net model demands from everyone who touches it.
Consider what failure costs, because settlement teams are funded in proportion to management's imagination of failure. A missed exchange window re-dates thousands of value dates at once: payroll promised Friday becomes Monday value, and the employer — not the network — absorbs the employee-relations damage while the bank absorbs compensation claims and emergency payroll reruns. A funding shortfall on settlement morning delays the entire date, not one payment: every clearer waiting on the balanced completion waits with it. A totals-entry error that goes undetected poisons the position calculation, and every downstream proof — advices, postings, reconciliation — inherits the error until someone traces it back to the input. None of these failures is exotic. Each is a normal Tuesday when discipline slips, which is why this chapter treats controls, re-verification and honest delay communication as core settlement skills rather than administrative overhead. The customer never sees the position calculation. They see whether Friday meant Friday, and they judge the bank accordingly.
Collections deserve explicit attention because newcomers file settlement under "payouts" and forget that every PAD collection, bill payment and cheque deposit must also settle. A collection settles in the same lifecycle with the direction of obligation reversed and authority playing a larger role: the payer's bank owes the payee's bank rather than the reverse, and the debit rests on a mandate or agreement that can be challenged after the fact. That challenge — the return — is a settlement event in its own right, unwinding through the same positions-and-funding machinery on a later date. Analysts who design collections as "payments backwards" miss this: the settlement lifecycle must be operable in both directions, with return rights, adjustment flows and re-settlement built in from day one. Section 8 takes this apart; for now, hold the principle that every collection you promise a corporate client implies a settlement position your bank must be ready to fund.
2. Participants, responsibilities and system boundaries
Settlement works because five kinds of participants each do their part and none does another's. Confusion about who owns which step is the root cause of most settlement incidents that are labelled "system errors" but are really accountability gaps. Learn the map cold.
Payments Canada owns and operates ACSS and makes the by-laws, rules and standards that govern it — including the exchange, clearing and settlement procedures, the stream rules, and the manual balancing and settlement procedures referenced later in this chapter. When this chapter says "the rules require," it means Payments Canada's legal framework for the retail batch system, with versions posted online as in force. Payments Canada does not settle anything itself: it provides the calculation, the procedures and the governance. Settlement happens on the books of the Bank of Canada. This boundary matters practically. A question about whether a total was entered correctly goes to operating procedures and participant discipline; a question about whether an obligation was discharged goes to settlement-account records. Escalate each to its owner.
The Bank of Canada plays two distinct roles that newcomers constantly merge. As overseer under the Payment Clearing and Settlement Act, it oversees Payments Canada payment systems and sets risk expectations. As settlement agent, it provides the settlement accounts on its own books across which ACSS obligations are finally settled in central-bank money. ACSS settlement-account holders meet their net settlement obligations by Lynx payments; an institution that is not a direct Lynx participant must arrange for a direct Lynx participant to do that on its behalf. Oversight asks “is the system safe?” Settlement agency answers “did the obligation settle on the Bank’s books?” The same institution has two functions and two evidence trails.
Direct clearers settle their own ACSS obligations; group clearers also have direct ACSS settlement responsibilities for their groups. A direct clearer enters its exchange totals, receives its net position, maintains its settlement account at the Bank of Canada, and meets a net debit through a Lynx payment — or receives its net credit when settlement completes. A direct clearer may also act as a clearing agent for indirect clearers; the agent’s system-level position is settled in ACSS, with bilateral accounting outside ACSS.
Clearing agents, group clearers and indirect clearers form the settlement chain for institutions that do not settle directly. An indirect clearer is represented by a clearing agent. The agent exchanges and settles for the indirect clearer, and the agent’s ACSS position is the one settled at system level. Rule D2 requires a clearing agent to hold and operate a settlement account for each indirect clearer it represents; that does not make the indirect clearer a direct ACSS settlement participant. Agent and indirect clearer then settle between themselves under their agreement covering timing, information and risk. Group clearers apply a related model to their groups. Do not describe bilateral terms as an ACSS rule unless the cited rule says so.
Customers, corporates and service providers sit outside settlement but determine whether it succeeds. The corporate that submits a clean, balanced, on-time file makes settlement boring; the one that submits duplicates, late repairs or unfunded payables makes settlement exciting in the worst way. Service bureaus, payment processors and vendor gateways that prepare files or operate connectivity act as hands, not owners: accountability for totals, funding and customer promises never transfers with the outsourced work. Write that sentence into every vendor contract discussion you ever have. When a bureau's file corrupts stream splits, the direct clearer still owns the entered totals, still funds the position, and still answers the customer — then pursues the vendor. Banks that forget this learn it during their first settlement-break post-mortem.
Two neighbouring systems complete the map. Lynx, Canada's live high-value RTGS system launched in September 2021 replacing the LVTS, settles each payment individually and immediately in central-bank money with real-time finality — and doubles as the funding rail through which ACSS net debits are paid. USBE, the US-dollar bulk exchange application, clears USD items for Canadian institutions but settles outside the Bank of Canada, through correspondent banks in New York — a boundary worth stating explicitly whenever nostro funding and Canadian-dollar settlement appear in the same requirement. Neither system is ACSS, and neither excuses misunderstanding ACSS: Lynx finality does not attach to batch items, and USBE obligations never touch a Bank of Canada settlement account.
3. Initiation, validation and bank processing
Settlement never sees a raw customer instruction. By the time the settlement lifecycle begins, initiation and validation have already converted customer intent into exchange-ready items — or rejected what could not be made ready. This section covers that conversion from the settlement lifecycle's point of view: what settlement assumes has already happened, what it verifies anyway, and how bank processing turns millions of validated items into the totals each direct clearer enters.
Settlement assumes three things about every item, and operations staff should be able to recite them. First, the item was authorised: a payroll credit rests on the employer's instruction and funding arrangement, a PAD rests on a mandate that can be produced on demand, a cheque rests on a genuine negotiable instrument. Second, the item was validated: format, routing, account existence, amount integrity, duplicate status, limit and balance checks all passed at the sending bank before release. Third, the item was routed deliberately: someone decided this item clears through ACSS in a specific stream with a specific value date, rather than travelling on-us, by wire, or by any other path. If any assumption is wrong, settlement still processes the item — clearing nets what was entered, not what should have been entered — and the error surfaces later as a return, an adjustment, or a customer complaint. This is why validation gates sit before exchange, never after: settlement is a calculator with no judgement, and feeding it invalid inputs produces precisely calculated wrong answers.
Bank processing between validation and exchange does four jobs. Aggregation gathers validated items into batches per stream and destination clearer — AFT credits for direct deposit, PAD debits for collections, imaged cheques, bill payment remittances, point-of-service entries, each in its own category with its own handling. Splitting separates on-us items (sender and receiver inside the same institution, settled by internal posting with no ACSS position involved) from interbank items that must be exchanged. Beginners routinely overestimate on-us share; in a concentrated banking market more stays on-us than intuition suggests, but every interbank item is a settlement obligation in waiting and must be identified exactly. Totals computation produces the control figures each direct clearer enters: volumes and values per stream per counterpart clearer, with hashes and balancing figures that prove nothing was lost between validation and entry. Release authorisation confirms cutoff compliance, funding readiness for the expected position direction, and dual control over the release itself. Each job leaves evidence — batch registers, split reports, control totals, release logs — and reconciliation in Section 9 will demand all of it.
Cutoffs govern this entire section, so understand them as economic commitments rather than timetable trivia. An exchange window closes when it closes; items validated after the window belong to the next business date with the next date's value. The bank's internal cutoffs for customers must therefore sit ahead of the network window with enough margin for validation, repair, approval and release — and that margin is a business decision with a cost. Generous customer cutoffs win business and lose sleep: every late file that operations "squeezes in" borrows against repair time, and a file squeezed past the point of safe validation becomes a settlement position containing items nobody verified. Product owners should publish the most restrictive applicable constraint, automate the hard stop, and give every promise a fallback ("missed today's window" must route somewhere explicit — next date, or a wire at wire pricing with customer consent — never into informal requests to the network, which does not negotiate). The settlement lifecycle is kind to banks with disciplined cutoffs and merciless to banks without them.
Rejects are the processing stage's proudest output, and healthy banks celebrate a high early-reject rate the way manufacturers celebrate catching defects before assembly. A reject stops an item before exchange: invalid transit, closed account, malformed record, failed mandate check, duplicate of an already-released item, over-limit file. The rejected item never enters any clearer’s totals, never touches a position, never needs a return — it goes back to the originator with a code and a repair path. Contrast this with a return, which unwinds an already-exchanged item through later settlement machinery at full cost to timelines, fees and customer experience. Every dollar a bank spends on validation and repair tooling returns itself many times over in returns avoided. When operations managers ask where to invest, the answer is almost always the same: earlier. Catch it in validation and it costs a message; catch it in settlement and it costs a business date; catch it from the customer and it costs the relationship.
4. Clearing, exchange, settlement and finality
This is the core of the chapter. Read it with the first two diagrams open, and trace one business date through five phases: exchange, clearing, the settlement window, funding, and completion. Each phase transforms the output of the previous one, each has a distinct owner and distinct proof, and skipping or blurring any phase is how settlement breaks get their start.
Exchange is the physical and electronic movement of items and totals between direct clearers. Paper-originated items follow cheque exchange mechanics through regional exchange points; electronic items move as files and records through secure networks. At the end of exchange, each direct clearer or group clearer enters the rule-defined totals for items exchanged — volume and value by stream and counterpart. For some streams the receiving clearer enters the figures; for others the delivering clearer does. B2, not a generic “owed funds” shortcut, determines the entry responsibility. If a clearer’s entered totals misstate what it exchanged — a stream miscoded, a counterpart misdirected, a file counted twice — the position calculation inherits the error exactly.
Clearing converts entered totals into obligations. The system offsets what clearers owe each other bilaterally and nets the results multilaterally until each direct clearer holds exactly one net position for the settlement date: a single debit to pay or a single credit to receive that represents thousands or millions of individual items. Study the fictional netting diagram until the maths feels obvious — three invented banks, six bilateral obligations, three pairwise nets, one position each, debits equalling credits to the cent. Real clearing does precisely this at national scale across every stream simultaneously.
The diagram above compresses the whole logic of clearing into one checkable fact: the system must balance. Total debits equal total credits, always, by construction — and if they do not, the defect is in the inputs, never in the arithmetic. That single insight organises every settlement investigation you will ever run. A position you cannot explain is an entered total you have not verified; a date that will not balance is a file, a stream split or a counterpart allocation you have not yet found. Clearing also fixes the boundary with on-us items decisively: anything that stayed inside one institution never entered any total, never touched any position, and must never appear in settlement proof. When auditors ask "is this item in the position," the answer comes from the split report, not from anyone's memory.
The settlement window discharges the positions clearing calculated. Net balances for a business date settle during the settlement window on the following business morning, in central-bank money across settlement accounts on the books of the Bank of Canada. Trace the relative timeline below and notice what it does not contain: no duplicated clock times, because exact windows belong to the in-force rules, stream schedules and closure calendar. Exchange precedes clearing; clearing precedes settlement; settlement evidence precedes downstream posting and reporting. Weekends and statutory holidays shift the pattern to the next business day.
The timeline above is worth memorising as a sequence, not a schedule. Analysts who internalise "exchange, then clearing, then funded settlement, then completion, then posting" can place any incident, any customer question and any system message in seconds. Analysts who memorise times instead of sequences are helpless the first time a holiday, a delay or a rule change moves the times. Teach the order to every new joiner; look up the times in the current rules every time you need them.
Funding is how each net debit gets paid. Every direct clearer or group clearer in a net debit position meets its full ACSS obligation through a Lynx payment to its Bank of Canada settlement account. The Bank of Canada policy calls this the way ACSS settlement-account holders meet their net settlement obligations; an ACSS holder that is not a direct Lynx participant must use a direct Lynx participant. Debits and credits are then settled on the Bank’s books in central-bank money, subject to the applicable ACSS procedures. Treasury forecasts from entered totals, with bilateral agent funding handled under the applicable arrangement. Settlement discharges obligations; funding provides the money; neither substitutes for the other.
Completion and finality close the date. Completion is the confirmed state in which every position for the date is extinguished, confirmations and advices are issued, and the evidence trail — exchange totals, positions, settlement records — is available for posting, reporting and reconciliation. Finality in the ACSS context must be stated with care: settlement between direct clearers for the date is complete and confirmed, but many underlying retail items retain return rights under stream rules — an NSF PAD, a dishonoured cheque, a bill-payment error correction — that unwind the customer-level economics on later dates through new settlement activity. This is the precise sense in which ACSS finality differs from Lynx finality. A settled Lynx payment is final and irrevocable between participants immediately; a settled ACSS date is complete as a settlement event while specified items remain returnable under their rules. Both statements are true simultaneously, and confusing them produces exactly the availability-policy errors examiners penalise: funds made available against batch credits that are spent before a valid return arrives. State it crisply to every stakeholder: the date settled; the item may still return. Posting, availability and returns policy must all be designed around that sentence.
B2 and B9 are not a generic “balancing” shortcut. Rule B2 covers manual preparation of clearing logs when computer-generated logs are not possible, including a workstation’s inability to connect to the ACSS/USBE web application. Rule B9 covers manual balancing for settlement only when a National Failure of ACSS is in effect and Payments Canada, in consultation with the Senior Operational Committee, determines that migration to manual balancing is required; it may also suspend clearing for the current cycle. This chapter does not reproduce the procedures. When a failure occurs, identify which rule and current contingency playbook apply, preserve prescribed evidence, and avoid invented balancing entries or informal bilateral workarounds.
5. Data, identifiers, messages and references
Settlement runs on references. Every totals entry, position, funding payment, advice and reconciliation break must key to identifiers that survive unchanged from validation through completion — because the moment a reference is rewritten, truncated or dropped, the evidence chain it belonged to becomes unprovable. This section names the data settlement actually consumes and the reference discipline that keeps it joinable.
The fundamental settlement record is the entered total: for each stream and counterpart clearer, the volume and value declared under the applicable rule. Some streams require the receiving clearer to enter the figures; others require the delivering clearer. Streams categorise the item being settled — AFT credits, AFT debits, imaged paper, remittances and point-of-service entries — with their own handling and return characteristics. Miscoding a stream or counterpart misstates the position; bank control totals must prove what was entered.
Around the totals sits a small constellation of identifiers that settlement staff use daily. Institution numbers and clearing arrangements identify who exchanges with whom; the Financial Institutions Branch Directory provides the routing reference the industry shares. The settlement date keys every position, funding payment and completion record — one date, one position per clearer, no exceptions — and value-date logic across the bank must agree with it exactly. Control totals and hashes from bank processing prove that what was validated is what got entered; any break between processing registers and entered totals is the first place an investigation looks. Funding references link each Lynx payment to the position it discharges, so treasury, operations and reconciliation all point at the same obligation. And return and adjustment references on later dates link backwards to the original settlement date and item, preserving history instead of overwriting it. None of these identifiers is glamorous. Together they are the difference between a settlement operation and a settlement hope.
Message standards enter the story at the funding boundary. ACSS exchange and clearing use stream-specific records and procedures; the current rules include longstanding stream identifiers and ISO AFT credit/debit streams. Funding moves through Lynx, whose payment messaging supports ISO 20022. Banks operating both systems must maintain a provable mapping from the ACSS position to the Lynx payment and general ledger; exact reference fields are implementation choices unless a current rule or message specification says otherwise.
Reference preservation has one enemy above all others: enrichment that rewrites. Every time an item passes through format conversion, stream reclassification, repair, or agent consolidation, some system is tempted to generate a fresh reference "for convenience" and discard the original. Each such rewrite severs one link in the chain that investigations, returns, adjustments and customer enquiries will need weeks later. The rule is absolute and cheap to enforce: original references travel with the item forever; every system-added identifier is appended, never substituted. Test this specifically — submit items with long, awkward, accented, bilingual references through every conversion your bank performs and verify byte-level survival — because Quebec accented names, long legal-entity titles and structured remittance data will find every truncation bug your test data missed. Settlement evidence that cannot be joined to the customer instruction is evidence of nothing.
6. Rules, cutoffs, service levels and customer impact
The settlement lifecycle operates inside a rule framework that defines what must happen, a calendar that defines when, and service levels that translate both into customer promises. This section teaches you to read all three as one connected commitment — and to spot instantly when a customer promise has no operational foundation behind it.
The rule framework is Payments Canada’s legal fabric for the retail batch system: by-laws, rules, standards and procedure documents, with versions posted online as in force. Exchange, clearing, settlement, return, adjustment and contingency questions must be answered from the applicable current document. As of this audit, Payments Canada’s rules page says ACSS rules were updated effective July 27, 2026; operators must open the current rule and procedure version rather than rely on a remembered section number.
The calendar is simpler than newcomers fear and more consequential than they expect. Payments Canada systems operate Monday to Friday excluding statutory holidays, with the definitive closure schedule published by Payments Canada. Business-date logic follows from that single fact: positions for a business date settle in the window on the following business morning, weekends and holidays push settlement to the next business day, and value dates promised to customers must be computed on business days, not calendar days. The failure mode is always the same — a promise counted in days that the calendar counts in business days. Payroll released to "settle in two days" across a holiday weekend, a supplier paid "Friday value" from a Thursday evening file that missed its window, a collection forecast that books weekend PADs as Monday cash: each is a calendar error wearing the costume of a system delay. Build a business-day calculator into every product surface that promises dates, feed it the published closure schedule, and test it across every holiday combination your auditors can devise. This is inexpensive engineering against one of the costliest error classes in retail payments.
Windows — exchange windows and the settlement window — are rule-defined phases with boundaries. This chapter avoids duplicating system-wide clock times, but some rules contain exact times for particular notices or obligations; operators must use the current rule, stream schedule and closure calendar for the applicable path. Banks layer internal cutoffs ahead of those boundaries and must label those as bank-specific.
Customer impact is where windows become money. A missed exchange window re-dates value: interest calculations shift, supplier terms breach, payroll misses the weekend, and the bank's options narrow to re-release for the next date or reroute time-critical items by wire with customer consent and wire pricing. A delayed settlement window freezes availability assumptions: receiving banks that posted provisional credits against expected settlement carry exposure until completion confirms, and corporate treasurers watching for incoming funds see nothing until the date completes. A return-heavy date — Monday mornings after a weekend of PAD activity are the classic example — means collected balances must be treated as provisional until return rights expire, whatever the ledger balance suggests. Teach customer-facing teams these three translations until they are reflex: missed window means re-dated value, delayed settlement means held availability, heavy-return dates mean provisional collections. Customers forgive delays they were warned about in language they understood. They do not forgive "the system was down" when the system was operating exactly as designed and the bank simply promised what the windows could not deliver.
7. Fraud, compliance and operational controls
Settlement is a backstop, not a first line of defence — but it is a backstop with teeth, because several fraud and compliance failures are cheapest to catch at settlement gates even when earlier gates missed them. This section places each control at its correct stage and states plainly what settlement controls can and cannot do.
Before exchange — bank implementation and compliance controls, not an ACSS screening service — validation and processing must apply the institution’s documented AML/sanctions, fraud, mandate, duplicate and release controls. The timing and decision logic are bank- and risk-policy-specific; ACSS itself calculates and settles what participants enter. A bank should not let an item proceed when its own legal or risk controls require a hold, and it must retrieve mandate and screening evidence for later returns or investigations. Settlement adds totals verification, an independent agreement between processing registers and entered totals by stream and counterpart. “No verification, no entry” is an internal control, not a quoted ACSS rule.
During the settlement window, controls shift to positions and funding. Position monitoring confirms that the calculated net matches treasury's forecast from entered totals within tolerance — a mismatch means an input changed after forecasting, and funding must not proceed on a forecast the position contradicts. Funding authorisation applies dual control and limit checks to each Lynx payment before release: the right amount, the right settlement account, the right date reference, released by the right people. Segregation of duties separates the hands that enter totals, authorise funding and confirm completion, so no single person can create, pay and certify the same obligation. And completion confirmation requires positive evidence — the date's records showing extinguishment — rather than absence of alarms. Each control answers one question an auditor will eventually ask: who verified the input, who authorised the money, who confirmed the outcome, and where is each fact recorded.
Compliance overlays the lifecycle with record-keeping and reporting duties that outlive every business date. Settlement records — entered totals, positions, funding payments, completion confirmations, advices, adjustments with their original linkages — must be retained and retrievable for audit, dispute, tax and regulatory needs, under the retention expectations that apply to the bank. Transaction monitoring and regulatory reporting obligations consume settlement data alongside channel and screening data; the bank's ability to explain any settled item end to end — who instructed, how it was screened, how it cleared, when it settled, where it posted — is the practical test of compliance readiness. State this as an operating requirement, not a legal lecture: if investigations cannot reconstruct an item's full journey from retained, reference-keyed records, the bank is not compliant in any sense that matters, whatever its policies claim. Build retention and retrievability into settlement systems from day one; bolting them on after launch costs multiples and still leaves gaps in the early dates.
Name what settlement controls cannot do, because overclaiming controls is itself a control failure. Settlement cannot detect an authorised-push scam — the instruction was genuine, the fraud is in the persuasion behind it, and only pre-release validation with callbacks to verified details stands a chance. Settlement cannot cure a sanctioned payment — if screening failed upstream, the obligation now exists and unwinding it is a legal and correspondent matter, not an operational one. Settlement cannot make an unfunded corporate payable good — the file will clear and the position will fund from the bank's resources while recovery pursues the customer. Controls at settlement catch errors of amount, duplication, misdirection and process — the bank's own mistakes, which are plentiful enough to justify every control in this section. Fraud and compliance belong primarily upstream; settlement's job is to refuse to compound upstream failures with settlement failures, and to leave evidence so complete that every failure teaches its lesson.
8. Exceptions, investigations and recovery
Settlement dates do not always complete cleanly, and the banks that handle bad dates well are the ones that designed for them in advance. This section gives you precise language for what can go wrong, a generic control sequence for dates that will not balance, and recovery mechanics that preserve history instead of destroying it.
Name each exception precisely, because the name selects the recovery path. A reject stops an item before exchange — it never entered any total and needs no settlement action, only a coded repair message to the originator. A return sends back an already-exchanged item under stream return rights — NSF, closed account, dishonoured paper, invalid mandate — unwinding its economics through settlement activity on a later date. An adjustment corrects a value or allocation error — wrong amount, wrong counterpart, misdirected stream — with a linked correction that references the original entry rather than overwriting it. A recall or return request asks for cooperation where no unilateral right exists, which in ACSS practice mostly concerns items whose settlement finality the rules treat as complete but whose customer-level outcome is disputed. An investigation is the case that tracks uncertainty itself: a missing credit, an unmatched total, a customer claim, held open with an owner and a deadline until the evidence resolves it. Misnaming any of these — calling a return a reject, an adjustment a new payment, an investigation a complaint to be waited out — routes the recovery down the wrong procedure and usually destroys the linkage auditors will demand.
When positions or bank control totals do not agree, use the following bank operating control sequence, not an asserted ACSS procedure. Hold affected local posting and downstream completion actions while the break is owned; re-verify logs, totals, stream and counterpart allocation; correct the source input with linkage and re-drive only through the supported process. Then identify whether the issue is a local connectivity/log problem covered by B2, a National Failure for which B9 has been invoked, or another stream-specific exception. Escalate under the current rulebook and ACSS/USBE contingency playbook; do not assume that a generic “hold and re-drive” sequence changes ACSS status. Communicate the evidence-supported impact and revised customer value date in parallel.
The diagram above is deliberately generic. It states no procedures, no times and no default steps, because those belong to the in-force rulebook and this chapter intentionally does not reproduce them. What it fixes is attitude and order: detect, hold, verify, correct, re-drive, escalate — with communication running in parallel from the first moment of delay. The communication template for a held date has exactly three honest sentences: exchange is held and why, settlement is re-timed to the next achievable window, and customer postings follow completion with stated value dates. Anything vaguer ("experiencing delays") invites every downstream team to invent its own story; anything more specific than the evidence supports ("fixed by ten") manufactures a second incident when the prediction fails. Operations managers should rehearse this communication the way fire crews rehearse evacuation: rarely needed, invaluable when needed.
Recovery mechanics share one inviolable principle: link, never overwrite. Every return references the original item and its settlement date. Every adjustment references the entry it corrects. Every re-driven calculation preserves the superseded run as history. Every investigation case accumulates evidence without editing it. This is not bureaucratic fussiness; it is what makes re-settlement reconcilable. A return that settles on Thursday must join in reconciliation to the item that settled the previous week — and that join works only if the linkage was created at recovery time, not reconstructed from memory during month-end. Banks whose operators "fix it quickly" by re-entering items as new business create orphans: settled money with no ancestry, unmatchable, ageing, and eventually written off or double-counted. Speed in recovery means fast detection, fast ownership and fast linkage — never fast re-entry.
Investigations deserve a final word because settlement investigations differ from customer-service enquiries in one decisive respect: the investigator must think in positions, not payments. A missing customer credit is rarely a lost payment; it is usually a correctly settled position followed by a failed posting, a misapplied return, or an agent that received value but has not yet distributed it. The investigation therefore walks the chain backwards from completion evidence — was the date complete, was this clearer’s position in it, was this stream’s total entered, was this item in the total, did the receiving bank post it — rather than starting from the customer’s anxiety and working forward. Staff the settlement investigation function with people who can read positions and empower them to demand evidence from every hand in the chain, including agents and vendors. Uncertainty with an owner and a deadline is an investigation. Uncertainty without one is a rumour, and rumours do not reconcile.
9. Posting, accounting, liquidity, reporting and reconciliation
Completion evidence is the foundation; this section builds the house. Posting applies settlement decisions to accounts, accounting records the bank's own obligations, liquidity management ensures funding is there when the window opens, reporting tells every stakeholder what happened, and reconciliation proves the whole story agrees. Each depends on the previous one, and all five depend on the completion evidence from Section 4.
Liquidity and funding translate positions into money in motion. Treasury's settlement-day job begins the previous day with forecasting: entered totals by stream and counterpart predict the direction and size of this morning's position, letting funding be arranged — incoming credits applied, intraday resources positioned, agent obligations for indirect clearers' shares prepared — before the window opens. On settlement morning, funding executes: each net debit travels as a Lynx payment to the clearer’s Bank of Canada settlement account, each net credit is received when the balanced date releases, and agent-to-indirect settlement follows bilaterally under standing agreements. The funding-flow diagram below shows the shape every banker should be able to sketch from memory.
The diagram above carries three lessons that text alone rarely lands. First, funding pays an obligation clearing already fixed — it creates nothing, negotiates nothing, and nets nothing further. Second, indirect clearers are invisible to ACSS settlement itself; their agent's single position absorbs them, which concentrates operational risk at agents and makes agent oversight a first-order safety matter. Third, a funding shortfall delays the date rather than rewriting anyone's position — the obligation waits, the window waits with it, and every downstream promise must be re-timed honestly. Treasury teams that forecast from entered totals, pre-position for their indirects' shares, and maintain visible contingency for forecast error make settlement boring. Teams that fund from memory, hope and last month's average make it eventful.
Settlement accounting records what funding did. The bank books its settlement activity against the confirmed position: the funding payment out (or incoming credit), any fees and charges per published schedules, and the internal clearing or suspense entries that bridge settlement timing to customer posting timing. Two disciplines keep these books clean. First, book from completion evidence, not from forecasts or screens — the ledger must reflect the settled position, and forecast-to-actual differences belong in variance reporting, not silently absorbed. Second, clear suspense daily with ageing and ownership: every bridging entry must resolve to a posted customer item, a confirmed return, or an owned investigation within the defined window, because suspense that ages silently is where double-posts, wrong-account credits and phantom balances hide. Finance, operations and reconciliation must read the same ledger; three versions of settlement truth is two too many.
Customer posting and availability apply settlement to people. Receiving banks credit beneficiaries per their posting policies and availability schedules — which is where the five crisp distinctions from this chapter's opening do their daily work. Posting follows completion; availability follows posting policy; neither equals settlement; returns may still arrive. A payroll credit posted Friday morning with immediate availability reflects a bank judgement that this stream's return risk justifies it, not a settlement fact that guarantees it. PAD-heavy corporate collections should be reported with return exposure visible, so treasurers do not disburse against provisional balances. Bill payments show as paid per biller-notification rules while the underlying settlement follows batch timing behind the scenes. Product owners must document the posting-and-availability policy per stream, per channel, in language operations can execute and customers can understand — and every policy must state its return-risk assumption explicitly, because the assumption is what fails on heavy-return dates.
Reporting turns settlement facts into stakeholder-specific truth. Operations needs position confirmations, completion status and break alerts in real time through the window. Treasury and finance need funding confirmations, forecast-versus-actual variance and fee accounting. Clearing agents need status their indirects can consume — which means timely, reference-keyed, machine-readable status, not end-of-day narrative. Corporate customers need settlement-date confirmation keyed to their original file references, returns files with usable codes, and adjustment advices that link to originals. Regulators and auditors need retained, retrievable, reference-keyed records on demand. One settlement event, five audiences, five report shapes — and the reference discipline from Section 5 is what lets every shape join back to the same facts. Reporting that cannot be traced to completion evidence is storytelling; ban it. Reconciliation then proves the date, as the diagram below shows.
The diagram above answers the only question reconciliation ever asks: did every obligation for the date settle in full, and can we show it? No payment story in this academy is complete until instruction, clearing evidence, settlement proof and books agree on reference, amount, date and status — and the bank can produce that agreement on demand. Treat unreconciled settlement as unfinished business regardless of what any screen displays, age every break visibly, and let management see repeat causes weekly. Reconciliation is not the back office confirming the front office's success. It is the process that decides whether success happened at all.
10. Bank implementation, testing and resilience
Knowing the settlement lifecycle and operating it are different capabilities. This section translates the chapter into build scope, testing discipline and resilience expectations that product owners, engineers and operations managers can plan against — staying at settlement-lifecycle level, with stream-specific configuration left to later chapters.
Implementation starts with architecture that respects the boundaries from Section 2. Channels and origination platforms own instructions. The payment hub owns validation, routing, stream assignment and release control. ACSS gateway services own exchange formatting, totals entry and clearing-record consumption. Treasury and liquidity systems own position forecasting and Lynx funding release. Core banking owns customer and suspense posting. Reporting services own advices and statements. Reconciliation and case management own matching, break ownership and investigations. These components exchange reference-keyed events rather than duplicating decisions — and the classic implementation errors all violate that principle: validating only in the channel so hub-released items bypass gates; screening only at release so warehoused items age past list updates; converting formats while dropping references; posting customer credits from channel status instead of completion evidence; letting the funding payment carry a reference no downstream system can join. Direct versus indirect participation shapes the build further: an indirect clearer builds agent-status consumption and bilateral settlement with its agent rather than settlement-account funding, while an agent builds multi-client position attribution, limit monitoring and per-client status distribution. Staffing is implementation too — coverage must extend through the settlement window, return activity and investigation hours, not merely through release hours.
Testing must prove the lifecycle, not just connectivity. Certification proves the bank can exchange; lifecycle testing proves it can settle. The minimum test portfolio covers: totals entry that rejects malformed, duplicate and over-limit submissions with correct codes; stream and counterpart allocation proven against split reports; position calculation agreement between the bank's forecast and the calculated net within tolerance; funding release with correct amount, account and date reference under dual control; posting correctness including no double-post on retry and correct suspense handling; reporting that joins every advice back to original customer references; reconciliation closure with break ownership and ageing; and full exception journeys — reject with repair, coded return with re-settlement linkage, adjustment with original linkage, missing-file detection, duplicate-entry detection, and a single investigation case tracked from uncertainty to evidenced resolution. Test data must include realistic Canadian content — bilingual and accented names, long legal-entity titles, structured remittance — plus failure injection: a gateway outage during exchange, a funding shortfall, a posting delay, stale reference data, a holiday-week calendar. Every scenario must answer the same three questions: which stages completed, which are pending, and what should the customer be told? If answering needs forensics, the implementation is not finished.
Resilience assumes components fail and requires graceful degradation without losing or duplicating obligations. Duplicate-safe retry everywhere — idempotency from release through totals entry to posting — so any retried step is provably harmless. Warehoused and in-flight work must survive outages with triggers and value dates intact, resuming in order rather than in a rush that creates duplicates. Exchange must be re-driveable without re-creating obligations: re-entering corrected totals, not re-releasing items. Posting engines must be pausable and resumable with proof of no gap and no overlap. Reporting must distinguish delayed from missing, so downstream teams wait rather than invent. Reconciliation must map the outage's footprint — exactly which dates, streams and counterparts are affected — and guide ordered catch-up. Add people and process: on-call coverage through settlement and return windows, incident communication in lifecycle states ("exchange held, settlement re-timed, postings follow with stated value dates"), and practiced fallback per procedure including the rulebook contingencies referenced in Section 8. Rehearse the bad morning twice a year with treasury, operations, finance and communications in the room. The date you need the rehearsal is the worst date to be writing the script.
11. Practical fictional Canadian examples
Theory settles when you watch settlement handle real-shaped pressure. This section works three fictional stories — invented institutions, people, amounts and relative timings used only to teach operating logic. None states system cutoff times; all speak in relative windows. None invents default or balancing procedures. Follow each story against the diagrams, then extract the control lesson before moving to takeaways.
Example (fictional): Prairie payroll — a direct clearer funds a Friday payday. Northgate Foods Ltd., a fictional Manitoba food distributor, submits its payroll file through its bank, a fictional direct clearer, ahead of the published customer cutoff: several thousand AFT credits for Friday value, with employee references and a control total. Initiation evidence is the file plus dual approval with a hash locking against re-release. Validation rejects a handful of lines — invalid transits, one closed account — with repair codes; the rest proceed. Processing splits out on-us items for employees banking at the same institution and assigns the remainder to the interbank AFT stream for Friday value. At exchange, the clearer enters its totals per stream per counterpart; clearing nets them with every other clearer’s entries into one position. The position is a net debit — Northgate’s bank owes more than it is owed for the date, as expected on a big payroll day — and treasury had forecast it from the entered totals. On settlement morning the bank sends a Lynx payment covering the full debit to its Bank of Canada settlement account; the date balances, credits release, completion confirms. Posting credits employees Friday morning while debiting Northgate’s funded account plus fees. Reporting gives the employer a funding debit advice and a confirmed-paid file keyed to original references; a small coded returns file follows on a later date for accounts that proved invalid after all. Reconciliation closes four ways: released items versus exchanged plus rejects, exchanged versus settled inclusion, settled versus posted minus linked returns, postings versus statements. The lesson: payroll settlement succeeds on initiation discipline, cutoff management and forecast funding — the position is never a surprise if the totals were verified.
Example (fictional): credit-union collection through a group clearer. Harbourview Savings, a fictional Nova Scotia credit union and indirect clearer, collects its members' monthly PADs — loan payments, insurance premiums, savings transfers — through its group clearer’s settlement arrangement. Harbourview owns mandate evidence and file quality; its agent owns totals entry, position funding and status information. On this particular date a duplicate submission — the same collection file released twice after a workstation retry — enters the agent’s totals before Harbourview’s duplicate check catches it. Clearing nets the doubled values faithfully, because clearing nets what was entered. The agent’s position forecast flags the anomaly: the indirect’s contribution is roughly double its recent pattern, and forecast-versus-actual tolerance trips before funding. Funding is held while operations re-verify inputs, find the duplicate, correct the entries with linked corrections, and re-drive the calculation to a balanced position. Settlement completes on the corrected position; Harbourview’s members see exactly one debit each; the incident case records detection, ownership, linkage and member communication. The lesson: the agent’s forecast tolerance caught what the originator’s control missed — defence in depth across the settlement chain works, but only if the agent treats indirects' pattern monitoring as its own control rather than someone else's problem. No member was harmed, and the evidence trail shows why.
Example (fictional): a heavy-return Monday and an honest delay. Lakeside Mutual, a fictional Ontario direct clearer, faces a Monday settlement shaped by a weekend of PAD activity and a cheque volume swollen by month-end bill payments. Exchange completes, clearing calculates, and the position is funded and settled normally — the date itself is clean. The pressure arrives after completion: returns begin flowing at volumes well above pattern — NSF debits from the weekend, several dishonoured paper items, a batch of invalid-account discoveries. Corporate clients watching collected balances see funds that are settled at position level but returnable at item level, and two treasurers prepare disbursements against balances that will not survive the week. Lakeside’s operations team executes the playbook this chapter prescribes: returns are processed as linked unwinds against original items and dates, corporate reporting shows collected balances with return exposure visible rather than bare ledger figures, availability policy for the affected streams is applied as documented rather than improvised, and each treasurer receives an honest, reference-keyed explanation of which credits remain provisional and under what rights. Nothing in the position breaks; no balancing procedure is needed; the date needed no escalation — only disciplined returns handling and truthful communication. The lesson: the date settled; the items may still return. Settlement competence includes managing the weeks after completion, not just the morning of it. Banks that report provisional collections as collected manufacture their own incidents; banks that show exposure keep their customers' trust through the heaviest return weeks of the year.
Hold the three stories side by side and the lifecycle's value becomes obvious. The payroll story is funding discipline: forecast from verified totals, pay the debit in full, post from completion. The credit-union story is input discipline across a chain: the agent verifies what the originator missed, linkage preserves history, members never feel the error. The Monday story is post-completion discipline: settled positions with returnable items, reported honestly until rights expire. Different pressures, same lifecycle, same demand for reference preservation and four-way proof. Any analyst who can narrate all three — naming the owner, the evidence and the fallback at each stage — is ready to operate settlement rather than merely describe it.
12. Key takeaways and authoritative references
Takeaways — the settlement logic you will reuse in every ACSS chapter that follows.
- One date, one lifecycle: exchanged totals become a single net position per direct clearer, the position settles in central-bank money, funding pays each debit in full, completion leaves evidence. Locate yourself in these phases before debating any detail.
- Clearing establishes what is owed; settlement discharges it; posting applies it to accounts; availability lets the beneficiary use it; finality makes it irrevocable. Five events, five timestamps, five proofs — never collapse them into "completed."
- The system must balance. Total debits equal total credits by construction, so every imbalance is an input defect — a total, a stream split, a counterpart, a duplicate, a missing file — never an arithmetic mystery.
- Net obligations settle in central-bank money via Bank of Canada settlement accounts; direct clearers fund net debits through Lynx payments. Funding pays a fixed obligation — it creates, negotiates and nets nothing.
- Direct clearers and group clearers have direct ACSS settlement responsibilities. Indirect clearers are represented by clearing agents; the agent’s system-level position settles, and Rule D2 requires the agent to hold and operate a settlement account for each represented indirect clearer. Bilateral timing, information and risk terms remain important.
- B2 is manual preparation of clearing logs when computer logs are unavailable; B9 is manual balancing for settlement only after the rule-defined National Failure invocation. Open the current rule and contingency playbook; never improvise balancing entries.
- Business days are Monday to Friday excluding statutory holidays under the current closure schedule. Windows have rule-defined boundaries; use the current rule, stream schedule and closure calendar rather than a remembered time.
- Settlement inherits validation’s failures without judgement. AML/sanctions, fraud, mandate and duplicate controls are bank implementation and compliance controls; ACSS does not perform those screenings. Totals must be independently verified against the bank’s processing records before entry.
- Name exceptions precisely — reject, return, adjustment, recall or return request, investigation — and link every recovery to its original. Overwritten history is unreconcilable history.
- When positions will not balance: hold completion, re-verify inputs, correct and re-drive, escalate under the rules — communicating honestly in parallel from the first moment of delay.
- No date is complete until instruction, clearing evidence, settlement proof and books agree on reference, amount, date and status. Reconcile four ways, age breaks with owners, and feed repeat causes back into validation.
- Build the lifecycle once — reference-keyed events, duplicate-safe retry, forecast funding, settlement-aware posting, complete reporting — then reuse it for every stream, every agent relationship and every bad morning.
Common misunderstandings, stated plainly. "Exchange equals settlement" — no, exchange moves items and totals while settlement discharges the resulting obligations the next business morning. "A funded position means customers are paid" — no, funding discharges clearer obligations; customer posting and availability follow under receiving-bank policy with return rights still live. "Lynx and ACSS settle the same way" — no, Lynx settles each payment gross with immediate finality while ACSS nets positions for deferred settlement with specified items returnable afterwards. "The date settled, so nothing can come back" — no, the date is complete as a settlement event while stream rules preserve item-level return rights. "Our vendor handles settlement" — no, hands can be outsourced but accountability for totals, funding and promises never transfers.
Authoritative references (official sources only; each supports a specific claim in this chapter). Links and rule versions were checked on October 5, 2026; recheck live rule pages before external publication.
- Payments Canada — Retail batch payment system (ACSS/USBE composition, 99% volume share, direct-clearer model, totals and next-morning settlement, 2025 ACSS summary statistics).
- Payments Canada — ACSS statistics (2025 totals, units, stream definitions and on-us exclusion notes).
- Payments Canada — High-value payment system — Lynx (live RTGS, finality, ISO 20022, inter-FI payments and 2025 statistics).
- Payments Canada — Rules & documentation (current versions; ACSS updated effective July 27, 2026).
- Payments Canada — Rule B2: Manual Preparation of Clearing Logs.
- Payments Canada — Rule B9: Manual Balancing for the Purpose of Settlement.
- Payments Canada — Rule D1: Direct Clearer/Group Clearer Requirements.
- Payments Canada — Rule D2: Clearing Agent Requirements.
- Payments Canada — System closure schedule.
- Bank of Canada — Settlement account policies for Payments Canada payment systems.
- Bank of Canada — Settlement account access policy for Lynx and ACSS.
- Bank of Canada — Payment systems the Bank of Canada oversees.
- Justice Canada — Canadian Payments Association By-law No. 3 — Payment Items and ACSS.
- Payments Canada — Real-Time Rail and Testing and launch (planned Q4 2026 launch; testing/onboarding, not ACSS production).
These sources support the chapter’s verifiable system claims: ACSS as the live retail batch system with USBE as its USD application; direct and group clearer participation; rule-defined exchange totals and net settlement on Bank of Canada books; ACSS net obligations met by Lynx payments; Monday-Friday operation except statutory holidays; and rulebook ownership of stream, return and contingency procedures. The 2025 ACSS figures are $10,606,975,666 items and $10,009,139,582 thousand (about $10.0 trillion), and the displayed Lynx 2025 figures are 13.6 million items and $93.3 trillion. The aggregate “about $103 trillion” statement is a rounded sum of the two official system pages, not a separate ACSS metric. RTR status: as of this audit date RTR is planned for a Q4 2026 launch and remains in collaborative testing and sequenced onboarding; do not describe RTR processing, settlement or finality as current ACSS production capability.
Chapter close and handoff. You can now follow any ACSS business date from exchanged totals to extinguished positions — and, more importantly, you know which of the five settlement events any question is really about. Later Block 3 chapters take each stream apart: what its items look like, what its return rights are, and where its exceptions bite. As you read them, keep asking the four proof questions of every story: where are the entered totals, where is the position, where is the settlement proof, and where is the posting — and do all four join on the same reference? Answer those, and settlement will always balance for you, even on the mornings it does not balance for the bank.
Diagrams in this chapter: settlement timeline across the business day (relative phases, no clock times); multilateral netting with a small fictional example; funding flow from direct clearer through Lynx to the Bank of Canada; settlement completion and evidence view; what happens when positions do not balance — all under /diagrams/payment-stories/canada/chapter-13/. All institutions, people, figures and timings in examples are fictional and labelled as such.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.