AFT ISO 20022 and Legacy Format Coexistence. Compare ISO 20022-enabled AFT processing with legacy formats, mapping, validation and coexistence controls.
Block 9 · Chapter 45 of 75
Canada's Automated Funds Transfer system is operating with two supported data formats. On one side sits the established path that carries payroll credits, pre-authorized collections, supplier payments and government disbursements: compact fixed records under Rule F1, built around codes, control totals and tight reference fields. On the other side sits the ISO 20022 path governed by Rule F4: structured messages exchanged under published usage guidelines, with room for fuller party identification and richer remittance detail. Both paths clear through the same Automated Clearing Settlement System and settle into deferred net positions. The published rules do not specify a universal cutover date, so the practical operating model is dual-format intake, a disciplined translation and mapping layer inside the bank hub, format-eligible exchange, and controls that protect data quality in both directions.
This chapter compares ISO 20022-enabled AFT processing with legacy formats the way a bank practitioner needs it: what each side can and cannot carry, where mapping lives and who owns it, how validation differs without changing its purpose, where richness is lost when rich messages travel toward lean records, how status, exceptions and reconciliation behave across the boundary, and how an originator migrates without breaking payroll. It describes capabilities and control patterns functionally. It does not reproduce record layouts, message schemas, element tables or version numbers, because those live in the published standards and usage guidelines, they change under version control, and a training chapter that quoted them would be stale before it was useful. Wherever this chapter touches the rulebook, it points at it; nothing here replaces it. Rule F1 covers AFT transactions using the established file standard, while Rule F4 covers AFT transactions exchanged using ISO 20022 messages; the current rule set supports both paths.
A status note anchors everything that follows, stated once so later sections can build on it. ACSS is live: a batch deferred-net system in which participants exchange items, positions are netted, and direct clearers settle net obligations through Bank of Canada settlement accounts on the morning of the following business day (Payments Canada). Payments Canada's current RTR page says the Real-Time Rail is planned to launch in Q4 2026; it is not an available production route at this audit date, nothing in this chapter routes to it, and its planned ISO capability does not change any AFT decision a bank makes today (RTR system page). AFT modernization is therefore a within-batch story: the same clearing and settlement model, two data languages, and a translation discipline between them. Every time this chapter says "planned," that distinction is intentional, and customer conversations should preserve it.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain in plain language why legacy and ISO 20022 AFT coexist, what Rule F1 and Rule F4 each govern, and why coexistence is a multi-year operating condition rather than a cutover to wait out;
- compare the two paths functionally across data richness, validation, remittance capacity and status reporting without quoting layouts or schemas;
- describe the translation and mapping layer inside the bank hub — normalization, explicit mapping, destination-rail validation, logging — and state who owns each step;
- explain the coexistence operating model: dual-format intake, one canonical internal model, dual-format clearing, governed by a counterparty capability registry and rail-eligibility routing;
- explain why translation loses richness in one direction, what truncation means operationally, and which controls — hold, log, report, repair at source — contain it;
- describe how validation, screening, limits and approvals gate release on both paths, and why the bank always validates against the rail that will carry the item;
- classify rejects, returns, reversals and identification-update advices as they behave on each path, and describe recovery that preserves the original item's identity across the format boundary;
- explain posting, accounting, reporting and reconciliation in a dual-format shop, including how structured remittance changes the receivables conversation without changing settlement;
- advise an originator on migration: inventory, cleanse, dual-run, counterparty-by-counterparty cutover and optimization, with rollback readiness at every gate;
- work through fictional but realistic Canadian cases — an ERP payroll upgrade, a mixed supplier base, a biller moving collections — and extract the control lesson from each;
- navigate confidently to the authoritative sources: the rules and documentation library, the ISO 20022 resource pages, the AFT onboarding material and the system pages.
For a roughly 60-minute core session, spend about 10 minutes on Section 1 with the coexistence diagram, 15 minutes on Sections 2–4 with the mapping-layer diagram, 10 minutes on Sections 5–6 with the comparison and truncation diagrams, 10 minutes on Sections 7–9, 10 minutes on the fictional cases in Section 11 with the migration playbook, and 5 minutes on takeaways and references in Section 12.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and system boundaries
- Initiation, validation and bank processing
- Clearing or exchange, settlement and finality
- Data, identifiers, messages and references
- Rules, cutoffs, service levels and customer impact
- Fraud, compliance and operational controls
- Exceptions, investigations and recovery
- Posting, accounting, liquidity, reporting and reconciliation
- Bank implementation, testing and resilience
- Practical Canadian examples
- Key takeaways and authoritative references
1. Business context and customer need
Start with a payroll manager who has just been told that the company's new enterprise system can produce a richer payroll file than the old one — full employee identification, structured cost-centre detail, remittance references finance has wanted for years — and who asks the bank a reasonable question: if the data is better, why does anything need to change downstream, and why is the bank talking about counterparties, rails and truncation? The honest answer is that the payroll manager sees one relationship, employer to bank, while the bank sees a chain: employer to originating bank, originating bank through clearing to every receiving bank, each receiving bank to its beneficiary customers, and every link must be able to carry what the first link sent. Better data at the front is only better outcomes if every downstream link can receive it, and during coexistence some of them cannot. That gap — between what an upgraded originator can send and what a mixed receiving base can absorb — is the entire subject of this chapter, and the bank sits exactly in the middle of it, translating where translation is safe and holding the line where it is not.
The business need behind ISO 20022 AFT is not speed. AFT remains a batch instrument with deferred settlement regardless of data language, and no message format changes which morning value settles. The need is carrying capacity and precision: fuller identification of the parties, structured remittance the beneficiary can apply without manual work, clearer linkage between returns and originals, and status information that tells the originator what actually happened to each instruction. Legacy AFT carries these as compact codes and tight reference fields because it was designed when every record had to fit a fixed shape. That design served Canada well for decades. But compactness has a price measured in operations headcount: receivables teams keying remittance by hand, investigations matching returns to originals by description, screening teams clearing false positives caused by truncated names. ISO 20022 AFT buys its value back in those queues. A supplier payment that arrives with structured invoice references closes itself. A return that links mechanically to its original reconciles itself. None of this changes settlement timing by a minute; all of it changes the cost of everything around settlement.
Coexistence has three practical consequences the banker must internalize before any technical discussion. First, no originator upgrades in isolation. A business sending ISO-rich files still pays beneficiaries at banks with mixed capability and still depends on service bureaus whose upgrades follow their own timetables. The bank's job is to make the upgrade valuable anyway: route each item on the path its destination supports, preserve richness where the path allows, and contain the loss where it does not. Second, the most predictable structural loss is rich-to-lean. Moving from a lean legacy record into a structured message must not invent information, while moving from a rich message into a lean record may leave content without a valid target field. Every control in this chapter's middle sections exists because of that asymmetry. Third, coexistence multiplies the test surface without changing the ACSS settlement model. Clearing, netting and the morning settlement remain governed by the rules; what multiplies is intake validation, mapping logic, status vocabularies, exception matching and reconciliation rules. The operations budget for coexistence is mainly a data and control budget, not a new settlement-rail liquidity project.
Customers experience coexistence through recurring questions this chapter equips you to answer honestly. Will our upgraded payroll file reach employees at other banks unchanged? It will, because the bank maps each item onto the path its destination supports — but detail beyond the legacy path's capacity is held and reported, not forced through. Will supplier payments reconcile faster? They will where the receiving side consumes structured remittance, and progressively as counterparties upgrade, which is why the bank tracks counterparty capability instead of promising universal richness on day one. Does ISO change when funds arrive? It does not; windows, business days and the morning settlement are untouched by data language. What happens to data that does not fit? It is logged with a reason, reported to the originator, and repaired at source — never silently dropped, never invented. Those four answers, given consistently by every channel and adviser, are worth more than any diagram.
The diagram above is the chapter's anchor. Read it top to bottom for flow — two intake formats converging on one canonical internal model, then diverging onto two clearing paths — and read the governance strip at the bottom as the control that makes the picture safe: a registry of what each counterparty can receive, with routing driven by eligibility rather than optimism.
2. Participants, responsibilities and system boundaries
A dual-format AFT payment involves every party a single-format payment involves, plus one new responsibility spread across several of them: deciding, for each item, which format may carry it and what happens to data that does not fit. Keep the classic chain straight — originator and beneficiary, originating and receiving banks, direct and indirect clearers with their agents, Payments Canada as owner and operator, the Bank of Canada as settlement agent and overseer — and overlay the format question on each link without blurring who owns what. Confusing the overlay with the chain produces the characteristic coexistence errors: treating mapping as the operator's job, treating a bureau's upgrade as the bank's completion, or treating a counterparty's capability as the originator's problem to discover by trial and error.
Format pressure starts with customers. The originator creates the economic event and increasingly chooses the data language: the employer whose new system emits structured payroll, the biller upgrading its collections platform, the small business still sending the compact file it has sent for a decade. The originator owns the obligation, the instruction and the quality of the data it supplies in whichever format it uses. An upgraded file with inconsistent remittance is not an upgrade; it is a larger haystack, and the bank should say so during onboarding rather than discovering it in the receivables queues. The beneficiary owns the other half: its bank can only deliver what its systems consume, and its reconciliation benefit arrives only when its systems are ready for structured data. Between them sit payroll processors, service bureaus and software vendors whose timetables constrain whole originator portfolios at once. Each intermediary's responsibility should be written down before volume flows: which formats it produces, how it handles rejects and status reports, who repairs truncated data, who reconciles during dual-run. Every painful migration incident involves a handoff where both sides assumed the other owned a step.
Banks carry the translation burden, and participation capacity shapes what each bank can promise. The originating bank validates the file, screens it, maps it where needed, validates the result against the destination rail's requirement, releases it into clearing directly or through its agent, and warrants what it introduces. The receiving bank accepts, posts, reports and returns with reason where it cannot post. A direct clearer does this on its own footprint with its own settlement account and funding duty; an indirect clearer does it within its agent's timetable, formats and processes — so its format offering is bounded by its agency agreement, explicitly enough that front-line staff never improvise it. An indirect bank whose agent cannot yet receive ISO clearing items must not accept ISO origination on the promise that clearing will catch up; the file will be mapped down or held, the originator will have paid for richness it never received, and the dispute will be about expectations the bank set carelessly.
Payments Canada authors both rulebooks and publishes the usage guidelines and onboarding material: Rule F1 for legacy AFT, Rule F4 for ISO 20022 AFT, the guidelines defining structured-message use between member institutions, and the multi-phase onboarding path — information gathering, formal registration with long advance notice, testing for direct clearers, agent-coordinated implementation for indirect clearers, ongoing monitoring — that moves a participant from intention to live exchange. What the operator does not do is equally important: it does not translate any bank's files, does not route per-item between formats, does not hold unmappable data, and does not guarantee that a rich message sent by one bank arrives rich at a less-capable receiver. Translation is a bank-hub function; routing by capability is a bank function. The operator provides rails, rules and framework; the banks drive on them.
The Bank of Canada's two hats — settlement agent and overseer of the designated prominent system — are format-indifferent by design. Net positions entering the morning settlement are values and volumes; the data language describing the underlying items has already done its work upstream. Settlement neither rewards nor punishes format choice, which is why the ISO business case must be built on reconciliation, screening and investigation savings rather than funding or float. A treasurer expecting a liquidity benefit will be disappointed; a receivables manager expecting fewer unapplied items will not be, provided the migration is managed as Section 10 describes.
Responsibility is a chain with one new link. The originator supplies quality data in an agreed format. The originating bank normalizes, maps, validates to the destination rail, screens, releases and warrants. The clearing layer exchanges under whichever rule governs the item's format. The settlement agent moves value finally, indifferent to format. The receiving bank posts, reports and returns with reason. Agents stand in for sponsored institutions at the clearing steps, formats included. Every investigation in Section 8 walks this chain backwards with one added question — which format carried the item, and what did mapping do to it — which is why the hub's mapping log is as much a part of the evidence chain as the release record.
3. Initiation, validation and bank processing
Every AFT item in either format starts in the same place: a customer instruction entering a bank channel and passing through payment operations before any external system sees it. Coexistence adds a routing question inside that flow. The channel varies — portal upload, host-to-host file, service bureau batch, biller collection file — but the discipline converges: turn an instruction into a releasable, warranted clearing item in the format its destination supports, or reject it with a reason while rejection is cheap. Rejects inside the bank cost a phone call and a same-day fix. Rejects in clearing cost a business day. Bad data released costs an investigation, returns and compensation. The wrong format costs all of that plus a mapping failure.
Initiation captures the familiar five facts plus authority — who pays whom, how much, in what currency and from which account, by when, with what references, under what authority — with one addition: the format used and the richness actually supplied. A structured file with empty optional fields is a legacy item wearing ISO clothing, and the hub should recognize it rather than routing on the envelope alone. Normalization is the hub's first and most consequential act: whatever the channel delivered becomes one internal instruction record — the canonical model from the anchor diagram — with a durable identifier surviving every later stage, carrying the richest data the source actually provided. Without that anchor the bank cannot track, investigate or reconcile across formats; it can only guess, and dual-format guessing is how duplicates happen.
Validation runs in two passes that must never merge. The first validates the instruction as an instruction: the debit account exists, is open, is enabled for this type and will be funded; totals balance to controls; duplicates and anomalies against history are checked — a doubled payroll total means the same thing in both formats; value dates fall on processable business days; authorization linkage exists for pulls. The second validates the mapped item against the destination rail's requirement: schema and usage guidelines for ISO-bound items, fixed-record edits for legacy-bound items. This is where coexistence bites, because each destination rejects different things for different reasons, and a file valid in one language may be invalid, or valid-but-lossy, in the other. The binding rule is sequence: map first, then validate the mapped result against the rail that will carry it, never the rail it came from. Validating an ISO-bound item against legacy edits, or waving a mapped-down item through because its source was valid, are the two characteristic validation failures of dual-format shops. The destination rail is always the examiner.
Between validation and release sits the control stack in the usual order — authentication and entitlement, limits, fraud scoring, sanctions screening with pass, false-positive or true-hit dispositions, record-keeping capture, cutoff logic assigning today's window or the next — with format-aware notes at three points. Screening needs complete untruncated data, so it runs on the richest representation before mapping, and the log records what was checked, when, against which lists, with what disposition, on which representation. Cutoff logic must account for mapping workload: a large file needing per-item eligibility lookups and mapping decisions is a late file even if the clock says otherwise, and channels should say so. Release commits the item to its format path under the governing rule, directly or through the agent, with the release record carrying the format decision and mapping-log reference alongside window assignment and gateway acknowledgement. For an indirect clearer, the agent's format timetable decides the path, and the agency agreement should say so explicitly.
After release the bank tracks acceptances and rejections per path, watches returns on their cycles, manages repair queues, posts, statements and feeds reconciliation. Status reporting diverges in texture though not purpose: structured status reports can carry per-transaction detail with coded reasons, while legacy acknowledgements are leaner and push more work onto the bank's own reporting. The bank should therefore normalize status upward — one vocabulary to the originator regardless of path — rather than exposing two dialects. Amendments after release stay narrow on both paths: pre-settlement correction where permitted, never silent editing of a settled item, with the original identifier following every correction. Two principles decide whether this survives reality. Route by eligibility rather than habit: the destination's registered capability decides the path. And fail visibly and early: a bank that rejects with a reason, a repair path and a next-window promise creates one call; a bank that accepts everything and fails in clearing creates a week of investigations.
Read the four hub steps as a checklist for every dual-format design review: if any step is missing, shared with an ungoverned upstream party, or ordered differently, the design has a finding before a single file flows.
4. Clearing or exchange, settlement and finality
The key settlement boundary is that ACSS netting and settlement do not use remittance richness to calculate positions. Exchange delivers items between participants; clearing validates, sorts and positions them by stream and window; settlement releases net obligations between settlement accounts. Posting, availability and finality remain subject to the receiving institution's processing and the applicable rules. Thus, ISO 20022 does not by itself change the ACSS settlement model or create instant funds availability. It can change identification, remittance, investigation and reconciliation around the value, and those benefits must not be sold as speed.
ACSS defers settlement by design, and the deferral is the whole point of batch economics. Participants exchange items during daytime windows through direct or agency arrangements, in either format as eligibility allows. Each direct clearer enters the volumes and values for which it is owed funds, those entries combine with paper totals into net balances, and settlement of the previous day's nets occurs the next business morning, when owing clearers send settlement payments and debits and credits across Bank of Canada accounts extinguish the balances. Thousands of items collapse into one funding event per clearer. Format is invisible at this layer by construction: a net built from ISO items settles exactly like one built from legacy items, and a mixed position settles like either. Treasury forecasts nets rather than items, as Section 9 explains, and any liquidity conversation pricing format choice is confused about which layer it stands on.
Finality is positional and rule-governed on both paths equally. When morning settlement completes, interbank positions settle finally in central-bank money — yet return rights for underlying items survive for defined reasons and timeframes: insufficient funds, closed accounts, disputed collections, paper returns. A payroll credit can post while its position settles later; a collection debit can post while the payer retains return rights. The one format-adjacent nuance is evidentiary, not legal: structured linkage between return and original makes the reason clearer faster, shortening the operational tail of return rights without shortening the rights. Never translate "better paperwork" into "fewer rights" or "faster finality." Rights and clocks come from the rules, which govern returns, reversals and adjustments on both formats with their own per-path mechanics but identical settlement consequences.
Contrast the two systems most often confused with AFT modernization. Lynx settles payments individually in real time across Bank of Canada accounts with immediate finality — the answer when a customer needs same-day certainty at wholesale pricing, and no AFT format choice competes with it. Payments Canada's current RTR page describes the planned system as launching in Q4 2026; until it is live and the bank has enabled it, it is not an AFT route. The honest rail-choice conversation has three branches: batch for scale with deferred settlement, wire for same-day finality, and a planned instant rail that must not be sold, scheduled or tested against as though live. The channel may only offer what operations confirms for this instruction, this amount, this rail, this business day — in either format.
Deeper exchange mechanics and the settlement lifecycle belong to their dedicated coverage; this section supplied the vocabulary and the format-indifference guarantee.
5. Data, identifiers, messages and references
If clearing is the road network, data is the addressing — and coexistence is the period when two addressing systems share the roads. The discipline has not changed — capture completely, validate early, preserve identity end to end — but now runs in two languages with a translator in the middle, and the translator is where quality is won or lost. This section maps what each path carries, which references must survive regardless of path, how message families divide their labour functionally, and where truncation risk concentrates. It stays functional throughout: capabilities and control patterns, never layouts, schemas or version tables.
Domestic routing starts on both paths with the same foundation: the Canadian account identifier triple of institution, transit and account, validated against the Financial Institutions File and related references establishing reachability. Exchange sorts on it, so reachability is a data question before a format question, and an unreachable destination must be rejected or repaired before release — never released "to see what happens" in either language. The cheapest fix is always before release, which is why Section 3 put routing validation where it did. Format upgrades never excuse dirty master data: a structured file with wrong identifiers fails exactly as fast as a legacy file with wrong identifiers, merely with better-formed content around the error. Master-data quality is a payments control in both languages, and the migration playbook starts with cleansing for exactly this reason.
Above routing, the paths diverge in carrying capacity, and the comparison drives every mapping decision the hub makes. The legacy path carries compact fixed records — batch headers, item records, amounts, dates, balancing control totals — with transaction codes identifying each record and return reason codes identifying why items came back, all defined by the standards and used exactly. Its reference space is tight, so beneficiary reconciliation often needs the bank's reporting to supplement what clearing carried. The ISO path carries structured, self-describing messages under published usage guidelines: fuller party identification, remittance that can be structured, unstructured or both, grouping handled by the message envelope rather than separate control-type records, and a character repertoire supporting English and French text. The industry's own portfolio intent is instructive: legacy content was mapped as close to like-for-like as possible, with optional richer remittance where structure allows more. Like-for-like first, enrichment second — continuity of clearing with room to grow, not a reinvention of what a payroll credit or collection means.
The message families divide their labour functionally across the end-to-end flow; learn the division, not the syntax. Corporate-to-bank initiation carries the originator's instruction toward its bank — credit initiation for payables and payroll pushes, debit initiation for collection pulls — while a status report can return accepted or rejected outcomes. Interbank clearing carries batched credits and debits between participating members, with return, reversal and identification-modification flows defined in the ISO AFT portfolio. Bank-to-corporate reports can include account reports, statements and entry notifications where the bank offers them. Important boundary: Payments Canada's page labels the corporate-to-bank and bank-to-corporate message examples as draft and for information only; they are not a universal customer-interface mandate. Banks may expose different APIs or file contracts. Rule F4's inter-member ISO AFT messages and usage guidelines are the binding clearing layer. What changes operationally is granularity and linkability: coded reasons, return-to-original references and structured remittance where the applicable path and receiving participant support them.
Five references must survive every dual-format journey. The bank's internal instruction identifier anchors tracking from intake through investigation across both paths; without it, a mapped item becomes two items the moment anyone asks a question. The clearing reference — file, batch and item traceability — anchors the system's view in whichever language travelled. End-to-end and remittance references anchor beneficiary reconciliation and must travel verbatim where the destination has room, or be held and reported where it does not. Return linkage anchors the round trip so returns find originals without manual matching — and cross-format returns, where the original went out in one language and the return arrives in another, match on identifiers, never descriptions. Status-report linkage ties each accepted or rejected transaction back to its instruction so the originator can act. Drop any one and a different team pays: investigations stall at the boundary, operations cannot match system reports, returns become research projects, receivables phones the bank, originators cannot tell who was paid. Reference discipline is unglamorous and decisive — the centre of a coexistence chapter, not a technical appendix.
Truncation needs a precise definition before it gets a control. It is what happens when a rich message must travel onward as a lean record and some content has no counterpart: extended party detail beyond the record's fields, remittance beyond the reference space, text beyond the repertoire. The loss is structural — no mapping table fits more into the record than the record holds — so the control cannot be "map better." It is a policy executed by the mapping gate: pass what fits under explicit rules, hold what does not, log every hold with its reason, report held content through status and reporting channels, repair at source by re-origination. The reverse direction needs the complementary discipline: legacy-to-ISO mapping must never invent richness — no padded parties, no synthesized remittance — because downstream consumers treat structured fields as authoritative and will act on fiction. Enrichment may draw only on trusted source data, never inference. And screening must run on the richest representation before truncation, so a name shortened for clearing is never the name a sanctions disposition was based on.
Two consequences close the section. Evidence preservation starts at origination in both formats and must survive translation — authorizations, approvals, validation results, the per-item mapping log, release records — because without the mapping log nobody can reconstruct what a truncated item once said. And free-text discipline travels with the item: guide originators on remittance content at intake, before their text becomes clearing content.
6. Rules, cutoffs, service levels and customer impact
Customers experience rules as promises: will it arrive today, when can funds be used, what will it cost, what reference appears, what happens on failure. Coexistence adds one promise — will our data arrive intact — and the bank experiences all of them as windows, obligations, evidence and format eligibility. This section deliberately avoids quoting exact clock times. Rule F1, Rule F4 and the current system-closure schedule contain binding exchange and processing windows; each bank may impose earlier channel or hub cutoffs. This chapter therefore speaks in relative windows and functional obligations. Any job aid quoting a specific hour or clause from this chapter must be checked against the current rule, standard, usage guideline and bank schedule.
The rulebook layering is straightforward in shape, and shape is all this chapter requires. By-law No. 3 founds payment items and ACSS. Under it, Rule F1 covers AFT transactions using the established file standard, while Rule F4 covers AFT transactions exchanged using ISO 20022 messages; both rules set processing, settlement, exception and participation obligations for their applicable path, with shared companions (routing-number, institution-file, code, security and pre-authorized-debit instruments) applying across both. Standards govern technical detail; usage guidelines govern structured-message use between members. Every operational question has a binding answer in the published framework, and "we have always done it this way" never substitutes for checking the current version. Coexistence content ages faster than single-format content; the current version is the only version that matters.
Participation formalities differ in ways that set migration timelines. Legacy exchange involves advance notice with exchange-point elections and confirmations on receivable record types, account-number formats and testing — the administrative shape of a mature system, including per-branch lead-time conventions requiring credits to be exchanged ahead of due dates by defined margins. ISO exchange has a structured path: information gathering, formal registration at least 180 calendar days before the intended implementation date, inter-financial-institution testing for ACSS direct clearers, agent-coordinated implementation for indirect clearers, and ongoing support and monitoring after go-live. The consequence for planning is direct: onboarding runs months, agent coordination sits on the critical path for indirect participants, and an originator software upgrade does not itself complete participant onboarding. Section 10 builds the bank-specific timeline around these rulebook gates.
Business days anchor batch in both formats. Applicable exchange periods and the published closure schedule determine whether an instruction is eligible for the current window; a file received after the applicable exchange period or the bank's channel cutoff moves to the next eligible window. A holiday can shift due dates, settlement mornings and applicable return clocks, so customer communication should reflect the published schedule proactively. Format adds exactly one consideration: mapping and eligibility workload must fit inside the window. A file needing per-item counterparty lookups and rich-to-lean decisions consumes processing a same-shaped legacy file does not, so hub cutoffs for structured intake legitimately sit earlier than the clearing cutoff, and channels must communicate the hub cutoff — when the originator must deliver for today's window — rather than the clearing cutoff it cannot use directly. Hub logic assigning each instruction to a window, on the correct path, and communicating it honestly at intake is the most customer-visible control in this chapter. Channels must never promise what the rail calendar cannot deliver: the channel offers only what processing confirms for this instruction, this amount, this originator, this format path, this business day.
Service levels bundle timing with certainty, information and recourse, and the advisory job is matching the business event to the bundle without letting format confuse the comparison. Batch offers low-cost scale with structured returns at the price of deferred settlement and return exposure — in either language. Same-day-final rails offer immediacy and irrevocability at wholesale pricing. Structured reporting offers reconciliation ease as bilaterally agreed — available where both sides are ready, progressive elsewhere. Compare bundles, not speeds or syntaxes. Customer communication must use the six words from Section 4 exactly — sent, accepted, settled, posted, available, final — with one coexistence addition: "delivered with full detail" versus "delivered with held content." A credit posted after rich-to-lean mapping must state both its posting and its data outcome, especially where structured remittance was expected. Most batch complaints are vocabulary failures in operational costume; most coexistence complaints will be detail-expectation failures in the same costume. State what travelled, what was held, where the held content is reported — and the costume never gets worn.
7. Fraud, compliance and operational controls
Controls fail most often not by absence but by placement, and coexistence adds new places to put them wrongly. A sanctions check on the truncated representation instead of the richest one, a fraud hold tuned to legacy patterns that structured files bypass, a limit calibrated to file counts that breaks when grouping changes, an authorization review starting only after a cross-format dispute arrives — each exists and still loses, because it runs on the wrong side of the event or the translation. This section places each control family where it can still change the outcome. Rail-level detail for fraud landscapes and screening systems lives in the programme's risk and compliance coverage; here the lesson is architectural: prevention before release on the richest representation, detection across processing and clearing on both paths, evidence — now including the mapping log — everywhere.
Fraud spans initiation, transaction risk and post-event response, and dual format gives both sides new surface. Takeover and social engineering attack initiation regardless of language: authenticate, verify device and behaviour, challenge anomalous payees and changed banking details before release, with callbacks to known contacts — and apply the same challenge to format-change requests, because "switch our file to the new format and reroute it" is a social-engineering sentence as much as "change our account number." Origination fraud attacks the file — fictitious employees, inflated supplier payments, fabricated collections — met with originator onboarding, dual control over release, and anomaly checks comparing economics rather than syntax, so a doubled payroll alerts whether it arrives as records or messages. Incoming-side fraud attacks the receiving account: mule networks collect credits and move them within hours, so score incoming credits too, on both paths. Collection fraud attacks authority — debits without valid authorization — met with mandate evidence before presentment and fast dispute handling after, in either language. Each is a before-release control first and an investigation second, and before-release means before mapping too: a fraudulent instruction mapped cleanly is still fraud, and the log will show how the bank laundered its appearance without checking its substance if scoring ran after translation.
Authorization deserves emphasis because pulls move money on claimed authority, and format upgrades tempt banks to re-paper authority unnecessarily or assume new files imply new mandates. Neither is correct. The bank must evidence the payer's authorization when challenged — agreement or mandate, captured understandably, stored retrievably, linked to the item — and migration changes the carrier, not the consent. Originators should hear plainly that upgrading files does not re-authorize anything, while banks must link unchanged mandate references to items in both formats so a dispute about a structured collection finds evidence as fast as one about a legacy item. Collections coverage teaches the rulebook's pre-authorized-debit expectations in full; this chapter's rule is continuity — consent survives format change, evidence reachable from both paths, and any migration plan treating re-authorization as a step has misunderstood what it migrates.
Sanctions, watchlist and related screening gate release on both paths, on the richest representation, before mapping. Parties and where applicable remittance text and routing are checked before release, with three dispositions: pass, false-positive release with documented reason, or true-hit hold with escalation. Three coexistence notes make this placement non-negotiable. First, files hold hundreds of parties and a single true hit must hold the tainted items without stranding clean ones — in either format, with hold reasons carried back through status the originator can act on. Second, untruncated data matters enormously: truncated beneficiary information breeds multi-day false-positive queues and the temptation to "release and check later" preceding every screening failure — so screen before truncation, always, and log which representation was screened. Third, structured data cuts both ways: fuller identification reduces false positives when originators supply it well, while larger free-text remittance expands the screening surface when they fill it carelessly — making intake guidance on remittance content a sanctions control, not documentation nicety. Log what was checked, when, against which lists, by whom, on which representation, with what disposition. In coexistence the representation line is the line auditors read first.
Anti-money-laundering and record-keeping attach to payment events in both formats, but the filing trigger is not format alone. FINTRAC's current guidance requires a financial entity or casino to report an international electronic funds transfer of $10,000 or more in a single transaction at initiation or final receipt; an international EFT is a transfer other than one within Canada. A domestic AFT item is therefore not automatically an EFTR merely because it is large, although other AML, sanctions, records or suspicious-transaction duties may apply. Client and transaction data must be captured at origination, preserved through mapping and clearing, and retrievable for the applicable retention window. Thresholds and filing mechanics belong to current FINTRAC guidance; this chapter's implementation rule is preservation and complete evidence, including the mapping log.
Oversight and audit complete the plane. Prominent-system designation brings risk-management expectations expressed as governance over both paths, documented dual-format procedures, tested resilience including mapping-layer failure, incident reporting stating format impact, and evidence that controls run every window in both languages. Supervisors and audit will ask for what this chapter has built: who instructed, who approved, what was checked and when and on which representation, how the item mapped and what was held, which window and path carried it, how it settled, where it posted, how exceptions were handled. A bank keeping that evidence as a processing by-product answers easily; one reconstructing it across a format boundary from two log dialects answers expensively. Operational controls tie the families together: entitlements and dual approval, per-path-calibrated limits, hub-inclusive cutoffs, owned ageing queues, amendment discipline, evidence preservation and segregation of duties — bound by release discipline, with every override controlled, dual-approved, time-bound and reviewed.
8. Exceptions, investigations and recovery
Every window breaks differently; every break is managed the same way: detect fast, classify correctly, contain within the rail's rights, recover as a new linked event, reconcile with evidence. Coexistence adds one classification question — which path, and did mapping contribute — and one matching discipline: identifiers, not descriptions, across the boundary. Banks that classify first recover cheaply. Banks that act first — re-sending, manually crediting, editing settled items, hand re-mapping failures — create duplicates and audit breaks dwarfing the original error. Each mechanism in full belongs to dedicated exceptions coverage; this section adds the format-boundary handling only this chapter can give.
Start with the taxonomy, because the boundary punishes imprecision hardest. A reject happens before clearing: processing, hub mapping and validation, gateway or receiving side refuses for invalid routing, closed account, limit breach, failed screening, incomplete data, or mapping failure where required content has no valid counterpart. Nothing settled; the originator repairs and re-originates, with mapping rejects explained as data problems with a source-side fix, never system unavailability. A return happens after entry: the receiving side sends the item back for insufficient funds, closed account, disputed collection or ineligible item, with rulebook reason codes and timeframes carried functionally in both languages — compact codes on the legacy path, structured return information with linkage on the ISO path. Returns are normal traffic, not scandals; straight-through matching on identifiers handles them daily. A reversal corrects bank or system error through a defined mechanism — duplicate file, wrong amount — never silent editing, in either format. An adjustment handles rulebook-allocated small-value consequences: fees, compensation, corrections. An identification-update advice is neither return nor reject but forward correction: the receiving agent notifies the sending agent of corrected routing, future items use it, past items stand — and the sender's master data must actually be updated or the advice was postage. An investigation tracks uncertainty: no confirmation, return without original, disagreeing settlement figure, misread status vocabulary. In coexistence, attach the path to every classification — "legacy return, insufficient funds," "ISO reject, schema," "mapping hold, rich-to-lean" — because the path decides the next system, queue and clock.
Return reasons cluster by shape, and shape survives translation: funds reasons mean retry policy and customer contact; account reasons mean master-data repair; authorization reasons mean mandate evidence or acceptance; administrative reasons — including mapping failures — mean internal fixes starting with hub logs.
Recovery follows one iron rule with a coexistence corollary. The iron rule: never mutate history; always create a linked new event. Rejects are repaired and re-originated with linkage to the original. Returned collections retry only within permitted discipline. Duplicates reverse through the defined mechanism with originals preserved. Adjustments rise as their own entries referencing originals. Every recovery carries the original instruction identifier, the failed item's clearing trace, and the new event's identifier. The corollary: never change formats mid-recovery to dodge a reject. A legacy reject re-sent as a structured message with identical defective content is the same defect with better punctuation — it will return with reason instead of rejecting with one, at greater cost. Mapping holds repair at source and re-originate whole, never by hub hand-edit, because hub editing creates items no source system recognizes and no reconciliation matches. The bank re-sending "the same payment again" without linkage has created two payments and will hear about the second from the customer at the worst moment.
Investigations run on the Section 2 chain with the mapping log as first-class exhibit. Start from the release record — when, which window, which path, which references, which mapping decisions — check clearing and posting on the travelled path, then contact the counterparty or agent with a precise reference-carrying query stating the path. Indirect clearers investigate through agents by contract, formats included. Cross-format cases — original in one language, return in another — match on identifiers end to end; matching by amount and date across formats is a reference failure to fix, not a technique to repeat. Status communication states what is known, on which path, and what is being done — never upgrading "tracked" to "resolved" before evidence arrives, never translating a lean acknowledgement into promises the detail does not support. Most investigations close within return and reporting cycles; the rest are usually reference failures or mapping mysteries — why Sections 5 and 7 called reference discipline and mapping logs decisive.
Containment comes last because batch scale punishes slow containment and dual format doubles the surface. Corrupt file, compromised credential, misdirected stream, bad mapping-table deployment: stop the bleeding first — hold pending releases from the source on both paths, quarantine repair and held-content queues, suspend the suspect mapping version, notify agents or counterparties where required — then diagnose. Mapping tables and hub releases need production-grade change governance — versioned, tested, dual-approved, rollback-ready — because a bad mapping deployment manufactures identical defects at file scale. Containment authority must be reachable every window, not convening tomorrow. Dedicated coverage builds the runbooks; this section's mindset with its coexistence extension: classify with the path, contain both paths, recover as linked events in the eligible format, reconcile with evidence including the mapping log.
9. Posting, accounting, liquidity, reporting and reconciliation
This section proves the movement afterwards — and coexistence changes the proof without changing the money. Posting, accounting, liquidity forecasting, reporting and reconciliation behave as batch always behaved; what changes is evidence arriving in two dialects, beneficiary detail sometimes held, and receivables progressively easing as structured data spreads. Operations must do two things at once: run timeless disciplines exactly as before, and normalize dual-format evidence into one story per customer. Teams doing only the first drown originators in two dialects; teams attempting only the second manufacture assurance they cannot support.
Posting stays path-indifferent. Credits debit originators and eventually credit beneficiaries; debits collect from payers and credit billers; fees, returns, reversals and adjustments post as linked entries. What a receiving bank auto-posts depends on its own engines, not the sender's language — a structured message at a bank consuming only mapped-down content posts what the mapped content supports, no more. Availability is not determined by the sender's format: posting is not availability, and the receiving institution applies its own holds, serviceability and return-rights rules. Batch "posted" always carries return-rights awareness, especially for collections. The coexistence posting control is matching discipline on returns and reversals: automatic matching keys on identifiers — instruction, clearing trace, return linkage — and breaks falling to manual matching by amount or description are counted, aged and driven down as data-quality metrics. Unapplied cash, suspense balances and manual-match rates are the dials on the coexistence dashboard; watch them as treasury watches positions.
Accounting follows the event, not the format. Origination creates customer and memo entries; release creates clearing-position entries; morning settlement creates central-bank-money entries for direct clearers and agent-settlement entries for indirect ones; returns, reversals and adjustments create linked entries preserving originals. No format-based subledgers: books record obligations and movements while format lives in references and the linked mapping log. The dual-format audit trail is the classic trail plus one exhibit — instruction, validation, mapping decisions with reasons, release, clearing confirmation, settlement position, posting, reports — assembled identically for both paths so an auditor follows money without needing format, only data. Indirect clearers reconcile through agents as before, confirming format handling in advices: what the agent received, which path cleared, what was held, what settled. The three-way daily close — positions, settlement confirmations, settlement-account entries — takes no format parameter; any break blamed on "the ISO file" should be reclassified on inspection into positions, confirmations or entries, with the file merely where evidence was found.
Liquidity is where format indifference pays its clearest dividend. Positions net values and volumes regardless of language, so treasury forecasts nets, never items or formats. Morning funding, intraday return-exposure management, agent-funding arrangements — all run as settlement coverage describes, coexistence adding only volume-mix awareness for staffing. Tell every treasurer who asks: ISO format does not itself change ACSS funding, float or netting. Bank-specific intake cutoffs and mapping workload can change when a customer must submit, while settlement remains governed by the rulebook. The return sits in operations headcount, reconciliation speed, screening quality and experience — real money in queues and write-offs, not a promised funding benefit. Business cases promising liquidity benefits mislead sponsors and set migrations up to fail on the morning the first settlement looks exactly like the last.
Reporting is where coexistence meets customers and where banks earn or lose the migration's reputation. The structured world offers intraday advices, per-entry notifications and end-of-day statements as bilaterally agreed; the legacy world its leaner equivalents; the bank's duty is one normalized story per customer regardless of mix. That means status normalized upward — per-transaction accepted and rejected detail with actionable reasons even for lean-travelled items, assembled by the bank where clearing did not supply it — held-content reporting stating exactly what did not travel and where it is available, and remittance forwarding delivering structured detail to ready beneficiaries while rendering faithful compact equivalents for the rest. Three avoidable failures recur: exposing two dialects and inviting originators to learn clearing; silently dropping held content so originators hear about it from suppliers; over-promising structured reporting to beneficiaries whose banks cannot deliver. Each is prevented by registry-plus-routing: know what each counterparty receives, route by eligibility, report what travelled and what was held.
Reconciliation closes the loop as daily practice, not aspiration. Three matches run every cycle: intake to release — every instruction accepted, rejected, held or released with its format decision; release to clearing — every item confirmed or rejected on its path with its trace; clearing through settlement to posting — positions, morning settlement and customer entries in agreement. Cross-format matching keys on identifiers always; description matching counts as defect. Held content reconciles as its own population: logged at mapping, reported, repaired at source, re-originated whole — with ageing and ownership, because unowned queues become write-offs. Dual-run adds a fourth match — legacy against ISO, item for item — until each counterparty's gate passes. The bank running these matches daily knows its coexistence position as treasury knows funding: a number, with a trend, owned by someone. The bank reconciling monthly discovers migrations the way customers do: by complaint.
10. Bank implementation, testing and resilience
Coexistence capability is production payments capability, not a mapping project with a go-live date. Implementation spans intake channels, hub normalization and mapping, dual-destination validation, richest-representation screening, the capability registry, status normalization, reporting, reconciliation, exception queues and the evidence store — each built, tested, deployed and rolled back under payments-grade governance. This section shapes that work: what to build, how to test, how to stay resilient, how to onboard without confusing anyone's software upgrade with the rulebook's.
Build the hub as four governed components mirroring Section 3, because architecture mirroring control is auditable. Normalization turns every intake variant into one canonical record with a durable identifier — versioned, tested, owned. Explicit mapping turns canonical records into destination items under named, versioned tables with per-item decision logging — no hand edits, no unlogged defaults, no silent drops, with rich-to-lean policy tabled as business rules rather than buried code. Destination validation checks mapped results against schemas and usage guidelines for ISO-bound items and fixed-record edits for legacy ones — validation suites owned alongside their mappings, so mapping changes cannot deploy without validation changes. Logging and reporting emit the mapping log, held-content queue, status inputs and reconciliation feeds as contractual outputs of every release — monitored for completeness, because a hub processing without logging manufactures unanswerable questions. Around these, the registry records what each counterparty and agent receives, eligibility routing consumes it at release, and status normalization turns both paths' confirmations into one originator vocabulary. Screening, limits and approvals gate both exits as shared services so improvements land everywhere at once. Every component gets an owner, a version, a test suite and a rollback — and any design review unable to point at each of these for a proposed change has found its first finding.
Test in layers following risk; no single test proves a dual-format shop safe. Mapping-table tests prove each named source-to-target decision including holds and rejects, with truncation cases as explicit test cases carrying expected log entries. Path-validation tests prove representative files against destination requirements in both languages, including invalid files that must reject with the right reason. Cross-format tests prove identifier survival both directions, including return-to-original matching where returns arrive in the other language. Screening tests prove dispositions on the richest representation with truncated cases proving no silent pass. End-to-end tests prove intake-to-status for representative originators, agent handoffs for indirect flows, and identification-update flows proving corrections actually land. Dual-run — parallel legacy and structured operation with item-for-item matched reconciliation — is the central control, exited counterparty by counterparty only on consecutive agreeing cycles, never on calendar pressure. Every layer needs entry and exit criteria written before it starts; a test without exit criteria is a demonstration, and demonstrations do not protect payroll.
Resilience means assuming each new component fails with the answer ready. Mapping-layer failure: intake holds safely with originators notified, clearing continues on released items, and no file bypasses mapping by hand — manual bypass is how duplicates and unlogged truncations enter, and must not exist even as an emergency option without dual approval, time bounds and full logging. Stale registry: routing fails closed toward the known-working format rather than optimistically toward richness — with staleness alerted, because an untrusted registry is a routing lottery. Bad mapping deployment: versioned rollback restores prior tables and the log identifies affected items for reprocessing as linked new events, never silent edits. Counterparty or agent unable to receive as registered: status normalization tells the originator in one vocabulary while operations reroutes by eligibility and corrects the registry at source. Communication templates must cover data outcomes — held content, delayed richness, extended dual-run — not only timing. Review resilience by asking, per component, what the next window looks like without it; any answer involving improvisation is a gap with a deadline.
Onboarding fails most often by confusing three different upgrades. The participant's rulebook onboarding — long-notice registration, testing, coordinated go-live — is the bank's obligation to the system and cannot be compressed by will. The originator's software upgrade — a new module emitting structured files — is the customer's project and changes no clearing path by itself. The bank's hub readiness — intake, mapping, validation, reporting, reconciliation for that originator's profile — is the bank's obligation to the customer, proven in dual-run before any cutover promise. State these apart in every kickoff, in writing; every migration dispute is two of them confused. Originator onboarding follows the playbook below: inventory what is sent and who counterparties are, cleanse masters and remittance quality first, dual-run with matched reconciliation, cut over counterparty by counterparty with rollback ready, then optimize around the new richness. No step is final until reconciliation and reporting agree across consecutive cycles, and rollback belongs to each gate, not an appendix. A migration that cannot roll back cannot safely go forward, and payroll is the wrong place to learn that.
Governance spans the multi-year horizon: versioned procedures and mapping tables under change control, a registry with an owner and staleness alert, owned ageing queues, daily reconciliation metrics, and evidence produced as a processing by-product. Strategy follows facts; customer promises follow capability, not commentary.
11. Practical Canadian examples
Theory earns its keep in cases sharing one structure: business situation, flow from intake through reconciliation, then the control lesson for the next migration meeting. All three are fictional Canadians from common patterns: a mid-market employer upgrading payroll software, a distributor paying a mixed supplier base, a biller modernizing collections. Names, figures and volumes are illustrative and deliberately imprecise where precision would imply a real institution. Read them for decisions and disciplines, not numbers to quote.
Example (fictional) — an ERP upgrade to an ISO payroll file. A Manitoba food distributor with about four hundred employees replaces its payroll module over a summer. The new module emits structured payroll with full employee identification, cost-centre detail and long-wanted remittance references. Payroll operations is delighted; the bank's onboarding team is careful, and the care is the story. Inventory shows employee accounts spread across several receiving banks, the employer's bank participating directly, and one bureau still forwarding a monthly legacy adjustment file. Cleansing finds fourteen employee records with pre-consolidation transit details and an unstandardized cost-centre set — repaired at source before volume moves, because structured files with dirty masters fail exactly as fast as legacy ones. Dual-run shadows two pay cycles: each payroll runs live-legacy plus shadow-structured, matched item for item on identifiers, with the held-content report reviewed line by line — cost-centre detail beyond the legacy path logged and reported, not forced. Cutover moves the main payroll to structured intake while the bureau file stays legacy, routed by eligibility, reconciled as one payroll across two paths. The first live run rejects eleven items at hub validation for account errors legacy edits had silently tolerated; each rejects visibly with reason, repairs at source, re-originates whole, and Friday pay lands intact. Optimization follows: Monday-morning manual matching becomes same-day identifier matching, and the held-content queue shrinks counterparty by counterparty as the registry records new capability. The control lesson: value came from cleansing, dual-run and eligibility routing, not file format — format merely let discipline pay.
Example (fictional) — a mixed supplier base and the payables run serving it. An Ontario building-supplies distributor pays several hundred suppliers twice monthly: large vendors with structured-ready receivables, mid-size vendors on legacy intake, a long tail of small suppliers whose banks consume only compact content. Its new payables platform emits fully structured payments with invoice-level remittance, and accounts payable asks whether every supplier now reconciles automatically. The bank's answer is honest and useful: automatically where the path supports it, faithfully but compactly elsewhere, with the difference reported rather than hidden. Intake accepts one canonical population; the hub maps per counterparty against the registry — structured clearing where eligible, legacy clearing with explicit rich-to-lean mapping where not, invoice detail beyond legacy capacity logged, held and reported. Screening runs on the richest representation before mapping. Destination-rail validation rejects a closed supplier account, a stale-vendor-master transit and a platform-emitted duplicate batch — visibly, per transaction, with reasons payable staff can act on before the window. Treasury sees one format-indifferent funding position. Reporting earns the fee: large vendors receive appliable structured remittance, mid-size vendors faithful compact references plus normalized advice, small suppliers what their banks deliver — and payables receives one normalized report per supplier stating what travelled and what was held. Over two quarters the held queue shrinks as the registry records new capability. One month a mapping-table change misroutes a capable vendor's items onto the legacy path; the daily legacy-versus-ISO match catches it that morning, versioned rollback restores prior tables, and items reprocess as linked new events with the log showing exactly what happened. The control lesson: route by registered eligibility, report what travelled and what was held, and let daily matches — not supplier complaints — find routing errors.
Example (fictional) — a biller moving collections to structured files. A Quebec property manager collecting monthly rents from a few thousand tenants upgrades its platform and asks its bank to move the debit portfolio to structured initiation. Onboarding starts where authorization lives: every mandate reference in the legacy portfolio must link to retrievable evidence before one structured collection releases, because migration changes the carrier, not the consent. Cleansing re-registers several hundred free-text mandate references from a retired system against canonical records in both formats, tested by simulated dispute retrieval before go-live. Dual-run shadows one full cycle with returns watched hardest — funds, account and two disputed debits — each matched on identifiers across the boundary, proving return linkage survives translation. Cutover staggers by payer-bank group to keep exception queues learnable, with normalized status giving one vocabulary regardless of path. In the second live cycle a payer-bank group returns a cluster after an account migration at their end; identification-update advices arrive, master data is actually updated rather than filed, and the next cycle uses corrected detail — forward correction working because someone owned the update. The same season proves fraud placement: first-time debits against changed payer details score high on anomaly checks, callbacks confirm two social-engineered changes, and items hold before release on the richest representation, before mapping. The control lesson: consent and evidence survive format change only if someone ensures they do, identifier-matched returns prove the boundary safe, and pre-mapping fraud controls protect both paths at once.
Three patterns repeat: source cleansing beats mapping heroics, dual-run with identifier matching exits counterparty by counterparty on consecutive clean cycles, and the mapping log plus normalized status reporting makes coexistence explainable to originators, beneficiaries, auditors and investigators.
12. Key takeaways and authoritative references
Coexistence is the current operating condition. AFT transactions under Rule F1 and ISO 20022 AFT transactions under Rule F4 use the same live retail batch system and settle through the same ACSS netting model, while the data and control obligations differ. The bank organizing around that fact — dual-format intake, one canonical model, format-eligibility routing and normalized evidence — spends energy on data quality where returns are.
Rich-to-lean mapping is the predictable lossy direction, and every control follows. Rich-to-lean mapping passes what fits under explicit policy, holds the rest, logs every hold with reason, reports held content, repairs at source by re-origination. Lean-to-rich mapping never invents content; enrichment draws only on trusted source data. Screening runs on the richest representation before truncation. The mapping log is retained evidence alongside validation and release records for the full return, dispute and audit window.
Validation answers to the destination. Each mapped item is validated against the rail carrying it — schemas and usage guidelines for ISO-bound items, fixed-record edits for legacy ones — with map-then-validate-to-destination enforced by design. Screening, limits and approvals gate both exits as shared services. Cutoffs account for mapping workload, and channels communicate the hub cutoff the originator can use.
The ACSS settlement model and netting are format-indifferent; preserve that boundary with customers. ISO 20022 does not by itself make value settle sooner, and morning positions are calculated from volumes and values rather than remittance. Posting and availability remain receiving-institution and rule dependent. The ISO case is an operations case — reconciliation, screening, investigation and experience — strong when stated honestly. Never sell format as speed, never promise universal richness on day one, and always state both halves of a mapped delivery: what travelled and what was held.
Migration succeeds counterparty by counterparty — inventory, cleanse, dual-run, gated cutover, optimization — with rollback at every gate, consent and evidence surviving format change, returns matched on identifiers, and daily matches across intake, clearing, settlement, dual-run populations and held content proving progress before customers must.
Authoritative references (official sources only; current published versions govern — check currency before relying on any detail):
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.