AFT Credit and Direct Deposit. Follow an AFT credit from originator submission to beneficiary posting and reporting.
Canada Payments & Collections · Block 4: AFT Credits and Direct Deposits · Chapter 17 of 75
Every second Friday, in thousands of Canadian workplaces, the same quiet expectation hangs in the air: the money will be there when people wake up. Nobody in those workplaces thinks about files, windows, clearing streams or settlement accounts. They think about rent due, groceries, a child's school fees. The AFT credit is the instrument that carries that expectation — the payer-initiated push payment that moves funds from an originator's account toward beneficiaries through Canada's retail batch system. A payroll run is the most familiar form, but the same mechanism carries supplier payments, pension and benefit disbursements, dividend payments, government direct deposits and a hundred other recurring disbursement rhythms. This chapter follows one such credit from the moment an originator submits a file to the moment a beneficiary sees a posted credit and both sides hold reporting they can reconcile.
The chapter stays deliberately at journey depth. It teaches the full lifecycle — submission, validation, funding, exchange, clearing, settlement, posting and reporting — with enough operating detail that you can explain each handoff, own each control and answer customer questions honestly. It does not go deep on payroll practice; payroll-specific depth belongs to Chapter 18, which takes employer payroll apart shift by shift. It does not catalogue corporate disbursement variants; those belong to Chapter 19. It does not teach return mechanics in full; returns, posting exceptions and customer-to-bank reconciliation belong to Chapter 20, and this chapter summarizes them only so the journey reads complete. The companion overview of Automated Funds Transfer in Canada, Chapter 16, sets the AFT frame this chapter walks through. Nothing here replaces the rulebook. AFT exchange in Canada is governed functionally by the Payments Canada rules framework — including the provisions practitioners know as Rule F1 for automated funds transfer and Rule F4 for related funds-transfer requirements — and the binding detail lives in the current published rules, standards and by-laws, not in any training chapter.
A few status facts anchor everything that follows, stated once so later sections can build on them. AFT credits are push payments: the payer initiates, the payer funds, and value moves toward the beneficiary. That direction is the whole difference between this chapter and the collections chapters of Block 5 — no mandate to pull, no payer authorization to evidence on the receiving side, just an originator's instruction backed by money already secured. Funding is a bank-and-originator control, not a universal ACSS rule: a bank may require prefunding or debit authority and verified cover before release under its customer agreement and risk policy. An AFT credit that fails those bank controls is rejected or held by that bank rather than released. Beneficiary posting follows receiving-institution controls: the receiving bank decides, under its account agreement, applicable rulebook duties and policy, whether each incoming credit is made available, is held/restricted, or is returned with a reason. Returns are possible for defined reasons — invalid or closed accounts, ineligible items and the other causes Chapter 20 teaches in full — and every section of this chapter preserves the original references those returns will need. Customer-channel cutoffs vary by bank, product and agent, but the current F1/F4 rules set ACSS exchange periods and deadlines in Eastern Time: receipt by 09:30:00, 16:30:00 or 21:00:00, on business days, for the three exchange periods. Use those as participant-processing rules, and use your bank's published schedules for customer cutoffs, together with the official system-closure calendar. ACSS, the retail batch system that carries AFT credits, is live. Lynx, the high-value system through which direct clearers settle their batch nets, is live. The Real-Time Rail is a planned instant system — industry planning points to a initial launch in Q4 2026 — and it appears in this chapter only where a banker needs to avoid routing today's volume to tomorrow's rail.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain in plain language what an AFT credit is — a payer-initiated push — and how it differs from a pre-authorized debit pull and from a wire;
- name the parties to an AFT credit — originator, originating bank, receiving bank, beneficiary, clearing agent where one stands in, Payments Canada and the Bank of Canada — and state what each owns;
- trace a credit from originator submission through validation, the funding and debit gate, release, exchange, clearing, settlement, beneficiary posting and reporting without confusing those stages;
- explain the funding rule precisely: prefund or debit under agreement on value date, before release, with rejects for insufficient cover rather than silent delay;
- describe how the originating bank validates a file — totals, routing, duplicates, dates, limits, approvals, screening — and why repair or reject must happen before release;
- explain what exchange, clearing, settlement, posting, availability and finality each mean for an AFT credit, and use each word correctly with customers and in incident tickets;
- describe what AFT data each item needs — institution, transit and account structure, file and item references, remittance — and why bad data must be repaired before exchange;
- explain business-day, window and cutoff discipline in relative terms and tell an originator when value is this-window batch versus next-window;
- place fraud, sanctions, anti-money-laundering and record-keeping controls at the correct point in the flow — before release wherever prevention is the goal;
- classify beneficiary posting outcomes — post, memo, hold, reject — and explain availability with return-rights honesty;
- summarize returns, investigations and recovery at journey depth while pointing to Chapter 20 for return mechanics and timelines;
- explain posting, accounting, liquidity, reporting and three-way reconciliation for a credit run from the bank operations view;
- describe what a bank must do to offer AFT origination and receipt, test changes and stay resilient, without treating planned rails as live;
- work through fictional but realistic Canadian cases — one payroll, one supplier run, one recurring disbursement — and extract the control lesson from each;
- navigate confidently to Chapters 18, 19 and 20 for payroll, corporate-disbursement and return-handling depth.
For a roughly 60-minute core session, spend about 10 minutes on the lifecycle and Section 1, 15 minutes on Sections 2–4 with the lifecycle and funding-gate diagrams, 10 minutes on Sections 5–6 with the reporting-flow diagram, 10 minutes on Sections 7–9 with the posting-outcomes and reconciliation-lineage diagrams, 10 minutes on the fictional cases in Section 11, and 5 minutes on takeaways and references in Section 12.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and system boundaries
- Initiation, validation and bank processing
- Clearing or exchange, settlement and finality
- Data, identifiers, messages and references
- Rules, cutoffs, service levels and customer impact
- Fraud, compliance and operational controls
- Exceptions, investigations and recovery
- Posting, accounting, liquidity, reporting and reconciliation
- Bank implementation, testing and resilience
- Practical Canadian examples
- Key takeaways and authoritative references
1. Business context and customer need
Start with three mornings a Canadian bank knows by heart. On a Friday morning, several hundred employees of a mid-sized manufacturer check their accounts before work and expect to see the same figure their pay stubs promised. On a Monday morning, a supplier's receivables clerk opens the bank statement and expects to find a customer's payment with an invoice reference clear enough to close two open invoices without a phone call. On the first business day of the month, a retiree expects a pension deposit to land exactly as it did last month, because the mortgage payment leaves the same account two days later. None of these people thinks about Automated Funds Transfer. Each of them thinks about timing, certainty, explanation and what happens when something is wrong — and each of them will call a bank, not a system operator, if the expectation breaks.
The AFT credit exists because these disbursement obligations share a shape: they are numerous, individually routine, predictable in rhythm, and tolerant of value that arrives in a later batch window rather than this second. An employer paying four hundred people, a business paying two hundred suppliers, a pension administrator paying fifty thousand beneficiaries — none of them wants to send four hundred or fifty thousand wires, and none of their beneficiaries needs same-second finality at wholesale pricing. They need a low-cost push mechanism that moves money reliably on a published rhythm, carries enough reference detail to reconcile, and handles the predictable share of failures through defined returns rather than investigations. That is the economic logic of the AFT credit, and it is why credits form one of the two great halves of retail batch alongside the pre-authorized debit collections of Block 5.
The push direction shapes everything about customer need. Because the originator initiates and funds, the originator's questions cluster around preparation and promise: what do I need to send, by when, with what money in which account, and what will my beneficiaries see and when. The beneficiary's questions cluster around arrival and explanation: when will it show, what reference will it carry, can the funds be used today, and who do I call if the amount looks wrong. The bank sits between those two question sets, and its advisory job is translation — turning the originator's file and funding into the beneficiary's posted credit with honest timing, complete references and evidence at both ends. Every section of this chapter equips you to answer one or more of these questions without inventing certainty the rail does not offer.
It helps to place the AFT credit on the map before going deeper. Against the pre-authorized debit, the difference is direction and authority: a credit pushes on the originator's instruction with the originator's money, while a debit pulls against a payer's account on claimed mandate authority that can be disputed weeks later. Against a Lynx wire, the difference is batch versus individual finality: a wire settles singly in real time in central-bank money with immediate irrevocability, at wholesale pricing, while an AFT credit travels in a batch file, clears with thousands of siblings, settles inside a net position on a deferred cycle, and remains subject to defined returns. Against Interac and card payments, the difference is rhythm and audience: consumer immediacy versus business-scale disbursement. The planned Real-Time Rail will add a 24/7 instant push capability when it launches, without changing today's routing, because it is not a system you can send to yet. A banker who can place a disbursement event on this map in thirty seconds — push or pull, batch or wire, Canadian dollars through ACSS or US dollars through the bulk US-dollar arrangements, this-window or next — has the single most valuable skill this block teaches. The rest is execution.
Scale turns small disciplines into large consequences. A single flawed file is hundreds or thousands of beneficiary events: one wrong value date delays every payee at once, one truncated remittance field creates a hundred queries, one missed cutoff shifts a whole run by a business day. Read the lifecycle diagram below left to right as the chapter's anchor: submission, validation, funding, exchange, clearing, settlement, posting, reporting. Every later section is a deeper pass over one box or one arrow in that picture.
The diagram above is your companion for the whole chapter. Notice what it asserts by shape: funding comes before exchange, never after; exchange delivers items without moving value; settlement extinguishes nets in central-bank money after clearing; posting is a receiving-bank decision, not a system event; reporting closes the loop for reconciliation. If you can walk any customer question to the correct box — "where is my file" to submission and validation, "where is my money" to funding and settlement, "why can't they see it" to posting, "how do I prove it" to reporting — the operating model is already working for you. The chapters ahead of this one open individual boxes into full rooms: Chapter 18 for payroll practice, Chapter 19 for corporate disbursement variants, Chapter 20 for returns and reconciliation craft. Follow the forward pointers; they are part of the design.
2. Participants, responsibilities and system boundaries
An AFT credit always involves more parties than the two customers who experience it as one organization paying another. The bank professional must keep five layers straight: the customers, the banks in their clearing capacities, the system operator, the settlement agent and overseer, and the intermediaries and agents in between. Confusing any two produces the classic errors this chapter corrects — treating the clearing system as the party that owes the beneficiary money, treating the originating bank's acceptance of a file as a guarantee of beneficiary posting, or treating a payroll processor as if it warrants the items.
Start with customers. The originator creates the economic event and supplies the money: the employer running payroll, the business paying suppliers, the pension administrator disbursing benefits, the corporation paying dividends, the government department issuing direct deposits. The beneficiary is entitled to receive: the employee, the supplier, the pensioner, the shareholder, the benefit recipient. In a credit push the originator's bank acts on the originator's instruction and moves funds toward the beneficiary; no beneficiary authorization is needed or sought, because nobody is pulling from the beneficiary's account. The boundary that matters operationally is this: customers own the obligation, the instruction and — on the originator side — the funding, but customers never settle interbank value. Only banks, through their clearing capacities, do. When an originator asks "did it go," the honest answer walks the chain of banks and agents; when a beneficiary asks "where is it," the honest answer starts at the receiving bank's posting decision and works backwards, never pointing at the system as a holder of funds.
Banks participate in distinct capacities, and the capacity determines liability, funding duty and what can be promised. A direct clearer exchanges AFT items directly, enters its volumes and values into the clearing calculation, holds a settlement account at the Bank of Canada, funds its net position on settlement mornings, and can act as clearing and settlement agent for others. A group clearer is a direct clearer acting for a member group under group clearing arrangements — one settlement footprint serving several institutions' flows. An indirect clearer participates through a direct clearer as its clearing and settlement agent: the agent exchanges on its behalf, includes its items in positions, and settles for it, under an agreement with defined cutoffs, funding, return-handling and reporting duties. Every AFT credit in this chapter travels one of these paths: originated through a direct clearer or through an indirect clearer via its agent, and received by a direct clearer or by an indirect clearer via its agent. Capacity is not a technical footnote. An indirect bank's file cutoff, late-file ability, return turnaround and incident communication are all bounded by its agent's timetable and processes, and every customer commitment must fit inside that frame.
Payments Canada sits in the middle as owner and operator: the rulebook anchored by By-law No. 3, the exchange and clearing infrastructure that carries AFT items, the calculation turning entered volumes and values into net positions, and the published operating framework including the business-day and closure calendar. What it does not do is equally important: it holds no customer accounts, does not decide whether any individual direct deposit posts, does not fund any participant's position, and does not guarantee any beneficiary payment. When this chapter says "the system," it means the operated clearing infrastructure plus the governing rulebook — never the bank's internal systems, and never a party to the customer obligation.
The Bank of Canada wears two hats that must never be blended. As provider of settlement accounts, it supplies the books on which net positions are extinguished. Payments Canada describes settlement of previous-day balances as payments to and from the Bank of Canada; participant procedures may use Lynx or another prescribed settlement mechanism. As overseer, the Bank supervises ACSS under the Payment Clearing and Settlement Act, with risk-management expectations for the designated system. The practical boundary: final Canadian-dollar batch settlement needs the Bank of Canada's books; assurance that batch risk is governed comes from oversight. Later blocks separate the oversight architecture fully; here, remember that one institution provides both the accounts and the supervision, and each answers a different question.
Around these core parties sit the intermediaries that originate scale: employers, pension administrators, enterprise systems, payroll processors and service bureaus that build the files banks release. Their responsibility should be written down before volume flows: who authenticates, validates, approves, warrants, handles returns and reconciles. The bank's duty to validate, warrant and control the files it releases does not move upstream to the bureau just because the bureau pressed the keys.
Responsibility, in short, is a chain with no gaps. The originator authorizes, prepares and funds. The originating bank validates, screens, approves, secures funding, releases and warrants. The clearing layer exchanges and positions. The settlement agent moves value finally. The receiving bank posts and reports. Agents stand in for their sponsored institutions at the clearing and settlement steps. Supervisors set the rules and expect evidence. Every investigation in Section 8 walks this chain backwards, which is why learning the chain once, here, pays for itself in every later chapter of this block.
3. Initiation, validation and bank processing
Every AFT credit starts in the same place: an originator instruction entering the originating bank's channel and passing through the bank's payment operations before any external system sees it. The channel varies — a business portal upload from a mid-sized employer, a host-to-host file from a corporate enterprise system or a pension administrator, a processor transmitting on behalf of dozens of small originators — but the bank's job converges on the same discipline: turn an instruction into a releasable, warranted, funded batch item, or reject it with a reason while rejection is still cheap. Items rejected inside the bank cost a phone call and a same-day fix. Items rejected in clearing cost a business day. Items released with bad data or without secured funding cost investigations, returns, compensation and trust. The whole economics of this section is that ordering.
Initiation captures six facts plus authority: who pays whom, how much, in what currency and from which account, on which value date, with what references, and under what authority to debit the originator. A payroll file carries employee account details, net amounts, pay date, control totals and the funding commitment; a supplier run carries vendor details, invoice-linked amounts, payment dates and remittance; a pension run carries beneficiary details, periodic amounts, effective dates and programme references. The bank's first job is normalization: whatever the channel delivered becomes one internal instruction record per item plus a durable file-level anchor, each with identifiers that survive every later stage.
Validation is where most preventable failures are caught, and it must complete before release. Account validation confirms the debit account exists, is open, is enabled for AFT origination and will carry the run. Routing validation confirms every destination institution, transit and account structure will survive exchange — an unreachable or malformed destination must be repaired or rejected here, never released "to see what happens," because each downstream failure mode is worse than a same-day hub reject. Duplicate and anomaly checks compare the run against history: a payroll file for twice the usual total, a supplier run with an unfamiliar volume spike, a dividend file with a new destination pattern, a file identifier already seen. Amount and date checks confirm value dates fall onprocessable business days and item totals balance to the file header's control totals — the control discipline that detects a truncated or corrupted file before it poisons clearing. Data-completeness checks confirm the fields the downstream path needs are present, including the remittance the beneficiary needs to reconcile without calling. Repair or reject happens here. Full stop.
Between validation and release sits the control stack, and its order matters as much as its contents. Authentication and entitlement confirm the file comes from the contracted originator through an approved channel. Limits confirm the run fits the originator's profile. Fraud scoring challenges anomalous payees and changed details before release, with callbacks for high-risk changes. Sanctions screening returns pass, false-positive release or true-hit hold — a single true hit holds the tainted items without stranding the clean ones. Record-keeping capture preserves file, approvals, validation and screening evidence. Cutoff logic assigns the run to this window or the next. Only then does the bank reach the funding gate. Screening after release is recovery, not prevention.
The funding and debit gate is this chapter's bank-control pattern, not a claim that F1/F4 prescribe one universal funding method. Under the originator agreement and the bank's risk policy, the bank may require prefunding in a designated account or debit authority with verified cover on value date. The file should not be released while that bank control is unresolved: an expected receivable, verbal assurance or unchecked balance is not cover. If the bank's funding control fails, its outcome is a documented reject or hold with a repair path and next-window communication. Log the run identifier, cover evidence, decision and approver so audit, treasury and investigations can reconstruct the event.
Release commits the funded, validated run to the clearing path: the file is delivered through the bank's gateway into ACSS exchange, directly for a direct clearer or through its agent for an indirect clearer, with the bank's warrant implied — the bank stands behind the items it introduces, including instruction quality, data accuracy and funding, under the rulebook. The bank records release time, window assignment, gateway acknowledgement and the external references at release, because every inquiry for the rest of each item's life starts from that record. For an indirect clearer, release also means handoff into the agent's timetable: the agent's cutoff, not the bank's internal readiness, decides which window the items enter, and the agency agreement should say so explicitly enough that front-line staff never have to improvise. After release the originating bank tracks acceptances and rejections, watches for returns on their own cycles, manages repair queues, posts its own entries, generates originator reporting and feeds every event into reconciliation. Amendments after release are narrow by design: pre-settlement correction where permitted, never silent editing of a settled item. Two principles decide whether this survives reality. First, route by policy rather than habit: a time-critical disbursement that missed its batch window belongs on a same-day-final rail if the customer accepts the cost — not in batch with a wish attached. Second, fail visibly and early: a bank that rejects with a reason, a repair path and a next-window promise creates one call; a bank that accepts everything and fails in clearing creates a week of investigations.
4. Clearing or exchange, settlement and finality
If Section 3 is about the bank's decision, this section is about the system's promise — and the most expensive misunderstandings in disbursement payments come from blending six events that are genuinely different. Exchange delivers items and data between participants. Clearing validates, sorts and positions those items by stream and window. Settlement moves value finally between settlement accounts. Posting debits and credits customer accounts on the bank's books. Availability tells the beneficiary the funds may be used. Finality tells the system the value movement cannot be unwound through the settlement mechanism. Every rail combines these differently, and the bank professional who blends them misleads originators, misstates liquidity and mishandles exceptions. Learn the six words, use them exactly, and half of disbursement confusion disappears.
AFT credits defer settlement by design, and the deferral is the whole point. The originating bank's released files enter daytime batch exchange windows through direct or agency arrangements. Each direct clearer enters the volumes and values of items exchanged, and those entries combine with the day's other batch traffic to determine net balances between direct clearers. Payments Canada says settlement of the previous day's net balances occurs during the next business morning through payments to and from Bank of Canada settlement accounts. Do not present a particular interbank settlement message or Lynx leg as a universal rule unless the current participant procedure says so. Thousands of direct deposits collapse into one funding event per clearer. That collapse is the efficiency of batch — and the reason treasury teams forecast nets rather than items, as Section 9 explains.
Finality here is positional and rule-governed, not per-item and instant. When morning settlement completes, interbank positions settle finally in central-bank money — yet defined return rights survive: closed or invalid accounts, ineligible items, receiving-bank rejects. A direct deposit can post while its position settles later; a credit that cannot post comes back through returns. That is the batch bargain: efficiency and reach at the cost of deferred finality and return exposure.
Contrast this with real-time gross settlement. In Lynx, each payment settles individually in real time across Bank of Canada accounts — final and irrevocable, recoverable only by a new payment with the beneficiary's agreement. AFT batch inverts every one of those properties: items accumulate, positions net, settlement follows in a later window, and defined returns remain available. The bridge is the settlement morning, when deferred nets are extinguished through individual Lynx payments. On a batch rail after its window, same-day finality is unavailable at any price; finality today requires a today-final rail with its pricing and irrevocability accepted explicitly.
Two forward pointers keep this chapter at journey depth. The full AFT participant, file and processing frame — the companion to this journey — belongs to Chapter 16, which this chapter assumes as background. The payroll application of this lifecycle, with employer calendars, pay-date arithmetic, off-cycle runs and employee-communication practice, belongs to Chapter 18. Corporate and supplier disbursement variants — invoice linkage, approval matrices, enterprise-system integration — belong to Chapter 19. Return mechanics, timelines, codes and the reconciliation craft for failed credits belong to Chapter 20. This section gave you the vocabulary and the shape; those chapters give you the working detail. Do not design operational procedures from this section alone.
5. Data, identifiers, messages and references
If clearing is the road network, data is the addressing — and AFT credits fail far more often from bad addressing and thin references than from system outages. The bank's data discipline, captured in three verbs — capture completely, validate early, preserve identity end to end — determines whether exchange, settlement, posting and reconciliation succeed or generate exceptions. This section maps what each credit needs, which references must survive the whole journey, and where modernization is changing the payload without changing the discipline.
Domestic batch routing starts with the Canadian account identifier triple: institution number, transit (branch) number and account number, governed by national routing conventions and validated against the Financial Institutions File and related references that establish reachability. Every AFT credit depends on this triple being correct, because exchange sorts on it: the system must know which clearer serves the destination account before it can position the item. Reachability is therefore a data question before it is a rail question, and an unreachable or malformed destination must be rejected or repaired in the bank's processing — never released "to see what happens." Each rail prices that error differently: batch charges it as a return cycle measured in days, a wire would charge it as a new payment requiring beneficiary cooperation, a cross-border leg would charge it as a multi-bank investigation. The cheapest place to fix addressing is always before release, which is why Section 3 put routing validation where it did.
Each AFT file then adds its own data layer on top of the triple. Batch headers carry originator identity, creation and value dates, and control totals — item count and total value — that must balance to the item records. Item records carry the destination triple, amount, transaction code, beneficiary reference and remittance. A file whose items do not sum to its header is truncated or corrupted and must be held for repair, not released as a partial run. Transaction codes identify item kinds; return reason codes identify why items came back. Using both exactly is what makes returns machine-processable. Respect that the standards exist, use current published versions, and validate before release.
Canada is living through a long coexistence: legacy batch formats sit alongside ISO 20022-enabled processing with richer structured data, meeting at mappings where truncation risk concentrates. The bank's processing must validate against the destination's schema, map explicitly, log what was truncated or enriched, and carry the original customer reference forward. Format detail belongs to the programme's ISO 20022 coverage; the journey lesson is that coexistence is a multi-year condition to be engineered for, not a cutover to wait out.
References are what let humans and systems agree they are discussing the same credit, and four must survive every journey. The bank's internal instruction identifier anchors tracking from intake through investigation. The run or file identifier anchors the batch: every item in a disbursement run must be traceable to its run, because originators reconcile, repair and re-originate by run, not by atomized item. The clearing reference — file, batch and item traceability through exchange — anchors the system's view and is what lets a return find its original without manual matching. The customer remittance — employee identifier, invoice number, pension reference, dividend holder number — anchors the beneficiary's reconciliation and is the field whose absence creates the "unapplied cash" queues that consume receivables teams and payroll helpdesks alike. Drop any one and a different team pays: drop the internal identifier and investigations stall; drop the run linkage and the originator cannot repair a partial failure; drop the clearing trace and operations cannot match system reports; drop the remittance and the beneficiary phones the bank. Reference discipline is unglamorous and decisive, which is exactly why it belongs in a journey chapter rather than being left to a technical appendix.
Two practical consequences follow. First, master-data quality is a payments control: clean employee banking records, validated vendor masters and disciplined beneficiary registers prevent more exceptions than any downstream repair process. The most common AFT credit failure in Canada is not exotic — it is a transposed account digit, a stale transit after a branch consolidation, a vendor record nobody revalidated. Second, evidence preservation starts at origination: files, approvals, validation results, funding evidence and release records must be retained retrievably for the full window in which returns, disputes and audits can arise. Storage is cheap. Reconstruction is expensive. Audit findings are most expensive.
6. Rules, cutoffs, service levels and customer impact
Originators experience rules as promises: will the run arrive on pay date, when can beneficiaries use the funds, what reference will appear, and what happens if an item fails. The bank experiences rules as windows, obligations and evidence. Customer-channel cutoffs vary by bank, clearer, file type and day, but the current F1/F4 rules do state participant exchange deadlines: 09:30:00, 16:30:00 and 21:00:00 ET on business days. Do not turn those participant deadlines into a customer promise; use the bank's published channel schedule and the official closure calendar.
The rulebook layering is straightforward in shape. By-law No. 3 establishes the legal foundation for payment items and ACSS. Rule F1 governs AFT transactions exchanged under Standard 005 (the legacy/non-ISO AFT format), including exchange, processing, funds availability, returns, tracing and settlement procedures. Rule F4 governs ISO 20022 AFT transactions exchanged under the ISO AFT Usage Guidelines. Standards and usage guidelines supply file/message structures, codes and data detail. Both rules should be read with the other ACSS rules, standards and the current published version. Functionally, every operational question has a binding answer in the current published framework, and "we have always done it this way" is never a substitute for checking the current version. The detailed map of which rule governs which stream belongs to the streams-and-windows coverage; here, know the layers, know that F1 and F4 functionally frame AFT work, and keep the habit of checking currency.
Business days anchor everything in batch: the rulebook's business-day calendar and Payments Canada's published closure schedule control participant processing. A Thursday-evening file may fall into the next exchange period or next business day depending on the bank's channel cutoff and receipt time. A Friday-afternoon run past the bank's cutoff waits under published policy, and the value date may move with it. A holiday changes the applicable business-day sequence; confirm the resulting due date, settlement date and return clock from the current schedule and rulebook rather than assuming a simple one-day shift. The hub logic assigning each run to a window at intake is the most customer-visible control in this chapter: the channel may only offer what processing confirms for this run, this amount, this originator, this business day.
Relative windows within a business day differ by stream. For AFT, F1/F4 define three participant exchange periods ending at 09:30:00, 16:30:00 and 21:00:00 ET on business days. The rules also use serviceability codes: code 0 generally requires exchange by the earlier of the prior business day, where available, or the due date; code 1 requires one business day lead time; and code 2 requires two business days. For funds availability, code 0 is generally within two hours of the applicable exchange deadline, while codes 1 and 2 require availability by opening of business on the due date, subject to the rule's exceptions and the account agreement. A bank's customer cutoff comes before its clearer exchange deadline; then clearing, settlement, posting and reporting follow. The service-level lesson is the discipline, not the timetable: release before the applicable cutoff means this window; after means the next; and "late but urgent" batch is a contradiction the bank should resolve by offering a same-day-final rail, not by improvising around the window. Pay-date arithmetic for payroll — how many business days before pay date the file must be approved, funded and released — is worked fully in Chapter 18; supplier lead-time guidance belongs to Chapter 19. This chapter establishes the principle both apply: count backwards from the beneficiary date in business days, through posting, settlement, clearing and exchange to the originator cutoff, and never compress the chain under pressure.
Service levels bundle timing with certainty, information and recourse. Batch offers low-cost scale with structured returns — at the price of deferred settlement and return exposure. Same-day-final rails offer immediacy and irrevocability — at wholesale pricing with no unilateral recall. The honest conversation compares bundles, not speeds.
Customer communication must reflect finality honestly, using the six words from Section 4 exactly. "Sent" means released from the bank's processing. "Accepted" means clearing took it. "Settled" means interbank value moved finally. "Posted" means the beneficiary account was credited. "Available" means the beneficiary may use the funds, subject to holds or return rights. "Final" means the value cannot be unwound through the settlement mechanism. An AFT "posted" must always be stated with return-rights awareness: a direct deposit that cannot post will come back, and the originator — not the system — owns the repair. Most disbursement complaints are vocabulary failures wearing operational costumes: the originator heard "sent" and promised beneficiaries "paid," and nobody corrected the translation until items returned.
7. Fraud, compliance and operational controls
Controls fail most often not by absence but by placement. A sanctions check that runs after value has settled, a fraud hold that triggers after the beneficiary has been told funds are available, an approval that is sought only after a dispute arrives — each is a control that exists and still loses, because it runs on the wrong side of the event it was meant to govern. This section places each control family at the point in the AFT credit flow where it can still change the outcome, and explains how the families interact. Rail-level control detail for fraud landscapes, reporting mechanics and screening systems lives in the programme's later risk and compliance coverage; here the lesson is architectural: prevention sits before release, detection sits across processing and clearing, and evidence sits everywhere.
Fraud controls span initiation, transaction risk and post-event response. Takeover and social engineering attack initiation: authenticate the submitter, challenge changed banking details and first-time beneficiaries before release, with callbacks for high-risk changes — the classic payroll-diversion fraud dies at this checkpoint or nowhere. Origination fraud attacks the file: fictitious employees, inflated supplier payments, fabricated files from compromised credentials — met with originator onboarding, segregation between creation and approval, dual control over release, and anomaly checks against history. Incoming-side fraud attacks the receiving account: mule networks collect direct deposits within hours, so incoming credits must be scored too, with first-time receipts held for review. Substitution fraud swaps a genuine instruction's destination — caught only by master-data discipline plus out-of-band confirmation. Each is a before-release control first and an investigation second.
Authorization controls on a credit run mean something different from the mandate evidence of the collections chapters, and the difference must be kept sharp. Nobody needs the beneficiary's permission to send a credit; what the bank needs is the originator's authority — the signed AFT origination agreement establishing the debit authority over the originator's account, the entitled submitters, the approved limits and the stream permissions — plus per-run approval by someone other than the file's creator. Dual control is not bureaucracy here; it is the control that makes fictitious-payee fraud require collusion rather than a single compromised credential. Approval evidence — who approved, when, against which limits, on what file hash or total — must be captured at release and preserved for the full window in which disputes and audits can arise. A run whose approval cannot be evidenced is operationally equivalent to an unapproved run, and examination outcomes will reflect that equivalence.
Sanctions and watchlist screening, and any applicable legal information requirements, are bank controls that should be placed before release. Do not describe FINTRAC's travel-rule/EFT requirements as a universal domestic AFT rule: FINTRAC's definition of electronic funds transfer expressly excludes transactions carried out by direct deposit or pre-authorized debit. Where a different payment instrument is in scope, apply its applicable legal and scheme requirements. For an AFT file, log the screening disposition and preserve the data needed for the applicable investigation. Screening placement is non-negotiable for batch for the same reason as for wires — once value moves, recovery requires cooperation — with the added batch consideration that files contain hundreds of parties and a single true hit must hold the tainted items without stranding the clean ones. Complete, untruncated data matters enormously: truncated beneficiary information creates multi-day false-positive queues and, worse, the temptation to "release and check later" that precedes every screening failure. Log what was checked, when, against which lists, by whom, with what disposition. That log is the difference between a defensible process and an anecdote.
Anti-money-laundering and record-keeping obligations attach to disbursement events without being payment approvals. Client identification, transaction records and reporting feeds must be captured at origination, preserved untruncated through clearing, and retrievable for the full retention window. Thresholds and filing mechanics belong to the dedicated compliance coverage; this chapter's rule is placement — capture at initiation, preserve through clearing, report from complete data. Payout patterns that look like layering must reach monitoring with run linkage intact, because monitoring without linkage is noise.
Oversight and audit complete the control plane. Designation of ACSS as a prominent system brings risk-management expectations expressed as governance, procedures, resilience, incident reporting and evidence that controls run every window. Supervisors will ask for what this chapter builds: who instructed, approved, checked, funded, which window carried it, how it settled and posted, how exceptions were handled.
Operational controls tie the families together: entitlements and dual approval, limits and velocity, the funding gate from Section 3, cutoff enforcement, queue ownership with ageing, amendment discipline, evidence preservation and segregation of duties. The control that binds them is release discipline — no run reaches clearing without passing authentication, validation, limits, funding, fraud, sanctions, cutoff and approval in that order, each decision logged. Overrides of that order — manual releases, verbal instructions, after-cutoff exceptions — must themselves be controlled, dual-approved, time-bound and reviewed, because the history of batch losses is largely a history of overrides that bypassed the order. Contingency connectivity, alternative file paths and communication trees belong in the same plane and return in Section 10 under resilience.
8. Exceptions, investigations and recovery
Every disbursement window breaks differently, but every break is managed the same way: detect fast, classify correctly, contain within the rail's rights, recover as a new linked event, and reconcile with evidence. Banks that classify first recover cheaply. Banks that act first — re-sending the whole run, manually crediting beneficiaries, editing a settled record — create duplicate payments, duplicate credits and audit breaks that dwarf the original error. This section teaches the classification and the recovery discipline at journey depth. Each mechanism in full — timelines, codes, adjustment flows, reconciliation of exceptions — belongs to Chapter 20, which this section summarizes and points to throughout.
Start with the taxonomy, because precise words are the cheapest control in exception handling. A reject happens before clearing — invalid routing, closed account, limit breach, failed screening, insufficient cover, incomplete data. Nothing settled; the originator repairs and re-originates with reason, repair path and next window. A return happens after entry — closed or invalid account, ineligible item, or the other defined causes Chapter 20 catalogues — with rulebook reason codes and timeframes. Returns are normal batch traffic, processed daily with straight-through matching. A reversal corrects a bank error — duplicate file, wrong amount — never by editing a settled record. An adjustment allocates fees and compensation. A recall asks the beneficiary's side to send funds back, requiring cooperation. An investigation tracks an uncertain outcome: no confirmation, orphan return, figures that disagree.
Return reasons for credits cluster into a short list. Account reasons dominate — closed, invalid, frozen, unreachable — saying addressing failed; recourse is master-data repair before re-origination, never blind retry. Administrative reasons — ineligible items, malformed records, duplicates — say the bank's own processing failed; recourse is internal. Funds failures on a push sit on the originator side — cover that never materialized — handled by dishonouring the run and containing exchanged items. Fraud reasons route through fraud and screening with evidence preserved. Code detail lives in Chapter 20; the journey skill is triage.
Recovery follows one iron rule: never mutate history; always create a linked new event. A rejected item is repaired and re-originated with linkage to the original run. A returned credit is corrected and re-originated as its own event referencing the original — never re-sent as an unexplained duplicate. A duplicate file is reversed through the defined mechanism with the original preserved. Every recovery carries three references: original run identifier, clearing trace of the failed item, and the new event's identifier. The bank that re-sends "the same payment again" without linkage has created two payments.
Investigations run on evidence assembled from the chain in Section 2. Start from the originating bank's release record — when, which window, which references, what funding evidence — check clearing and posting records, and only then contact the counterparty or agent with a precise, reference-carrying query. For indirect clearers, the agent is part of the investigation path by contract: the indirect bank's operations team needs the agent's exchange confirmations, position reports and return feeds, and the agency agreement should guarantee them on investigation timelines, not month-end timelines. Status communication follows the vocabulary rule from Section 6: state what is known and what is being done, never upgrade "tracked" to "resolved" before the evidence arrives. The rulebook sets trace boundaries that operations must not overpromise: F1 requires trace facilities for at least 12 months, does not require responses for transactions under $20 or requests more than 12 months after settlement, and sets a two- or five-business-day response target depending on the settlement-date age. A missing run identifier still turns a precise trace into manual reconstruction.
Containment deserves a final word because batch scale punishes slow containment. A corrupt file, a compromised originator credential, a misdirected stream, a funding failure discovered after partial release: first stop the bleeding — hold pending releases from the affected source, quarantine the repair queue, notify agents or counterparties where required, freeze further debits under the compromised authority — and only then diagnose. Containment decisions need pre-assigned authority reachable during every window, not an escalation tree that convenes tomorrow. Chapter 20 builds the runbooks; this section establishes the mindset: classify, contain, recover as linked events, reconcile with evidence.
The diagram above sits in this section deliberately, though its decision belongs to the receiving bank: posting outcomes are where most credit exceptions are born, and understanding them is what lets the originating side investigate intelligently. Read it as the receiving bank's side of the investigation checklist — was the account open, did screening pass, did policy post hard or memo first, was a hold applied, was the item returned with which reason — and every originator query you raise will carry the fields the receiving side needs to answer.
9. Posting, accounting, liquidity, reporting and reconciliation
This is the section where a disbursement run becomes money on statements and funding on balance sheets — where operations, finance and treasury meet. Posting moves customer balances. Accounting records what the bank did in its own books. Liquidity ensures the bank can fund what it owes on settlement mornings. Reporting tells originators and beneficiaries what happened. Reconciliation proves the whole story agrees. Each is a distinct discipline with distinct owners, and disbursement failures at month-end or on settlement mornings almost always trace to blurring two of them. Keep them separate and each becomes manageable.
Posting translates clearing outcomes into customer account entries on both sides of the credit. Under F1/F4, funds availability is tied to the destination branch's serviceability code, due date and the account agreement; it may occur before the interbank settlement date. On the originating side, the debit, prefund hold and fees are bank-specific ledger events and must be described as such. On the receiving side, the institution applies its account agreement, applicable rulebook duties and risk controls; a credit may be made available, restricted/held, or returned with the applicable reason.
Accounting is the bank's implementation layer: it should keep customer balances, clearing/settlement positions, suspense, fees and adjustments separately identifiable and reconcile them to the rulebook reports and settlement-account evidence. The exact debit, hold and suspense design is bank-specific; ageing suspense is an internal exception. Returns, reversals and adjustments should post as linked new events rather than edits to historical entries.
Liquidity is the treasury view: a direct clearer funds one net obligation per cycle rather than thousands of gross credits — efficient only if forecast accurately. Treasury needs timely forecasts adjusted for holidays, large runs, known returns and seasonal peaks. Funding moves through settlement accounts via Lynx legs, and an indirect clearer must fund its agent with equal seriousness. Forecast the net, fund the net, confirm the funding. Every settlement morning.
Reporting closes the loop to everyone with a stake in the outcome, and the reporting diagram below maps the three audiences. Originators receive acceptance confirmations, reject lists with reasons and repair paths, return notices linked to originals, and run-level settlement summaries — on cycles that let them repair within the next window rather than discovering failures at month-end. Beneficiaries receive credit advices, statement lines carrying the originator's reference, and remittance detail where the originator sent it — the evidence that lets a supplier close invoices and an employee trust the pay stub. Agents report positions, settlement and returns to their indirect clearers in sufficient detail for the indirect bank to post, reconcile and answer its customers. Management receives window-level dashboards: volumes, rejects, returns by reason, suspense ageing, funding status. Each audience needs its own cut of the same truth, generated from the same anchored identifiers — which is why reference discipline from Section 5 returns here as a reporting requirement, not just an operations preference.
Reconciliation proves the story, and credit reconciliation is three-way by nature with a run-level spine. First, internal records — what processing released versus what posting applied — must agree: every released item posted or queued with a reason, every originator debit matched to its run. Second, internal records must agree with clearing evidence — exchanged, positioned and returned as reported, run by run. Third, clearing evidence must agree with settlement evidence — positions extinguished through settlement-account entries matching to the dollar. The lineage diagram below shows the five checkpoints — run, entries, clearing, settlement, statements — as one traceable chain. Direct clearers reconcile all three legs including Bank of Canada account entries; indirect clearers reconcile through their agent's reporting, which is why agency reporting standards belong in the agency agreement. Breaks get worked by category — timing breaks clearing next cycle versus genuine breaks signalling missing items or processing defects — with ownership and ageing on every open break. Unreconciled differences compound with age. Chapter 20 teaches the break-working craft for credits; this section establishes the architecture every break-worker stands on.
10. Bank implementation, testing and resilience
Offering AFT origination — or receiving direct deposits — is an implementation project with regulatory, operational and customer dimensions, and this section maps it at the level a product owner, analyst or operations manager needs. It does not replace vendor documentation, testing guides or the rulebook. It tells you what the work consists of, where the risk concentrates, and how to tell a ready institution from an unready one.
Participation choices come first: originate and receive directly — exchanging, entering positions, holding settlement accounts and funding nets — or indirectly through an agent, or within group arrangements. The decision weighs volume and growth, funding capability, operations coverage, technology readiness, and direct control overhead against agency dependency: timetable constraint, reporting dependence and commercial terms. For indirect institutions the implementation is dominated by one document: the agency agreement, whose cutoffs, funding calls, returns, reporting, incident coordination and liability must be explicit enough to operate from under pressure.
Product and channel work comes next. Origination needs a channel — portal upload, host-to-host or processor connectivity — with authentication, validation, balancing, limits, approval workflow and cutoff assignment built in. Each originator needs an agreement establishing debit authority, limits, value-date rules, return handling and liability; each processor relationship needs the written handoff map from Section 2. Receiving needs posting-policy configuration plus advice and statement generation carrying references forward untruncated. Each capability should trace from a named section of this chapter to a named owner and a named test.
Connectivity and certification follow. The bank connects through approved channels, implements the file and message standards for its credit streams, configures its gateway and hub adapters, and proves through structured testing that it can submit valid files, receive and apply reports and returns, handle rejects, secure funding at the gate, and reconcile positions. Testing must cover the unhappy paths with at least the energy given to the happy ones: malformed files, totals that do not balance, duplicate deliveries, unfunded runs, returns of every major reason, holiday-week calendars, late-window arrivals, agent-cutoff misses. Parallel operation — running new flows alongside old with full reconciliation comparison — earns its cost the first time it catches a mapping defect. Cutover needs a rollback plan with a named decision-maker and a clock: batch windows do not wait while committees convene. Originator migration — moving employer, supplier and programme files onto the new rails — deserves product ownership with timetables, because the bank's data quality is bounded by what its largest originators send, and a migration that preserves bad master data preserves the exceptions too.
Change management after go-live is where most institutions live. Every format change, platform migration, new originator product, routing-reference update and rulebook amendment is a mini-implementation: impact assessment, regression testing, originator and operations communication, and a monitored first window with extra reconciliation coverage. ISO 20022 coexistence makes this permanent: dual-format validation and mapping regression tests are standing capabilities, not project phases.
Resilience is the supervisory-grade expression of all of this, proportionate to a prominent system's role in the economy. Backup connectivity and contingency file paths must be tested, not merely documented. Missed-window procedures must state plainly what happens: runs belong to the next window, originators and affected beneficiaries are told so promptly, funding forecasts are revised, pay-date communications go out before helpdesks fill. Settlement-morning contingency needs treasury, operations and management in one procedure with one owner. The funding gate needs its own contingency: what happens when a large originator's cover fails on value date, who decides, who calls, what posts and what holds. Incident communication needs templates that use the Section 6 vocabulary correctly under stress. Staffing must cover every window the bank participates in, including holiday weeks and the return-driven work arriving days later. A contingency never tested is a hope, and hopes are not controls.
Modernization readiness closes the section. As of this chapter's 2026-10-05 audit, Payments Canada describes RTR as launching in Q4 2026, with sequenced onboarding and testing still underway; it is not a generally available production rail. Keep routing today's AFT volume to the live ACSS path. A bank may prepare a payment hub with rail adapters, reference carriage and format-mapping capability, but those are implementation choices, not evidence that RTR is live. Training scripts, job aids and customer pages that mention the planned rail must label it planned in the same sentence, because the cost of a misrouted expectation is measured in missed pay dates.
11. Practical Canadian examples
The three cases below are fictional — invented organizations, invented figures, realistic mechanics — each labelled as required. Only the first touches payroll, briefly: payroll depth belongs to Chapter 18. The second follows a supplier run, pointing to Chapter 19. The third follows a recurring disbursement with a posting exception, pointing to Chapter 20. Each ends with the control lesson to take back to work.
Example (fictional): Lakeside Outfitters and the Friday pay run. Lakeside Outfitters is a fictional Ontario retailer with about 180 employees paid biweekly by direct deposit. On Tuesday afternoon its payroll administrator uploads the pay file through the bank portal: employee details, net amounts, Friday pay date, control totals. Processing validates — totals balance, destinations reachable, amount within limit, second approver signed off, fraud and screening clear — and the funding gate confirms cover before release. The credits exchange, clear and settle through the normal cycle; employees see credits Friday morning and the company's system reconciles to bank confirmations the same day.
Then the wrinkle that makes the case instructive: two items return with account reasons — one closed account from an employee who changed banks without telling payroll, one transposed digit that passed format checks but matches no open account. Operations matches both returns to the original run via the clearing trace, notifies Lakeside the same day with reasons, repair paths and next-window promise, and Lakeside re-originates both credits after correcting the banking details. Control lesson: format validation is necessary but not sufficient — validated employee banking details at onboarding and a leaver-and-changes process reduce common payroll exceptions, and return linkage supports a controlled next-window correction. Everything about payroll calendars, cutoffs counted backwards from pay date, off-cycle corrections and employee messaging is taught in Chapter 18; this case exists only to show the journey working, not to teach the payroll craft.
Example (fictional): Prairie Foods and the Thursday supplier run. Prairie Foods is a fictional Alberta food distributor paying about 240 vendors weekly by AFT credit. On Wednesday morning its accounts-payable team releases a supplier run through host-to-host: vendor details, invoice-linked amounts, Thursday value date, structured remittance. Processing validates — totals balance, destinations reachable, within limit, dual approval present, a first-time vendor confirmed by callback, screening passed — and the funding gate secures cover. Vendors receive credits with remittance intact; the system auto-matches confirmations to invoices; short-paid vendors call about amounts, not missing money — a commercial dispute, not a payments incident.
Then the wrinkle: one large vendor's remittance arrives truncated — the enterprise system emitted a longer reference than the batch format preserves, and the mapping dropped the tail without logging it. The vendor's receivables team cannot match the payment and phones Prairie, which phones the bank. Investigation starts from the release record, finds the unlogged truncation in the mapping, and recovers by reissuing the advice detail out of band while the bank fixes the mapping to log truncations explicitly. Control lesson: remittance is the product for supplier payments — mapping discipline, truncation logging and end-to-end reference carriage decide whether a disbursement run closes invoices or creates phone calls. Chapter 19 teaches corporate and supplier disbursement practice — approval matrices, enterprise integration, invoice linkage — in full; the journey lesson here is that data completeness at Section 5 is a commercial control, not a technical nicety.
Example (fictional): Harbourview Pension Services and the held deposit. Harbourview Pension Services is a fictional Nova Scotia administrator disbursing about 12,000 monthly pensions by direct deposit. The January run validates, funds, exchanges, clears and settles normally; 11,997 credits post hard. Three do not. One returns with an account reason — a beneficiary who died in December whose account has closed; the administrator updates its register rather than re-originating. One is held — a change-of-banking request that fails verification; callbacks confirm fraud and the item is stopped before hard posting. One posts memo first under intraday policy, then hard, with the pension reference carried throughout.
Control lesson: the receiving bank's posting controls are the last line of defence for disbursements, and the originator's register hygiene is the first. A beneficiary master that revalidates changed details through known contacts defeats diversion fraud that no downstream control can reliably catch; a receiving bank that holds first-time destinations under policy catches what onboarding missed. Returns in this case route to Chapter 20 for timelines and codes; fraud patterns route to the programme's fraud coverage. The journey lesson is the architecture: prevention before release, defence at posting, evidence everywhere.
Read together, the three cases rehearse the chapter's core moves: secure funding before release, validate before exchange, assign every run to its window honestly, preserve references end to end, state availability with return-rights honesty, triage exceptions by category, and recover as linked new events. If you can walk any one of these cases from submission to reconciliation without confusing the six vocabulary words, the operating model is yours.
12. Key takeaways and authoritative references
Twelve points carry this chapter. If you retain nothing else, retain these — and know where each one deepens in the chapters ahead.
- An AFT credit is a push: the originator initiates and funds, value moves toward the beneficiary. No mandate, no pull, no beneficiary authorization — just an instruction backed by money already secured. Direction decides the control set.
- The bank's funding control is resolved before release. A bank may require prefunding or debit authority with verified cover under its customer agreement and risk policy. If that control fails, hold or reject with a reason rather than release an unresolved run.
- Validate before release; repair while rejection is cheap. Account, routing, duplicate, amount, date, limit, approval, screening and data-completeness checks belong inside the originating bank's processing, in order, each decision logged.
- Exchange, clearing, settlement, posting, availability and finality are six different events. Use the words exactly — in originator scripts, incident tickets, procedures and audit responses. Most disbursement confusion is vocabulary failure.
- The system is operated by Payments Canada under By-law No. 3; final settlement happens on the Bank of Canada's books. The operator provides the rulebook, infrastructure and clearing calculation — not customer accounts, funding or guarantees. Previous-day net balances settle through payments to and from Bank of Canada settlement accounts, in central-bank money; the exact interbank settlement mechanism is governed by current participant procedures.
- F1 covers Standard 005 AFT transactions and F4 covers ISO 20022 AFT transactions. Know what each rule and its linked standards govern, and check the current published versions; never build procedures from remembered rule text.
- Windows and business days are the originator promise. Monday to Friday excluding published holidays; release before the applicable cutoff means this window, after means the next. Never quote exact times from training material — use the bank's published schedules with the closure calendar — and never promise same-day finality on batch timing.
- Beneficiary posting follows receiving-institution controls: post, memo, hold or reject. The system never posts to customers. Availability is usable-per-policy with return-rights honesty, never unconditional finality.
- Data quality is a payments control. Correct triples, balanced files, valid codes, surviving remittance and four durable references — internal identifier, run linkage, clearing trace, customer remittance — decide whether clearing, posting and reconciliation succeed. Master-data onboarding is part of the disbursement product.
- Returns are normal traffic; recovery always creates linked new events. Classify first — reject, return, reversal, adjustment, recall request, investigation — contain within the rail's rights, and never mutate history. Chapter 20 teaches the mechanics in full.
- Posting, accounting, liquidity, reporting and reconciliation are five disciplines, not one. Post under explicit policy with memo-versus-hard discipline; account customer, clearing, settlement and income separately; forecast and fund the morning net; report each audience its cut of one truth; reconcile three ways — internal to internal, internal to clearing, clearing to settlement.
- Implement deliberately, stay resilient, modernize honestly. Choose capacity on economics, contract agency explicitly, build the bank-specific funding and approval controls in, test unhappy paths, run parallel before cutover, rehearse contingency, and label RTR as planned until Payments Canada confirms production availability.
Forward map for this block: Chapter 16 sets the AFT frame this journey walks; Chapter 18 takes employer payroll to working depth; Chapter 19 takes corporate and supplier disbursements to working depth; Chapter 20 takes credit returns, posting exceptions and customer-to-bank reconciliation to working depth. Study them in order; each assumes the vocabulary and the map this chapter built. Do not write operational procedures from this journey chapter alone.
Authoritative references (official sources only)
This chapter uses only official sources. Re-check any time-sensitive page before customer or examination use. No exact customer-channel cutoff times are stated; F1/F4 participant exchange deadlines are stated where useful, while binding customer times come from your bank's published schedules with the published system closure calendar. Rules are described functionally throughout; the binding text is the current published rulebook, not this chapter.
- Payments Canada — Retail batch payment system page. Operator description of the retail batch system comprising ACSS and USBE, direct and indirect participation, entry of volumes and values into net balances, and morning settlement of previous-day balances through payments to and from the Bank of Canada. https://www.payments.ca/systems-services/payment-systems/retail-batch-payment-system
- Payments Canada — Rules and documentation page. Source for the current AFT rules, standards and by-laws including By-law No. 3 and the funds-transfer rules framework, with versions in force and update history. https://www.payments.ca/systems-services/rules-documentation
- Payments Canada — High-value payment system (Lynx) page. Operator description of Lynx as the real-time gross settlement system through which direct clearers move settlement value, including participation conditions such as holding a Bank of Canada settlement account. https://www.payments.ca/systems-services/payment-systems/high-value-payment-system-lynx
- Bank of Canada — Payment systems overseen by the Bank. Central-bank description of oversight under the Payment Clearing and Settlement Act, including ACSS as an overseen prominent deferred net settlement system for retail payments. https://www.bankofcanada.ca/regulatory-oversight/financial-market-infrastructures/payment-systems-the-bank-of-canada-oversees/
- Bank of Canada — Settlement account policies for Payments Canada systems. Central-bank description of settlement accounts for Lynx, ACSS and the planned RTR, settlement finality in central-bank money, and eligibility and application for settlement accounts. https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/
- Payments Canada — Rule F1, Rules applicable to Automated Funds Transfer (AFT) Transactions (2026). Current Standard 005 AFT exchange, deadlines, serviceability codes, funds availability, returns, tracing and settlement procedures. https://www.payments.ca/sites/default/files/f1eng.pdf
- Payments Canada — Rule F4, Rules applicable to AFT Transactions exchanged using ISO 20022 messages (2026). Current ISO AFT scope, message exchange, remittance, returns, reversals, tracing and settlement procedures. https://www.payments.ca/sites/default/files/f4eng.pdf
- Payments Canada — Automatic funds transfer: ISO 20022 onboarding, registration, testing and message portfolio. https://www.payments.ca/payment-resources/iso-20022/automatic-funds-transfer
- Payments Canada — System closure schedule. Official participant business-day and holiday calendar used with F1/F4 deadlines. https://www.payments.ca/system-closure-schedule
- Justice Canada — Canadian Payments Association By-law No. 3 — Payment Items and Automated Clearing Settlement System, current to September 21, 2026 and last amended September 26, 2025. https://laws-lois.justice.gc.ca/eng/regulations/SOR-2003-346/index.html
- FINTRAC — Record keeping requirements for financial entities, including the definition/exclusion of direct deposits and prescribed EFT records. https://fintrac-canafe.canada.ca/guidance-directives/recordkeeping-document/record/fin-eng
- FINTRAC — Reporting electronic funds transfers to FINTRAC, including the $10,000 international EFT reporting rule for financial entities. https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng
- Bank of Canada — Retail payments supervision. RPAA scope, PSP operational-risk, incident, safeguarding and reporting responsibilities; these do not automatically apply to every bank AFT customer flow. https://www.bankofcanada.ca/regulatory-oversight/retail-payments/
Diagrams in this chapter: AFT credit lifecycle; originator funding and debit control gate; beneficiary posting outcomes; direct-deposit reporting and advice flow; credit reconciliation lineage — all under /diagrams/payment-stories/canada/chapter-17/. No exact cutoff times are shown in the diagrams. The Real-Time Rail is shown as planned. Stories and organizations are fictional.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.