ISO 20022, Settlement and Finality. Connect payment data, settlement, liquidity, irrevocability and beneficiary funds availability.
Block 12 · Chapter 59 of 75
As of this audit date, Canada's Real-Time Rail (RTR) is a planned national system scheduled to launch in Q4 2026, not a live production rail. Its approved launch model joins three things that are often discussed separately: ISO 20022 payment data, real-time settlement and customer funds availability. A bank implementation fails when it treats any one of them as the whole payment.
ISO 20022 describes and structures the business information exchanged between participants. It does not by itself create settlement finality. Under the approved RTR model, settlement is achieved through RTR Clearing and Settlement by entries to RTR Settlement Accounts on the books of the Bank of Canada, or to Settlement Agents' accounts when participants settle indirectly. Customer funds availability is the final receiving-bank obligation after the settlement outcome, subject to the exceptions in Rule 7.
The approved and effective RTR design for launch is specific; it is not evidence that the rail is already in production. The payment item exchanged is a pacs.008 FIToFICustomerCreditTransfer. The receiving participant uses a pacs.002 FIToFIPaymentStatusReport for its payment acceptance status. The Settlement Outcome Message is also a pacs.002, sent by the RTR Exchange after RTR Clearing and Settlement confirms that settlement has occurred. A pacs.028 supports payment-status inquiry. Payments Canada also publishes RTR specifications for head.001, admi.002, admi.004 and admi.011. The approved design must be followed rather than importing assumptions from CBPR+, SEPA Instant, FedNow, RTP or another ISO 20022 scheme.
At settlement level, Rule 8 requires sufficient payment capacity and, for the normal RTR Exchange payment flow, supports reservation before settlement. Direct participants settle through their own Bank of Canada RTR Settlement Accounts. Indirect participants settle through their Settlement Agent. The current Exchange and normal clearing-and-settlement value limit is CAD 100,000. Direct participants fund and defund RTR settlement accounts using Lynx payments under their Bank of Canada arrangements.
At customer level, finality also needs careful language. Rule 6 makes an RTR Payment Message irrevocable by the Sending Participant once it is submitted to the Exchange. Rule 7 states that after the amount is made available to the payee the payment is final and irrevocable, while setting out specific exceptions and return mechanisms. That does not mean a bank can erase a settled payment or run a generic chargeback. It means the original payment history remains intact and any permitted return/recovery is a linked event.
This chapter connects data, transaction identity, settlement capacity, settlement evidence, accounting, finality, funds availability and reconciliation into one bank-grade model.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain why ISO 20022 messaging and settlement finality are related but different concepts;
- identify the published RTR core ISO 20022 message families intended for launch;
- explain the purpose of head.001, pacs.008, pacs.002, pacs.028, admi.002, admi.004 and admi.011 at a practical level;
- explain why message use must follow the RTR usage specification rather than generic ISO knowledge;
- identify UETR as required payment information and a duplicate-control key;
- design an identity chain that links customer order, internal payment, UETR, external statuses and settlement;
- explain direct and indirect settlement-account treatment;
- explain payment capacity, reserved balance, ISP Net Position and Net Debit Cap;
- describe how Rule 8 reserves and settles value;
- explain why the Bank of Canada account is the settlement foundation while Payments Canada operates the RTR;
- describe RTR funding and defunding through Lynx;
- distinguish message acceptance, positive payment outcome, settlement outcome and beneficiary funds availability;
- explain the 60-second funds-availability requirement;
- explain the difference between irrevocability at submission and finality after payee funds availability;
- identify Rule 7 exceptions and return processes without describing them as chargebacks or pacs.004 settlement reversals;
- design posting, accounting and settlement reconciliation;
- explain how rich remittance can support corporate reconciliation;
- design operational evidence sufficient for audit and investigation;
- test liquidity, message, settlement, posting and finality edge cases.
For a focused core session, spend about 15 minutes on Sections 1–3, 15 minutes on Sections 4–6, 10 minutes on Sections 7–8, 10 minutes on Sections 9–10, 5 minutes on practical scenarios and 5 minutes on the rules and references.
Chapter navigator
- ISO 20022 in the RTR context
- RTR message families and their purpose
- Transaction identity, UETR and traceability
- From payment message to settlement obligation
- Payment capacity, reservation and indirect positions
- Settlement accounts and central-bank settlement
- Finality, irrevocability and funds availability
- Accounting, evidence and reconciliation
- Remittance data, reporting and investigations
- Implementation and test design
- Practical settlement and finality scenarios
- Key takeaways and authoritative references
1. ISO 20022 in the RTR context
ISO 20022 is a business-message standard. It gives payments a structured vocabulary for parties, accounts, agents, amounts, references, remittance and statuses.
The key word is structured.
A legacy payment implementation often stores information as:
- one account field;
- one amount;
- one free-text reference;
- one response code.
An ISO 20022 implementation can preserve more context, but only if the bank's internal model supports it.
ISO 20022 is not one universal payment flow
pacs.008 exists in many schemes, but its allowed values, required fields, process semantics and response flow vary.
For RTR, the controlled sources are:
- RTR ISO 20022 Message Specifications;
- companion document;
- RTR Exchange API Specification;
- RTR Rules.
Do not copy a CBPR+ mapping and call it RTR.
Examples of scheme-specific differences can include:
- required identifiers;
- amount/currency rules;
- service codes;
- rejection reasons;
- timing;
- status semantics;
- remittance restrictions.
Canonical internal payment model
A bank benefits from a canonical model between customer channels and the RTR mapper.
Example groups:
Identity
- internal payment ID;
- customer order ID;
- UETR;
- message ID.
Parties
- payor;
- payee;
- sending participant;
- receiving participant.
Accounts
- debtor account;
- payee account;
- internal ledger identifiers.
Value
- CAD amount;
- customer fees;
- product limits.
Routing
- institution number;
- competitive service;
- connection service provider.
Remittance
- unstructured reference;
- structured remittance elements;
- related remittance.
Risk
- payee/account validation result, if used (any Confirmation of Payee/CoP is bank- or competitive-service-specific);
- fraud assessment;
- internal risk decision.
Status
- participant acceptance;
- payment outcome;
- settlement outcome;
- customer posting.
The ISO mapper should transform this canonical object into the published RTR message version, not embed customer product logic inside XML construction.
2. RTR message families and their purpose
Payments Canada's published RTR ISO page provides the following message families for participant preparation and go-live.
head.001 — Business Application Header
The Business Application Header carries message-level routing and application context.
It should be validated and logged with the business message.
Common implementation concerns:
- sender/receiver context;
- business service;
- message definition;
- creation/time data;
- correlation to payload.
Do not treat the header as disposable transport metadata if operations may need it to prove what was sent.
pacs.008 — FI-to-FI Customer Credit Transfer
This is the RTR Payment Message acceptable for Exchange.
Rule 6 requires payment information including:
- amount;
- payee account;
- sending participant institution number;
- receiving participant institution number;
- UETR;
- Connection Service Provider Identifier;
- Competitive Service Identifier.
The detailed message specification defines the actual XML path and usage.
Authentication and fraud (scheme rule): Rule 6 requires each Sending Participant to authenticate the Payor that initiates an RTR Payment Message and to use Central Fraud Services as required by Rule 13. Payments Canada describes those RTR fraud-mitigation services as mandatory for all participants at launch and in addition to each participant's own fraud controls. Channel authentication, step-up methods and bank risk thresholds remain implementation-specific.
Cross-border boundary (scheme rule): Rule 6 states that, effective 30 September 2027, an RTR Payment Message sent in fulfilment of an international electronic funds transfer must carry the INTL code in the Service Level component. Before that date, the domestic leg of an international electronic funds transfer may not be sent through the RTR Exchange. This is an RTR rule, not a general statement that all cross-border payments use RTR.
pacs.002 — FI-to-FI Payment Status Report
pacs.002 has more than one practical role in the RTR lifecycle.
It is used for:
- receiving-participant payment acceptance status;
- Settlement Outcome Message after settlement.
The business context determines what the status means.
An operations screen should therefore show:
- pacs.002 business purpose;
- related UETR/payment;
- status/reason;
- timestamp.
"pacs.002 received" is not enough.
pacs.028 — FI-to-FI Payment Status Request
pacs.028 supports status inquiry.
This matters when expected payment outcome or settlement outcome evidence is missing.
It is an operational recovery tool, not a reason to create a duplicate payment.
admi.002 — message reject
admi.002 represents a message-level reject scenario in the RTR ISO set.
Technical rejects should be separated from business payment rejection.
Examples:
- malformed/unsupported message;
- application-level validation issue.
A message reject may mean the business payment never entered the expected processing state.
admi.004 — system event notification
This supports system-event communication.
Operations should connect system events to:
- service status;
- alerting;
- incident management;
- payment processing controls.
admi.011 — system event acknowledgement
This supports acknowledgement of system events.
Reliable operational messaging is part of the always-on rail, not an optional monitoring feature.
Version control
Payments Canada's RTR ISO page states the displayed specifications were last updated 30 May 2025.
A bank should record:
- specification version;
- deployment version;
- effective date;
- test certification version.
If Payments Canada publishes a later version, regression impact must be assessed.
3. Transaction identity, UETR and traceability
Payment identity is the backbone of reconciliation.
UETR requirement
Rule 6 requires UETR in the RTR Payment Message.
Rule 6 also rejects duplicate UETRs reused for messages sent to the Exchange within the previous 90 calendar days.
Rule 7 uses UETR as key information in return and return-request processes.
So UETR spans:
- processing;
- duplicate control;
- investigation;
- recovery.
Do not overload one identifier
A robust bank stores several identifiers:
| Identifier | Owner | Purpose |
|---|
| Customer order ID | Channel/product | customer request |
| Internal payment ID | Payment hub | economic transaction |
| UETR | RTR payment | external lifecycle identity |
| Technical message ID | Gateway | individual transmission/message |
| Settlement reference | Settlement layer | financial settlement evidence |
| Ledger entry ID | Core accounting | customer booking |
| Case ID | Operations | exception/return/investigation |
The identifiers should cross-reference each other.
Retry example
A gateway sends pacs.008.
TCP connection breaks.
The technical retry can be safe only if:
- the same business payment is recognized;
- the same UETR remains attached;
- the transport/API behavior follows the RTR specification;
- the system does not create a second customer order.
A new UETR is not a generic "retry ID."
Investigation query
Operations should be able to enter any of:
- customer reference;
- UETR;
- internal payment ID;
- payor/payee account;
- amount/date;
- settlement reference.
The system should reconstruct the lifecycle.
4. From payment message to settlement obligation
The pacs.008 represents the payment message exchanged between participants.
The settlement layer deals with the RTR Payment Obligation.
Rule 1 defines the obligation as the obligation of a participant to pay another participant a fixed amount in RTR Clearing and Settlement.
Settlement Instructions
Settlement Instructions contain the information needed to clear and settle the obligation.
They may be generated by:
- the RTR Exchange;
- a Third-Party Exchange;
- RTR Clearing and Settlement for a Participant-to-Participant Transfer.
For the normal RTR payment flow, the Exchange produces the settlement path after the required payment and reservation conditions are satisfied.
Why separate message and obligation
A payment message contains customer/business data.
Settlement needs:
- amount;
- sending settlement side;
- receiving settlement side;
- settlement-agent mappings;
- capacity;
- reservation;
- account entries.
The settlement system does not need the full customer experience to move central-bank value.
Exchange value and settlement value
Rule 6:
- RTR Exchange Value Limit = CAD 100,000.
Rule 8:
- RTR Clearing and Settlement Value Limit = CAD 100,000 for normal obligations, subject to rule provisions.
These aligned limits simplify the normal flow, but they are conceptually different controls.
The bank should still validate the amount before message creation.
5. Payment capacity, reservation and indirect positions
Real-time settlement requires available financial capacity.
Payment capacity
Rule 8 requires the sending participant's Settlement Account to have Payment Capacity not less than the amount needed to settle the obligation.
For an indirect sending participant, the relevant account is its Settlement Agent's account.
Reserved Balance
For instructions requiring reservation, RTR Clearing and Settlement reserves the amount needed for the payment.
The account state changes:
- Payment Capacity decreases;
- Reserved Balance increases.
This protects the value for the pending settlement.
Indirect settlement participant position
If the sending participant is indirect:
- reservation occurs in the Settlement Agent's account;
- the indirect participant's ISP Net Position is updated;
- the settlement must not breach its Net Debit Cap.
This gives the agent a controlled exposure model.
Treasury views
A settlement dashboard should show:
- total settlement account balance/context;
- payment capacity;
- reserved balance;
- outgoing obligation pipeline;
- incoming settlements;
- per-indirect ISP Net Position;
- per-indirect Net Debit Cap;
- threshold alerts;
- funding/defunding status.
Customer payment operations may only need a subset, but treasury needs the full picture.
Participant-to-Participant Transfers
Rule 8 permits Participant-to-Participant Transfers between direct participants as a tool to manage Payment Capacity during the RTR Operating Cycle.
These are settlement/liquidity operations, not customer pacs.008 payments.
Accounting and monitoring should classify them separately.
6. Settlement accounts and central-bank settlement
The direct participant's RTR Settlement Account is on the books of the Bank of Canada.
Settlement account ownership
Payments Canada owns and operates the RTR.
The Bank of Canada provides settlement accounts.
Payments Canada effects the rule-governed account entries in RTR Clearing and Settlement.
This distinction should be reflected accurately in architecture diagrams.
Direct-to-direct settlement
For a direct sending and receiving participant:
- sending payment capacity/reserved balance is reduced as applicable;
- receiving participant payment capacity increases;
- the RTR Payment Obligation is settled.
Indirect settlement
If one side is indirect:
- its Settlement Agent's account receives the relevant settlement entry;
- the indirect participant's position is updated.
If both sides are indirect, each can have a different Settlement Agent.
Funding
Rule 8 requires a direct participant to fund its RTR Settlement Account by sending a payment to the Bank through Lynx under the Bank agreement and operating procedures.
After Bank direction in the RTR Clearing and Settlement Portal, Payments Canada credits the amount to the account's Payment Capacity.
Defunding
A direct participant can request defunding subject to Bank procedures and sufficient Payment Capacity.
Payments Canada reduces Payment Capacity and the Bank sends a payment to the participant through Lynx.
24/7 liquidity implication
RTR is designed for continuous payments, but funding arrangements must be managed around Bank/Lynx operational procedures.
Treasury needs:
- predictive funding;
- weekend/holiday buffers;
- alerts;
- sponsor-volume forecasting;
- contingency policy.
A 24/7 rail cannot depend on a weekday-only manual liquidity team.
7. Finality, irrevocability and funds availability
These terms are related but not identical.
Irrevocability at message submission
Rule 6 says an RTR Payment Message, once submitted to the RTR Exchange, cannot be cancelled, revoked or amended by the Sending Participant.
This protects the external process from unilateral recall.
It does not mean settlement has already happened.
Settlement
Settlement occurs when the RTR Payment Obligation is transferred through the appropriate account entries.
After settlement:
- RTR Clearing and Settlement confirms to the Exchange;
- the Exchange sends Settlement Outcome Message to participants.
Payee funds availability
Rule 6 requires the receiving participant, subject to Rule 7 exceptions, to make the amount available promptly and no later than 60 seconds after receiving the settlement outcome.
Final and irrevocable payee payment
Rule 7 states that where the amount has been made available to the payee, payment is final and irrevocable except for specifically defined circumstances.
Those circumstances include:
- Processing Error;
- End-User Error;
- Unauthorized RTR Payment;
- Authorized RTR Payment Fraud;
- specified deceased-account/legal cases.
The existence of a return mechanism does not convert RTR into a chargeback rail.
Four clocks
Operations should track four times:
- submission time;
- receiving-participant acceptance time;
- settlement outcome time;
- payee funds-available time.
These times prove different obligations.
Customer statement language
Avoid:
"Settled" when only acceptance exists.
Prefer:
- Processing;
- Accepted by recipient institution;
- Completed/settled when settlement evidence exists;
- Funds available where receiving-bank evidence confirms it;
- Exception/under review where Rule 7 applies.
8. Accounting, evidence and reconciliation
Accounting must represent the economic state accurately.
The evidence-chain diagram above traces the full path from customer instruction through message identity to settlement proof, showing which artefact supports each journal stage on both sides.
Sending bank
Possible stages:
- customer funds reserved;
- external payment submitted;
- customer debited;
- settlement confirmed;
- fees recognized;
- rejection releases reservation.
The exact journal sequence depends on the bank.
Receiving bank
Possible stages:
- settlement outcome received;
- customer account credited;
- funds made available;
- settlement asset/position reconciled.
Indirect participant accounting
The indirect participant needs to reconcile:
- customer ledger;
- RTR payment outcome;
- position with Settlement Agent.
The Settlement Agent needs to reconcile:
- Bank of Canada settlement account;
- each indirect participant position;
- its own payments.
Evidence model
Retain:
- inbound/outbound payload hash or controlled message copy;
- UETR;
- participant IDs;
- timestamps;
- settlement status;
- settlement agent;
- amount;
- customer posting IDs;
- exception reason;
- return linkage.
Reconciliation timing
Do not wait for end-of-day.
Useful layers:
- transaction-level near-real-time matching;
- intraday settlement position control;
- periodic balance check;
- end-of-cycle/accounting close;
- exception ageing.
Break ownership
A settlement break should route to settlement/reconciliation.
A customer posting break should route to core/accounting.
A missing pacs.002 should route to payment/gateway operations.
A fraud hold should route to fraud/investigations.
One generic "payments operations" queue becomes a bottleneck.
9. Remittance data, reporting and investigations
ISO 20022 enables richer payment context.
Extended remittance
Rule 10 requires each participant to receive all Extended Remittance Information included in an RTR Payment Message and governs how it is handled.
Rule 10 sets a maximum of 9,000 characters for the structured component within Remittance Information, excluding tags. The Sending Participant must prescribe terms and conditions prohibiting a Payor from supplying Malicious Content for inclusion. Rule 10 does not require a Receiving Participant to scan every message, but Rule 6 and Rule 7 provide reject/return paths where harmful content is detected.
A bank should not promise every channel can display 9,000 characters. Subject to its terms and the Payee's request, the Receiving Participant must provide or make the Extended Remittance Information available to the Payee as soon as possible and no later than 60 seconds after the amount is made available, and must retain it for at least 90 calendar days. The bank should preserve and deliver the scheme-supported data appropriately.
Corporate reconciliation
Structured remittance can carry invoice-oriented information that helps:
- accounts receivable;
- ERP matching;
- payment allocation;
- supplier reconciliation.
Example:
Customer sends CAD 18,450 covering three invoices.
The payment and remittance arrive together.
The supplier's system maps:
- invoice A CAD 5,000;
- invoice B CAD 7,450;
- invoice C CAD 6,000.
This removes manual matching.
Reporting
Customer reporting may include:
- payment reference;
- amount;
- date/time;
- counterparty;
- remittance;
- status.
Operational reporting adds:
- UETR;
- participant;
- settlement status;
- rejection codes;
- fraud decision;
- latency;
- exception.
Treasury reporting adds:
- settlement capacity;
- reserved balance;
- sponsored positions;
- funding.
Investigation bundle
For an investigation, assemble one evidence package:
- customer instruction;
- authentication;
- payee/account validation result, if used (any CoP is bank- or competitive-service-specific);
- fraud assessment;
- pacs.008;
- pacs.002 responses;
- settlement outcome;
- customer debit/credit;
- remittance;
- case communication.
This reduces handoffs between teams.
10. Implementation and test design
Message contract testing
For each message:
- schema-valid positive case;
- missing required field;
- invalid enumeration;
- incorrect header/payload correlation;
- oversized data;
- invalid UETR;
- unsupported version.
Business validation
Test:
- CAD only;
- CAD 100,000 accepted where participant/customer limits allow;
- above-limit rejected before send;
- duplicate UETR;
- invalid participant;
- account restrictions.
Settlement
Test:
- enough payment capacity;
- reservation consumes capacity;
- settlement releases reserved balance correctly;
- receiver capacity increases;
- indirect position updated;
- net debit cap breach prevents path;
- settlement agent change.
Funding
Test:
- Lynx funding recognized in Payment Capacity;
- duplicate funding event;
- delayed portal instruction;
- defunding with insufficient free capacity;
- reconciliation to Lynx.
Funds availability
Measure:
- settlement outcome receipt;
- credit completion;
- 60-second threshold;
- exception path.
Do not use end-of-day batch timestamps to prove a real-time service level.
Version regression
When a new ISO specification is published:
- compare element/cardinality changes;
- update canonical mapping;
- run message regression;
- run negative tests;
- update operations parsing;
- update archived sample library.
Deeper ISO 20022 and settlement implementation
The most important design principle is to avoid turning ISO 20022 into a gateway-only concern. The message is only one representation of the payment. The bank's internal data, settlement model and accounting evidence must preserve the same economic meaning.
Canonical model and scheme model
A bank can support several rails that all use ISO 20022 while still having different rules.
For example:
- RTR;
- Lynx;
- CBPR+;
- future other instant-payment connections.
A canonical internal payment model can normalize common concepts:
- debtor;
- creditor;
- accounts;
- amount;
- currency;
- remittance;
- identifiers;
- status.
A scheme adapter then applies:
- RTR mandatory fields;
- RTR code sets;
- value limits;
- participant identifiers;
- service identifiers;
- RTR-specific validation.
This is safer than making the canonical model equal to one particular pacs.008 version.
Do not flatten ISO too early
A common implementation mistake is:
ISO XML
→ generic flat table
→ internal processing
→ reconstruct ISO later.
This loses:
- party structure;
- multiple identifiers;
- structured remittance;
- agent relationships;
- original context.
Instead:
- parse into structured canonical objects;
- persist significant business elements;
- retain original controlled payload/evidence where required;
- map to downstream systems with known truncation rules.
If a legacy core supports only 140 characters of remittance, the bank should preserve the full RTR remittance in a side store/reporting service rather than permanently discard it.
Message validation layers
An RTR message can fail at several levels.
XML/schema validation
- element structure;
- data type;
- cardinality.
RTR usage validation
- required/forbidden elements;
- allowed code values;
- field relationships.
API/technical validation
- endpoint;
- authentication;
- envelope;
- message size;
- technical identifiers.
Business validation
- CAD;
- amount limit;
- participant reachability;
- account eligibility.
Risk validation
- authentication;
- fraud;
- legal/compliance.
Each layer should return its own reason category. Mixing all failures into INVALID_MESSAGE makes support and defect analysis difficult.
Business Application Header correlation
The Business Application Header and the business document should be treated as correlated but distinct artifacts.
Operations should be able to see:
- header sender;
- header receiver;
- business message type;
- creation timestamp;
- business service/version;
- payload identifier.
If a header is valid but payload is wrong, that is different from a completely malformed transmission.
Message version governance
ISO messages evolve.
For every deployed RTR version, maintain:
- scheme release name/version;
- schema package;
- companion document version;
- API specification version;
- code-set version;
- effective date;
- certification evidence.
A message generated according to last year's valid specification may become non-conformant after a standards change.
Release management should therefore compare:
- new mandatory fields;
- removed/deprecated elements;
- changed cardinality;
- new status codes;
- validation-rule changes;
- remittance changes;
- API changes.
Golden message samples
Maintain a controlled sample library.
Examples:
- valid retail pacs.008;
- valid corporate pacs.008 with structured remittance;
- direct-to-direct;
- indirect sender;
- indirect receiver;
- boundary amount;
- invalid currency;
- invalid account;
- duplicate UETR;
- receiver rejection pacs.002;
- positive settlement outcome;
- pacs.028 status request;
- admi.002 reject;
- system event messages.
Each sample should be:
- versioned;
- tied to current specification;
- validated automatically;
- readable by developers/testers/operations.
Do not use random old XML copied from another rail.
Identifier preservation
A payment can accumulate many identifiers.
The relationship should be explicit:
Customer order
→ internal payment
→ UETR
→ pacs.008 message ID
→ acceptance/status message IDs
→ settlement outcome reference
→ customer debit/credit IDs
→ return/investigation ID
A relational or event model should allow queries in both directions.
From customer debit:
find settlement.
From settlement:
find original customer authorization.
From return case:
find original pacs.008.
UETR validation
UETR handling should include:
- format validation under applicable specification;
- uniqueness before send;
- database uniqueness constraint where practical;
- retention long enough to enforce operational/history rules;
- searchable index.
The bank should not rely only on the RTR Exchange to catch duplicate UETR. Catching it locally is faster and clearer.
UETR and privacy
UETR is a transaction identifier, not a password.
Still, customer-facing systems should avoid exposing unnecessary internal data around it.
A customer may be given the UETR/reference for support, but the bank should authenticate the customer before discussing transaction details.
Settlement object separate from payment object
A robust architecture can represent settlement as a linked object.
Payment:
- customer intent;
- participants;
- amount;
- UETR;
- product;
- statuses.
Settlement:
- settlement instruction/reference;
- settlement account/agent;
- reservation;
- settlement timestamp;
- capacity impact;
- outcome.
This supports cases where the customer-payment lifecycle and settlement lifecycle progress at different speeds.
Payment Capacity versus ledger balance
Payment Capacity is a scheme settlement concept under Rule 8.
A bank should not assume:
customer deposits = settlement capacity.
Nor should it assume:
general ledger cash account balance = current real-time payment capacity.
Treasury systems need the authoritative settlement-capacity value/state.
Reserved Balance accounting
When funds are reserved in the RTR settlement process, the bank should represent the reservation distinctly from completed settlement.
Treasury view:
- available payment capacity reduced;
- reserved balance increased;
- total economic resources unchanged until settlement.
After settlement:
- reservation released/consumed as appropriate;
- sending position decreases;
- receiving position increases.
Monitoring must distinguish:
- free capacity;
- reserved;
- settled.
Otherwise an operator may see a high account balance and incorrectly assume all of it is available for new payments.
Concurrent reservations
Instant systems can create many reservations simultaneously.
Testing should include:
- several payments arriving at once near capacity limit;
- atomic reservation logic;
- no oversubscription;
- deterministic rejection/outcome.
If two CAD 60,000 payments arrive when only CAD 100,000 capacity is available, the system cannot reserve CAD 120,000 because both checked the balance before either updated it.
Concurrency is a financial-control requirement.
Indirect participant position accounting
For an indirect participant, Settlement Agent books should maintain a sub-position.
Conceptually:
Settlement Agent central RTR account
→ own participant position
→ ISP A position
→ ISP B position
→ ISP C position
The sum/sub-ledger relationship must reconcile to the central account and other relevant obligations.
An individual ISP's Net Debit Cap is a risk control, not necessarily the same as its contractual customer funds.
Net Debit Cap changes
A cap can change.
Store:
- previous cap;
- new cap;
- effective timestamp;
- approver;
- reason;
- source.
Payments before and after the change should be evaluated against the cap effective at their reservation time.
Emergency cap reduction should generate:
- participant notification;
- operational alert;
- possible product restriction.
Payment-capacity forecasting
Treasury should forecast:
- free capacity;
- pending reserved amount;
- expected incoming settlements;
- expected high-value customer flows;
- indirect-participant demand.
Forecasting is not a substitute for real-time control. It provides early warning.
A good forecast can trigger funding before the bank reaches a critical threshold.
Lynx funding evidence
RTR funding/defunding through Lynx creates a cross-system reconciliation.
Funding evidence chain:
- treasury funding instruction;
- Lynx payment;
- Bank of Canada processing;
- RTR portal/direction;
- RTR Payment Capacity increase;
- accounting entry.
Defunding chain is the reverse economic direction.
Treasury should reconcile both legs. A Lynx payment sent does not prove RTR capacity increased until the corresponding RTR evidence exists.
Funding failure
Possible failures:
- Lynx payment rejected;
- wrong amount;
- delayed processing;
- RTR portal instruction not completed;
- internal accounting missing;
- reconciliation mismatch.
The product team should not promise unlimited 24/7 capacity based on an assumption that funding is instant at all times.
Participant-to-Participant Transfers
Rule 8 includes Participant-to-Participant Transfers between direct settlement participants for Payment Capacity management.
These transfers are not customer payments.
Use a different product/event classification:
- liquidity transfer;
- treasury instruction;
- no retail customer beneficiary;
- separate approval;
- separate accounting;
- separate reconciliation.
This avoids misreporting treasury liquidity movement as customer volume.
Settlement finality and accounting finality
A central settlement can be final while internal accounting is temporarily incomplete due to system failure.
Example:
- RTR settlement completes;
- customer debit posting service fails.
The bank now has external financial settlement without completed customer accounting.
This is a high-priority reconciliation break.
The correct response is:
- preserve settlement evidence;
- repair customer accounting idempotently;
- do not attempt to reverse external settlement merely to make internal books look consistent.
Incoming finality and customer availability
Likewise:
- external settlement can complete;
- incoming core ledger can be unavailable.
Rule 6/7 determine the participant's obligations and exceptions.
The bank's incident procedure should:
- identify affected settled payments;
- track the funds-availability timer;
- invoke applicable exception procedures where relevant;
- repair posting;
- communicate accurately.
Four levels of proof
For an operations analyst, "proof" can be grouped as:
Proof of authorization
customer/entitlement evidence.
Proof of external submission
pacs.008/network evidence.
Proof of settlement
Settlement Outcome Message and settlement-account/position evidence.
Proof of customer availability
receiving ledger evidence.
Each answers a different dispute.
Finality language for customer terms
Customer terms should avoid using scheme/legal concepts without explanation.
Possible plain-language approach:
- once an instant payment is submitted, it generally cannot be cancelled;
- the payment may be rejected before settlement;
- after completion, recovery may be possible only in defined circumstances and is not guaranteed;
- customers should verify recipient details before authorizing.
Legal teams determine final wording, but product screens should align with the underlying process.
Return is a new economic event
When value is returned:
- original payment remains settled historically;
- return creates a new value movement;
- return amount may need separate accounting;
- customer reimbursement may be another event.
A clean ledger/event model might show:
Payment P1
- customer debit CAD 1,000
- RTR settlement CAD 1,000
- payee credit CAD 1,000
Return R1
- return recovered CAD 1,000
- customer re-credit CAD 1,000
Do not transform P1 into a zero-value "cancelled" record.
Partial recovery
If only part is recovered:
- original remains CAD 1,000;
- return may be CAD 600;
- customer reimbursement could be CAD 1,000 under a policy;
- bank loss/recoverable could be CAD 400.
Finance needs all amounts explicitly.
Remittance storage architecture
Rule 10's richer remittance support can require a sidecar document/data service.
The main transaction table may store:
- concise display reference;
- pointer to structured remittance object;
- remittance version/hash.
The remittance store can preserve:
- structured invoice information;
- extended content;
- related identifiers.
Access controls should prevent malicious or inappropriate content from being rendered unsafely in customer channels.
Remittance and fraud
Rich remittance is useful but can also carry untrusted content.
Controls can include:
- schema validation;
- content restrictions from the scheme;
- safe rendering;
- no executable HTML/script;
- malware/content controls where applicable;
- display truncation without data loss.
Do not directly render external remittance as trusted markup.
Data lineage
For key fields, track lineage.
Example payee account:
customer input
→ channel validation
→ canonical payment
→ pacs.008 field
→ receiver account validation
→ posting.
If a defect changes a digit in mapping, lineage helps locate where it happened.
Reconciliation layers
A mature RTR environment can use several reconciliation layers.
Message reconciliation
Every outbound pacs.008 has expected status/outcome.
Settlement reconciliation
Every settled payment maps to central/agent position change.
Customer reconciliation
Every settled outgoing payment has correct customer debit; every incoming has correct customer credit or explained exception.
Liquidity reconciliation
Settlement capacity changes align with settlement, funding, defunding and transfers.
Return reconciliation
Every accepted return/recovery maps to original and accounting.
Intraday control totals
Even with transaction-level matching, control totals are valuable.
By interval:
- count outgoing submitted;
- count outgoing settled;
- total outgoing settled;
- count incoming settled;
- total incoming settled;
- open reservations;
- returns.
Control totals can reveal a missing data feed even if individual unmatched records have not yet surfaced.
Settlement-agent control totals
For a Settlement Agent:
- own settled totals;
- each ISP totals;
- aggregate ISP totals;
- total central account movement.
These should reconcile according to the scheme/agent accounting model.
Break ageing
Instant-payment breaks should have aggressive ageing.
Categories:
- under 1 minute;
- 1–5 minutes;
- 5–30 minutes;
- over 30 minutes;
- over business-defined critical threshold.
A settlement break aged for hours is materially different from a normal batch-day reconciliation item.
Data warehouse versus operational source
A warehouse may lag.
Customer support and operations should use operational sources for current payment state.
Analytics can use replicated data later.
Do not answer a real-time customer inquiry from yesterday's warehouse extract.
Testing message ordering
Distributed systems can deliver or process related events out of order internally.
Test:
- settlement outcome reaches reconciliation before payment-hub status update;
- customer ledger event arrives before analytics copy of settlement;
- system-event notice arrives during payment processing.
Consumers should use identifiers and event sequencing, not assume database arrival order equals business order.
Testing duplicate event delivery
Event brokers often provide at-least-once delivery.
Consumers must be idempotent.
Test duplicate:
- acceptance event;
- settlement outcome;
- customer posting confirmation;
- funding event.
No duplicate journal or status corruption should result.
Testing precision and amount handling
CAD amounts need correct decimal handling.
Use decimal monetary types, not binary floating point.
Test:
- 0.01;
- typical values;
- CAD 99,999.99;
- CAD 100,000.00;
- invalid over-limit;
- zero/negative where prohibited.
Accounting and message values should remain identical.
Time and timezone handling
Store timestamps in a consistent machine representation with timezone/offset and preserve external timestamps.
Display in customer/local operational timezone as needed.
Testing should include:
- midnight;
- daylight-saving transitions;
- year-end;
- leap day;
- long weekends.
A 24/7 rail will encounter all of them without closing.
Operational evidence checklist for one settled payment
A bank should be able to assemble:
- customer authorization;
- authenticated user/device or corporate authority;
- CoP result;
- fraud assessment;
- internal payment ID;
- UETR;
- pacs.008;
- receiver pacs.002;
- reservation/payment outcome;
- settlement outcome pacs.002;
- settlement account/agent position evidence;
- customer debit;
- receiving credit evidence where accessible to the receiving bank;
- notification;
- remittance;
- reconciliation result.
Not every team sees every field, but the evidence should exist.
Operational evidence checklist for a failed payment
For a rejected/unsettled payment retain:
- customer order;
- validation result;
- UETR if created;
- message/attempt evidence;
- rejection layer;
- reason;
- customer funds release/reversal;
- customer notification;
- defect/case if bank-caused.
This proves that value did not settle and the customer was treated correctly.
Settlement and ISO 20022 design patterns
Separate data quality from scheme availability
A payment can fail because:
- the rail is unavailable;
- participant route is unavailable;
- message data is invalid;
- customer account is ineligible;
- settlement capacity is insufficient.
These should not share one generic error.
Customer:
"We cannot send this instant payment right now."
Operations:
SETTLEMENT_CAPACITY_UNAVAILABLE.
Developer:
no malformed ISO issue.
This classification improves diagnosis.
Data validation at source
The cheapest place to correct bad data is the customer/source system.
Validate before ISO construction:
- required account format;
- amount precision;
- CAD currency;
- mandatory payee;
- remittance size;
- supported characters/content;
- participant routing.
The RTR gateway should still validate the final message, but it should not become the first line of business-data quality.
Corporate API contracts
Corporate APIs can expose business-friendly fields rather than raw ISO XML.
Example:
- debtorAccount;
- creditorAccount;
- creditorName;
- amount;
- currency;
- invoiceReferences;
- clientPaymentId.
The bank maps this to pacs.008.
Benefits:
- stable customer API;
- centralized scheme mapping;
- easier standards upgrades.
Advanced corporate customers may use ISO-native APIs/files where supported, but the bank still validates against current RTR usage rules.
Field-level lineage for support
For critical elements maintain lineage:
Customer creditor account
→ API request path
→ canonical field
→ pacs.008 element
→ receiver validation
→ payee posting.
If receiver rejects for account reason, support can determine whether the customer entered bad data or bank mapping corrupted it.
Remittance reconciliation example
Customer pays CAD 24,750 covering:
- Invoice 101: 7,500
- Invoice 102: 9,250
- Invoice 103: 8,000
The payment principal remains one CAD 24,750 obligation.
Structured remittance can describe the invoice allocation.
The receiving company can:
- receive payment;
- receive structured remittance;
- match invoices;
- post cash application;
- report exceptions if allocation does not reconcile.
Do not create three settlement obligations merely because there are three invoices unless the customer actually instructed three payments.
Message reject versus payment reject
An admi.002 message reject and a receiving-participant payment rejection are not the same.
Message reject
technical/application message was not accepted as a valid processable message.
Payment rejection
the business payment was processed to a decision and rejected under the payment flow.
Operations screens should display the layer.
A message reject may require technical repair. A payment rejection may require customer correction or a new payment instruction.
System event handling
admi.004/admi.011 system-event messages support operational coordination.
A participant should:
- validate and authenticate the event;
- correlate to system/service context;
- alert operations;
- acknowledge as required;
- apply operational procedure;
- retain evidence.
System events should not be mixed into customer payment history as though they were payment statuses.
Settlement instruction source
The settlement system can receive instructions from approved sources under the rules.
Record:
- source type;
- source identifier;
- related payment/UETR where applicable;
- amount;
- participants;
- settlement timestamp.
This helps treasury distinguish customer-payment settlement from liquidity/other approved settlement activity.
Direct participant reconciliation example
Outgoing payment CAD 12,000:
Customer ledger:
Payment:
- UETR U1;
- settled CAD 12,000.
Settlement:
- Bank RTR position decreases CAD 12,000.
Reconciliation:
If customer debit = 12,000 but settlement = 0:
- external settlement break.
If settlement = 12,000 but customer debit = 0:
- internal accounting break.
If two customer debits = 24,000 but one settlement = 12,000:
Indirect participant reconciliation example
PSP sends CAD 4,000.
PSP:
- customer debit CAD 4,000;
- payment UETR U2;
- sponsored position decreases CAD 4,000.
Settlement Agent:
- ISP sub-ledger for PSP decreases CAD 4,000;
- central settlement account decreases according to aggregate settlement.
Both parties need evidence.
A settlement-agent statement alone may not contain the customer's account information. The PSP must correlate through participant/payment identifiers.
Reservation reconciliation
Reservations are temporary financial states.
Monitor:
- reservation created;
- linked UETR;
- amount;
- reservation timestamp;
- outcome;
- release/consume timestamp.
An aged reservation with no payment outcome can strand capacity.
Create alerts for:
- reservation older than expected service-level threshold;
- reservation with missing payment;
- settled payment with reservation still open;
- released reservation but payment marked pending.
Liquidity stress test
Assume:
- opening free capacity CAD 20m;
- outgoing surge CAD 18m;
- expected incoming CAD 10m delayed;
- indirect participant needs CAD 5m;
- funding route temporarily unavailable.
The bank needs a policy before this occurs.
Possible controlled actions:
- restrict selected products;
- reduce internal limits;
- prioritize according to approved policy;
- escalate treasury;
- communicate outage.
The scheme rules determine what actions are allowed; the bank's liquidity plan determines how early it reacts.
Settlement capacity is not a credit facility
Unless specific arrangements say otherwise, banks should not treat the RTR settlement account as an unlimited overdraft resource.
Payment release must respect actual capacity and approved rules.
For indirect participants, the Settlement Agent's Net Debit Cap is also a hard risk constraint in the settlement design.
Funding thresholds
Treasury can define:
- target capacity;
- minimum operational buffer;
- early-warning threshold;
- emergency threshold.
Thresholds should vary by:
- time of week;
- customer volume;
- sponsored participant demand;
- anticipated events.
A static threshold designed from weekday averages may fail on long weekends.
Accounting journal design
Exact accounts differ by institution, but requirements should identify economic meaning.
Sending side may need journals for:
- customer funds reservation;
- customer debit;
- RTR settlement asset/position;
- fee income;
- rejection reversal;
- returned value;
- customer reimbursement.
Receiving side:
- RTR settlement asset/position;
- customer credit;
- exception/suspense if funds cannot be made available;
- return.
Avoid embedding the settlement lifecycle only in memo fields.
Suspense accounts
If an external settlement cannot immediately be posted to the intended customer due to a valid exception or technical issue, a controlled suspense/holding account may be needed according to bank accounting design.
Controls:
- linked UETR;
- reason;
- owner;
- age;
- expected resolution;
- daily review;
- no unidentified balance.
A generic payments suspense that accumulates unmatched instant transactions undermines the real-time control model.
Return accounting
When a return is received:
- identify original UETR/payment;
- book returned value;
- determine customer re-credit;
- handle fees/loss under policy;
- close/partially close case.
If original customer was already reimbursed:
- returned funds may reduce bank recoverable/loss, not create another customer credit.
Cross-system precision
Use exact decimal monetary types consistently in:
- API;
- canonical model;
- ISO;
- fraud;
- settlement;
- ledger;
- reconciliation.
A binary float rounding difference of one cent can prevent exact transaction matching.
Audit of manual journal adjustments
Manual accounting corrections should require:
- reason;
- source payment/UETR;
- operator;
- approver where required;
- amount;
- affected accounts;
- timestamp.
Never "fix reconciliation" by posting an unexplained journal that loses connection to the payment.
Performance and persistence trade-off
Real-time systems sometimes avoid durable writes to reduce latency.
For financial state, durability wins over a few milliseconds.
Critical events to commit durably include:
- payment identity/UETR;
- authorization/risk decision;
- external submission;
- settlement outcome;
- customer posting.
Caches can accelerate reads, but the recovery source must survive process/node failure.
Event replay safety
If rebuilding state from an event log:
- every event has stable ID;
- consumers are idempotent;
- ordering rules exist;
- duplicate replay cannot create financial postings.
Test full replay in non-production.
Data retention by purpose
Different records can have different legal/business retention requirements.
Categories:
- payment message;
- customer authorization;
- fraud evidence;
- accounting;
- operational log;
- remittance;
- case communication.
Data governance should define authoritative retention rather than keeping everything forever or deleting useful evidence too early.
Operational access controls
Not every role should see:
- full customer data;
- fraud score;
- remittance;
- settlement account;
- sensitive beneficiary details.
Use role-based access and purpose-based views.
Operations can investigate payment state without necessarily seeing internal model features.
Production metrics for ISO and settlement
Useful metrics include:
ISO/data
- schema rejects;
- usage-rule rejects;
- top invalid fields;
- duplicate UETR.
Status
- receiver acceptance rate;
- rejection code distribution;
- pacs.028 rate;
- missing/late outcome.
Settlement
- reservation success;
- settlement success;
- capacity utilization;
- aged reservations;
- sponsored NDC utilization.
Posting
- settlement-to-credit latency;
- Rule 7 exception rate;
- posting failures.
Reconciliation
- unmatched payment;
- unmatched settlement;
- unmatched ledger;
- open returns.
Standards release regression
A release test should cover:
- all golden messages;
- all reject paths;
- exact field mappings;
- remittance;
- status correlation;
- operations screens;
- archive/replay;
- reporting.
A message change can break an operations parser even when the gateway remains schema-valid.
Documentation ownership
Maintain three complementary documents:
Business operating model
what the payment means and who owns each state.
Message mapping
canonical fields to current ISO/API.
Operational runbook
what to do when outcomes are missing, settlement breaks or posting fails.
One giant technical document becomes stale quickly.
Practitioner review questions
Before signing off a design ask:
- Can we explain every pacs.002 by context?
- Can we prove settlement separately from message acceptance?
- Can we reconcile an indirect participant to its Settlement Agent?
- Can we recover after a crash without changing UETR?
- Can we preserve full remittance even if the core is narrow?
- Can we identify an aged reservation?
- Can we prove the 60-second receiving credit requirement?
- Can a return be linked without overwriting the original?
- Can we replay events without duplicate money movement?
If any answer is no, the solution is not yet bank-grade.
Settlement evidence and accounting design
The settlement layer should be built as an auditable financial sub-ledger, not as a collection of transient API responses.
Settlement evidence record
For every settled payment, persist a record containing:
- UETR;
- internal payment ID;
- amount;
- sending participant;
- receiving participant;
- sending Settlement Agent where applicable;
- receiving Settlement Agent where applicable;
- reservation/outcome references;
- settlement timestamp;
- Settlement Outcome Message reference;
- settlement-account/position impact;
- reconciliation status.
This is the bridge between ISO messages and accounting.
Reservation lifecycle
A reservation should have an explicit lifecycle:
CREATED
→ ACTIVE
→ CONSUMED_BY_SETTLEMENT
or
CREATED
→ RELEASED_WITHOUT_SETTLEMENT
Monitor for impossible or aged conditions:
- settled payment with ACTIVE reservation;
- released reservation with payment still marked settlement pending;
- reservation with no related UETR;
- reservation older than service-level expectation.
Aged reservations can strand liquidity and create false capacity views.
Payment Capacity dashboard
Treasury needs real-time measures such as:
- available Payment Capacity;
- Reserved Balance;
- utilization percentage;
- largest pending outgoing payments;
- projected next-hour demand;
- indirect participant positions;
- Net Debit Cap utilization;
- latest successful funding/defunding;
- critical threshold.
The dashboard should show trends, not only current balance.
Funding bridge reconciliation
Funding through Lynx should reconcile as a cross-system chain:
Treasury instruction
→ Lynx payment
→ Bank of Canada processing
→ RTR capacity update
→ internal treasury ledger.
A missing last step means the bank has sent liquidity but cannot yet rely on increased RTR Payment Capacity.
Defunding requires the reverse control.
Direct and indirect accounting
A direct participant can reconcile:
customer/payment ledger
↔ RTR settlement record
↔ Bank of Canada RTR settlement account.
An indirect participant adds:
customer/payment ledger
↔ participant payment record
↔ sponsored position with Settlement Agent.
The Settlement Agent separately reconciles:
Bank of Canada RTR settlement account
↔ own obligations
↔ every indirect participant sub-position.
Both parties need consistent end-of-period evidence.
Accounting event examples
Outgoing settlement can generate:
- customer debit or conversion of pre-send reservation;
- settlement asset/cash movement;
- fee entry if product charges separately.
Incoming settlement can generate:
- settlement asset/cash movement;
- customer credit;
- suspense/exception entry if Rule 7 treatment prevents immediate normal posting.
A return creates a new event; never rewrite the original settlement journal.
ISO message archive
Store the authoritative message representation required by the bank's policy plus:
- specification version;
- business-purpose classification;
- related UETR;
- payload/hash;
- received/sent timestamp.
This makes a future standards upgrade auditable.
pacs.002 context classification
Because pacs.002 has multiple roles in RTR, store purpose explicitly.
Examples:
- RECEIVER_ACCEPTANCE_STATUS;
- SETTLEMENT_OUTCOME.
Do not infer purpose only from file location or timing.
Operations screens should display:
"Receiver accepted"
versus
"Settlement confirmed."
pacs.028 monitoring
Status inquiry is a health signal.
Track:
- number of pacs.028 requests;
- trigger reason;
- participant;
- age of original payment;
- final resolution.
A sudden spike can indicate:
- delayed settlement outcomes;
- network instability;
- correlation defect;
- participant performance issue.
admi messages
admi.002, admi.004 and admi.011 are operationally important even though they do not move customer value.
Monitor:
- message rejects by reason;
- heartbeat/event health;
- missed acknowledgements.
An admi.002 spike after a release often signals a standards or mapping defect that can affect large volume quickly.
Data-quality KPIs
Measure:
- ISO validation reject rate;
- top invalid fields;
- UETR duplicate attempts;
- remittance truncation in internal downstream systems;
- missing participant/routing data;
- manual repair rate;
- reporting-reference match rate.
The goal of ISO 20022 is not XML compliance alone; it is usable, preserved business data.
Finality evidence package
When a customer or auditor asks whether a payment completed, the bank should assemble:
- customer authorization;
- pacs.008/UETR;
- receiving acceptance;
- reservation/payment outcome;
- Settlement Outcome Message;
- settlement-account/agent-position evidence;
- customer debit/credit;
- statement/reporting line;
- reconciliation result.
This avoids treating one message as proof of the entire lifecycle.
Legal/finality wording
Product and operations teams should agree approved wording.
"Settlement is final" refers to the scheme settlement event.
"The beneficiary has the funds" requires evidence from the receiving-side account process.
"A return was requested" does not mean original finality disappeared.
Precise wording protects both customers and operations.
Stress scenario
Assume a direct participant has:
- CAD 15m free Payment Capacity;
- CAD 12m reserved;
- CAD 6m additional customer payments queued;
- expected CAD 5m incoming delayed;
- Lynx funding window constrained.
The nominal account resources may look large, but free capacity for new payments is limited.
Treasury needs controls that react before customer-facing failures appear.
Accounting close in a 24/7 rail
A continuous rail still needs accounting periods.
The bank should:
- keep processing while accounting date rolls;
- tag events with settlement timestamp and accounting business date;
- reconcile late/early period entries;
- keep unresolved breaks visible;
- avoid using "end of day" as a reason to pause payment processing.
Continuous processing and controlled financial close must coexist.
Scheme-version change
When Payments Canada updates RTR message specifications:
- compare schemas/usage rules;
- identify canonical-model impact;
- update mappings;
- run golden-message regression;
- test operations parsing;
- test archive/replay;
- certify before effective date.
A standards change can break reconciliation even if payments still settle, so end-to-end testing is mandatory.
Message-to-ledger control matrix
A bank-grade RTR design can express the relationship between message events and financial events explicitly.
| External/business event | Settlement meaning | Customer accounting expectation |
|---|
| pacs.008 submitted | none yet | reservation may exist; do not call settled |
| receiver pacs.002 accepted | receiver decision only | no settlement proof |
| positive payment outcome | settlement instructed/expected | continue controlled processing |
| Settlement Outcome pacs.002 | settlement occurred | outgoing debit/incoming credit must reconcile |
| Rule 7 exception | settlement may already exist | use controlled suspense/availability treatment |
| return/recovery | new linked value event | separate re-credit/recovery accounting |
This matrix should be embedded into requirements, operations training and reconciliation design.
Settlement-agent data lineage
For an indirect participant, the payment should retain:
- indirect participant;
- Settlement Agent;
- Settlement Agent relationship version;
- NDC context;
- settlement-account reference available to the agent;
- ISP position effect.
If the agent changes later, the old payment must still resolve to the historical relationship.
Reconciliation control totals
In addition to transaction matching, calculate periodic control totals:
- count/value submitted;
- count/value settled outgoing;
- count/value settled incoming;
- open reservations;
- returns;
- funding/defunding;
- P2P liquidity transfers where applicable.
A missing feed can be detected quickly when totals diverge, even before individual breaks are investigated.
Data preservation versus customer display
Not every ISO element belongs on a customer statement, but losing it internally is different from choosing not to display it.
Define three layers:
authoritative received/sent message data
preserve according to policy.
canonical operational data
fields needed by payment, fraud, investigation and reconciliation.
customer display data
clear subset appropriate for channel/statement.
This prevents screen constraints from silently reducing the bank's evidence.
Standards-change operational test
After an ISO/specification release, operations should test its screens and cases as well as developers testing XML. Confirm that new reason codes, identifiers and message versions are searchable and readable in the investigation desktop; otherwise a technically successful standards upgrade can still degrade support.
Settlement data model and reconciliation case study
A settlement record should allow finance and operations to reconstruct the same payment independently.
Suggested settlement record
Important attributes include payment ID, UETR, direction, amount, sending and receiving participants, Settlement Agents where applicable, reservation reference, Settlement Outcome reference, settlement timestamp, customer posting reference, reconciliation status and any later return-case link.
Do not store the entire lifecycle only in one mutable status string.
Case study — direct participant outgoing payment
A customer instructs CAD 18,000.
The bank reserves customer funds, creates payment P100 and UETR U100, sends pacs.008, receives the receiver decision, obtains the required settlement reservation, receives the Settlement Outcome, converts the customer reservation into a debit and reconciles external settlement to the customer ledger.
Expected evidence is straightforward: customer debit CAD 18,000, settled amount CAD 18,000, UETR U100 consistently linked, no stale reservation and reconciliation status MATCHED.
Break A — settled but customer debit missing
External settlement says CAD 18,000 settled while the customer account shows no final debit. This is not a scheme failure. It is an internal accounting break with financial exposure. The bank should prevent external resend, repair the customer/accounting event idempotently, retain original settlement evidence and escalate according to financial-control severity.
Break B — customer debit but no settlement
If the customer was debited but the external payment was rejected before settlement, the bank must release or recredit under controlled accounting, explain that settlement did not occur and investigate why accounting ran too early if that contradicts the intended design.
Case study — indirect participant
PSP A sends CAD 6,000 through Settlement Agent B.
PSP A records the customer debit, payment/UETR and sponsored settlement position. Agent B records PSP A's sub-ledger movement and the central RTR settlement-account movement.
The central account entry alone does not identify PSP A's customer. The participant sub-ledger and payment identifiers provide that linkage.
Settlement Agent control
The Settlement Agent should reconcile the Bank of Canada RTR account to its own activity, aggregate indirect-participant movements and other permitted settlement/liquidity events. A sponsored sub-ledger mismatch is a financial-control break even if customer payments appear successful.
Return case
If CAD 6,000 later returns, keep the original settlement history unchanged. Create a linked return with the original UETR, reason, amount recovered and new accounting references. If the customer was already reimbursed, recovered funds reduce bank loss or recoverable rather than crediting the customer twice.
Reconciliation SLA
Run transaction-level matching continuously, alert immediately on settled-but-unposted items, monitor aged reservations, perform intraday position controls and close accounting control totals without stopping the 24/7 rail.
Audit reconstruction test
Select a historical payment and reconstruct customer instruction, UETR, messages, settlement, ledger, reporting and reconciliation without asking a developer to search production logs. If that is not possible, the evidence model is incomplete even when the live payment succeeded.
11. Practical settlement and finality scenarios
The following are fictional teaching examples with illustrative amounts. They describe the approved RTR rules and a possible bank implementation; they are not reports of live RTR production transactions.
Example 1 — pacs.002 acceptance misread as settlement
Receiver sends acceptance pacs.002.
Sending channel marks payment "settled."
This is wrong.
Acceptance says the receiver accepted the message. Settlement outcome comes later.
Example 2 — message submitted, customer asks to cancel
pacs.008 has entered the RTR Exchange.
Customer calls immediately.
Rule 6 prevents the Sending Participant from cancelling/revoking/amending the submitted message.
The bank explains the process and, if the facts fit a Rule 7 reason, may use the Rule 7 Payment Return Request process rather than pretending the original can be recalled. A Sending Participant may initiate one such request within 60 calendar days from the date the RTR Payment Message was exchanged; the Receiving Participant normally responds within 10 calendar days, with a possible extension of no more than 30 calendar days.
Example 3 — direct participant low capacity
Bank has CAD 70,000 Payment Capacity.
It attempts an outgoing CAD 80,000 eligible RTR payment.
Customer has enough deposit funds, but settlement capacity is not enough.
Customer balance and settlement capacity are different controls.
Example 4 — indirect participant cap
PSP has customer funds and its Settlement Agent has overall capacity.
But PSP's ISP Net Position would breach the agent-set Net Debit Cap.
Settlement cannot proceed as though the cap did not exist.
Example 5 — weekend funding plan
Bank forecasts weekend outgoing peak of CAD 60 million.
It cannot depend on a manual Monday-morning top-up.
Treasury prefunds and sets thresholds based on the Bank/Lynx funding arrangements.
Example 6 — payee ledger timeout
Settlement outcome arrives.
Receiving core ledger times out.
Operations must determine whether:
- credit actually posted but response was lost;
- credit failed;
- Rule 7 event-beyond-control process applies.
Blindly posting again risks duplicate credit.
Example 7 — remittance preservation
pacs.008 contains structured invoice data.
Gateway maps it into a 140-character legacy field and discards the rest.
Payment settles, but the supplier cannot reconcile.
Technically successful, operationally degraded.
The correct architecture preserves the structured data end-to-end.
Example 8 — permitted return
Payment settles and is credited.
Later a valid fraud case meets Rule 7 handling.
A return is initiated.
Reconciliation keeps:
- original payment settled;
- original UETR;
- return reason;
- recovery amount;
- customer reimbursement.
It does not rewrite original status to "never happened."
12. Key takeaways and authoritative references
ISO 20022, settlement and finality are different layers of one RTR payment.
The published RTR ISO set intended for go-live includes head.001, pacs.008, pacs.002, pacs.028, admi.002, admi.004 and admi.011. pacs.008 is the payment item. pacs.002 supports acceptance/status and the Settlement Outcome Message according to context. pacs.028 supports status inquiry. The published specifications were last updated 30 May 2025, so implementation teams must verify the version in force before certification.
UETR is required and should become a persistent cross-system key. It links processing, duplicate controls and Rule 7 investigation/return processes.
Under the approved model, settlement occurs through Bank of Canada RTR Settlement Accounts for direct participants or through Settlement Agents for indirect participants. Rule 8 manages payment capacity, reservation and settlement. Funding and defunding connect RTR accounts to Lynx under Bank procedures. At this audit date those are launch-model capabilities, not evidence of live production processing.
The effective rules state that once submitted to the Exchange, the RTR Payment Message is not cancellable/revocable/amendable by the sending participant. Settlement outcome confirms that settlement occurred. When the RTR launches, the receiving participant must then make funds available promptly and within 60 seconds, subject to Rule 7 exceptions. Later permitted recovery does not erase original settlement.
The practitioner rules are:
- map ISO according to RTR specifications, not another scheme;
- preserve structured data rather than flattening it;
- use UETR as a lifecycle key but keep internal/customer identifiers too;
- separate payment message from settlement obligation;
- monitor payment capacity and reserved balance in real time;
- model Settlement Agents and ISP positions explicitly;
- distinguish irrevocable submission, settlement and payee finality;
- prove funds-availability timing with receiving-ledger evidence;
- keep returns as linked events, not status rewrites;
- reconcile message, central settlement and customer accounting continuously.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.