Canadian Domestic Wire Lifecycle. Trace a domestic CAD wire from customer instruction through bank controls, Lynx settlement and beneficiary posting.
Block 8 · Chapter 37 of 75
This chapter traces one domestic Canadian-dollar wire from the moment a customer instructs it to the moment both sides can prove what happened. You follow the instruction through the sending bank's validation and control stack, through release to the Lynx gateway, through real-time gross settlement in central-bank money, through the receiving bank's checks and beneficiary posting, and into confirmation, reporting and reconciliation. It stays at lifecycle depth on purpose: the deep treatment of settlement mechanics and finality law lives in Chapter 38, liquidity and queue management in Chapter 39, and returns, investigations and reconciliation practice in Chapter 40. Here you learn the whole journey in order, so those chapters land on a frame you already own. Scope note: the main path is an inter-financial-institution customer wire that uses Lynx. An on-us wire between two customers of the same financial institution is not processed through Lynx and has institution-specific processing and evidence; do not label it a Lynx settlement. Payments Canada distinguishes on-us wires from Lynx wires.
A wire is the payment a customer chooses when certainty matters more than cost. A law firm moving trust funds for a Friday closing, a manufacturer paying for equipment that must ship today, a treasury team covering a settlement obligation — none of them wants the cheapest rail. They want a payment that settles today, finally, with evidence. For inter-financial-institution Canadian-dollar wires, Canada's high-value rail is Lynx, which launched on 1 September 2021 as the country's RTGS system for high-value and time-critical payments. Every stage in this chapter exists to protect that promise: that a properly instructed, funded wire released inside the applicable window is designed to settle individually and irrevocably through Lynx, subject to the system, participant and bank processing state, and to post to the right beneficiary with a traceable evidence chain.
What you will be able to do after this chapter
After working through this chapter, you should be able to:
- explain when a domestic CAD wire is the right rail — and when batch, Interac or another path serves the customer better;
- name every party to a domestic wire and state exactly where the sending bank's responsibility ends and the receiving bank's begins;
- trace a wire instruction from channel intake through validation, the pre-release control stack, release, Lynx settlement, beneficiary posting and confirmation without confusing those stages;
- describe how Lynx settles — gross, real time, in central-bank money across Bank of Canada settlement accounts — and why settled means final and irrevocable through the system;
- list the data a wire needs — institution, transit and account routing, beneficiary-agent identification, amount, value date, remittance and references — and explain the role of a UETR where the message flow generates one and the PCRN after a Lynx settlement;
- explain rules, business-day calendars, relative cutoff windows and service levels honestly, without inventing exact cutoff times or fees;
- place fraud, FINTRAC, sanctions and operational controls before release and explain why screening after settlement is recovery, not prevention;
- classify rejects, misdirected payments, return requests and investigations, and describe recovery that preserves the original transaction identity;
- explain posting, accounting, charges conventions, reporting and reconciliation from both banks' operations view;
- describe how a bank implements, tests and hardens its wire capability, and how to handle the three fictional business situations in Section 11;
- navigate to Chapters 38 to 40 for finality, liquidity and returns depth, and to the Lynx rules and official sources for anything binding.
For a roughly 60-minute core session, spend about 10 minutes on this introduction and Sections 1–2, 15 minutes on Sections 3–4 with the lifecycle and control diagrams, 10 minutes on Sections 5–6 with the data and charges material, 10 minutes on Sections 7–8 with the control plane, 10 minutes on the fictional stories 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
- Lynx clearing, RTGS settlement and finality
- Data, identifiers, messages and references
- Rules, cutoffs, service levels and customer impact
- Fraud, compliance and operational controls
- Exceptions, misdirected payments, investigations and recovery
- Posting, accounting, charges, reporting and reconciliation
- Bank implementation, testing and resilience
- Practical examples
- Key takeaways and authoritative references
1. Business context and customer need
Nobody wakes up wanting a wire. Customers want a closing that completes on Friday, equipment released from the supplier's yard today, a settlement obligation covered without a penalty, payroll taxes remitted before a deadline. The wire is simply the instrument they reach for when the cost of uncertainty exceeds the cost of the payment. Your first job as a banking professional is to hear the business event behind the instruction and confirm that a domestic wire is genuinely the right answer — because once a wire settles in Lynx, there is no unilateral unwind, and a customer who chose urgency by habit pays wholesale pricing for certainty they never needed.
Consider the three situations that recur through this chapter. A Toronto law firm holds home-purchase funds in trust and must move them to a vendor's lawyer for a Friday afternoon closing; if the money is short by even a dollar or arrives without the right reference, the closing adjourns and two moving trucks idle on the street. An Alberta manufacturer has a press line down and the replacement part ships only against same-day final funds; a batch payment that arrives Monday is a weekend of lost production. A prairie agribusiness closes on farmland and the seller's bank must show final credit before title transfers. Each case shares three demands: today, in full, provably. That is the wire's service bundle — same-day finality, irrevocability through the settlement system, and an evidence chain both sides can reconcile. Nothing else in the domestic toolkit sells exactly that bundle.
That bundle is expensive to produce, which is why the bank must qualify the need before quoting the rail. A wire consumes intraday liquidity, senior approvals, fraud and sanctions capacity, and operations attention at both banks. A supplier who would accept next-window batch value should not be paid by wire; a customer who needs rich remittance and same-day finality should not be talked into batch to save a fee and then rescued on Friday afternoon. The qualification conversation takes five minutes and prevents the two classic failures of wire practice: urgency bought for routine payments, and routine rails promised for urgent ones. Teach every customer-facing colleague to ask what date the beneficiary must have final funds, what reference the beneficiary must see, and what happens commercially if either is missed. Those three answers route the payment correctly more reliably than any product brochure.
The economics sharpen the point. Canada's high-value system concentrates value, not volume: for 2025, Payments Canada reported Lynx settling about 13.6 million payments worth about $93.3 trillion — a daily average value near $372 billion across a comparatively small item count, against batch volumes in the billions of items. Those figures are cited here from Payments Canada reporting to convey concentration, not for memorization. The practical reading is direct: each individual wire carries, on average, value large enough that one delayed or misdirected payment is a treasury event for the customer and an operational event for the bank. Wire operations cannot be staffed or controlled like batch operations with smaller tickets. Every wire deserves individual validation, individual approval, individual tracking and individual confirmation — because the system settles them individually too.
Timing shapes the business context as much as value. Lynx operates on business days — Monday to Friday excluding statutory holidays under the published system closure schedule — and each bank layers its own internal cutoffs, liquidity management and approval availability on top. A wire instructed at four in the afternoon is not the same product as the identical wire instructed at nine in the morning, even though the screen looks the same. The afternoon instruction faces thinner liquidity, tighter approval windows and a shorter repair runway before the business day ends. The banker who explains this at intake — "if we release by our internal window today it settles today; after that it is first in tomorrow's queue" — earns trust. The banker who accepts every instruction with "it will go today" manufactures the Friday-evening escalation. Relative windows, honestly communicated, are the entire customer-impact story of Section 6.
Information is the third leg of the bundle, and the most undervalued. A wire without usable remittance is final money the beneficiary cannot apply. The law firm's closing funds need the file number the receiving lawyer's trust ledger expects. The equipment payment needs the invoice and release code the supplier's yard checks before loading the truck. The farmland payment needs the agreement reference both lawyers match to title. Lynx carries ISO 20022 messaging capable of rich remittance, but capability is not delivery: the sending bank must capture the reference completely at intake, carry it through its hub without truncation, and the receiving bank must surface it on the credit advice and statement. When this chapter insists on data discipline in Section 5, it is protecting the commercial purpose of the payment, not indulging a formatting preference.
Finally, place the domestic wire inside the whole Canadian board from the ecosystem chapter. The same bank that sends wires also moves payroll and supplier batches through ACSS, person-to-person value through Interac, card authorizations at the till, US-dollar batch through USBE and cross-border value through correspondent and SWIFT paths. The wire is the urgent-final leg of that board, not the whole board. A treasurer with a Friday closing, a Thursday payroll file and a US supplier payment due Tuesday needs one bank that routes each event to its right rail and reports all three coherently. This chapter teaches the wire leg at lifecycle depth so you can play your position in that larger operating view — and so you can explain to any customer, auditor or colleague why this payment went by wire while the others did not.
The diagram above is your anchor for the chapter. Read it top to bottom for flow and note the hinge: everything above release is prevention, everything below settlement is consequence management. Sections 3 and 7 expand the top half, Sections 4 and 9 the bottom half, and Section 8 the bridge between them when something goes wrong.
2. Participants, responsibilities and system boundaries
A domestic wire looks like two customers and two banks. Operate it that way and you will misassign every investigation. The full cast has six layers — the customers, the two banks, the system operator and network provider, the settlement agent and overseer, and the supervisors — and each owns a defined slice with no gaps and no overlaps. The boundary that matters most in daily practice is the settlement handover: the sending bank owns everything up to and including release and funding, Lynx owns the final movement of value, and the receiving bank owns everything from settlement to the beneficiary's account. Memorize that sentence before you touch a wire queue.
Start with the customers. The originator — the law firm, the manufacturer, the agribusiness — instructs the payment, funds it, and bears the commercial consequence of its data. The beneficiary — the vendor's lawyer, the equipment supplier, the seller — is entitled to receive it and to recognize it by the agreed reference. Neither customer settles interbank value. Neither customer operates in Lynx. The originator's leverage ends at giving a complete, authorized instruction before the bank's window; the beneficiary's leverage begins at recognizing the credit and matching the reference. Every dispute that starts "but the customer said" must be walked back to what the instruction actually contained, because banks settle instructions, not intentions.
When it releases, it takes responsibility for the message under its customer agreement and the applicable Lynx participant framework; this is an operating-accountability statement, not a claim that Lynx independently validates the customer's account number. If the account number is wrong, the reference is truncated, or screening was skipped, the bank's contractual, control and investigation responsibilities must be assessed regardless of what happens downstream.
Verify means confirming the beneficiary account is open and entitled to receive wires, applying any name and account checks required by the bank's policy, and screening inbound credits through its own fraud and sanctions controls. Under current Lynx Rule 10, the receiving participant may rely on an account number, client number or BIC and has no general duty to detect a name/identifier inconsistency; any enhanced name check is a bank control, not a universal Lynx rule.
Behind the two banks sit the system parties. Payments Canada owns and operates Lynx: the rulebooks, the settlement engine, participant coordination, training and ongoing development. SWIFT provides the payment message network over which participants exchange Lynx instructions and monitors message processing. Lynx participants are Payments Canada members — domestic banks, some foreign bank branches and other financial institutions — that hold a settlement account at the Bank of Canada, can pledge collateral for Lynx purposes, meet the technical requirements and hold SWIFT membership; institutions that are not direct participants arrange wires through a direct participant. The Bank of Canada provides the settlement accounts in which gross settlement occurs, oversees Lynx as a systemically important payment system under the Payment Clearing and Settlement Act, and observes its risk-management standards for designated infrastructure. The Minister of Finance holds oversight powers over Payments Canada under the Canadian Payments Act. None of these parties validates an individual customer's instruction, posts to a customer account, or rescues a misdirected payment — those are bank responsibilities executed inside system rules.
FINTRAC, as Canada's financial intelligence unit and AML/ATF supervisor, requires reporting entities to meet prescribed reporting and record-keeping obligations. Do not describe every domestic Lynx wire as an EFT report: for financial entities, the current EFT guidance is principally about reportable international EFT initiation or final receipt at $10,000 or more, subject to the Regulations and exceptions; AML/ATF controls and records still apply as applicable. FINTRAC does not approve or block individual wires. The Bank of Canada's RPAA mandate supervises PSPs that are subject to the Act; it is not an approval channel for a bank's individual wire. The bank or PSP must define who authenticates, screens, holds funds and evidences each stage.
Indirect participation deserves explicit attention because it changes cutoffs without changing responsibilities. A customer of an institution that is not a direct Lynx participant still gets a full wire service — but the instruction passes through the direct participant that sponsors it, under that sponsor's cutoff, funding and processing discipline. The customer's bank must translate its own promise into the sponsor's window and never offer timing the sponsor cannot deliver. When a Friday closing depends on a sponsored wire, the banker confirms the sponsor's window first and quotes the customer second.
The diagram above compresses the section into a working poster. The sending bank validates, screens, funds, releases and warrants. The receiving bank verifies, posts, applies charges per the agreed option and reports. Settlement is the shared handover — gross, final, irrevocable. Print it mentally on the wire desk wall: every investigation in Section 8 starts by locating the failure on one side of that handover.
3. Initiation, validation and bank processing
Every wire begins as a customer instruction entering a bank channel and converging on the bank's payment hub — the shared layer for intake, validation, decisioning, release, gateway formatting, tracking and reconciliation. Well-run banks operate one hub with a wire adapter rather than letting each channel talk directly to Lynx, because the controls in this section must apply identically whether the instruction arrived at a branch counter, a business portal, a host-to-host file, an API from the customer's ERP, or a recorded phone instruction from an authorized signer. The channel owns the conversation; the hub owns the decision. Confuse the two and controls fragment.
The originator supplies the debit account, the sender's full legal name and address, the beneficiary's full legal name and address, the beneficiary bank's nine-digit CACPA routing code (institution plus transit) or equivalent current routing data, the beneficiary account number, the amount, the requested value date, the remittance the beneficiary must see, the charge option where one is offered, and any callback contact for verification. A bank may collect additional fields.
Routing validation confirms the institution number, transit and account structure against current Payments Canada routing references such as the Financial Institutions Branch Directory/Financial Institutions File, and confirms the beneficiary bank's reachability for Lynx — directly or through its sponsor. The nine-digit CACPA code must be paired with the properly formatted creditor account number; the 2026 CACPA best-practice document is guidance, not a source of legal rights or obligations.
The control stack then gates release. The sequence below is a bank-specific control design, not a universal Lynx rule or a claim that every institution uses the same six layers in the same order; the governing institution's policy, customer agreement and applicable law control.
The hub's release record is the starting point of every inquiry, every status report and every investigation: release time, gateway reference, amount, parties, charge option and the window it was assigned to. Where the current published Lynx ISO 20022 catalogue applies, the bank uses the relevant MX message (for example, pacs.008 for an FI-to-FI customer credit transfer); message selection is not inferred solely from a customer-facing product label.
Two design principles decide whether this processing survives contact with reality. First, fail visibly and early: a hub that rejects with a reason, a repair path and a next-window promise creates one phone call, while a hub that accepts everything and fails downstream creates a week of investigations. Second, route by policy with reasoned override: the hub defaults each instruction to its right rail by urgency, value, data and finality need, and any override — batch to wire, wire to batch — is itself dual-approved, reason-coded and visible in reporting. The Friday-closing wire that arrives after the internal window is not "squeezed in"; it is honestly queued for first settlement next business day with the customer told so in writing, or it is escalated through the documented override path with eyes open. That discipline is what makes the lifecycle in Section 1 trustworthy.
4. Lynx clearing, RTGS settlement and finality
Settlement is the system's promise, and Lynx keeps it in the strongest form Canadian payments offer: each payment settled individually, in real time, in central-bank money, finally and irrevocably. There is no netting, no batch window, no deferred position. A released wire enters the RTGS queue where priority and available intraday liquidity govern when during the business day it settles; when it settles, value moves gross across settlement accounts at the Bank of Canada and the payment is final through the system. Everything in this section follows from that single mechanism — and everything in Chapters 38 to 40 deepens it. This chapter gives you the lifecycle view; Chapter 38 gives you finality law and the point-of-finality detail, Chapter 39 the liquidity, queue, priority and throughput mechanics, and Chapter 40 the returns and reconciliation practice.
Walk the settlement event slowly, because bankers who blur it mislead customers. Queueing is not settlement: a released wire waiting on liquidity or its turn has moved data, not value, and its status is honestly "queued" or "pending settlement," never "settled." Settlement is the gross debit and credit across Bank of Canada accounts — the sending participant's settlement position reduced, the receiving participant's increased, payment by payment. Finality attaches at settlement: from that moment the value movement cannot be unwound through the settlement mechanism, and no participant can unilaterally reverse it. Notification follows: the receiving participant learns that final funds are its to post. Posting, covered in Section 9, is then the receiving bank's act, not the system's. Four events — queue, settle, notify, post — in that order, and only the second is finality. Train every wire colleague to keep the four apart in customer language, because "it settled" stated of a merely queued payment is the costliest sentence in wire practice.
The RTGS design explains both the wire's power and its price. Because each payment settles gross, the sending participant must fund each payment with intraday liquidity — its settlement balance plus collateralized intraday credit within the Bank of Canada framework — rather than funding a single end-of-window net position as in batch. That funding requirement is why wires carry wholesale pricing and why afternoon wires face a different liquidity landscape than morning ones. It is also why queue management is an active treasury discipline rather than passive waiting: participants prioritize payments, monitor throughput expectations, and manage their queues through the business day so time-critical wires settle when customers need them. The customer never manages liquidity directly, but the customer pays for it and depends on it — which is why the sending bank's liquidity posture is part of the wire product even though it is invisible on the confirmation slip. Chapter 39 teaches this machinery fully; here remember the consequence: a funded, prioritized, in-window wire settles within the business day, while an unfunded or deprioritized one queues regardless of how loudly the customer needs it.
Practically, a misdirected or erroneous wire that has been made available to the unintended payee is handled through participant cooperation, the voluntary misdirected-payment guideline and any general-law remedy; it is not a card-style chargeback or unilateral system reversal. Do not overstate this as ‘no returns’: current Lynx Rule 10 requires or permits participant returns in specified cases, including certain errors detected before funds are made available, restrictions imposed by the receiving participant, law or court order, and payee requests. A participant return is a new pacs.004 payment message and is distinct from a customer-requested recall.
As of 5 October 2026, the Real-Time Rail is not yet in production. Payments Canada says RTR is scheduled to launch in Q4 2026 with sequenced participant onboarding and testing still governing readiness; its intended design is instant, data-rich exchange/clearing/settlement, including 24/7 operation, but that is planned capability until launch and participant go-live. RTR status and launch plan.
Close with the operating-day frame. Lynx is a business-day system — Monday to Friday excluding statutory holidays per the published closure schedule — and each business day has a defined processing cycle from opening through payment acceptance to end-of-cycle procedures. Instructions released after the applicable acceptance point, or on a closure day, belong to the next business day's processing; they are honestly queued or held, not "sent." The bank's internal cutoff sits inside the system day to leave room for approvals, liquidity arrangement, repair and gateway handling. Exact times vary by bank, participant and day and are never stated in this chapter; what matters is the structure — system day, bank window, customer promise — and the discipline that the customer promise is always the innermost of the three.
5. Data, identifiers, messages and references
Wires fail far more often from bad addressing and thin references than from system outages. The sending bank's data discipline — capture completely, validate early, preserve identity end to end — determines whether settlement, posting and reconciliation succeed or generate the exceptions of Section 8. This section maps what a domestic wire needs, how Lynx messages carry it, and which references must survive the whole journey.
Domestic routing starts with the Canadian account identifier triple: institution number, transit number and account number, governed by CACPA routing conventions and validated against current Payments Canada routing references. For straight-through processing, current Payments Canada best practice emphasizes a nine-digit CACPA code paired with the creditor account number, plus the creditor's full legal name and address.
Amount and currency are necessary but not sufficient; the wire also needs the requested value date, the charge option where offered, the purpose or regulatory detail the corridor requires, and above all the remittance the beneficiary must see — the file number, invoice reference, agreement number or release code that lets the beneficiary apply final funds on arrival. Originator and beneficiary identification should include the full legal name and address required by the applicable message, bank policy and current Payments Canada formatting guidance. Truncated or abbreviated party data can create screening and posting problems and can impair required records; the exact FINTRAC reporting fields and thresholds depend on the transaction and reporting entity.
Lynx's current published ISO 20022 catalogue lists the UG2026 core messages pacs.008 (FI-to-FI customer credit transfer), pacs.009 core/cov (financial institution credit transfer) and pacs.004 (payment return). The published UG2025 bank-to-customer reporting message is camt.053; corporate-to-bank guidance lists pain.001, pain.002 and camt.052/.053/.054 and is explicitly informational, not a binding rule. Do not present generic ISO camt.056/camt.029 investigation messages as Lynx-mandated without the participant's current procedure or specification. Lynx uses the SWIFT message network, and the Lynx-generated Payment Confirmation Reference Number identifies a payment obligation settled through Lynx. A UETR may be used for end-to-end tracking where the participant/message flow supports it, but it is not a substitute for the PCRN. The corporate-to-bank edge can use structured ISO 20022 input so the bank can map data without re-keying, subject to that bank's implementation.
References are what let humans and systems agree they are discussing the same payment. The bank's internal instruction identifier follows the payment from intake through release, settlement, posting and reconciliation. Gateway and Lynx references — including the PCRN generated for a settled Lynx payment — prove system events. A UETR should be retained where the participant/message flow generates one; it is not universal for every wire and is not a substitute for the PCRN. Return or investigation linkage ties any exception back to the original, while customer remittance ties the money to the commercial obligation — the closing file, invoice or agreement. Missing any available key can break a later process: without the internal identifier the bank cannot find its own decision record, without a supported UETR the relevant cross-bank inquiry may be slower, and without remittance the beneficiary may not apply funds that settled perfectly.
Two disciplines tie the section together. First, validate against the live reference, not memory: routing references update, sponsors change, beneficiary details drift, and the hub must check current data at instruction time rather than trusting the customer's saved template. Saved templates are a convenience and a fraud vector in equal measure, which is why beneficiary-change control sits in the stack of Section 3. Second, preserve rather than transform: the hub maps explicitly, logs truncation or enrichment, and never silently rewrites a reference the beneficiary needs. A wire that settles with the wrong file number is a settled error — final money, unappliable, recoverable only with cooperation. Data discipline before release is finality protection.
6. Rules, cutoffs, service levels and customer impact
Customers experience rules as promises: will it arrive today, when can it be used, what will it cost, what reference will appear, what happens if it fails. The bank experiences rules as windows, obligations and evidence. This section connects the two without inventing a single exact cutoff time or fee — because exact times vary by bank, participant, payment type and day, and exact fees follow each bank's published schedule. This chapter speaks only in relative structure: business-day windows, internal cutoffs inside system days, and the customer promise innermost of all. Any study note, job aid or customer script that quotes a specific hour or dollar figure from this chapter is misusing it.
Business days anchor everything. Lynx processes on business days — Monday to Friday excluding statutory holidays under the published system closure schedule — and the bank's wire day is built inside that frame with room for intake, approval, liquidity arrangement, repair and gateway handling. A Thursday instruction inside the bank's window belongs to Thursday's processing; the identical instruction after the window, or on a closure day, belongs honestly to the next business day. Holidays do not compress the week; they shift value dates, approval availability and repair runways. The hub must assign every instruction to a business-day window at intake, communicate that window in writing, and never let a channel promise what the calendar cannot deliver. The Friday-closing law firm needs to hear on Thursday morning what today's window requires — complete data, signed authority, funded account, reachable approver — not discover at four o'clock that the instruction missed its day.
Relative windows differ by purpose within the day. Morning intake offers the full repair runway and the deepest liquidity; midday carries the throughput bulk where queues are actively managed; afternoon demands complete data on arrival because the repair and approval runway shortens toward end-of-cycle procedures. The customer-impact translation is direct and must be stated plainly: an instruction received with missing beneficiary data in the morning is a repairable phone call, while the same gap in the afternoon is a next-day payment. Pricing interacts with timing honestly stated — urgency costs, in wholesale fees and in the operations attention each wire consumes — and customers accept that tradeoff when it is explicit. What they do not accept is paying for urgency and receiving next-day timing, or being promised same-day settlement on an instruction the bank has not yet validated. The channel may only offer what the hub confirms for this instruction, this amount, this window, today: one clock shared between promise and capability.
Service levels bundle timing with certainty, information and recourse, and the wire's bundle must be sold whole. Timing: Lynx wires are typically made available the same business day when submitted and processed within the relevant system and bank windows, but Payments Canada says operating hours, bank cutoffs, intermediary processing and incomplete information can add time; do not promise a guaranteed same-day result before the bank confirms state.
For this chapter's operational vocabulary (not a universal Lynx status taxonomy), customer language must keep the five status words apart:
Payments Canada's deduction-of-charges document is a voluntary guideline, not a fee schedule or a source of new legal obligations; it encourages members, upon request, to credit the Lynx recipient with the full amount sent and handle receiving service charges separately. The misdirected-payment document is likewise a common-understanding guideline and says it does not create legal rights or obligations. This chapter describes both only functionally.
The operational rule is simple: agree the option at instruction, show it on the confirmation, carry it in the message data, and never promise a net credit the receiving bank's posting cannot evidence. Short payments destroy closings — a closing funded a dollar light does not close — so trust-account and settlement wires deserve explicit amount-to-be-credited confirmation with the beneficiary's bank where the transaction supports it. Fee disputes after settlement are consent-based conversations; fee clarity before release is prevention.
7. Fraud, compliance and operational controls
Controls fail most often not by absence but by placement. A sanctions check that runs after settlement, a fraud hold that triggers after the gateway acknowledgement, a callback performed against contact details printed on the fraudulent instruction, a FINTRAC report built from truncated party data — each is a control that exists and still loses. This section places each control family where it can still change the outcome: before release. It expands the stack introduced in Section 3 into its fraud, compliance and operational depth, at lifecycle level; the full rail-level control detail lives in Block 13 and the procedure depth in Chapters 38 to 40.
Fraud controls span initiation, transaction risk and post-event response. Account-takeover and social engineering attack initiation: authenticate strongly, verify device and behavioural signals, and challenge anomalous payees before release rather than after. Push-payment scams attack instruction truth: the instruction is properly authorized but factually corrupt — a supplier's "new account details" from a spoofed email, a lawyer's "updated trust instructions" from a lookalike domain — and the defense is beneficiary-change control with callbacks to independently sourced contacts plus dual approval that actually inspects the data. Mule activity attacks the receiving side: score inbound credits as well as outbound wires, because a newly opened account receiving a large wire and immediately dispersing it is the visible half of someone else's fraud. Velocity, round-figure, first-time-payee and off-pattern signals must feed one case queue so a customer hit across two rails is seen once. After settlement, fraud response becomes the consent-based recovery of Section 8 — which is why the pre-release minutes are the cheapest fraud investment the bank makes.
Sanctions and watchlist screening gates release with three dispositions and no fourth option. Pass releases. False positive releases with documented reason and second eyes, because an over-blocking hub that holds every closing for manual review will be bypassed by shouting relationship managers — and bypassed controls are absent controls. True hit holds with escalation, freezing the instruction inside the bank before any system sees it. Screen parties, remittance text and routing against current lists at instruction time, and re-screen if the instruction ages or its data changes before release. Log what was checked, when, against which list version, by whom, with what disposition. Domestic wires need this as much as cross-border ones: a settled domestic wire cannot be unilaterally unwound, so a missed domestic hit is a settled violation, not a held instruction.
FINTRAC and record-keeping obligations attach to prescribed events without becoming payment approvals. Capture complete originator and beneficiary data at intake, preserve the instruction-to-settlement linkage through every reference in Section 5, and feed reporting from untruncated data so prescribed electronic-funds-transfer reporting where applicable reflects the real payment. For a financial entity, current FINTRAC guidance generally concerns international EFT initiation or final receipt at $10,000 or more, with regulatory exceptions and aggregation rules; the bank must determine the actual reporting treatment rather than assume every domestic CAD wire is reportable.
Operational controls also cover exceptions to the order: manual releases, verbal instructions and after-cutoff overrides must be controlled, dual-approved, reason-coded and time-bound, because an uncontrolled override can bypass the sequence and must be treated as a measurable operational risk.
The control that ties the plane together is release discipline: no instruction reaches the Lynx gateway without passing authentication, validation, limits, fraud, sanctions, callback and approval in that order, with each decision logged. Resilience controls — backup connectivity to the gateway, contingency procedures for participant or network outages, failover staffing for key roles, communication trees for queued-wire customers — belong in the same plane and are detailed in Section 10. Measure the plane the way an auditor would: pre-release reject and repair rates, screening disposition quality, callback completion on changed payees, override frequency and approval, and time from instruction to release by window. A wire control plane that cannot report those five numbers is a set of intentions, not a set of controls.
8. Exceptions, misdirected payments, investigations and recovery
Every wire 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 on assumption, manually crediting before settlement evidence, editing a queued payment — create duplicates, double credits and audit breaks that dwarf the original error. This section teaches the classification and the recovery discipline at lifecycle depth; the full returns and investigation procedure lives in Chapter 40.
A customer return request or recall after settlement is a request, not a card-style chargeback. If funds have been made available to an unintended payee, recovery normally depends on receiving-participant cooperation, the applicable guideline and any general-law remedy. Separately, Lynx Rule 10 provides defined participant return paths for specified exceptions and requires pacs.004 for a participant return. An investigation tracks an uncertain outcome — a wire acknowledged but without settlement confirmation, a beneficiary claiming non-receipt of a settled wire, or a queued payment during an outage — through the participant's current status/inquiry procedure, PCRN and other references, UETR where supported, and receiving-bank confirmation; do not assume a generic camt.056/camt.029 flow is a Lynx rule.
A customer may ask for cancellation before settlement, but whether a queued payment can be stopped is governed by the bank's agreement and the current participant/gateway procedure; it is a narrow, state-dependent possibility, not a general customer right.
Investigations walk one path with five stations: confirm release and references, confirm gateway acceptance, confirm settlement evidence with the confirmation reference, confirm posting or non-posting with the receiving bank, then communicate state. For a beneficiary-claims-non-receipt case on a settled wire, the walk usually ends at posting evidence — the credit advice, the statement line, the remittance the beneficiary failed to match — which resolves more cases than any interbank message. For a genuinely misdirected settlement, the walk moves to the guideline handling with urgency proportional to the funds' mobility: funds sitting in a valid but wrong account are recoverable with cooperation, while funds already dispersed through mule networks become a fraud case with law-enforcement dimensions. For uncertain states during outages, the iron rule is never duplicate blindly: confirm original state first through gateway and system inquiry, because a re-sent wire that duplicates a merely unconfirmed original creates two final payments and halves the chance of recovering either. Timeouts become duplicates only when impatience replaces procedure.
Recovery follows four rules that should be posted on the investigations wall. Never edit settled value — originate a linked corrective payment with its own approvals and controls, because the correction is itself a wire. Never re-send on assumption — confirm the original's state at each of the five stations first. Choose the recovery rail by current urgency, not by original rail: a small residual shortfall after a closing may travel better as a second wire the same day or as batch value the next window depending on what the beneficiary actually needs now. Communicate state plus next value date, not activity: "settled, posted short by the disclosed charge, corrective wire released for today's window" closes a case, while "we are working with the other bank" reopens it hourly. And preserve the original identifier through every recovery event so reconciliation, reporting and audit see one story.
Contain the commercial damage while the machinery runs. For time-critical wires — the closing, the equipment release, the settlement cover — the customer needs a funded plan B discussed at the first sign of trouble, not after the window closes: an alternate funding arrangement, a partial release against undertaking where the transaction supports it, or an honest next-window commitment. For fraud-suspected misdirections, contain first: notify the receiving bank immediately, request beneficiary-account restraint where lawful and available, engage the fraud team and, where appropriate, law enforcement — then pursue recovery. Speed of notification is the dominant variable in fund mobility; an hour's delay in contacting the receiving bank routinely matters more than any later procedural perfection. Log every step against the original identifier, because the investigation record is the reconciliation evidence and the regulatory evidence alike.
9. Posting, accounting, charges, reporting and reconciliation
Posting is where the system's promise becomes the customer's money, and it belongs entirely to the receiving bank. Settlement moved value finally between participants; posting credits the beneficiary's account. The two events are separated by the receiving bank's verification, its charge application, and its reporting — and the quality of that short interval decides whether a perfectly settled wire is a satisfied beneficiary or a Section 8 case. This section walks the receiving side, both sides' accounting, the charges conventions, customer reporting and the reconciliation that proves the whole lifecycle. Liquidity depth lives in Chapter 39 and returns depth in Chapter 40; this section gives you the post-settlement lifecycle those chapters deepen.
Receiving-bank processing runs verify, screen, apply, post, report. Verify confirms the beneficiary account is open, entitled to receive wires, and matches the instruction's account and name data per the bank's policy — including its treatment of name-versus-account discrepancies, which must be defined before the first exception, not invented during it. Screen runs the inbound credit through the bank's fraud and sanctions controls, because mule networks and sanctioned parties receive as well as send. Apply handles the charge convention for the payment: under sender-borne treatment the beneficiary is credited the full instructed amount with the sender's charges handled at the sending side, while under shared treatment the bank applies its own disclosed charges per the agreed option and the binding documentation — crediting, in every case, exactly what the option and the message data support, with any deduction disclosed on the advice. Post credits the account with the value date the rules support and makes the funds available per the bank's funds-availability practice. Report surfaces the credit on the advice and statement with the full remittance — file number, invoice, agreement reference — because applied funds are the product the beneficiary bought.
The sending bank debits the originator's account for principal plus its charges and records a decrease in its Lynx settlement position when the payment settles; it recognizes fee income per its schedule. The receiving bank records an increase in its Lynx settlement position and credits the beneficiary account per the charge option, recognizing any disclosed charges. The direction matters: the participant that sends value is debited at settlement and the participant that receives value is credited.
Customer reporting must keep the five status words apart all the way to the statement. The originator receives release acknowledgement, settlement confirmation carrying the PCRN/confirmation reference for a settled Lynx payment and a UETR where the participant flow generates one, and the debit advice with principal, charges and remittance shown separately. The beneficiary receives the credit advice with amount credited, any disclosed deduction, value date, full remittance and the references needed to match the originator's ERP — plus statement lines that preserve those references rather than truncating them into unmatchable text. Corporate-to-bank reporting in camt.052, camt.053 and camt.054 formats feeds the customer's reconciliation engines; intra-day camt for treasury visibility, end-of-day statements for ledger posting, debit-credit notifications for exception workflows. A beneficiary that cannot match a settled wire to its receivables is a customer with final funds and an open invoice — technically complete, commercially failed.
Reconciliation proves the story end to end at three levels that must all agree. Internal reconciliation matches each instruction identifier across intake, approval, release, gateway acknowledgement, settlement confirmation, customer debit, fee posting and reporting — any identifier present at one station and missing at another is a break to investigate that day. Interbank reconciliation matches the bank's sent and received wires against settlement account movements and against the receiving or sending bank's confirmations, with the UETR and confirmation references as the cross-bank keys. Customer reconciliation matches the bank's advices and camt statements against the originator's payables and the beneficiary's receivables, where the remittance discipline of Section 5 pays off or its absence bills. Breaks age visibly with ownership: unmatched gateway acknowledgements, settlement confirmations without customer debits, customer debits without settlement evidence, settled wires without posting confirmation, postings without remittance. No break idles without an owner and a next action, because an idle wire break is next week's loss.
Liquidity awareness threads through all of this without becoming a treasury chapter — that is Chapter 39's job. The operations view needs only three facts: each wire consumes sending-participant intraday liquidity at settlement, queued wires reflect funding and priority reality rather than system failure, and end-of-day funding, collateral and throughput expectations must be managed so tomorrow's queue starts clean. The reconciliation desk and the liquidity desk share one queue view: operations sees customer impact and repair actions, treasury sees funding and prioritization, and both see the same wires. When afternoon queues build, the two desks decide together which wires the available liquidity settles first — with time-critical customer commitments, not ticket order, setting priority.
10. Bank implementation, testing and resilience
A wire capability is not a gateway connection. It is the hub, the controls, the references, the liquidity access, the people and the procedures operating as one system — implemented deliberately, tested adversarially and hardened for the days when something fails. This section describes how a bank builds, proves and sustains that capability at lifecycle level; message and settlement-mechanics depth belongs to Chapters 38 and 39.
Implementation starts with the hub adapter and its reference data. The bank wires one intake model that normalizes every channel into the instruction record of Section 3, one validation engine fed by current routing references including the Financial Institutions File, one control stack in the fixed order of Section 7, one gateway formatter producing schema-valid Lynx messages with UETR and full remittance, and one tracking store keyed on the internal identifier with every external reference bound at its station. Reference data is a production system, not a spreadsheet: routing tables, sponsor mappings, participant reachability, list versions for screening, fee schedules for the charge options, and calendar data for business days and windows — each with ownership, update cadence and fallback behavior when an update fails. Saved beneficiary templates get lifecycle management: creation with verification, change with callback and dual approval, expiry review, and freezing on anomaly signals. Most wire incidents trace to stale or corrupted reference data rather than to system defects, so this unglamorous layer deserves senior ownership.
People and entitlements are implemented alongside the software. Wire roles — initiator, approver, releaser, investigator, reconciler, liquidity manager — are defined with least privilege and segregation so no one person spans instruction to settlement. Approval authority matrices set who may approve what amount in which window, with escalation paths for time-critical overrides that preserve dual control under pressure. Training is scenario-based, not slide-based: each wire colleague works the Friday-closing repair, the afternoon queued wire, the beneficiary-claims-non-receipt inquiry and the suspected-misdirection notification until the vocabulary, the five stations and the four recovery rules are reflex. New staff shadow live queues before touching them; returning staff re-certify after long absences. The Friday-afternoon wire desk staffed by its least experienced people with no escalation path is an implementation choice, and it is the wrong one.
Functional testing walks every lifecycle path: clean settlement, pre-release reject, gateway reject, queued-then-settled, beneficiary posting with each charge option, misdirected-payment notification flows, participant return via pacs.004 where applicable, bank investigation procedures and all five status words to the customer.
Resilience is tested operations, not standby hardware. The bank maintains backup connectivity to its gateway paths, documented contingency procedures for participant or network outages consistent with the Lynx emergency and contingency expectations, and a communication plan that tells queued-wire customers their state plus next value date rather than silence. Queue ownership during incidents is pre-assigned: who watches gateway acknowledgements, who talks to the direct participant or sponsor, who prioritizes with treasury, who calls the closing lawyer with the honest status. Recovery-time and recovery-point expectations are set for the wire service specifically, because a generic IT recovery plan that restores batch files by morning does not cover afternoon wire queues. Post-incident reviews feed the control plane: every outage, near-miss and override is examined for what the hub, the references, the staffing or the procedure must change, with actions tracked to closure. A wire capability that does not learn from its incidents is rehearsing its next loss.
Change management closes the loop. Every hub change, message-version adoption, reference-data migration, fee-schedule update, sponsor change and staffing-model change passes impact assessment, testing, approval and monitored deployment with rollback criteria — including customer communication where timing, references or charges change. ISO 20022 migration work follows the same path: richer data is an opportunity that becomes truncation risk without explicit mapping, validation and logging, as Section 5 warns. The measure of implementation maturity is boring and quantitative: straight-through rates without repair, pre-release reject rates with reasons, status-word accuracy in customer communication, break ageing in reconciliation, and incident counts with repeat causes. Report those monthly to the owners who can fund fixes, because wire quality is bought with attention long before it is bought with technology.
11. Practical examples
Theory earns its keep in concrete situations. The three stories below are fictional — invented law firms, manufacturers, amounts and timelines — but each follows the lifecycle, controls and recovery discipline of the preceding sections exactly. Read each for the decision that mattered, not the dollar figure.
Example (fictional): the law-firm trust transfer that had to close Friday
Harbourline Law, a fictional Toronto firm, holds $486,250 in trust for a home purchase closing Friday afternoon. The vendor's lawyer, at a different bank, must show final credit with the firm's file reference "HL-2026-08417" before the closing proceeds. On Thursday morning the Harbourline clerk builds the wire in the business portal: debit the trust account, beneficiary the vendor firm's trust account with institution, transit and account numbers from the direction letter, amount to the dollar, remittance carrying the file number, charge treatment confirmed as sender-borne so the receiving side expects the full amount.
Validation catches the first problem: the direction letter shows a transit number that fails the current routing reference. The hub rejects with reason and repair path rather than releasing to see what happens. The clerk calls the vendor firm on a known number from the firm's matter file — not the number on the letter — and learns the letter reprinted an old transit after a branch consolidation; the corrected transit validates. Dual approval follows with the handling lawyer inspecting amount, beneficiary and file reference against the direction letter. Fraud scoring is quiet, sanctions screening passes, and the callback to the vendor firm on the known number confirms the account change. Release occurs Thursday midday, inside the window; the gateway acknowledges, the wire settles gross in Lynx with finality, and the confirmation reference returns to the hub.
Friday morning the vendor's lawyer claims non-receipt. Harbourline's bank walks the five stations: released Thursday with references, gateway accepted, settlement confirmed with the confirmation reference and UETR, and — on inquiry — the receiving bank confirms posting Thursday afternoon with the full remittance. The walk ends at posting evidence: the vendor firm's junior clerk searched its trust ledger for the purchaser's surname instead of the file number. The credit advice carried "HL-2026-08417" exactly; matched on the file number, the funds were there all along. The closing proceeds at two o'clock. The lesson the bank debriefs: pre-release repair of the transit cost one phone call, while post-settlement repair would have needed a consent-based new payment and no Friday closing; and remittance discipline at intake is what made Friday's ten-minute resolution possible.
Example (fictional): the equipment payment that unblocked a production line
Prairie Ridge Manufacturing, a fictional Alberta food processor, has a press line down Thursday morning. The replacement part, $78,400, ships from the supplier's yard only against same-day final funds with the release code "PRM-REL-5519" on the payment. The plant manager wants it paid now; the controller wants the supplier's emailed "updated banking details" used because they arrived an hour ago. The bank's hub enforces the order that saves them both.
The instruction enters by portal with the emailed account details. Validation flags a first-time payee with changed account data — the supplier has been paid monthly for three years to a different account. The control stack holds: fraud scoring elevates on the first-time change, beneficiary-change control demands a callback, and the callback goes to the supplier's known accounts-receivable number from the master file, not the email. The supplier's AR clerk has never heard of new details; the email was spoofed from a lookalike domain. The controller authorizes the wire to the verified account on file with the release code in remittance, dual approval inspects it, screening passes, and the wire releases inside the morning window with the full repair runway intact. Settlement follows, final and irrevocable, and the credit advice carries the release code the yard checks. The part loads Thursday afternoon.
The debrief writes itself. Had the emailed details been used, the wire would have settled finally to a mule account and recovery would have depended on the consent-based handling of Section 8 — with the production line idle through the negotiation. The bank's discipline — change control with independently sourced callback, genuine dual approval, no override by shouting — prevented a settled fraud rather than funding one. The controller converts the supplier relationship to verified-template management with change freezes, and the bank records the attempt in its fraud intelligence so the next spoofed email against any customer scores higher.
Example (fictional): the farmland closing funded a dollar light
A fictional Saskatchewan agribusiness closes on farmland Friday: $1,240,000 to the seller's bank, with both lawyers expecting the full figure credited. The originator instructs the wire Thursday with shared charges treatment, each side bearing its own bank's charges, without confirming what the receiving bank will deduct or what net credit the seller's lawyer must see. The wire validates cleanly — known payee, verified template, funded account — passes screening, releases, settles finally, and posts. Friday morning the seller's lawyer reports $1,240,000 expected but a net credit below it after the receiving bank applied its disclosed charge; the shortfall is small and the lawyers bridge it with an undertaking, but the closing starts with a dispute instead of a signature.
Nothing failed technically and everything failed commercially. The investigation walk confirms each station green: correct account, settled finally, posted per the agreed option with the deduction disclosed on the advice. The failure was fee clarity at instruction — the originator was never told the net-credit consequence of the option it chose, and nobody confirmed the amount-to-be-credited with the beneficiary's bank. The bank's fix is procedural, not technical: trust-account and settlement wires default to sender-borne treatment with explicit net-credit confirmation where the transaction supports it, the portal shows the expected net credit before the approver signs, and confirmations state the charge option in plain words. The lesson generalizes to every wire with a contractual amount: agree the option at instruction, show it on the confirmation, carry it in the message, and never promise a net credit posting cannot evidence. Chapters 38 and 39 deepen the settlement mechanics behind this story; the lifecycle lesson is that charges agreed vaguely at intake become disputes finally settled on Friday morning.
12. Key takeaways and authoritative references
Carry twelve sentences from this chapter onto the wire desk, and you will handle most days correctly.
- An inter-FI domestic CAD Lynx wire is the certainty product: typically same-business-day availability when processed in the applicable windows, final and irrevocable through Lynx once settled, with evidence — chosen when the commercial event needs exactly that bundle.
- The sending bank owns instruction through release and funding; Lynx owns final settlement; the receiving bank owns verification, posting and reporting — no gaps, no overlaps.
- Every control that matters runs before release in fixed order: authentication, validation, limits, fraud, sanctions, callback, approval, window assignment.
- Lynx settles each payment obligation individually in real time in central-bank money; settlement is final and irrevocable through Lynx between participants. Post-settlement recovery is not a unilateral rewind: use defined Rule 10 returns where applicable, or a linked corrective/recovery process under the facts.
- Data discipline is finality protection: complete routing, beneficiary-agent identification, full remittance, and five references that survive the whole journey.
- Promise in relative windows from the published business-day calendar; never invent exact cutoff times or fees — the customer promise sits innermost of system day, bank window and hub confirmation.
- Fraud defense centers on beneficiary-change control with independently sourced callbacks and genuine dual approval; screening after settlement is recovery, not prevention.
- Classify before acting — reject, misdirected payment, return request, investigation, reversal — because each authorizes different action and Lynx offers no unilateral unwind.
- Posting quality decides whether perfect settlement satisfies the beneficiary: verify, screen inbound, apply the agreed charge option, post with value date, report with full remittance.
- Reconcile at three levels — internal, interbank, customer — with ownership and ageing on every break; suspense that ages overnight is an investigation.
- Implement one hub with current reference data, segregated roles, scenario-trained people, adversarial testing and rehearsed resilience — and measure it monthly.
- For depth, go forward: Chapter 38 for settlement mechanics and finality, Chapter 39 for liquidity and queues, Chapter 40 for returns, investigations and reconciliation practice — and to the official sources below for anything binding.
Authoritative references
Only official sources are cited. Rule-level detail, current calendars and binding treatments live in these publications, not in this chapter.
- Payments Canada — High-value payment system - Lynx (system facts, participants, SWIFT, 2025 statistics). Available at: https://www.payments.ca/systems-services/payment-systems/high-value-payment-system-lynx
- Payments Canada — Lynx statistics (2025 volume/value basis). Available at: https://www.payments.ca/high-value-payment-system-lynx-statistics
- Payments Canada — Lynx Rule 10: Finality and Return (2026; participant return exceptions and pacs.004 return message). Available at: https://payments.ca/sites/default/files/rule_10_finality_and_return.pdf
- Payments Canada — Lynx ISO 20022 message specifications (UG2026 core messages and UG2025 reporting/corporate-to-bank guidance). Available at: https://www.payments.ca/payment-resources/iso-20022/high-value-payment-system-lynx
- Payments Canada — Lynx wire payments and the Payment Confirmation Reference Number (PCRN, operating hours and on-us/non-participant caveats). Available at: https://www.payments.ca/explainer-lynx-wire-payments-and-payment-confirmation-reference-number
- Payments Canada — Business wire payments guide (required data, OUR/BEN/SHA charge fields, customer cutoffs and on-us distinction). Available at: https://www.payments.ca/payment-resources/support-guides/business-guides/wire-payments
- Payments Canada — New best practices resource for Canadian wire transfers (2026 CACPA formatting guidance; informational only). Available at: https://www.payments.ca/new-best-practices-resource-canadian-wire-transfers
- Payments Canada — Rules and documentation (current Lynx rules, procedures, standards and guidelines). Available at: https://www.payments.ca/systems-services/rules-documentation
- Payments Canada — Guideline: Misdirected Lynx Payments (implemented 2022; common understanding, not legal rights). Available at: https://payments.ca/sites/default/files/Guideline_Misdirected_Lynx_payments.pdf
- Payments Canada — Guideline for the Deduction of Charges for the Receipt of Lynx Payments (voluntary, implemented 2022; amended 2023). Available at: https://payments.ca/sites/default/files/Guideline_Deduction_of_charges_for_the_receipt_of_Lynx_payments.pdf
- Bank of Canada — Lynx designation as a systemically important payment system (legal finality protection and oversight). Available at: https://www.bankofcanada.ca/2021/09/bank-canada-designates-lynx-systemically-important-payment-system/
- Bank of Canada — Settlement account policies for Payments Canada payment systems (central-bank money and direct-participant accounts; RTR planned). Available at: https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/
- FINTRAC — Reporting electronic funds transfers (current thresholds, international EFT scope and records). Available at: https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng
- Bank of Canada — Retail payments supervision (RPAA PSP scope and responsibilities). Available at: https://www.bankofcanada.ca/regulatory-oversight/retail-payments/
- Payments Canada — Real-Time Rail payment system and Testing and launch (Q4 2026 planned launch; not production as of this audit). Available at: https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system and https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/testing-and-launch
- Interac — Interac e-Transfer Disclosure (low-value domestic service and PPS designation). Available at: https://www.interac.ca/en/interac-e-transfer-disclosure/
- OSFI — Operational Risk Management and Resilience Guideline E-21 (critical operations, disruption tolerances and scenario testing). Available at: https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/operational-risk-management-resilience-guideline
- Justice Canada — Canadian Payments Association By-law No. 9 — Lynx (current to 2026-09-21; legal definitions and participant obligations). Available at: https://laws-lois.justice.gc.ca/eng/regulations/SOR-2021-182/FullText.html
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.