Automated Funds Transfer in Canada. Understand AFT participants, files, exchange, clearing, settlement and bank processing.
Canada Payments & Collections · Block 4 · Chapter 16 of 75
If ACSS is the quiet workhorse of Canadian payments, Automated Funds Transfer is the harness it wears most days. AFT is the electronic stream inside ACSS through which employers pay staff by direct deposit, businesses pay suppliers in batches, governments deliver benefits, and billers collect thousands of pre-authorized debits without touching paper. No customer ever asks which stream carried their pay. Every payroll cutoff conversation, every month-end reconciliation break and every batch "where is my money" call runs through the mechanics this chapter teaches.
This chapter gives you AFT end to end at working depth: who participates and where each party's responsibility stops, how files are built, validated, released, exchanged, cleared and settled, how push credits and pull debits differ despite sharing the same rails, what data the system needs, which rules govern, where controls sit, how exceptions recover, and what a bank must build and test to participate. It stays at operating-model level throughout. Payroll practice gets its own later chapter, pre-authorized debit authorization and collection practice get theirs, return-and-reconciliation craft gets its own, and ISO 20022 coexistence gets its own. Wherever this chapter touches those topics it summarizes only what you need to hold the whole picture, then points forward. Nothing here replaces the rulebook: AFT exchange is governed by Rule F1 for established AFT and Rule F4 for ISO 20022 AFT, under By-law No. 3, and the binding detail lives in the current published rules, standards and usage guidelines, not in any training chapter.
Three status facts anchor everything that follows, stated once so later sections can build on them. First, AFT is an electronic file-based payment family cleared through the retail batch system: Canadian-dollar AFT items use ACSS, while the rule framework also covers U.S.-dollar AFT subject to Rule K8 and the USBE settlement path. Files are exchanged between clearers, volumes and values enter the clearing calculation, positions net, and direct clearers settle what they owe through payments to Bank of Canada settlement accounts; Lynx is Canada's live high-value system and the current mechanism for inter-FI settlement payments. Second, timing has two layers: Rule F1/F4 contain system exchange deadlines and lead-time/availability requirements, while a bank or agent may impose earlier customer cutoffs. Settlement of the previous day's net balances occurs during the next business-day morning; posting and availability follow the applicable rule and account policy, and returns run on rule-defined windows. Third, as of 5 October 2026, the Real-Time Rail is still in testing with a sequenced Q4 2026 launch target, not a production route for today's AFT work.
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 AFT is — the electronic batch stream of ACSS — and name the business it carries: direct-deposit payroll, supplier and benefit credits, and pre-authorized collections;
- distinguish a push credit from a pull debit and explain why the same file mechanics produce different authorization, return and dispute consequences;
- trace an AFT file from originator instruction through validation, screening, release, exchange, clearing, net positions, deferred settlement, posting and reporting without confusing those stages;
- name every party in the chain — originator, beneficiary or payer, originating and receiving institutions, direct, group and indirect clearers, agents, service bureaus, Payments Canada and the Bank of Canada — and state what each owns;
- explain the difference between Rule F1 established AFT and Rule F4 ISO 20022 AFT, and describe their coexistence as a mapping condition to engineer for rather than a cutover to wait out;
- describe the file, batch and item-record hierarchy functionally — what each level carries and why control totals must balance at every level — without quoting field specifications from memory;
- explain AFT settlement: net positions from clearing, funded by direct clearers through Lynx payments to Bank of Canada settlement accounts on a later business day, with agents settling for the indirect clearers they sponsor;
- use the six vocabulary words — exchange, clearing, settlement, posting, availability, finality — exactly, and explain why availability on a batch rail is not finality;
- explain business-day, window, due-date and cutoff discipline in relative terms, assign any instruction honestly to this window or the next, and route late-but-urgent work to a same-day-final rail instead of improvising around the window;
- place fraud, authorization, sanctions and record-keeping controls before release, and explain why screening after release is recovery rather than prevention;
- classify rejects, returns, reversals, adjustments and recall requests, and describe recovery that always creates a linked new event and never edits history;
- explain posting, accounting, liquidity, reporting and three-way reconciliation for AFT, including funding the settlement position and reconciling through an agent;
- describe what a bank must do to offer AFT — capacity choice, agency terms, connectivity, unhappy-path testing, parallel operation, contingency — and how to stay ready for ISO 20022 coexistence and the planned Real-Time Rail without treating either as live routing;
- work through fictional Canadian cases, extract each control lesson, and find the later chapters on payroll, PAD, returns and ISO 20022.
For a roughly 60-minute core session, spend about 10 minutes on Section 1 with the push-versus-pull diagram, 15 minutes on Sections 2–3 with the operating-model and bank-modules diagrams, 10 minutes on Sections 4–5 with the file-hierarchy diagram, 10 minutes on Sections 6–8 with the timeline diagram, 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, settlement and finality
- Data, files, messages and references
- Rules, cutoffs, service levels and customer impact
- Fraud, compliance and operational controls
- Exceptions, returns 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 two ordinary Canadian business days that look nothing alike to the customer and almost identical to the clearing system. On one, a manufacturer with four hundred staff expects every paycheque credited in time for Friday morning — money flowing outward from one employer to hundreds of employees. On the other, a provincial utility expects forty thousand monthly bills collected without chasing forty thousand households — money flowing inward from thousands of payers to one biller. The first is a push: the originator sends funds toward beneficiaries. The second is a pull: the payee collects from payers on the strength of authorizations signed long ago. AFT serves both through the same file mechanics, the same exchange windows, the same netting and the same deferred settlement — and a banker who cannot keep the two directions straight will misjudge authorization, misprice risk and mishandle the first dispute.
AFT exists because these recurring obligations share a shape that suits batch processing: numerous, individually modest, predictable in rhythm, and tolerant of value that settles in a later window rather than this second. Running payroll as hundreds of individual real-time payments, each with its own funding event, would cost a multiple of batch for no customer benefit. Accumulating the items into files, exchanging the files between banks, netting each participant's obligations into a single position and settling that position once is radically cheaper in liquidity, processing and operations attention. That is the economic logic the fundamentals chapter taught for ACSS as a whole; AFT is where the logic is purest, because AFT files are its highest-volume, most-automated expression. Payments Canada's 2025 ACSS statistics report 10,606,975,666 items worth $10,009,139,582,000 across all ACSS categories. AFT is a subset: 1,294,728,182 credit items worth $5,037,186,190,000 and 1,178,636,330 debit items worth $1,611,498,509,000. Those figures include items exchanged between direct clearers, not on-us items. The totals show AFT's scale without incorrectly treating all ACSS volume as AFT. A single flawed employer file can still create thousands of customer events, and a missed window shifts value for every originator queued behind it.
Customers experience AFT through a short list of recurring questions, and every section of this chapter equips you to answer one or more of them honestly. The payroll administrator asks: if I release the file today, will staff see pay on the due date — a question about windows and cutoffs answered in Sections 3 and 6. The supplier's receivables clerk asks: will the payment carry our invoice reference so cash applies itself — a question about data answered in Section 5. The employee asks: can I spend it today — a question about posting versus settlement versus availability answered in Sections 4 and 9. The householder who sees an unfamiliar utility debit asks: did I agree to this, and how do I get it back — a question about authorization and returns answered in Sections 7 and 8. The small-business owner asks: why does batch cost so little compared to a wire — a question about the batch bargain answered right here. None of these customers thinks about streams, rules or settlement accounts. Each of them will judge the bank on timing, certainty, cost and recourse.
It helps to place AFT on the map before going deeper. Within ACSS, AFT is the electronic file-based stream family: credits that push funds out — payroll, supplier direct deposits, government benefits — and debits that pull funds in — pre-authorized collections for bills, dues, loan instalments and contributions. Paper cheques and their images clear through ACSS too, but through paper mechanics with their own handling; AFT never involves a physical instrument, only files, records and entries. When a payment needs same-day certainty and irrevocability, the answer is a Lynx wire — individual real-time settlement in central-bank money at wholesale pricing — not a faster AFT file, because batch finality cannot be hurried at any price after its window. The planned Real-Time Rail, when it launches, will add a genuine instant capability to the choice set; until then it changes advisory conversations about the future without changing a single routing decision today. Place every event on this map — push or pull, batch or wire, file or paper — before designing anything.
The diagram above carries the chapter's central distinction, so study it before reading further. Both lanes share file discipline, validation before release, ACSS exchange, netted settlement, linked returns and three-way reconciliation. They differ in who authorizes, who bears return exposure and what evidence wins a dispute. Push asks whether the beneficiary was paid on the due date. Pull asks whether the collection was authorized, funded and still standing after returns ran their course. Every later section revisits this split, so fix it in mind now.
Later chapters take the specialist topics to full depth — payroll, pre-authorized debits, returns and reconciliation, ISO 20022 coexistence — and no operational procedure should be written from a summary section alone.
2. Participants, responsibilities and system boundaries
An AFT payment always involves more parties than the two customers who experience it as one person paying another, and the bank professional must keep five layers straight: the customers at each end, the banks in their clearing capacities, the intermediaries that create scale, the system operator, and the settlement agent with its oversight twin. Confusing any two produces the classic errors — treating the system as the party that owes the beneficiary money, or a payroll bureau as if it warranted the file.
Start with customers, because direction decides everything downstream. The originator creates the economic event and the file: the employer running payroll, the business paying suppliers, the government department issuing benefits, the biller collecting monthly charges. The beneficiary in a push is entitled to receive: the employee, the supplier, the benefit recipient. In a pull, the roles refract: the biller is the originator of the collection file, while the payer — the householder, the member, the borrower — is the party debited, and the payer's authorization is the foundation the whole collection stands on. The boundary that matters operationally is this: customers own the obligation, the instruction and, for pulls, the authorization — but customers never settle interbank value. Only banks, acting in their clearing capacities, move value between institutions. When a customer asks where the money is, walk the chain of banks and agents — never point at the system as a holder of funds.
Banks participate in AFT through the same capacities the fundamentals chapter established for ACSS, and capacity determines liability, funding duty and what may be promised to customers. A direct clearer exchanges AFT files directly with other clearers, enters its volumes and values into the clearing calculation, holds a settlement account at the Bank of Canada, funds its net position in the settlement window, and may act as clearing and settlement agent for others. A group clearer is a direct clearer serving a group of member institutions under group arrangements — one settlement footprint carrying several institutions' flows. An indirect clearer participates through a direct clearer as its clearing and settlement agent: the agent exchanges files on its behalf, includes its items in positions, settles for it, and reports back, all under an agreement with defined cutoffs, funding calls, return handling, reporting content and incident coordination. Eligibility for direct status was broadened so qualifying members may apply — but many sensibly remain indirect, because an agent absorbs settlement, funding and coverage overhead.
The practical consequence runs through every customer commitment an indirect bank makes. Its payroll cutoff is bounded by its agent's file-acceptance timetable, not by its own portal's closing time. Its ability to release a late file depends on whether the agent still has a window. Its return turnaround follows the agent's reporting cycle, and its incident communication during a bad window is only as fast as the agent's notification. Whenever anyone says the bank will do something with an AFT file, the professional reflex must be to ask in which capacity — direct, group or indirect — because the answer changes cutoffs, funding, returns and incident handling every time.
Around the core parties sit the intermediaries that originate scale: employers, billers, payroll processors, corporate service bureaus and software platforms that build the files banks release into clearing. Their economic importance is enormous — a large share of AFT volume reaches banks through bureau channels — and their legal position must be stated plainly: the bank's duty to validate, warrant and control the file does not move upstream to the bureau because the bureau pressed the keys. Each origination relationship should document, before volume flows, who authenticates the file, who validates content, who warrants authorization, who handles returns and retries, and who reconciles what against which report. Every painful AFT incident involves a handoff where both sides assumed the other owned a step. Write the responsibilities down; test the handoff with a small file before the first large one.
Payments Canada sits in the middle as owner and operator of ACSS. It publishes and maintains the rulebook anchored by By-law No. 3 — including the AFT rules, Rule F1 for established AFT and Rule F4 for ISO 20022 AFT, with the associated standards and usage guidelines — and it operates the exchange and clearing infrastructure through which AFT files move and in which volumes and values become net positions. What it does not do is equally load-bearing: it holds no customer accounts, decides no individual posting, funds no participant's position, guarantees no beneficiary payment, and screens no file for fraud. 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 the two hats the fundamentals chapter separated. As settlement provider it provides the settlement accounts on whose books ACSS net positions are finally extinguished; direct clearers make the required inter-FI settlement payments through the live high-value infrastructure. As overseer it oversees ACSS and Lynx under the Payment Clearing and Settlement Act, with Lynx designated systemically important. One institution, two functions, each answering a different question — never to be blended in customer communication, incident tickets or audit responses.
The diagram above is the chapter's anchor. Read it along the flow — originator, originating institution, ACSS exchange and clearing, receiving institution, beneficiary, with the settlement layer running underneath and returns travelling the same path in reverse — and then for ownership: customers instruct, banks warrant and post, the operator calculates, the central bank settles. Responsibility is a chain with no gaps: the originator authorizes and funds; the originating bank validates, releases and warrants; the clearing layer exchanges and positions; the settlement agent moves value finally; the receiving bank posts and reports. Every investigation in Section 8 walks this chain backwards, which is why learning it once, here, pays for itself in every later chapter.
3. Initiation, validation and bank processing
Every AFT item starts in the same place: a customer instruction entering a bank channel and passing through the bank's payment operations before any external system sees it. The channel varies — a business portal upload, a host-to-host file from an employer's enterprise system, a biller's collection file on a standing schedule, a bureau transmission carrying dozens of employer payrolls — but the bank's job converges on one discipline: turn an instruction into a releasable, warranted 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-window fix. Items rejected in clearing cost a business day and a round of reporting. Items released with bad data cost an investigation, returns and customer compensation. The whole economics of this section is that ordering.
Initiation captures five facts plus authority: who pays whom, how much, in what currency and between which accounts, for which due date, with what references, and under what authority. A payroll file carries employee account details, amounts, the pay date that is the file's due date, batch totals and the employer's funding commitment. A supplier-payment file carries vendor account details, amounts, value dates and the invoice references the payee needs to apply cash. A collection file carries payer account details, amounts, collection dates and linkage to the underlying authorizations. Capture currency explicitly: AFT covers Canadian-dollar items and, subject to stated exceptions, US-dollar items — and an assumed currency can enter the wrong settlement path. The bank's first processing job is normalization: whatever the channel delivered becomes one internal instruction record per item with a durable identifier that survives every later stage. Without that internal anchor the bank cannot track, investigate, repair or reconcile.
Validation is where most preventable AFT failures are caught, and it must complete before release — full stop. Account validation confirms the debit account exists, is open, is enabled for this payment type and will be funded on the due date. Routing validation confirms the destination's institution, transit and account structure will survive exchange, checked against current routing references: an unreachable or malformed destination must be repaired or rejected here, never released to see what happens. Duplicate and anomaly checks compare the file against history — a payroll file for twice the usual total, a collection file with an unfamiliar spike, a file identifier already seen — because duplicate release is the costliest unforced error in batch and the cheapest to prevent. Amount and date checks confirm value dates fall on processable business days and item amounts sum to the stated batch and file control totals. Authorization linkage confirms the pull has its basis: the mandate or agreement reference for each collection, available as retrievable evidence even where it does not travel with every clearing record. Data-completeness checks confirm required fields are present, including beneficiary remittance detail. Repair or reject happens here, with a reason, a repair path and a next-window promise communicated the same day.
Between validation and release sits the control stack, and its order matters as much as its contents. Authentication and entitlement confirm the file genuinely comes from the authorized originator with the right approvals — dual control over file release for meaningful values, callbacks to known contacts for new originators and changed destination details. Limits against approved thresholds bind each originator to file sizes and totals the bank has underwritten. Fraud scoring challenges anomalous payees, first-time destinations and mule-pattern incoming credits before value moves. Sanctions and watchlist screening with pass, false-positive or true-hit dispositions gates release for every party on the file — and files contain hundreds of parties, so a single true hit must hold the tainted items without stranding the clean ones. Record-keeping capture preserves the instruction, approvals, validation results and screening dispositions for the full window in which returns, disputes and audits can arise. Cutoff logic assigns the instruction to this window or the next and communicates that assignment honestly at intake. Only after all of these does the bank release. Section 7 expands each control family; the architectural point here is placement — screening after release is recovery, not prevention, and batch recovery runs on return cycles measured in business days.
Release commits the instruction to the clearing path with the bank's warrant implied: the bank stands behind the items it introduces, including their authorization and data quality, under the rulebook. A direct clearer delivers the file through its gateway into ACSS exchange and records release time, window assignment, gateway acknowledgement and external references, because every inquiry for the rest of the item's life starts from that record. An indirect clearer hands the file into its agent's timetable, and the agent's cutoff — not the bank's internal readiness — decides which window the items enter. Bureau-originated volume gets the same release discipline with one addition: the bank verifies the bureau transmission against the originator's standing instructions and limits before it becomes the bank's warrant. After release the bank tracks acceptances and rejections, watches for returns, manages repair queues, posts entries, reports, and feeds reconciliation. Amendments after release are narrow by design: correction before the clearing point of no return where the rules permit it, never silent editing of an exchanged or settled item. Two principles decide whether all of this survives reality. First, route by policy rather than habit: a time-critical payment 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 phone call; a bank that accepts everything and fails in clearing creates a week of investigations.
The diagram above collects the bank's side into five modules with an evidence spine running through all of them. Use it as an implementation checklist, a review framework and an incident map: when an AFT file goes wrong, locate the module where prevention should have engaged, and the fix is usually a control moved earlier or a handoff written down rather than a new system.
4. Clearing, 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 AFT come from blending six events that are genuinely different. Exchange delivers files and records 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. Use the six words exactly, and half of batch confusion disappears.
AFT defers settlement by design, and the deferral is the whole point of the stream. Participants exchange files during batch windows — credit batches and debit batches, established-format and ISO 20022 files side by side — through direct or agency arrangements. Each direct clearer enters the volumes and values of the items for which it is owed funds, and those entries combine with the other retail-batch totals to determine net balances: a single net amount each direct clearer owes to the system or is owed by it. Settlement of the previous cycle's net balances then occurs on a later business day, when direct clearers with net owing positions send Lynx payments and the resulting debits and credits across settlement accounts at the Bank of Canada extinguish the balances. Thousands of customer items — payroll credits for hundreds of employers, collection debits for dozens of billers — collapse into one funding event per clearer. That collapse is the efficiency of batch, and it is why treasury teams forecast nets rather than items, as Section 9 explains. AFT items clear inside ACSS while the resulting nets settle through Lynx mechanics into central-bank money — gross legs producing a net result.
Finality in this model is positional and rule-governed, not per-item and instant. When the settlement window completes, interbank positions are settled finally in central-bank money — yet return rights for the underlying customer items survive for defined reasons and timeframes: insufficient funds, closed or invalid accounts, disputed collections, error corrections. A payroll credit can post to the employee while its interbank position settles later; a collection debit can post to the biller while the payer retains the right to see it returned. That is the batch bargain stated precisely: efficiency and reach at the cost of deferred finality and return exposure. Contrast real-time gross settlement, where each payment settles individually across Bank of Canada accounts with immediate finality and no netting, and where recovering a misdirected payment requires a new payment with the beneficiary's cooperation. The customer question behind half of all rail-choice discussions — can you just make it final today — has exactly one honest answer on a batch rail after its window: no at any price. Finality today requires a today-final rail, with its pricing, data requirements and irrevocability accepted explicitly.
Two boundary notes keep this section honest. The first concerns currency. AFT covers Canadian-dollar items and, subject to stated exceptions in the rulebook, US-dollar items on accounts domiciled in Canada — and US-dollar batch settlement does not travel the Lynx-to-Bank-of-Canada path that Canadian-dollar nets use. Validate currency at initiation, as Section 3 required, and confirm the settlement path for any US-dollar file before promising timing. The second concerns the planned Real-Time Rail: because it is not a live system, nothing in this section's sequencing changes when industry discussion mentions it. Deferred batch settlement with surviving return rights is today's reality for AFT, and customer advice must describe today's reality. Exchange mechanics and the settlement lifecycle belong to their dedicated chapters; this section gave you the vocabulary, shape and bargain.
5. Data, files, messages and references
If clearing is the road network, data is the addressing — and AFT fails far more often from bad addressing, unbalanced files and thin references than from system outages. The bank's data discipline compresses into three verbs: capture completely, validate early, preserve identity end to end. This section maps what each AFT file needs, which references must survive the whole journey, and where the coexistence of established and ISO 20022 formats changes the payload without changing the discipline.
Start with the hierarchy, because every AFT conversation assumes it. A file is an exchange unit containing one or more AFT transactions. Its structure, logical records and control fields are defined by Standard 005 for established AFT or the ISO AFT Usage Guidelines for ISO 20022 AFT; do not assume that a training diagram's grouping rule is a complete field specification. Within the file sit one or more batches or message-level groupings, each grouping items of a kind — credit items carrying push payments such as payroll and supplier deposits, debit items carrying pull collections with their authorization linkage. Within each grouping sit item records, one per beneficiary or payer: destination or payer account details, amount, due or collection date, the originator's reference, and the remittance detail the other end needs to reconcile. The applicable format's control totals must balance at the required levels, and a file that fails initial validation is rejected or repaired before exchange, never released to clearing to see what happens.
The diagram above is deliberately functional: it shows what each level carries and where balancing applies, and it specifies nothing about field layouts, record codes or message tags. That restraint is a professional habit, not an omission. Established AFT files are governed by Rule F1 with the associated file standard; ISO 20022 AFT files are governed by Rule F4 with the ISO AFT usage guidelines; transaction and return-reason coding conventions live in their own published standard. All of these are versioned documents that change, and any training material quoting their field detail is already decaying. The discipline that does not decay: validate against the current published version before release, map explicitly where formats meet, log what was truncated or enriched at every mapping, and carry the originator's reference forward so the beneficiary can reconcile. The later chapter on ISO 20022 and legacy-format coexistence teaches the mapping craft in full. Coexistence is a multi-year condition to engineer for, not a cutover to wait out.
Domestic routing rests on the Canadian account-identifier triple — institution, transit and account — validated against current routing references that establish reachability, because exchange sorts on it. An unreachable or malformed destination must be rejected or repaired inside the bank's processing: batch charges that error as a return cycle measured in business days. The block's routing chapters teach the reference mechanics; this section's contribution is the placement rule — fix addressing before release.
References are what let humans and systems agree they are discussing the same item, and four must survive every AFT journey. The bank's internal instruction identifier anchors tracking from intake through investigation. The clearing trace — file, batch and item traceability through exchange — anchors the system's view and matches system reports to bank records. The return linkage anchors the round trip when an item comes back, so the return finds its original without manual matching. The customer remittance — employee identifier, invoice number, account reference — anchors the beneficiary's reconciliation and decides whether cash applies itself or joins the unapplied queue. Drop any one and a different team pays: drop the internal identifier and investigations stall; drop the clearing trace and operations cannot match system reports; drop the return linkage and returns become research projects; drop the remittance and the beneficiary phones the bank.
Two practical consequences follow. First, master-data quality is a payments control: clean vendor masters, validated employee banking details collected with care at onboarding, disciplined mandate records for every pull collection. More AFT exceptions are prevented by onboarding hygiene than by any downstream repair process. Second, evidence preservation starts at origination: authorizations, approvals, validation results, screening dispositions and release records must be retained retrievably for the full window in which returns, disputes and audits can arise. A mandate file that cannot be found when a payer disputes is operationally equivalent to no mandate at all.
6. Rules, cutoffs, service levels and customer impact
Customers experience rules as promises — will it arrive on the due date, when can the funds be used, what will it cost, what happens if it fails — while the bank experiences rules as windows, obligations and evidence. This section distinguishes system-rule deadlines from bank and agent customer cutoffs. The former are stated in the next paragraph; the latter vary by bank, clearer, file type, currency, risk decision and holiday calendar. Binding customer promises therefore come from the current F1/F4 text together with the bank's published schedules and the published system closure calendar.
The rulebook layering is straightforward in shape, and shape is all an operating-model chapter requires. By-law No. 3 establishes the legal foundation for payment items and ACSS. Rules under it govern what may be exchanged, participant conduct, stream requirements, returns and adjustments, and the obligations of each capacity — with Rule F1 governing established AFT exchange, processing, settlement and exception handling, and Rule F4 governing ISO 20022 AFT exchange on the same dimensions. Standards govern the technical detail: file layouts, encoding, transaction and return-reason codes, control documents. Functionally, every operational question has a binding answer in the published framework, and past practice is never a substitute for checking the current version. The detailed map of which rule governs which stream and window belongs to the streams-and-windows chapter later in this block; here, know the layers, know the two AFT rules by name and purpose, and keep the habit of checking currency.
Business days anchor everything in AFT. Payments Canada systems operate Monday to Friday except statutory holidays, with closures published in the system closure schedule. A file received after the applicable rule or bank/agent cutoff belongs to the next window. A Friday-afternoon instruction that falls after the bank's internal cutoff waits under published policy, and the customer should hear that at intake rather than discovering it when pay is late. A holiday shifts due dates, exchange, settlement and return clocks under the applicable rule and calendar; it is not safe to promise that a channel deadline overrides the closure schedule. The intake logic that assigns each instruction to a business-day window — and communicates that window honestly at intake — is the single most customer-visible control in this chapter.
Within the business-day frame, AFT runs on two rule disciplines. F1 and F4 currently set three exchange deadlines for receipt, on business days in Eastern Time: 09:30:00, 16:30:00 and 21:00:00. The exchange periods are the preceding intervals, and a file is assigned to the period in which the processing clearer receives it. For credits, Serviceability Code 0 requires exchange on the earlier of the business day before the due date (where available) or the due date; Code 1 requires one business day before; Code 2 requires two business days before. Subject to the rule's exceptions, Code 0 funds are made available within two hours of the applicable exchange deadline, while Codes 1 and 2 are available by opening of business on the due date; an indirect clearer's Code 0 uses its IC cut-off. Debit transactions may not be delivered before the due date. These are system-rule requirements, not a promise that a bank's customer cutoff is the same clock time. The second discipline is deferred settlement after exchange: positions settle on the next business-day cycle, while posting and availability follow the applicable rule and account policy.
The timeline above answers the intake question behind most AFT complaints: what has to happen, in what order, for money to move on the due date. Walk any customer file along it — where are we now, what is the next gate, what happens if this gate is missed — and the conversation changes from promises to mechanics. Missed the cutoff means next window, stated plainly and early. Late but genuinely urgent means a same-day-final rail with its pricing and irrevocability accepted explicitly, never batch with a wish attached. Holidays shift the whole chain by a business day, communicated before the week starts.
Service levels bundle timing with certainty, information and recourse, and the bank's advisory job is to match the business event to the bundle rather than selling speed in isolation. 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. 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 account was credited or debited; 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. Most AFT complaints are vocabulary failures wearing operational costumes: the customer heard sent and understood final, and nobody corrected the translation until money moved unexpectedly.
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 authorization review that starts 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 flow where it can still change the outcome. Rail-level control detail for fraud landscapes, reporting mechanics and screening systems lives in the programme's later risk and compliance coverage, including the dedicated fraud-landscape chapter; here the lesson is architectural — prevention sits before release, detection sits across processing and clearing, and evidence sits everywhere.
Fraud against AFT spans initiation, transaction risk and post-event response, and batch gives both sides time: time for the fraudster to layer across files, and time for the bank to catch what layering leaves behind. Takeover and social engineering attack initiation — authenticate the originator, verify device and behaviour, challenge anomalous payees and changed banking details before release, with callbacks to known contacts for high-risk changes, because a single altered account number in a payroll file diverts a real salary. Origination fraud attacks the file itself — fictitious employees added before a run, inflated supplier payments to a controlled account, fabricated collection files drawn on strangers — met with originator onboarding that underwrites volume and values, dual control over file release, and anomaly checks against history that treat every first-time spike as guilty until explained. Incoming-side fraud attacks the receiving account: mule networks collect batch credits and move them on within hours, which means scoring incoming credits too rather than screening only outgoing payments. Collection fraud attacks authority: debits raised without valid authorization — met with mandate evidence before presentment and fast, honest dispute handling after. There is no instrument to examine here, only data and authority, so the controls are onboarding depth, file analytics and evidence retrievability. Each of these is a before-release control first and an investigation second.
Authorization controls deserve separate emphasis because pulls move money on claimed authority rather than fresh instruction, and AFT debits are the highest-volume pull most banks handle. The bank must be able to evidence the payer's authorization when challenged: the agreement or mandate captured understandably at signup, stored retrievably, linked to each collection item, and producible when a payer disputes weeks later. Authorization practice — what a valid pre-authorized agreement contains, how cancellation works, what the biller must do on dispute — gets full treatment in the programme's PAD coverage; the operating-model point here is that authorization evidence is created at onboarding and preserved at origination, never assembled during a dispute. A biller whose mandates live in filing cabinets or nowhere at all has no product, only exposure — and the bank that onboards such a biller without verifying mandate practice has underwritten that exposure as its own return volume.
Sanctions, watchlist and related screening are bank-specific and risk-based controls implemented under applicable law, supervisory expectations and the institution's policies; Rule F1/F4 does not turn this training summary into a sanctions procedure. Where a bank screens parties, remittance information or routing before release, it needs dispositions, escalation and quarantine controls that can handle a high-volume file without releasing a true hit. Complete data from origination, explicit mapping logs where formats meet, and evidence stating what was checked, when, against which lists, by whom and with what outcome support a defensible process. Do not confuse this with FINTRAC's electronic-funds-transfer report: FINTRAC expressly excludes transfers carried out by direct deposit or pre-authorized debit from that EFT definition, while other AML, suspicious-transaction, record-keeping and sanctions obligations can still apply according to the entity and activity.
AML, sanctions and record-keeping obligations attach according to the institution, client, transaction and applicable legislation; they are not identical to an AFT approval rule. Batch scale makes evidence a systems discipline: capture at initiation, preserve untruncated through clearing, and feed reporting from complete data — with file-level metadata, item-level linkage and automated feeds tested with every format or platform change. FINTRAC's current EFT guidance excludes direct deposits and PADs from the EFT report definition, so a bank must not label every AFT item a reportable EFT; it must apply the correct statutory and regulatory test. Thresholds, retention periods and filing mechanics belong to current FINTRAC guidance and the institution's compliance program. Supervisors and audit will still ask who instructed, who approved, what was checked and when, which window carried it, how it settled, where it posted and how exceptions were handled. A bank that keeps that evidence as a by-product of disciplined processing answers easily; a bank that reconstructs it after the fact answers expensively. The control that binds the families is release discipline from Section 3 — no instruction reaches clearing without passing authentication, validation, limits, fraud, sanctions, cutoff and approval in that order, each decision logged. Overrides of that order 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.
8. Exceptions, returns and recovery
Every AFT 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 file, manually crediting the beneficiary, editing an exchanged record — create duplicate payments and audit breaks that dwarf the original error. This section teaches the classification and the recovery discipline at operating-model depth. Each mechanism in full — timelines, reason codes, adjustment flows, reconciliation of exceptions — belongs to the dedicated returns-and-reconciliation chapters later in the programme, including the AFT credit-returns chapter and the PAD insufficient-funds-and-retries chapter, summarized and pointed to throughout.
Start with the taxonomy, because precise words are the cheapest control in exception handling. A reject happens before clearing: the bank's processing, the gateway or the receiving side refuses the instruction — invalid routing, closed account, limit breach, failed screening, incomplete data, unbalanced file. Nothing settled; the originator repairs and re-originates. A return happens after entry: the receiving side sends the item back — insufficient funds, closed account, disputed collection, erroneous credit — with reason codes and timeframes defined by the rulebook. Returns are normal batch traffic, not scandals: a well-run AFT operation processes them daily with straight-through matching. A reversal corrects a bank or system error through a defined mechanism — a duplicate file released twice, a wrong amount the bank introduced — never by silent editing. An adjustment handles the small-value consequences the rulebook allocates: fees, compensation and corrections. A recall or return request, rare in pure batch, asks the other side to send funds back — which requires cooperation, because settled value cannot be unilaterally pulled back. An investigation tracks an uncertain outcome: a file with no acknowledgement, a return without a matching original, a settlement figure that does not agree.
Return reasons cluster into a short list worth learning by shape rather than by code — codes live in the published standard and change, while shapes endure. Funds reasons — insufficient funds, stopped or held payments — say the payer side could not or would not pay; recourse is retry discipline and customer contact, and retry without a rulebook-aware limit is how one failure becomes three. Account reasons — closed, invalid, frozen, misdirected by bad data — say addressing or account state failed; recourse is master-data repair before re-origination, because re-sending to the same bad address manufactures the next return in advance. Authorization reasons — disputed collections, debits the payer says were never agreed or were cancelled — say the pull lacked an enforceable basis; recourse is mandate evidence or acceptance of the return, with re-origination off the table until the authorization position is resolved. Administrative reasons — ineligible items, malformed records, duplicates the bank released — say the bank's own processing failed; recourse is internal, starting with the validation and release discipline of Section 3. Code-level detail, per-reason handling and retry boundaries live in the returns chapters; the operating-model skill is triage, because the category decides the next step and the owner.
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 instruction. A returned credit is corrected and re-originated as its own item, carrying the references that tie it to the failure it replaces. A returned collection is retried only within the permitted retry discipline, with payer communication that states what happened and what changes next. A duplicate file is reversed through the defined mechanism with the original preserved for audit — the bank that re-sends the same payment again without linkage has created two payments and will discover the second one from the customer at the worst moment. Every recovery carries three references minimum: the original instruction identifier, the clearing trace of the failed or returned item, and the new event's own identifier. Investigations run on evidence assembled from the chain in Section 2: start from the bank's release record — when, which window, which references — 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. 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. Most AFT investigations close within return and reporting cycles; the ones that do not are usually reference failures — which is why Section 5 called reference discipline decisive.
Containment deserves a final word because batch scale punishes slow containment without mercy. A corrupt file, a compromised originator credential, a bureau transmission carrying another client's data: first stop the bleeding — hold pending releases from the affected source, quarantine the repair queue, notify agents or counterparties where required — and only then diagnose. Containment decisions need pre-assigned authority reachable during every window, not an escalation tree that convenes tomorrow. The returns chapters build the runbooks with timelines and codes; this section establishes the mindset: classify, contain, recover as linked events, reconcile with evidence. One boundary to carry forward: payroll and PAD exceptions each have domain-specific handling — pay-date repair urgency for payroll credits, mandate-evidence and retry discipline for collections — taught in their own chapters.
9. Posting, accounting, liquidity, reporting and reconciliation
This is the section where batch becomes money on statements and funding on balance sheets — where operations, finance and treasury meet over the same file. Posting moves customer balances. Accounting records what the bank did in its own books. Liquidity ensures the bank can fund what it owes in the settlement window. Reporting tells customers, counterparties and agents what happened. Reconciliation proves the whole story agrees. Each is a distinct discipline with distinct owners, and AFT failures at month-end or in the settlement window almost always trace to blurring two of them.
Posting translates clearing outcomes into customer account entries, governed by the timing relationship from Section 4: customer posting frequently precedes interbank settlement, and availability follows posting policy rather than settlement itself. Posting policy encodes the bank's risk appetite explicitly — which AFT items post on which day relative to exchange and settlement, which categories post memo first and hard later, which attract holds, and how availability is communicated with return-rights honesty. Memo-versus-hard discipline matters because memo entries inform while hard entries move balances; confusing the two creates the showed-then-disappeared complaints that erode trust faster than any delay. Originator-side posting has its own discipline: the employer's account debited for the payroll total with fees separated, the biller's account credited for collections with returns debited back as their own entries. Pull debits deserve special care — a payer debited for a collection must see a description identifying the biller well enough to prevent the dispute that a cryptic descriptor manufactures, and a biller credited for thousands of collections must receive reporting granular enough to reconcile without phoning the bank.
Accounting records the bank's own position through every stage, and separates three things the business must never net prematurely: amounts due to and from customers, amounts due to and from the clearing through positions and settlement accounts, and the fees and adjustments that are the bank's own income or expense. Clearing and suspense accounts carry items between exchange and settlement; settlement accounts carry the final interbank movement for direct clearers; agency accounts carry the indirect bank's position with its agent. Each must balance and clear to zero on its own cycle. Returns and adjustments post as their own linked entries — never as edits to history.
Liquidity is the treasury view of the same flow: because positions net, a direct clearer funds one net obligation per cycle rather than thousands of gross items — efficient, but only if the net is forecast accurately. Treasury needs timely position forecasts from operations, adjusted for holidays, large originator files, known return volumes and seasonal peaks like month-end payrolls. The funding moves through the settlement accounts via Lynx settlement legs, and an indirect clearer must fund its agent under the agency timetable with equal seriousness. Forecast the net, fund the net, confirm the funding — every settlement window.
Reporting closes the loop to everyone with a stake in the outcome. Originators receive acceptance, rejection and return reporting on cycles that let them repair within the next window rather than discovering failures at month-end — file-level confirmations that reconcile to their enterprise systems and return advices in repair-grade detail. Beneficiaries receive statements whose descriptors identify the originator. Agents report positions, settlement and returns to their indirect clearers in sufficient detail for the indirect bank to post, reconcile and answer its customers — which is why agency reporting standards belong in the agency agreement. 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 of Section 5.
Reconciliation proves the story, and AFT reconciliation is three-way by nature. First, internal records — what processing released versus what posting applied — must agree: every released item posted or queued with a reason. Second, internal records must agree with clearing evidence — exchanged, positioned, rejected and returned as reported. Third, clearing evidence must agree with settlement evidence — positions extinguished through settlement-account entries matching to the dollar. Direct clearers reconcile all three legs including Bank of Canada account entries; indirect clearers reconcile through their agent's reporting. Breaks get worked by category — timing breaks that clear next cycle versus genuine breaks signalling missing items or processing defects — with ownership and ageing on every open break. Unreconciled differences compound with age. The block's exceptions-and-reconciliation chapter teaches the break-working craft; this section establishes the architecture.
10. Bank implementation, testing and resilience
Offering AFT — or changing anything about how a bank participates in it — is an implementation project with regulatory, operational and customer dimensions. 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. Banks that treat AFT onboarding as a file-format task discover, usually in the first live window, that it is a capacity, funding, control and reconciliation task wearing a file-format costume.
Participation choices come first: clear directly — exchanging files, entering positions, holding settlement accounts and funding nets — or indirectly through a direct clearer as agent, or within group arrangements. The decision weighs volume and growth, funding capability, operations coverage across every window the bank will use, technology readiness, and the control overhead of direct obligations against the dependency cost of agency: timetable constraint, reporting dependence, commercial terms and concentration risk. Eligibility for direct status was broadened so qualifying members may apply — but eligibility is permission, not a recommendation, and many institutions remain indirect by sound business judgment. For them the implementation is dominated by one document: the agency agreement, whose cutoffs, funding calls, return handling, reporting content and timing, incident coordination, liability allocation and termination assistance must be explicit enough to operate from under pressure. Counterparties sometimes negotiate agency terms as commercial paperwork; operations teams live inside them as procedure. Let operations mark up the draft.
Connectivity and certification come next. The bank connects through approved channels, implements the file and message standards for its streams — established and ISO 20022 paths both, with explicit mapping where they meet — configures its gateway and hub adapters, and proves through structured testing that it can send valid files, receive and apply reports and returns, handle rejects of every major kind, and reconcile positions to the dollar. The published lead times are material: a direct clearer must register for AFT exchange at least 90 calendar days before participating, while ISO 20022 AFT registration is at least 180 days before the intended implementation date. F1/F4 also require participant testing before exchange; ISO onboarding states that indirect implementation is coordinated with the clearing agent. Plan backwards from the first live due date, and do not generalize these system registration periods to every bank product or customer onboarding. Testing must cover the unhappy paths with at least the energy given to the happy ones: malformed files, unbalanced batches, duplicate deliveries, returns of every major reason, holiday-week calendars, late-window arrivals, agent-timeout behaviour for indirect participants. Parallel operation — running new flows alongside old with full reconciliation comparison — earns its cost the first time it catches a mapping defect that unit tests missed. Cutover needs a rollback plan with a named decision-maker and a clock: batch windows do not wait while committees convene.
Change management after go-live is where most institutions actually live. Every format change, platform migration, new originator product, routing-reference update and rulebook amendment is a mini-implementation: impact assessment, regression testing, originator communication, operations briefing, and a monitored first window with extra reconciliation coverage. The ISO 20022 coexistence from Section 5 makes this permanent: dual-format validation, explicit mapping rules and originator migration timetables are standing capabilities, not project phases.
Resilience is the supervisory-grade expression of all of this. Backup connectivity and contingency file paths must be tested, not merely documented, consistent with OSFI expectations for critical-operation tolerances, scenario testing, continuity, recovery and third-party dependencies. Missed-window procedures must state plainly what happens: items belong to the next window, customers are told so promptly in the vocabulary of Section 6, and funding forecasts are revised. Staffing must cover every window the bank participates in, including holiday weeks and return-driven work arriving later. Modernization readiness closes the section: maintain a payment hub with rail adapters, disciplined reference carriage and format-mapping capability, so each future rail arrives as a new adapter plus testing rather than a rebuild. As of 5 October 2026, Payments Canada says RTR testing continues toward a sequenced Q4 2026 launch; that is not proof that a bank can route live customer work to RTR today.
11. Practical Canadian examples
Theory settles when you watch it work on recognizable business. The three cases below are fictional — invented companies, invented figures, realistic mechanics — each labelled as required. They cross a payroll push, a collection pull with returns, and a supplier payment gone wrong.
Example (fictional): Lakeshore Packaging and the Friday payroll. Lakeshore is a fictional Ontario packaging firm with about 350 employees paid biweekly by direct deposit. On Wednesday afternoon its payroll administrator uploads the payroll file through the company's bank portal: employee account details, amounts, pay date Friday, batch totals and funding authorization. The bank's processing validates the file — applicable format controls pass, destinations are well-formed and reachable, the amount sits within the company's approved limit, the release carries proper dual approval, fraud checks find no anomalous payees, and the Wednesday release satisfies the applicable Serviceability Code and bank cutoff for a Friday due date. The file's credit batches enter exchange in their window, clear and settle through the deferred cycle; employees see credits on the due date. Then the wrinkle: one account number was keyed wrong — a transposed digit that still passed format checks. The credit cannot post and returns with an account reason. Operations matches the return to the original via the clearing trace, notifies Lakeshore the same day with reason, repair path and next-window promise, and Lakeshore re-originates that single credit as a linked new item. Control lesson: validated employee banking details at onboarding prevent the most common payroll exception there is.
Example (fictional): Prairie Ridge Utilities and the month of returns. Prairie Ridge is a fictional Alberta utility collecting about 60,000 monthly bills by pre-authorized debit. Each collection file carries payer details, amounts, dates and linkage to the signed authorizations held on file. The bank validates, releases and exchanges the debit batches; receivables post and reconcile. Then three exception flavours arrive across the month, each handled differently — which is the point. Several thousand debits return for insufficient funds around the first of the month: funds reasons, handled by the permitted retry discipline plus customer communication owned by the collections team. Several hundred return with closed or invalid accounts: account reasons, requiring updated banking details before any re-origination. A handful of customers dispute authorization, stating they cancelled when they moved: authorization reasons, requiring Prairie Ridge to produce the mandate evidence or accept the returns, with re-origination off the table until fresh consent is captured. Control lesson: for pulls, the authorization file is the product — and for the bank, triage by category with the right owner for each. The PAD chapters teach authorization and retry handling in depth.
Example (fictional): Beacon Marine Supply and the misdirected supplier run. Beacon is a fictional Nova Scotia marine supplier paying about eighty vendors by AFT credit each month. Its office manager builds the payment file — and this month the vendor master carries a stale account number for the largest vendor, changed by unverified email instruction. The bank's validation passes the file: the stale account is well-formed and reachable, totals balance, screening passes — because validation checks structure, not account ownership. The credit exchanges, clears, settles and posts to a stranger's account, and recovery now requires the cooperation mechanics of Section 8, because settled value cannot be unilaterally pulled back. Control lesson: the failure happened weeks before the file, in master-data governance — verify banking-detail changes to known contacts, and flag first-time account changes for callback before release. Read together, the three cases rehearse the chapter's core moves: validate before release, assign every item to its window honestly, preserve references end to end, state finality with return-rights awareness, triage by category with the right owner, and recover as linked new events.
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.
- AFT is the electronic batch stream family of ACSS: push credits and pull debits in files. Direct-deposit payroll, supplier and benefit credits push funds out; pre-authorized collections pull funds in on mandate authority. Same file mechanics and netting — different authorization, return and dispute consequences.
- The batch bargain governs AFT absolutely: efficiency and reach for deferred finality plus return exposure. Thousands of items collapse into one funding event per clearer.
- Exchange, clearing, settlement, posting, availability and finality are six different events. Use the words exactly — in customer scripts, incident tickets, procedures and audit responses. Most AFT confusion is vocabulary failure.
- The chain runs originator, originating institution, ACSS exchange and clearing, receiving institution, beneficiary — with settlement underneath. Customers instruct and authorize; banks validate, warrant, post and report; the operator calculates positions; the central bank settles. Agents stand in for sponsored institutions.
- Capacity determines what can be promised. Direct clearers exchange and settle through Bank of Canada accounts and can sponsor others; group clearers serve member groups; indirect clearers inherit their agent's timetable, reporting and incident speed. Check capacity before committing to timing.
- Rule F1 governs established AFT; Rule F4 governs ISO 20022 AFT; both sit under By-law No. 3. Read the current published versions with their standards and usage guidelines, and treat established-versus-ISO coexistence as a standing engineering condition with explicit mapping.
- Files, batches and item records balance at every level, and references survive end to end. Items sum to batches, batches sum to files; internal identifier, clearing trace, return linkage and customer remittance travel the whole journey. Master-data quality is a payments control.
- Timing is relative: file in advance of the due date, settle on a later business day, report per policy. Release before the applicable cutoff means this window; after means the next. Use the current F1/F4 deadlines and serviceability rules with the bank or agent schedule — and never promise same-day finality on batch timing.
- Settlement nets inside ACSS and funds through Lynx mechanics into central-bank money. Direct clearers extinguish previous-cycle nets via Lynx payments to settlement accounts at the Bank of Canada; indirect clearers settle through their agents. Lynx has been live since 2021. As of 5 October 2026, RTR is in testing with a Q4 2026 launch target, not live AFT routing.
- Controls prevent only before release. Authentication, validation, limits, fraud scoring, sanctions screening, cutoff assignment and dual approval run in that order, each decision logged; overrides are themselves controlled. Screening after release is recovery.
- 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, triage by funds, account, authorization or administrative cause with the right owner, and never mutate history.
- Implement deliberately, test unhappily, stay resilient, modernize honestly. Choose capacity on economics, contract agency explicitly, test unhappy paths, run parallel before cutover, rehearse contingency, and prepare hub architecture for ISO coexistence and the planned Q4 2026 launch — not live routing before production go-live.
Forward map: payroll through AFT, pre-authorized debits, return-and-reconciliation craft, and ISO 20022 coexistence each own their depth in dedicated chapters. Study them after this one. Do not write operational procedures from this chapter alone.
Authoritative references (official sources only)
This chapter uses only official sources. Re-check any time-sensitive page before customer or examination use. Rule F1/F4 exchange deadlines and serviceability requirements are stated functionally and must be read with the current rule text; bank and agent customer cutoffs can be earlier. File specifications, record layouts and code values are described functionally throughout; the binding text is the current published rulebook, standards and usage guidelines — including Rule F1, Rule F4 and their associated documents, found through the rules-and-documentation source below — not this chapter.
-
Payments Canada — Retail batch payment system page. Operator description of the retail batch system comprising ACSS and USBE, AFT credits (mainly direct deposits) and AFT debits (pre-authorized debits) as electronic streams, direct and indirect participation, entry of volumes and values into net balances, and settlement of previous-day balances on the following business day 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 ACSS rules, standards, by-laws and procedures — including By-law No. 3, Rule F1 for established AFT and Rule F4 for ISO 20022 AFT — 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 a live RTGS wire system and as the mechanism for inter-FI payments used to settle amounts owing from customer activity, with direct participants maintaining Bank of Canada settlement accounts. https://www.payments.ca/systems-services/payment-systems/high-value-payment-system-lynx
-
Bank of Canada — Payment systems the Bank of Canada oversees. Central-bank description of exchange, clearing, settlement, ACSS, direct/indirect participation, Lynx and RTR modernization. The page identifies RTR as a system being designed; current launch sequencing is in Payments Canada’s RTR testing page below. 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 payment systems. Central-bank description of settlement accounts for Lynx, ACSS and RTR, settlement finality in central-bank money, and eligibility/application requirements; page updated July 31, 2026. https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/
-
Payments Canada — Automated Clearing Settlement System statistics (January 20, 2026). Official 2025 ACSS category volumes and values, including separate AFT credit and debit totals. https://www.payments.ca/automated-clearing-settlement-system-acss-statistics
-
Payments Canada — Automatic funds transfer (ISO 20022). Official ISO AFT onboarding periods, testing, message families and usage-guideline resources. https://www.payments.ca/payment-resources/iso-20022/automatic-funds-transfer
-
Payments Canada — System closure schedule. Official business-day and statutory-holiday closure calendar. https://www.payments.ca/system-closure-schedule
-
Payments Canada — Testing and launch (Real-Time Rail). Current testing status and sequenced Q4 2026 launch target as of the audit date. https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/testing-and-launch
-
Payments Canada — Rule H1, Pre-Authorized Debits. Current PAD authorization, categories, return and recourse framework referenced by AFT debit processing. https://payments.ca/sites/default/files/h1eng.pdf
-
FINTRAC — Reporting electronic funds transfers; Record keeping requirements for financial entities. Current definitions and exclusions for direct deposits/PADs, reporting tests and retention/evidence obligations. https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng and https://fintrac-canafe.canada.ca/guidance-directives/recordkeeping-document/record/fin-eng
-
OSFI — Operational Risk Management and Resilience Guideline. Supervisory expectations for critical-operation tolerances, scenario testing, continuity, recovery and third-party resilience. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/operational-risk-management-resilience-guideline
Diagrams in this chapter: AFT end-to-end operating model; AFT file, batch and record hierarchy; push-credit versus pull-debit lanes; AFT timeline from file day to availability; bank processing modules for AFT — all under /diagrams/payment-stories/canada/chapter-16/. File and record detail is functional throughout; binding specifications live in current Standard 005, ISO AFT Usage Guidelines, Standard 007 and related rules. The diagrams show no clock times; the chapter text now states the current F1/F4 exchange deadlines and serviceability requirements. As of 5 October 2026, RTR is shown and referenced as in testing with a Q4 2026 launch target, not live AFT routing. Stories and companies are fictional.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.