RTR End to End Payment Lifecycle. Follow the intended instant credit-transfer journey from customer authorization through validation, exchange, response and posting.
Block 12 · Chapter 58 of 75
Release status (audited 2026-10-05): planned RTR target flow, not a current production transaction. Payments Canada’s current launch page schedules RTR launch for Q4 2026, with sequenced onboarding: initial direct-to-Exchange participants in Q4 2026, initial Interac e-Transfer Clearing and Settlement migration participants in Q1 2027, and additional migration participants in Q2 2027. Testing and participant assurance are still in progress. The approved Rules and By-law are in force from August 24, 2026, but that legal framework is not evidence that live customer payments are already available. Use “will/must under the approved Rules” for scheme behavior and “bank should/may” for institution-specific design.
Source labels used in this chapter: Rule/By-law means a Payments Canada or federal legal requirement; scheme specification/procedure means a controlled Payments Canada technical or operational document; bank implementation means a design pattern, not a universal mandate; Example means a fictional test case, not a production statistic or named institution.
A Real-Time Rail payment should never be described as one API call that "moves money instantly." It is a controlled sequence of customer, fraud, message, participant, settlement and ledger events. The sequence matters because each stage answers a different question.
A customer can authorize a payment that is never submitted. A pacs.008 can be submitted but rejected by the RTR Exchange. The receiving participant can reject an otherwise well-formed message. The receiving participant can accept but settlement capacity can prevent a positive payment outcome. Settlement can occur while the receiving bank still has to complete the final payee-credit step. A settled payment can later enter a Rule 7 return or recovery process without changing the historical fact that the original payment settled.
The approved 2026 Rules provide a precise lifecycle. Rule 6 identifies pacs.008 as the RTR Payment Message. The sending participant authenticates the payor and uses Central Fraud Services as required. The Exchange validates the payment. The receiving participant sends a pacs.002 Payment Acceptance Status Message accepting or rejecting. A positive Payment Outcome Report depends on receiving-participant acceptance and confirmation that settlement funds have been reserved. The Exchange then directs RTR Clearing and Settlement to implement the Settlement Instructions. After settlement, the Exchange sends a pacs.002 Settlement Outcome Message to both participants. Subject to Rule 7 exceptions, the receiving participant must make funds available to the payee promptly and no later than 60 seconds after receiving that settlement outcome.
This chapter treats every transition as an auditable business event. That approach is essential for architects designing idempotency, business analysts writing requirements, developers mapping messages, testers creating negative scenarios, operations teams investigating uncertain payments and reconciliation teams proving that external settlement agrees with both customer ledgers.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- trace an RTR payment from customer intent to final payee funds availability;
- distinguish customer authorization, payment creation, Exchange submission and Exchange validation;
- explain why payor authentication and fraud decisioning occur before releasing the payment message;
- identify the mandatory business information required for the pacs.008 at rule level;
- explain how UETR supports identity and duplicate control;
- explain the receiving participant's pacs.002 acceptance/rejection decision;
- distinguish participant acceptance from the Payment Outcome Report;
- explain the role of Rule 8 funds reservation and payment capacity;
- describe the transition from positive payment outcome to settlement instruction;
- explain how RTR Clearing and Settlement makes the account entries;
- identify the pacs.002 Settlement Outcome Message as evidence that settlement occurred;
- explain the 60-second payee funds-availability requirement and Rule 7 exceptions;
- model an uncertain outcome safely using status inquiry rather than blind retry;
- explain why a submitted RTR payment cannot be cancelled, revoked or amended by the sending participant;
- distinguish a rejection before settlement from a return/recovery after settlement;
- explain the Payment Return Request case-management timelines;
- design payment states and customer-facing statuses without overstating certainty;
- reconcile one RTR payment across message, settlement, customer posting and exception evidence;
- create positive, negative, timeout, duplicate and resilience test scenarios.
For a focused core session, spend about 10 minutes on Sections 1–2, 20 minutes on Sections 3–6 and the interaction-flow diagram, 10 minutes on Sections 7–8, 10 minutes on Sections 9–10, 5 minutes on the scenarios and 5 minutes on the practitioner rules.
Chapter navigator
- The lifecycle as a chain of state transitions
- Customer initiation, authentication and pre-send controls
- Creating and submitting the pacs008
- Exchange validation and receiving-participant decision
- Reservation, Payment Outcome and settlement direction
- Settlement and the Settlement Outcome Message
- Payee posting, customer communication and accounting
- Uncertain outcomes, status requests and duplicate prevention
- Rejections, exceptions, returns and recovery
- Reconciliation, observability and test design
- Practical lifecycle scenarios
- Key takeaways and authoritative references
1. The lifecycle as a chain of state transitions
The safest way to model instant payments is to ask what evidence exists at every point.
A bank should be able to answer:
- Did the customer create the intent?
- Was the customer authenticated?
- Did the customer confirm the final payee/amount?
- Did confirmation of payee run?
- What fraud assessment was received?
- Did the bank approve the payment?
- Was a pacs.008 created?
- Was it submitted to the RTR Exchange?
- Did the Exchange accept it for processing?
- Did the receiving participant accept or reject it?
- Were settlement funds reserved?
- Was a positive Payment Outcome Report produced?
- Was settlement implemented?
- Was a settlement outcome received?
- Did the receiving participant credit/make funds available to the payee?
- Was any exception or return initiated?
Each answer maps to a durable event.
Why one "success" flag is dangerous
Consider a boolean field named successful.
What does true mean?
- channel submitted?
- bank accepted?
- RTR Exchange accepted?
- beneficiary participant accepted?
- funds reserved?
- settled?
- beneficiary credited?
If different applications use different meanings, operations will provide incorrect information to customers.
A stronger payment object uses explicit states and timestamps.
Example:
| State | Evidence |
|---|
| AUTHORIZED | customer authentication + authorization record |
| RISK_APPROVED | bank decision + central fraud assessment |
| SUBMITTED | network/Exchange submission evidence |
| RECEIVER_ACCEPTED | acceptance pacs.002 |
| FUNDS_RESERVED | Rule 8 reservation outcome |
| PAYMENT_OUTCOME_POSITIVE | RTR Exchange outcome event |
| SETTLED | settlement outcome pacs.002 |
| PAYEE_AVAILABLE | receiving-bank ledger/customer event |
| REJECTED | rejection evidence + reason |
| EXCEPTION | Rule 7 case |
| RETURN_PENDING | return/return-request case |
| RETURNED | recovery/return value evidence |
Customer-facing wording can be simpler, but operations needs the richer model.
Economic payment identity
One economic customer instruction should retain one stable internal payment ID.
The UETR is an external end-to-end transaction reference required in the RTR payment message. It should be linked to, not used as a replacement for, the bank's customer order and accounting identifiers.
Useful identity hierarchy:
- customerOrderId;
- paymentInstructionId;
- internalPaymentId;
- UETR;
- message technical ID;
- settlement reference;
- return/case ID.
This separation makes retries safe.
2. Customer initiation, authentication and pre-send controls
The fastest possible payment is still a controlled payment.
Customer intent
The initiation layer collects:
- debit account;
- amount;
- payee;
- payee account/routing information;
- remittance;
- requested product/service;
- customer acknowledgement.
Under the approved RTR Rules, the RTR Payment Obligation must be in Canadian dollars. That is a scheme constraint for the planned service, not a claim that RTR is already a live production route. The bank should identify currency before route selection.
Authentication
Rule 6 requires the sending participant to ensure that the payor has been authenticated. Rule 13 requires capability to use industry best practices for MFA or equivalent and to use it to authenticate the payor prior to initiating an RTR Payment Message.
The architecture should distinguish:
login authentication
proves access to the channel.
transaction authentication/authorization
proves authority for this payment under the bank's policy.
A session authenticated six hours ago may not be enough for a high-risk new-beneficiary payment. The bank's risk policy determines step-up requirements.
Corporate entitlement
For corporate customers, the authorization problem is richer.
A company may require:
- maker/checker;
- two signatories;
- account-level payment entitlement;
- per-user limit;
- company limit;
- API certificate plus user approval;
- scheduled release.
The final authorized customer intent should be frozen before the bank creates the RTR message.
Confirmation of payee
Rule 13 requires each Sending Participant to implement Confirmation of Payee using Central Confirmation of Payee or an Association-registered and approved third-party service. It runs before message submission. The Sending Participant must also give the Payor the choice to proceed regardless of the result and outline the risks of proceeding. The service and customer choice are scheme requirements; the exact UX, risk treatment and evidence model are bank-specific.
The bank should store:
- input payee name;
- account/routing data;
- response classification;
- displayed name/result where permitted;
- customer warning;
- customer decision to proceed;
- timestamp/version;
- fraud-decision linkage.
A mismatch does not automatically mean fraud, and a match does not prove legitimacy.
Central Fraud Analytics and participant controls
Rule 13 requires Central Fraud Analytics for each RTR Payment Message. Before introducing the message to the RTR Exchange, the sending participant receives a Fraud Assessment and decides whether to send using that assessment and other relevant information.
That makes fraud part of the payment critical path.
Participant logic can combine:
- central fraud score/recommendation;
- device risk;
- account takeover signals;
- customer behaviour;
- beneficiary history;
- velocity;
- amount;
- geolocation consistency;
- mule indicators;
- customer/product risk.
Balance and limits
Pre-send checks should include:
- customer available balance;
- account status;
- product eligibility;
- customer daily/per-payment limit;
- service limit;
- RTR CAD 100,000 Exchange limit;
- RTR Clearing and Settlement CAD 100,000 value limit (distinct from the Exchange limit; Participant-to-Participant Transfers are exempt from that clearing-and-settlement limit);
- receiving-participant reachability.
The customer debit design is bank-specific. Some banks may place an internal hold/reservation before external submission to prevent the customer spending the same funds elsewhere. Whatever model is chosen must reconcile to the external settlement outcome.
3. Creating and submitting the pacs.008
Rule 6 makes the FIToFICustomerCreditTransfer pacs.008 the payment item acceptable for exchange through the RTR Exchange.
Required rule-level information
The Rule requires relevant specification fields including:
- amount of the RTR Payment Obligation;
- payee account number;
- sending-participant institution number;
- receiving-participant institution number;
- UETR;
- Connection Service Provider Identifier;
- Competitive Service Identifier.
The detailed ISO 20022 specification contains the exact element definitions and technical constraints. Payments Canada’s public ISO page identifies its latest posted specification set as updated May 30, 2025; requirements should link to the participant-controlled/current version and companion document rather than reproducing a stale schema inside a Jira story.
UETR
The UETR is a required unique transaction identity.
Rule 6 states a sending participant must not send an RTR message containing a UETR identical to one already assigned to another message. A UETR used by another RTR Payment Message sent to the Exchange in the previous 90 calendar days is rejected as duplicate.
This means:
- generate once per economic payment;
- persist before network transmission;
- never regenerate merely because the first response is delayed;
- search by UETR in operations;
- retain UETR in reconciliation and cases.
CAD and value limit
The RTR Payment Obligation must be Canadian dollars.
The Exchange Value Limit is CAD 100,000.
If the customer instruction is CAD 100,001, the bank should stop/reroute before sending.
If the customer product limit is CAD 25,000, an instruction for CAD 30,000 should fail at the product layer even though it is below the scheme maximum.
International-EFT boundary
Rule 6 section 10 creates a dated reporting boundary: effective September 30, 2027, a Sending Participant must identify an RTR Payment Message that fulfils an international electronic funds transfer by populating INTL 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. “CAD” therefore does not by itself mean “domestic”; classify the payment against the current Proceeds of Crime (Money Laundering) and Terrorist Financing Regulations and FINTRAC guidance before routing. Do not add an international-RTR route or reporting deadline that is not supported by the then-current Rule, companion document and applicable law.
ISO and API validation
Rule 6 requires format compliance with:
- RTR ISO 20022 Message Specifications;
- RTR Exchange API Specification;
- RTR ISO 20022 Message Specifications Companion Document.
Banks should have validation at multiple levels:
- schema/technical format;
- RTR usage rules;
- API envelope/security;
- business data;
- reference/reachability;
- risk and product rules.
A message being XML-valid does not mean it is business-valid.
Submission is an irrevocability boundary
Rule 6 states that once an RTR Payment Message is submitted to the RTR Exchange, it cannot be cancelled, revoked or amended by the Sending Participant.
The bank should make this boundary explicit in UX and state management.
Before submission:
- customer/bank may still cancel under product design.
After submission:
- do not pretend a local "cancel" can retract the message;
- use the defined exception/return/recovery processes if a problem is discovered.
This is a critical difference from queued batch payments.
4. Exchange validation and receiving-participant decision
The RTR Exchange validates the incoming payment against the rule and technical requirements.
If required conditions are not met, the message is rejected.
Receiving-participant pacs.002
After receipt of the RTR Payment Message, the receiving participant sends a Payment Acceptance Status Message, pacs.002, within the timing set by the RTR Service Level Description.
The message confirms acceptance or rejection.
Rule 6 lists rejection reasons including:
| Context | Rule code/example |
|---|
| Duplicate | DUPL |
| RTR value limit exceeded | AM02 |
| Invalid account / restrictions described by rule | AC01 |
| Wrong currency | AC09 |
| Incorrect format | FF01 |
| Malicious/harmful content | RR07 |
| Other permitted reason | NARR |
The exact ISO mapping must follow the current specification.
Receiving account validation
The receiver should not accept first and only later discover basic account eligibility.
Pre-acceptance checks can include:
- account format;
- account exists/eligible;
- account can receive direct deposit;
- CAD account handling;
- restrictions that require rejection;
- malicious-content indicators.
Some legal restrictions and exceptions can still be handled after settlement under Rule 7, so the lifecycle needs both pre-settlement rejection and post-settlement exception states.
Acceptance cannot be changed
Rule 6 states that once the Payment Acceptance Status Message is received by the Exchange, it cannot be changed or revoked by the receiving participant.
That makes acceptance a controlled business decision.
Interaction flow
The sequence is intentionally more than pacs.008 followed by "OK."
A positive path requires:
- message;
- receiver acceptance;
- settlement capacity;
- outcome;
- settlement;
- settlement outcome.
5. Reservation, Payment Outcome and settlement direction
The receiving participant's acceptance is necessary but not sufficient for a positive payment outcome.
Settlement capacity reservation
Rule 8 provides for reservation of funds.
When reservation applies, RTR Clearing and Settlement reserves an amount equal to the RTR Payment Obligation from the sending side's payment capacity.
For a direct sending participant, this affects its own Settlement Account.
For an indirect participant, it affects the Settlement Agent's account and the indirect participant's position, subject to the Net Debit Cap.
Why reservation matters
Without reservation, a bank could accept many payments whose aggregate value exceeds available settlement capacity.
Reservation creates a controlled bridge between:
- message acceptance;
- settlement feasibility.
Treasury and payment operations should monitor:
- current payment capacity;
- reserved balance;
- failed reservations;
- sponsored participant positions.
Positive Payment Outcome Report
Rule 6 states that the RTR Exchange sends a positive Payment Outcome Report to both participants indicating that the payment obligation will be settled when:
- the receiving participant's acceptance was received within required timing; and
- notice indicates that funds have been reserved under Rule 8.
The exact system event should be logged because it is stronger than participant acceptance but still precedes the final settlement outcome.
Direction to implement settlement
After the positive outcome, the RTR Exchange submits a direction to RTR Clearing and Settlement to implement the Settlement Instructions.
Architecture should not have the sending bank independently decide "receiver accepted, so settle." The system workflow drives the settlement instruction.
6. Settlement and the Settlement Outcome Message
Rule 8 defines settlement as the transfer of the RTR Payment Obligation through entries made to the relevant Settlement Accounts.
Direct participants
For direct-to-direct settlement, the system reduces the sending participant's payment capacity/reserved balance as applicable and increases the receiving participant's payment capacity.
Indirect participants
If either participant is indirect, the entries are made to the relevant Settlement Agent's Settlement Account, with corresponding indirect-participant position treatment.
This is why reconciliation needs participant and settlement-agent identities.
Settlement notification
Once settlement has occurred:
- RTR Clearing and Settlement notifies the RTR Exchange;
- the Exchange sends the Settlement Outcome Message to both sending and receiving participants.
Rule 1 identifies the Settlement Outcome Message as a FItoFIPaymentStatusReport pacs.002.
This corrects a common ISO assumption: do not use pacs.004 as "RTR settlement confirmation." pacs.004 is a return message in other ISO contexts, but that is not the approved RTR settlement-outcome design.
Settlement evidence to retain
Store:
- UETR;
- original payment amount;
- sending/receiving participant;
- settlement-agent identities if applicable;
- acceptance time/status;
- payment outcome;
- settlement outcome;
- settlement time;
- external/system reference;
- internal posting IDs.
Settlement evidence should be immutable after completion, with corrections represented as linked events.
Operating cycle, cutoffs and liquidity replenishment
RTR is designed for 24/7/365 processing rather than an ACSS-style batch window. Rule 1 defines the RTR Operating Cycle, while the exact response timers for non-financial messages are controlled by the current RTR Service Level Description. Do not hard-code a customer or participant cutoff from this chapter; resolve the live SLD and participant agreement at implementation time. Rule 8 permits direct Participant-to-Participant Transfers at any time during the RTR Operating Cycle to manage Payment Capacity. Funding and defunding of RTR Settlement Accounts occur through Lynx under the Bank of Canada settlement-account agreement and its timing and operational restrictions. These liquidity-management flows are not customer RTR Payment Messages and are not subject to the RTR Clearing and Settlement Value Limit.
7. Payee posting, customer communication and accounting
Settlement at participant level does not automatically mean the payee's account has been posted in the receiving bank's ledger.
60-second requirement
Rule 6 states that, subject to Rule 7 exceptions, the receiving participant must make the amount available to the payee:
- promptly; and
- no later than 60 seconds after receipt of the Settlement Outcome Message.
That is a measurable service requirement.
The receiving bank should timestamp:
- settlement outcome received;
- ledger credit submitted;
- ledger credit completed;
- funds available;
- customer notification.
Incoming accounting
A typical receiving-bank accounting design may include:
- credit customer account;
- recognize corresponding RTR settlement asset/position movement;
- reconcile to the settlement outcome and settlement account.
The exact chart of accounts is institution-specific.
The key rule is that customer credit and central settlement must be explainably linked.
Customer status language
Recommended customer meanings:
Processing
bank has accepted the customer order but final external outcome not known.
Sent / submitted
payment entered the external process. Avoid implying recipient has funds.
Completed
use only when bank's product definition has sufficient evidence, ideally settlement plus expected posting outcome.
Rejected
payment did not proceed due to defined pre-settlement decision.
Under review / exception
settlement may have occurred but funds availability is subject to Rule 7/legal treatment.
Return requested
a recovery request exists; funds are not yet recovered.
Returned
return value has actually been received/reconciled.
The user interface should not say "cancelled" merely because a return was requested.
Sending-bank accounting
The sending bank must synchronize customer debit with the external outcome.
Potential pattern:
- reserve/earmark before submission;
- convert reservation to debit on positive final state;
- release reservation on rejection.
Other designs may debit earlier and reverse on rejection.
Whatever approach is selected, it needs:
- idempotency;
- no double debit;
- deterministic recovery after system outage;
- reconciliation to settlement.
8. Uncertain outcomes, status requests and duplicate prevention
Uncertainty is normal in distributed systems.
A timeout means:
the caller does not know the result.
It does not mean:
the payment did not happen.
Common uncertainty points
- channel times out waiting for payment hub;
- payment hub times out waiting for gateway;
- gateway connection breaks after submission;
- expected Payment Outcome Report not received;
- Settlement Outcome Message delayed/missing;
- ledger posting response lost.
Each requires a different recovery strategy.
pacs.028 Payment Status Request
The RTR ISO message set includes pacs.028 FI-to-FI Payment Status Request.
Rule 6 specifically requires the receiving participant to send a Payment Status Request Message when it does not receive the Payment Outcome Report or Settlement Outcome Message within the service-level timing, following the defined procedures.
Banks should therefore implement status recovery as a first-class function.
Idempotency layers
Strong duplicate prevention includes:
channel idempotency key
prevents double-click/API retry from creating two customer orders.
payment ID
stable internal identity.
UETR
stable RTR identity and rule-level duplicate key.
network technical identity
prevents transport replay confusion.
posting idempotency
prevents duplicate customer debit/credit.
A bank that relies only on UETR can still create two different UETRs for two duplicate customer orders. The control begins at the channel.
Recovery rule
After uncertainty:
- freeze new economic instruction;
- search internal state;
- inspect network/Exchange evidence;
- query supported external status where required;
- reconcile settlement evidence;
- resume/repair the same payment;
- create a new payment only if the original is conclusively not the economic transaction to be completed.
9. Rejections, exceptions, returns and recovery
The terms are not interchangeable.
The three-outcomes diagram above keeps the section's vocabulary honest: every payment ends accepted, rejected or uncertain, and each outcome has a different owner, evidence trail and recovery path.
Rejection
A rejection is a negative decision before the normal settlement completion path.
Examples:
- wrong currency;
- value limit;
- invalid account;
- format;
- duplicate;
- receiving participant rejection.
The original payment should not be described as "returned" if it never settled.
Rule 7 exception before payee credit
Settlement may occur, but the receiving participant can be relieved of immediate payee availability under defined circumstances.
Examples include:
- duplicate discovered;
- error/omission;
- foreign-currency account handling;
- malicious/harmful content;
- event beyond control;
- account restriction;
- law/court order;
- payee restriction.
The operational record should say:
- settled;
- payee credit exception;
- reason;
- disposition/return status.
Finality and permitted returns
Rule 7 states that once the amount has been made available to the payee, the payment is final and irrevocable except in specified circumstances such as:
- Processing Error;
- End-User Error;
- Unauthorized RTR Payment;
- Authorized RTR Payment Fraud;
- certain deceased-account or legal cases.
This is not a generic chargeback scheme.
Payment Return Request
The sending participant may initiate one Payment Return Request within 60 calendar days from exchange of the original message.
Required original-payment information includes:
- UETR;
- acceptance date/time;
- amount;
- reason.
Allowed request reasons include:
- Requested by Payor;
- Processing Error;
- End-User Error;
- Authorized RTR Payment Fraud;
- Unauthorized RTR Payment.
The receiving participant must normally respond within 10 calendar days by:
- accepting;
- rejecting;
- requesting an extension.
An extension can be granted up to 30 calendar days from receipt; no acceptance/rejection by then means deemed rejection.
Method of return
Rule 7 does not say "send pacs.004 settlement reversal."
It requires the receiving participant to effect the return using its proprietary methods, the Request for Returns/Returns Procedures Document, or procedures agreed with the sending participant, and to include the required linkage information.
That distinction should be reflected in implementation requirements.
Customer reimbursement and interbank recovery are separate
A bank may decide or be required under its customer terms/policies to reimburse a customer before it recovers value from the other participant.
Therefore track separately:
- customer reimbursement;
- interbank return request;
- receiving participant decision;
- recovered amount;
- loss account;
- fraud case.
Do not wait to model this until the first fraud incident.
10. Reconciliation, observability and test design
A real-time rail needs real-time evidence.
Four-way reconciliation
At minimum reconcile:
Customer
- original instruction;
- debit/credit;
- fees;
- notification.
Payment processing
- internal payment ID;
- UETR;
- route;
- statuses.
RTR external
- pacs.008;
- acceptance/rejection pacs.002;
- outcome;
- settlement outcome pacs.002.
Settlement
- direct settlement-account entry or sponsored-position movement.
A fifth dimension handles:
- exceptions;
- return request;
- return/recovery.
Break categories
Useful break codes:
- CUSTOMER_DEBIT_MISSING;
- CUSTOMER_DEBIT_DUPLICATE;
- EXTERNAL_STATUS_MISSING;
- SETTLEMENT_OUTCOME_MISSING;
- SETTLEMENT_POSITION_MISMATCH;
- PAYEE_POSTING_DELAY;
- UETR_DUPLICATE;
- RETURN_UNMATCHED;
- SPONSORED_POSITION_MISMATCH.
The break code should guide the owner.
Observability
Real-time dashboards should show:
- initiation volume;
- fraud declines;
- CoP mismatch rates;
- Exchange rejects by reason;
- receiver rejects;
- positive outcomes;
- settlement outcomes;
- p50/p95/p99 latency;
- funds-availability timing;
- missing outcomes;
- status requests;
- settlement capacity;
- Rule 7 cases;
- return requests;
- reconciliation breaks.
Test matrix
Initiation
- valid retail;
- valid corporate with dual approval;
- insufficient customer funds;
- unauthorized user.
Fraud
- CoP match/no match;
- central fraud adverse result;
- customer proceeds after warning;
- account takeover pattern.
Message
- valid pacs.008;
- missing required field;
- CAD 100,000 boundary;
- CAD 100,000.01;
- wrong currency;
- duplicate UETR;
- malformed format.
Receiver
- accept;
- reject AC01;
- reject RR07;
- timeout.
Settlement
- direct/direct;
- indirect/direct;
- direct/indirect;
- insufficient payment capacity;
- net debit cap.
Posting
- credit within normal latency;
- ledger timeout;
- Rule 7 legal restriction;
- event beyond control.
Uncertainty
- lost response after send;
- duplicate channel click;
- gateway restart;
- late settlement outcome.
Returns
- valid Payment Return Request;
- rejection;
- extension;
- deemed rejection;
- partial amount;
- customer reimbursed before recovery.
Detailed lifecycle engineering and operations
The rule sequence is compact. Bank implementation is not. Every transition can create a different financial, customer and operational consequence, so the lifecycle should be designed around durable events rather than synchronous application calls.
Customer order versus RTR payment
A customer order can exist before there is an RTR payment.
For example, a corporate customer creates a payment at 09:00, a second approver releases it at 09:20, fraud controls complete at 09:20:02 and only then does the bank create the pacs.008.
Store:
- orderCreatedAt;
- authorizationCompletedAt;
- paymentCreatedAt;
- UETR;
- submittedAt.
This distinction helps when a customer asks why a payment "created at 09:00" did not reach the rail until 09:20.
Scheduled and future-dated customer intent
A bank can allow a customer to prepare an instruction for later execution, but the actual RTR payment should be created/released only when product and bank controls determine it is ready for immediate processing.
At execution time revalidate:
- account status;
- balance;
- participant reachability;
- customer limit;
- fraud conditions;
- applicable scheme/product configuration.
Do not assume a validation performed days earlier remains valid.
Freeze the authorized payload
After the final customer approval, key payment data should be immutable unless the bank intentionally creates a new authorization cycle.
Fields include:
- debit account;
- payee account;
- amount;
- payee identity;
- critical remittance/purpose elements;
- product/route where customer terms depend on it.
If an operations user repairs a payee account after customer authorization without a defined re-authorization process, the bank may execute something the customer never approved.
Pre-send reservation of customer funds
A bank may reserve customer funds before external submission.
The reservation should have:
- reservation ID;
- amount;
- currency;
- account;
- expiry/release logic;
- linked payment ID;
- idempotent conversion to final debit.
The customer-funds reservation is not the same as Rule 8 reservation of RTR Settlement Account capacity.
These are two different liquidity controls:
customer reservation
protects the bank from customer double-spending.
RTR settlement reservation
protects the settlement process from insufficient participant payment capacity.
The architecture should use distinct terms and identifiers.
Fraud-decision evidence
The bank should retain not only a final approve/decline result but the decision context needed for investigation.
Examples:
- CoP response category;
- customer override/proceed decision;
- Central Fraud Analytics assessment;
- internal model result;
- device/account signals;
- rule hit;
- manual review if any;
- final decision and timestamp.
Sensitive model internals do not need to be exposed to the customer, but the bank should be able to explain the control path.
Create UETR before attempting send
Generate and persist UETR before the first external submission.
A safe sequence is:
- create durable payment record;
- assign UETR;
- commit payment state;
- build message;
- send.
An unsafe sequence is:
- generate UETR in memory;
- send;
- application crashes;
- database never records UETR;
- recovery creates a new UETR and sends again.
The second sequence can create duplicate economic payments.
Message payload hashing
Some banks retain a controlled hash of the submitted business payload.
This can support:
- evidence that the same payload was retried;
- detection of unintended mutation;
- audit comparison;
- non-repudiation controls alongside existing scheme/network security.
The hash should not replace the actual regulated/required record retention.
Technical acknowledgement versus business outcome
A network/API layer may acknowledge receipt before the business payment has been accepted.
Keep at least:
- transport accepted;
- Exchange validated;
- receiving participant accepted;
- payment outcome;
- settlement outcome.
A 200 HTTP response or equivalent technical acknowledgement should never directly trigger customer wording such as "money delivered."
Exchange rejection
An Exchange-level reject can occur before the receiving participant receives the business payment.
Operations should capture:
- reject layer;
- reason;
- message ID;
- UETR;
- timestamp;
- whether customer funds were reserved/debited;
- customer action.
If the reject is due to bank-created bad data, the bank should fix the source/mapping. Repeated manual repair is not an acceptable steady-state design.
Receiving-participant decision service
The receiving bank needs a low-latency decision service.
Inputs can include:
- account existence/status;
- CAD receiving eligibility;
- duplicate controls;
- malicious-content controls;
- legal/risk restrictions that apply pre-acceptance;
- participant fraud policy where appropriate;
- message validation.
Outputs should be deterministic:
- accept;
- reject;
- rule-supported reason;
- evidence.
The service should not depend on a human manually reviewing normal payments.
Reject reason governance
Internal reasons are often more granular than scheme reasons.
Example:
Internal:
- CLOSED_ACCOUNT;
- INVALID_TRANSIT;
- NON_RTR_ACCOUNT;
- ACCOUNT_BLOCKED_FOR_PRODUCT.
External scheme mapping may use an allowed standardized reason according to the current specification.
Maintain a governed mapping:
internalReason → externalReason → customerMessage → operationsOwner.
This prevents inconsistent customer treatment across channels.
Receiver acceptance is a commitment
Once the receiving participant's Payment Acceptance Status Message is received by the Exchange, the Rule says it cannot be changed or revoked.
The receiving bank should therefore complete required pre-acceptance checks before producing the positive status.
Do not:
- accept immediately for speed;
- then run basic account eligibility;
- then attempt to undo acceptance.
That design creates settlement and exception risk.
Reservation failure handling
A positive receiver decision can still be followed by a settlement-capacity problem.
The sending bank should monitor reservation/outcome separately from receiver acceptance.
Customer wording should not expose an internal contradiction such as:
"Recipient bank accepted, so payment is complete"
when settlement did not occur.
A safer timeline:
- Recipient institution accepted;
- Payment still processing;
- Final outcome pending.
Payment Outcome Report persistence
Persist the positive or negative outcome as its own event.
Fields can include:
- UETR;
- outcome;
- reason;
- timestamp;
- related acceptance;
- related reservation result;
- external reference.
This helps prove why settlement was or was not directed.
Settlement event immutability
Once settlement outcome confirms completion, treat the settlement event as immutable.
Do not change:
SETTLED → REJECTED
because a later customer complaint occurs.
Instead:
SETTLED → RETURN_REQUESTED
or
SETTLED → RULE7_EXCEPTION
or
SETTLED → FRAUD_CASE_OPEN.
Historical event integrity is essential for accounting.
Receiver posting idempotency
Incoming customer credit needs its own idempotency key.
A receiving core should prevent:
- settlement outcome replay;
- application retry;
- disaster-recovery replay;
from crediting the customer twice.
Possible key:
participant + UETR + payment direction/event type.
The precise key depends on architecture, but it must be durable.
Credit-before-response ambiguity
A core ledger can successfully credit the payee but return a timeout to the payment service.
The payment service must not blindly submit the credit again.
Recovery should query the ledger by the idempotency/reference key.
This is the same distributed-systems principle as external RTR uncertainty, applied inside the bank.
60-second control
Receiving participants need a measurable control for the Rule 6 funds-availability requirement.
Track:
- settlementOutcomeReceivedAt;
- creditInstructionCreatedAt;
- ledgerPostedAt;
- fundsAvailableAt.
Alert before the 60-second threshold where operationally possible.
If an exception under Rule 7 applies, store:
- exception type;
- reason;
- decision time;
- owner;
- next action.
Do not hide exceptions inside a generic delayed queue.
Customer notification should follow evidence
Notifications should be driven by business state.
For sending customer:
- order accepted;
- processing;
- completed;
- rejected;
- return case update.
For receiving customer:
- incoming payment credited;
- remittance available.
Avoid push notifications generated by network submission before final outcome.
Statement and transaction history
Customer statement text should remain stable after initial posting while separate status/case information can evolve.
Useful transaction fields:
- amount;
- counterparty display;
- date/time;
- customer reference;
- remittance;
- payment type;
- status/reference.
Do not expose UETR as the only customer reference; it is useful for support but not friendly as the primary transaction label.
Uncertain sending-side submission
Scenario:
- bank sends pacs.008;
- connection breaks before acknowledgement.
Recovery steps:
- payment state becomes UNKNOWN_EXTERNAL_SUBMISSION, not FAILED;
- UETR remains locked;
- gateway checks durable transport evidence;
- supported status/recovery process is used;
- customer cannot trigger a new economic payment from a blind retry action;
- final state is reconciled.
If the original conclusively never entered the external process, the bank can decide whether the same payment can be submitted under the supported technical rules. That is different from creating a second customer instruction.
Missing Payment Outcome Report
A participant expecting an outcome should:
- start scheme/service-level timer;
- record breach;
- initiate supported status inquiry/process;
- escalate if unresolved.
The case should preserve:
- what message was sent;
- what statuses were received;
- when the timer expired;
- status request;
- final resolution.
Missing Settlement Outcome Message
This is higher risk because payment settlement may already have happened.
Do not release customer funds reservations or tell the sender it failed until the state is resolved.
For a receiver, do not create a second credit path without determining whether settlement occurred.
Status request as controlled message
pacs.028/status request should have:
- related UETR;
- reason/trigger;
- unique technical message ID;
- timestamp;
- response correlation.
Status inquiries are operational messages and should be observable separately from payment volume.
A spike in pacs.028 can indicate:
- network instability;
- delayed outcomes;
- application correlation defect;
- performance degradation.
Duplicate UETR versus duplicate customer payment
The scheme duplicate control and bank business duplicate control solve different problems.
Duplicate UETR:
- two RTR messages use same UETR.
Duplicate customer payment:
- customer accidentally created two orders, each with different UETR.
Prevent business duplicates using:
- idempotency key;
- same customer/account/payee/amount/time heuristic;
- duplicate-warning policy;
- corporate file/payment identifier controls.
Do not block legitimate recurring payments merely because amount/payee match; duplicate detection needs context.
Pre-settlement reject accounting
If customer funds were reserved:
- release reservation exactly once.
If customer was already debited under the bank's design:
- reverse/re-credit under controlled journal.
Record:
- original debit;
- rejection;
- reversal.
Do not delete the original accounting event.
Rule 7 exception categories
After settlement outcome, receiving-side exception handling should categorize the case.
Examples:
- duplicate detected after normal acceptance;
- data error/omission;
- foreign-currency account treatment;
- malicious/harmful content;
- event beyond control;
- account restriction;
- legal/court order;
- payee instruction/restriction.
Each category can have different:
- funds-availability treatment;
- return timing;
- legal/compliance owner;
- customer communication.
Return versus Payment Return Request
A return and a request for return are not the same.
Return
value is actually being sent back under the permitted process.
Payment Return Request
sending participant asks the receiving participant to return value.
A request can be:
- accepted;
- rejected;
- extended;
- deemed rejected after the rule timeline.
Customer support should never say "your money has been returned" when only a request exists.
Payment Return Request case model
Suggested fields:
- caseId;
- originalUETR;
- originalAmount;
- requestedReturnAmount;
- reason;
- requestSentAt;
- responseDueAt;
- extensionRequestedAt;
- extendedDueAt;
- receiverDecision;
- recoveredAmount;
- customerReimbursementAmount;
- status;
- evidence.
This supports the 60-day initiation window and receiver response timelines.
Partial returns
Where the applicable procedures allow a return amount that differs from the original, reconciliation must handle:
- original amount;
- returned amount;
- remaining exposure;
- customer reimbursement;
- fees/loss.
Never assume return amount always equals original payment.
Authorized-payment fraud versus unauthorized payment
Operations and fraud teams should preserve the distinction.
Unauthorized RTR Payment
customer did not authorize the payment.
Examples:
- account takeover;
- credential compromise.
Authorized RTR Payment Fraud
customer authorized the payment but was deceived, such as an impersonation or invoice scam.
Investigation evidence and customer treatment can differ.
Do not label every scam "unauthorized."
End-user error
A customer may send to wrong payee or wrong account.
That is not automatically fraud.
The bank should:
- capture error claim;
- determine original authorization;
- use permitted return-request process where appropriate;
- avoid promising recovery.
Processing error
A bank can also make an error.
Examples:
- wrong amount generated from customer instruction;
- duplicate caused by bank system;
- wrong beneficiary mapping.
Processing-error cases need:
- root cause;
- customer remediation;
- interbank return process;
- loss/recovery accounting;
- defect correction.
Investigations workspace
Operations need one workspace showing:
- customer/order data;
- UETR;
- messages;
- status timeline;
- settlement;
- posting;
- fraud data access appropriate to role;
- return case;
- communications.
Copying information between five screens during a fraud call increases error and response time.
Audit trail
Every manual operation should record:
- user;
- time;
- action;
- before/after state;
- reason;
- approval where needed.
High-risk actions:
- force state repair;
- manual ledger adjustment;
- manual customer reimbursement;
- return initiation;
- participant/routing override.
Event-driven reconciliation
A real-time design can create expected reconciliation events as the payment progresses.
Example:
- pacs.008 submitted → expect external outcome;
- settlement outcome received → expect settlement-account/position evidence;
- incoming settlement outcome → expect customer credit;
- return accepted → expect recovered value.
This makes missing evidence visible quickly.
Reconciliation tolerances
For RTR principal amounts, transaction-level reconciliation should normally be exact.
Do not use broad amount tolerances that could match the wrong instant payment.
Keys should include:
- UETR;
- participant;
- amount;
- direction;
- event/reference.
Fees and customer charges should be reconciled in their own accounting stream if they are not part of the RTR Payment Obligation.
End-of-day still matters
A 24/7 rail does not eliminate financial close.
End-of-day controls can verify:
- all settlement outcomes matched;
- customer postings complete;
- unresolved unknowns;
- settlement-account balance/position;
- indirect participant sub-ledgers;
- open return cases;
- suspense accounts.
The end-of-day process must not stop transaction processing.
Failure-mode testing
Test failures at the exact boundary.
After customer authorization, before UETR
- payment can safely resume.
After UETR persisted, before send
- same payment resumes with same UETR.
After send, before acknowledgement
- query/recover, no blind resend.
After receiver acceptance, before outcome
- state remains pending, settlement not assumed.
After settlement, before sending-bank ledger update
- recover from settlement evidence.
After settlement, before receiver credit response
- query posting by idempotency key.
During return recovery
- customer reimbursement and interbank recovery remain distinct.
Chaos and resilience scenarios
Beyond functional tests, inject:
- database failover;
- duplicate event delivery;
- out-of-order status delivery;
- gateway restart;
- CSP network partition;
- delayed fraud response;
- core ledger timeout;
- settlement capacity alert;
- clock skew;
- partial regional outage.
The objective is to prove the payment remains financially correct even when systems are not perfectly ordered.
Operational service-level dashboard
A useful dashboard includes:
- payment volume;
- acceptance rate;
- rejection rate by reason;
- settlement completion rate;
- settlement-to-payee-credit latency;
- unknown-state count;
- oldest unknown;
- status-request rate;
- duplicate attempts;
- return-request volume;
- open Rule 7 cases;
- reconciliation breaks.
The dashboard should allow filtering by:
- sending/receiving;
- participant;
- direct/indirect;
- competitive service;
- customer segment;
- time range.
Post-incident reconciliation
After any significant incident:
- identify all potentially affected payments;
- freeze unsafe automated retries;
- obtain external status;
- reconcile settlement;
- reconcile customer ledger;
- repair missing internal events;
- correct customer communication;
- review return/reimbursement cases;
- document root cause;
- implement prevention.
"Service is back up" is not the end of a payments incident. Financial integrity must be proven.
Lifecycle requirements for product owners, developers and testers
Business requirement versus technical message requirement
A good RTR requirement should state the business condition first and the ISO/API behavior second.
Weak:
"Send pacs.002 after pacs.008."
Stronger:
"When the receiving participant has completed the rule-required validation of an inbound RTR payment, the receiving service must return an acceptance or rejection status within the applicable service-level timing. The response must use the current RTR pacs.002 specification and preserve the related payment/UETR correlation."
The stronger requirement explains:
- actor;
- decision;
- timing;
- business meaning;
- message;
- correlation.
This helps developers implement the right process even if the message version changes.
State-transition rules
Each internal state should define:
- allowed previous states;
- event that causes transition;
- required evidence;
- accounting consequence;
- customer wording;
- retry behavior;
- next timeout/escalation.
Example:
SUBMITTED
- previous: READY_TO_SEND;
- evidence: durable outbound submission;
- accounting: customer reservation remains;
- customer wording: Processing;
- retry: do not create new payment;
- timeout: status recovery.
SETTLED
- previous: positive outcome / settlement pending;
- evidence: Settlement Outcome Message;
- accounting: final external settlement recognized;
- customer wording: Completed only according to product evidence policy;
- retry: never re-submit original payment.
This makes state handling testable rather than implicit in code.
Invalid state transitions
The platform should reject impossible transitions.
Examples:
- REJECTED → SETTLED without a separate new payment;
- SETTLED → SUBMITTED;
- RETURNED → REJECTED;
- receiver acceptance after a final receiver rejection for the same processing instance;
- second customer debit after settlement replay.
An invalid transition should create an operational alert, not silently overwrite history.
Event ordering and late messages
External and internal events may arrive late.
Suppose:
- payment settles;
- settlement outcome is stored;
- a delayed internal copy of receiver-acceptance event arrives.
The system must not move status backwards from SETTLED to RECEIVER_ACCEPTED.
Use:
- monotonic business-state rules;
- event timestamps;
- event sequence/correlation;
- immutable event history.
Customer retry behavior
If a customer presses retry after receiving an uncertain screen, the channel should first find the original customer order.
Possible response:
"Your payment is still being checked. Do not send another payment. Reference: XYZ."
Only after the original is conclusively rejected/failed before settlement should the product offer a new payment action.
This reduces duplicate scam/error risk as well as technical duplicates.
Batch-like corporate initiation
A corporate platform may submit hundreds or thousands of individual RTR payments from one file or API job.
The batch/job is an orchestration container.
Each RTR payment should still have:
- its own customer payment identity;
- its own UETR;
- its own fraud outcome;
- its own external status;
- its own settlement;
- its own reconciliation.
If 997 of 1,000 payments settle and three reject, do not mark the entire job simply "failed."
Corporate reporting should show:
- total submitted;
- settled;
- rejected;
- pending/unknown;
- returned.
Cutover and restart
During deployment or failover:
- stop accepting new work only if necessary;
- drain or persist in-flight payment state;
- restart consumers idempotently;
- replay durable events safely;
- verify no unprocessed settlement outcome;
- reconcile before declaring recovery complete.
A restart should never require an operator to decide manually which payments to resend from memory.
Production support decision tree
When a customer says "recipient did not get the money," support should follow evidence:
- Find payment by customer reference/UETR.
- Was pacs.008 submitted?
- no: bank/customer initiation issue.
- Was it rejected?
- yes: explain rejection; no settlement.
- Was positive payment outcome achieved?
- no/unknown: operations/status inquiry.
- Was settlement outcome received?
- no/unknown: urgent status/settlement investigation.
- Was receiving-side posting completed or Rule 7 exception recorded?
- yes: provide appropriate status.
- unknown: receiving participant/investigation process.
This prevents support from using "sent" as proof of beneficiary receipt.
Evidence retention for disputes
For disputed payments, preserve the state history rather than only the final status.
A final database row:
status = RETURNED
does not tell the whole story.
The event history should show:
- authorized;
- risk approved;
- submitted;
- accepted;
- settled;
- payee credited;
- fraud reported;
- return requested;
- returned.
That sequence matters for customer treatment and audit.
Lifecycle acceptance criteria
For delivery teams, the lifecycle can be converted into concrete acceptance criteria.
Outgoing payment
A valid payment is complete only when:
- customer authorization is durable;
- required fraud controls completed;
- one stable UETR exists;
- pacs.008 submission is recorded;
- external statuses correlate to the same UETR;
- settlement outcome is known;
- customer debit is correct;
- reconciliation is matched.
Incoming payment
A valid incoming payment is complete only when:
- pacs.008 was validated;
- receiver decision was sent once;
- settlement outcome was received;
- customer credit/funds-availability requirement was met or a valid Rule 7 exception exists;
- accounting is matched;
- customer reporting/remittance is available as designed.
Rejected payment
A rejected payment is complete only when:
- rejection layer/reason is known;
- no settlement is incorrectly recorded;
- customer reservation/debit is released or corrected;
- customer receives appropriate status;
- repeat bank-caused rejects are routed to defect management.
Unknown payment
An unknown payment is not a terminal state.
It requires:
- timer;
- status recovery;
- operations owner;
- duplicate suppression;
- escalation;
- final reconciliation.
Unknown items should have an ageing dashboard and zero silent closure.
Returned payment
A returned/recovered payment is complete only when:
- original settled payment remains linked;
- return reason and amount are known;
- recovered value is reconciled;
- customer reimbursement is handled exactly once;
- case status reflects actual recovery.
Nonfunctional acceptance
The implementation should also prove:
- peak throughput;
- burst traffic;
- failover;
- idempotent replay;
- message ordering tolerance;
- clock synchronization;
- log/evidence search;
- role-based access;
- monitoring and alerting.
A payment flow that passes functional happy-path tests but duplicates value after failover is not production-ready.
Operational handover
Before release, development should hand operations:
- state diagram;
- status/reason mapping;
- example messages;
- dashboard links;
- known thresholds;
- runbooks;
- escalation contacts;
- reconciliation procedures;
- return/exception procedure.
Operations should rehearse the handover using real scenarios, not only read documentation.
Root-cause categories
Production incidents should use consistent root-cause categories:
- customer/input;
- participant reference data;
- fraud;
- internal payment hub;
- gateway/CSP;
- RTR external;
- receiving participant;
- settlement/liquidity;
- core ledger;
- reconciliation;
- operator/change.
This helps trend defects and prevents everything from being classified as "RTR issue."
Customer-impact measurement
For each incident measure:
- payments affected;
- value affected;
- customers affected;
- settled-but-not-posted count;
- duplicate-risk count;
- recovery time;
- customer reimbursements;
- open reconciliation breaks.
Technical uptime alone can hide financial/customer impact.
State-machine design for real-time payments
An RTR implementation should have an explicit state machine rather than letting each component invent its own status vocabulary.
Suggested state groups
Customer/pre-send
- CREATED
- AWAITING_AUTHORIZATION
- AUTHORIZED
- RISK_REVIEW
- READY_TO_SEND
External processing
- SUBMITTED
- RECEIVER_ACCEPTED
- RECEIVER_REJECTED
- RESERVATION_PENDING
- PAYMENT_OUTCOME_POSITIVE
- SETTLEMENT_PENDING
Final external
- SETTLED
- REJECTED
- UNKNOWN_REQUIRES_STATUS
Customer application
- DEBIT_POSTED
- PAYEE_CREDITED
- RULE7_EXCEPTION
Recovery
- RETURN_REQUESTED
- RETURN_ACCEPTED
- RETURN_REJECTED
- PARTIALLY_RETURNED
- RETURNED
The exact names can differ, but the meanings should not overlap.
Event sourcing versus mutable status
A final currentStatus is useful for screens, but keep the event history.
Example:
10:00:01 AUTHORIZED
10:00:02 RISK_APPROVED
10:00:03 SUBMITTED
10:00:04 RECEIVER_ACCEPTED
10:00:04 RESERVATION_CONFIRMED
10:00:05 SETTLED
10:00:07 PAYEE_CREDITED
If a later fraud case opens, append:
11:20:00 RETURN_REQUESTED
Do not overwrite SETTLED with RETURN_REQUESTED and lose the settlement fact.
Correlation across systems
Every critical event should carry enough identifiers to correlate:
- internal payment ID;
- UETR;
- customer order ID where relevant;
- participant identities;
- external message/reference;
- amount/currency;
- timestamp.
Reconciliation should never depend on free-text descriptions.
Timers are business controls
Timers should be associated with expected events.
Examples:
SUBMITTED
→ expect receiver/payment outcome within applicable service-level timing.
SETTLED incoming
→ expect payee funds available within Rule 6 requirement unless Rule 7 exception.
RETURN_REQUESTED
→ expect receiving-participant response within Rule 7 case timeline.
A timer expiry should create a specific operational event and owner.
No silent terminal "failed"
"Failed" hides too much.
Different terminal outcomes include:
- customer validation rejected;
- fraud declined;
- Exchange message rejected;
- receiving participant rejected;
- settlement could not complete;
- business payment returned later.
Customer wording can be simplified, but operational state must remain precise.
Customer notification matrix
| Internal evidence | Customer wording |
|---|
| Authorized, not yet submitted | Scheduled/Processing |
| Submitted, final outcome unknown | Processing |
| Receiver rejected | Could not be completed |
| Settlement confirmed | Sent/Completed according to product policy |
| Incoming payee credit completed | Received |
| Rule 7 exception | Under review / availability restricted |
| Return requested | Recovery requested |
| Value actually recovered | Returned |
The bank should never use "refunded" for a return request that has not produced value.
Idempotency test pattern
For every financial operation, deliberately send the same event twice in test.
Examples:
- customer submit twice;
- pacs.008 send callback twice;
- settlement outcome event twice;
- incoming posting event twice;
- return recovery event twice.
Expected result:
one economic payment, one debit, one credit.
Crash-window testing
Deliberately crash after:
- UETR persisted, before send;
- send completed, before acknowledgement stored;
- settlement outcome received, before customer debit;
- incoming settlement outcome received, before customer credit response stored.
For each crash, prove recovery without duplicate value.
Customer ledger versus external settlement
The reconciliation engine should detect these combinations:
| External | Customer ledger | Meaning |
|---|
| Not settled | No debit | normal reject |
| Not settled | Debit posted | customer accounting defect |
| Settled | Debit posted | expected outgoing |
| Settled | No debit | serious accounting break |
| Incoming settled | Credit posted | expected incoming |
| Incoming settled | No credit/exception | urgent posting/Rule 7 case |
This matrix belongs in operations training.
Exception ownership
Route by root cause:
- authentication → channel/security;
- fraud → fraud operations;
- malformed ISO → gateway/message team;
- receiver rejection → payment operations/customer repair;
- payment capacity → treasury;
- missing outcome → RTR operations;
- posting failure → core/accounting;
- return claim → investigations;
- reconciliation mismatch → finance/payment reconciliation.
A single generic queue increases recovery time.
Reconciliation checkpointing
Near-real-time reconciliation can use checkpoints:
- every outbound submitted payment has an external outcome;
- every settled payment has a ledger consequence;
- every settlement-account/agent position movement has payment evidence;
- every return has an original payment;
- every customer reimbursement has one case.
Checks can run continuously and again at accounting close.
Operational replay
If an event stream must be replayed:
- read-only reconstruction should be default;
- financial side effects must be idempotent;
- posting services require stable keys;
- operators need controlled tools;
- replay scope and reason must be audited.
Never recover an incident by manually re-sending a list of payments from a spreadsheet without first determining their external state.
End-to-end acceptance test
A chapter-level "happy path" is not enough for production sign-off. One complete acceptance scenario should prove:
customer authorization
→ fraud/CoP
→ pacs.008
→ receiver pacs.002
→ reservation/outcome
→ settlement
→ settlement outcome
→ customer accounting
→ payee availability
→ statement/report
→ reconciliation.
Then repeat with one controlled failure at each boundary.
That is the difference between message testing and payment testing.
Business analyst requirements checklist
A lifecycle user story should specify more than the message name.
For each transition define:
- trigger;
- preconditions;
- source and target state;
- required input data;
- external message/event;
- timeout;
- error outcome;
- accounting effect;
- customer communication;
- reconciliation evidence.
Example requirement:
When a positive Settlement Outcome Message is received for an incoming payment, the receiving participant must correlate it to the original UETR, create the idempotent customer-credit instruction, capture the settlement-outcome timestamp, and make the amount available within the Rule 6 requirement unless a documented Rule 7 exception applies.
Acceptance tests should then cover:
- normal posting;
- duplicate settlement outcome;
- core timeout after successful credit;
- valid Rule 7 exception;
- reconciliation break.
Status reason catalogue
Create a controlled catalogue that maps:
external reason/code
→ internal business reason
→ customer wording
→ owner
→ allowed next actions.
This prevents a developer from showing raw scheme codes to customers and prevents operations from manually translating the same rejection differently across channels.
Customer-support evidence
The support desktop should display:
- customer reference;
- amount/payee;
- UETR;
- current business state;
- last confirmed external event;
- whether settlement occurred;
- whether payee posting is confirmed;
- exception/return case;
- next action and owner.
It should not require support staff to inspect XML or infer settlement from a generic "accepted" flag.
Settlement-to-posting SLA monitoring
For incoming payments, measure the distribution from Settlement Outcome receipt to funds available:
- p50;
- p95;
- p99;
- count over internal warning threshold;
- count over the rule threshold;
- valid Rule 7 exceptions.
Averages can hide a small population of serious breaches.
Release regression pack
Every material release should replay:
- clean direct-to-direct payment;
- indirect participant path;
- duplicate UETR;
- receiver rejection;
- capacity failure;
- missing outcome/status inquiry;
- incoming core timeout;
- Rule 7 exception;
- return request;
- reconciliation replay.
This ensures the lifecycle remains financially correct after technical change.
Negative-path test catalogue
The fastest way to prove lifecycle quality is to test where certainty breaks.
Customer and authorization failures
Test unauthorized users, expired entitlement, missing second approver, customer edits after authorization, and account closure between payment creation and release. No pacs.008 should be released until the authorization state is valid, and changed critical data should trigger the appropriate new control cycle.
Fraud and payee failures
Test confirmation-of-payee mismatch, service unavailable, central analytics adverse result, internal model decline and new-beneficiary high-risk patterns. Decision evidence must be retained, and customer warning must remain distinct from the bank's final fraud decision.
Message failures
Test malformed pacs.008, missing identifiers, invalid currency, above-limit amount, duplicate UETR and unsupported versions. The failure layer must be explicit; customer reservations must be released or corrected exactly once; and no settlement state should be created.
Receiver failures
Test invalid receiving account, supported receiver rejection, delayed response and a response lost internally after receipt. State must remain recoverable without blind resubmission.
Settlement failures
Test insufficient Payment Capacity, ISP Net Debit Cap breach, reservation timeout and Settlement Agent incident. Receiver acceptance must never be misreported as settlement, and treasury/settlement ownership must be clear.
Incoming posting failures
Test settlement outcome received while the core ledger is unavailable, credit posted but response lost, duplicate settlement event and a valid Rule 7 exception. Posting must be idempotent and the funds-availability timer measurable.
Network uncertainty
Test connection loss after submission, application restart before acknowledgement persistence, delayed settlement outcome and delayed status-query response. The original UETR must remain stable and status recovery must happen before any new economic payment is created.
Accounting failures
Test external settlement with missing customer debit, incoming settlement with missing credit, duplicate journal event and a return recovered after the customer was already reimbursed. Repair must be idempotent and never duplicate customer value.
Return-case failures
Test duplicate return request, request outside the permitted window, receiving-party extension, partial recovery and no recovery. The original settled payment remains immutable while the return case and accounting evolve separately.
Operational acceptance
A negative test is complete only when operations can explain what happened, where it failed, whether money settled, what happened to customer funds, what action comes next and who owns it. That is more important than the raw HTTP or XML error returned by a component.
11. Practical lifecycle scenarios
The scenarios below are fictional test cases. They illustrate the approved target flow and exception handling; they do not assert that RTR is live, that a named bank behaves this way, or that any latency is a production statistic.
Example 1 — clean payment
Customer sends CAD 1,200.
All controls pass.
pacs.008 sent with UETR A.
Receiver accepts using pacs.002.
Reservation succeeds.
Positive Payment Outcome Report generated.
Settlement executed.
Settlement Outcome pacs.002 received.
Receiver credits payee in 4 seconds.
Reconciliation matches.
This is the reference happy path.
Example 2 — wrong currency
Customer tries to send USD through RTR.
The bank should stop the request before pacs.008.
If a non-CAD obligation reaches the RTR validation path, Rule 6 provides wrong-currency rejection treatment.
The product may offer an FX conversion to CAD and then create a separate eligible CAD RTR payment.
Example 3 — CAD 100,000 boundary
CAD 100,000 is within the current RTR Exchange Value Limit.
CAD 100,000.01 is not.
But the customer's bank limit might be CAD 25,000.
Test both system and product thresholds separately.
Example 4 — duplicate double-click
Customer presses Pay twice.
Channel idempotency sees the same customer request key and returns the existing payment.
No second pacs.008 is created.
If the channel failed and created two internal orders, UETR logic alone may not protect you if each order has a different UETR. That is why idempotency belongs at multiple layers.
Example 5 — receiver accepts, reservation fails
Receiver sends positive acceptance.
Settlement reservation cannot be completed because sending-side capacity is insufficient.
The payment must not be labelled settled.
Treasury/operations handle the capacity situation and the system follows its defined outcome.
Example 6 — settlement outcome missing
Receiver accepted and expects outcome, but settlement outcome is not received in required timing.
It follows the Rule 6 status-request procedure using the supported Payment Status Request flow.
It does not assume settlement failed.
Example 7 — legal restriction after settlement
Settlement Outcome says settlement occurred.
Receiver identifies a legal restriction preventing normal funds availability.
It applies Rule 7/legal treatment.
Sending bank should not tell payor "the bank rejected the transfer" because settlement already happened.
The accurate state is settled with receiving-side funds-availability exception.
Example 8 — fraud reported after payee credit
Payor says an authorized push-payment scam occurred.
Sending bank opens fraud case and, where appropriate, initiates Payment Return Request.
Receiving bank investigates/responds.
The original payment remains a historical settled payment.
Recovery is a new linked case/value flow.
Example 9 — customer reimbursement precedes recovery
Sending bank determines under policy that customer should be reimbursed immediately.
It credits customer.
Interbank recovery is still pending.
Finance records:
- customer reimbursement;
- loss/recoverable;
- return-request case;
- later recovered amount.
Without separate objects, accounting can accidentally credit customer twice when recovery arrives.
12. Key takeaways and authoritative references
The RTR lifecycle is a sequence of controlled states, not a single "instant payment" call.
The sending participant authenticates the payor, applies participant and central fraud controls, validates product/funds/limits and creates the pacs.008. The RTR Exchange validates and routes it. The receiving participant sends a pacs.002 acceptance or rejection. Positive outcome depends on acceptance plus required reservation. The Exchange directs settlement. After settlement, the Exchange sends a pacs.002 Settlement Outcome Message to both participants.
Subject to Rule 7 exceptions, the receiving participant must make funds available promptly and within 60 seconds after receipt of the settlement outcome. That makes payee funds availability a separate measurable event after system settlement.
UETR is a required identifier and duplicate-control key, but strong idempotency begins earlier at customer initiation. A timeout means unknown, not failed. Use status recovery and the defined pacs.028/status process rather than creating a second payment.
Once the RTR Payment Message is submitted to the Exchange, the sending participant cannot cancel, revoke or amend it. Post-settlement problems use Rule 7 exception, return and Payment Return Request processes. The current Rules do not make pacs.004 the RTR settlement confirmation or a universal return mechanism.
The practitioner rules are:
- model one economic payment through explicit states;
- persist identity before network send;
- run fraud and authentication before releasing the pacs.008;
- distinguish receiver acceptance from payment outcome;
- distinguish payment outcome from settlement;
- distinguish settlement from payee funds availability;
- treat pacs.002 as both acceptance/status and settlement-outcome family according to context;
- query unknown states before retrying;
- retain the original settled record when a return/recovery occurs;
- reconcile customer, message, settlement and ledger evidence continuously.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.