Real Time Payment and Exception Journey. Work through an RTR-oriented payment scenario covering real-time controls, uncertain outcomes, customer communication and reconciliation.
Block 15 · Chapter 75 of 75
This final Canadian payment story is deliberately written as a launch-readiness scenario, not as a description of a currently live retail service.
At the 5 October 2026 audit date, Canadian Payments Association By-law No. 10 and the Real-Time Rail (RTR) Rules are in force from August 24, 2026, but Payments Canada still describes the RTR as a planned, sequenced launch in Q4 2026. The published launch strategy targets initial direct-to-Exchange participants in Q4 2026, initial Interac e-Transfer clearing and settlement migration participants in Q1 2027, additional migration participants in Q2 2027 and full initial-launch-phase volumes in Q3 2027.
That distinction matters. Banks can build and test against the approved rules today, but they should not tell customers that an RTR production payment has already been sent before the rail launches.
Classification used below: the Rules and By-law statements are Payments Canada scheme/legal requirements; the architecture, controls, ledger and runbooks are bank implementation guidance; Elena and the contractors are fictional examples. Current Interac e-Transfer remains a separate production service; references to RTR are future/launch-readiness unless explicitly labelled otherwise.
The approved rules now give a precise end-to-end model:
- Rule 6 defines the RTR Exchange flow and identifies the RTR Payment Message as pacs.008;
- the payment obligation must be in Canadian dollars;
- the RTR Exchange value limit is CAD 100,000 per RTR Payment Message;
- a sending participant must authenticate the payor and use Central Fraud Services as required by Rule 13;
- Rule 13 requires participant fraud controls, confirmation of payee and Central Fraud Analytics;
- the receiving participant returns a pacs.002 Payment Acceptance Status Message accepting or rejecting the payment;
- funds are reserved under the Rule 8 settlement model;
- a positive Payment Outcome Report leads to settlement instructions;
- the Settlement Outcome Message confirms settlement;
- subject to Rule 7 exceptions, the receiving participant must make funds available to the payee promptly and no later than 60 seconds after receiving the Settlement Outcome Message;
- once an RTR Payment Message is submitted to the RTR Exchange, the sending participant cannot cancel, revoke or amend it;
- Rule 7 governs exceptions, returns and payment-return requests after the payment has progressed.
The operating lesson is:
Real time compresses every control window, but it does not eliminate payment states. Authentication, fraud assessment, exchange acceptance, receiving-participant response, funds reservation, settlement, payee credit, return and customer communication remain different events.
This chapter follows one simulated future payment and then deliberately breaks it in several ways so you can see how a bank should respond.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain the current October 2026 launch status accurately;
- trace an RTR payment using the approved Rule 6 lifecycle;
- explain the CAD 100,000 exchange limit;
- explain UETR duplicate controls;
- describe Rule 13 MFA/transaction-monitoring/confirmation-of-payee/Central Fraud Analytics responsibilities;
- distinguish payor authentication from payment fraud decisioning;
- explain why confirmation of payee is risk information rather than a guarantee;
- distinguish pacs.008 payment message, pacs.002 acceptance status, Payment Outcome Report and Settlement Outcome Message;
- explain the role of payment capacity and funds reservation under Rule 8;
- explain irrevocability after submission to the RTR Exchange;
- explain the 60-second funds-availability requirement subject to Rule 7 exceptions;
- classify duplicate, account, currency, harmful-content and other receiving-side rejection/exception scenarios;
- explain how a timeout must be handled without blindly resending;
- distinguish a settled payment from a later return or payment-return request;
- connect the RTR lifecycle to customer posting, liquidity, reconciliation, fraud, sanctions and incident management.
Chapter navigator
- The launch-readiness story
- Participants and settlement models
- Customer intent, authentication and confirmation of payee
- Rule 6 exchange lifecycle
- Rule 8 funds reservation and settlement
- Payee funds availability and posting
- Rule 7 exceptions and returns
- Uncertain outcomes and duplicate prevention
- Fraud, sanctions and customer communication
- Architecture, operations and reconciliation
- End-to-end real-time scenarios
- Testing, takeaways and authoritative references
1. The launch-readiness story
Imagine the date is after a bank has successfully gone live on the RTR.
A customer, Elena, wants to pay a contractor CAD 12,500.
The contractor's account is at another participating institution.
Elena expects:
- the bank to identify the intended payee;
- fraud checks to happen immediately;
- clear confirmation;
- the contractor to receive funds quickly;
- no uncertainty about whether to resend.
The bank must do far more than one API call.
Business requirement
Pay CAD 12,500
from Elena
to contractor
now
with invoice reference RENOV-883
Bank requirement
Authenticate
→ confirm payee
→ fraud assessment
→ validate amount/account/CAD
→ create pacs.008 + UETR
→ send to RTR Exchange
→ receiving participant accepts/rejects
→ reserve settlement funds
→ settle
→ payee funds available
→ notify
→ reconcile
2. Participants and settlement models
Payor
Elena authorizes payment.
Sending participant
Elena's FI:
- authenticates;
- confirmation of payee;
- fraud;
- creates RTR Payment Message;
- manages customer debit;
- participates in settlement directly or through settlement agent.
RTR Exchange
Receives pacs.008 and:
- validates;
- routes to receiving participant;
- receives pacs.002 response;
- coordinates Payment Outcome Report;
- directs settlement.
Receiving participant
Contractor's FI:
- validates;
- accepts/rejects;
- receives settlement outcome;
- credits payee subject to Rule 7.
RTR Clearing and Settlement
Implements settlement instructions under Rule 8.
Direct Settlement Participant
Holds RTR settlement account.
Responsible for maintaining funds/payment capacity.
Indirect Settlement Participant
Uses Settlement Agent.
Rule 8 applies net debit cap/ISP position controls.
Bank of Canada
May grant RTR settlement accounts under its published July 31, 2026 access policy; the policy is an eligibility and assessment framework, not proof that every applicant has an account.
Central Fraud Services
Provide shared fraud capabilities required by Rule 13.
3. Customer intent, authentication and confirmation of payee
Real-time fraud control begins before pacs.008.
Payor authentication
Rule 13 requires sending participant to have capability to use industry best-practice MFA or equivalent and use it to authenticate payor before initiating an RTR Payment Message.
Authentication proves the person/session.
It does not prove the contractor is legitimate.
Confirmation of payee
Rule 13 requires each sending participant to implement confirmation of payee using:
- Central Confirmation of Payee;
or
- registered and approved third-party CoP.
Result feeds customer decision.
Customer choice
Rule 13 states the sending participant must provide the payor the choice to proceed regardless of CoP result and ensure the risks are outlined.
This is an important design point.
The bank UI should not present a non-match as:
“Payment impossible”
unless another control independently blocks it.
Instead:
- display result;
- explain risk;
- obtain customer choice;
- apply bank's own fraud decision.
Central Fraud Analytics
Rule 13 requires Central Fraud Analytics for each RTR Payment Message.
Before introducing pacs.008:
- receive Fraud Assessment;
- sending participant decides whether to send using assessment and any other relevant information.
Central result is an input.
Participant remains responsible for its decision.
Continuous transaction monitoring
Rule 13 requires sending participants to maintain continuous transaction monitoring processes to prevent fraudulent RTR Payment Messages entering the Exchange.
Example
Elena pays known contractor.
Signals:
- known device;
- normal location;
- beneficiary confirmation match;
- amount consistent;
- Central Fraud Assessment normal.
Bank allows.
4. Rule 6 exchange lifecycle
Rule 6 provides the core message flow.
Step 1: pacs.008
Only payment item acceptable through RTR Exchange for clearing/settlement is FIToFICustomerCreditTransfer pacs.008.
Step 2: required information
Rule 6 requires relevant data including:
- amount;
- payee account number;
- sending participant institution number;
- receiving participant institution number;
- UETR;
- sending participant CSP identifier;
- Competitive Service identifier.
Exact message uses current RTR ISO 20022 specifications.
Step 3: CAD only
RTR Payment Obligation must be CAD.
USD 12,500:
Step 4: CAD 100,000 limit
Rule 6 sets RTR Exchange Value Limit CAD 100,000.
Participant may set lower customer limit.
Elena CAD 12,500:
- within system limit;
- still subject to her bank limit.
Step 5: duplicate UETR
Sending participant must not reuse UETR.
RTR Exchange rejects an RTR Payment Message if UETR matches one used in prior 90 calendar days.
This supports duplicate protection.
Step 6: irrevocability
Once submitted to RTR Exchange:
- cannot be cancelled;
- cannot be revoked;
- cannot be amended by sending participant.
Therefore customer confirmation must occur before submission.
Step 7: receiving pacs.002
Receiving participant sends pacs.002 acceptance/rejection within service-level timing.
Rule 6 lists rejection reasons including:
- duplicate;
- value limit exceeded;
- invalid account number;
- wrong currency;
- formatting;
- malicious/harmful content;
- other.
Step 8: Payment Outcome Report
RTR Exchange sends positive outcome when:
- receiving participant accepted;
- funds reservation notice indicates funds reserved.
Step 9: settlement instruction
Exchange directs RTR Clearing and Settlement to implement settlement.
Step 10: Settlement Outcome Message
After settlement:
- Exchange sends Settlement Outcome Message to sending and receiving participants.
This is the key event for customer financial state.
5. Rule 8 funds reservation and settlement
Real-time payment requires real-time settlement capacity.
Direct participant funding
Rule 8 requires Direct Settlement Participant to maintain funds in Settlement Account for:
- own obligations;
- Member Non-Participants it serves;
- Indirect Settlement Participants for which it acts as Settlement Agent.
Payment capacity
Sending settlement account must have payment capacity at least equal to payment obligation.
For indirect:
- Settlement Agent's account;
- ISP net position cannot fall below Net Debit Cap.
Reservation
After acceptable settlement instructions:
- amount is reserved;
- payment capacity reduced;
- reserved balance increased.
Why reserve before outcome
Prevents positive payment outcome without settlement funding.
Settlement
After positive Payment Outcome Report and settlement direction:
- RTR Clearing and Settlement transfers value under rules.
Funding/defunding
Rule 8 provides processes:
- direct participants fund RTR settlement accounts by sending a payment through Lynx under the Bank agreement;
- defunding transfers out through the RTR Clearing and Settlement Portal, followed by a Lynx payment from the Bank.
The Bank policy also says a direct RTR participant that is not a Lynx direct participant must arrange for a Lynx direct participant to fund and receive defunding payments before the RTR account becomes operational.
This links high-value infrastructure and real-time liquidity operations.
24/7 treasury
RTR operating cycle requires:
- settlement balance monitoring;
- overnight/weekend coverage;
- funding plan;
- alerts.
A retail front end cannot be 24/7 while treasury has no out-of-hours operating model.
6. Payee funds availability and posting
Rule 6 says:
- upon Settlement Outcome Message,
- subject to Rule 7 exceptions,
- receiving participant must make amount available promptly,
- no later than 60 seconds from receiving Settlement Outcome Message.
This creates strong operational requirement.
Receiving-bank workflow
Settlement outcome
→ identify account
→ post
→ funds available
→ notify payee
60-second clock
This is not a marketing target.
It is a rule-based maximum under Rule 6, subject to Rule 7 exception cases.
Receiving systems need:
- high availability;
- low-latency ledger;
- exception routing.
Customer account state
Receiving bank should track:
- settlement received;
- posting pending;
- credited;
- Rule 7 exception;
- return initiated.
Sender status
Sending participant must make payment status available promptly or according to customer agreement.
Do not show “failed” during temporary unknown.
7. Rule 7 exceptions and returns
Rule 7 covers cases where receiving participant can be relieved of normal funds-availability obligation.
Duplicate / error
If before crediting payee the receiving participant discovers:
- duplicate UETR;
- error/omission preventing credit,
Rule 7 requires return according to procedures, generally as soon as possible and no later than next business day following Settlement Outcome Message for specified cases.
Foreign currency account
If payee account is non-CAD and receiving participant chooses not to convert:
Malicious/harmful content
Receiving participant may:
- return;
- make available when appropriate;
- otherwise treat per contractual arrangements, as allowed by Rule 7.
Event beyond control
If technical malfunction/event beyond reasonable control prevents credit:
- make amount available as soon as reasonably practicable after restoration, subject to rule conditions.
This is different from immediate return.
Payee/account restriction
If receiving FI restriction prevents credit:
Law/court restriction
If sanctions/AML/court law prevents credit:
- return or otherwise treat in accordance with law.
Rule 7 specifically includes economic sanctions, AML/ATF and taxation within the law concept in this context.
Payee request
Where receiving participant agreed to payee request not to make amount available:
After payee credit
Rule 7 also covers exceptions to final and irrevocable payment after amount was made available, including:
- Processing Error;
- End-User Error;
- Unauthorized RTR Payment;
- Authorized RTR Payment Fraud;
- specified deceased/legal circumstances.
Payment Return Request
A sending participant can initiate a return request under Rule 7 for permitted reasons.
Request is not a return. A Sending Participant may submit one request within 60 calendar days after exchange, and must identify the original UETR, acceptance date/time, amount and permitted reason.
The Receiving Participant must respond within 10 calendar days by accepting, rejecting or requesting an extension. The Sending Participant may grant no more than 30 calendar days; absent an accept/reject response within that period, the request is deemed rejected. The receiving participant may also request additional information.
A successful response can still return less than the original amount if the receiving participant cannot return the full amount; the response should explain the difference.
Method of return
A successful return is a separate RTR return event under current rules/specifications.
Original settlement remains historical.
8. Uncertain outcomes and duplicate prevention
Real-time timeout is dangerous.
The uncertain-status diagram above governs the scenario below: communicate the timeout honestly first, then prevent the duplicate — never the reverse.
Scenario
Elena confirms payment.
Bank sends pacs.008.
Customer mobile app loses connection.
She sees spinner then:
“Something went wrong.”
She taps pay again.
Without controls:
Correct approach
Use:
- bank payment ID;
- UETR;
- idempotency key;
- status request.
Rule 6 provides Payment Status Request Message process when receiving participant does not receive expected outcome/settlement messages. Bank internal systems should similarly query/reconstruct rather than blindly resend.
UETR duplicate protection
Same UETR reused:
- RTR Exchange rejects duplicate within 90-day rule window.
But bank should not intentionally rely on RTR rejection as its only duplicate control.
Use internal idempotency first.
Unknown state
Customer status:
“Confirming payment status — do not resend.”
Operations:
- query Exchange;
- check outcome;
- settlement.
If settled
Repair customer status.
Do not create new payment.
If rejected
Release any customer reservation/correct accounting and show reason.
If truly not submitted
A new send can proceed under controlled original instruction/new UETR as appropriate.
9. Fraud, sanctions and customer communication
Authorized fraud
Elena is deceived by fake contractor.
CoP:
- may match if fraudster owns matching account.
Authentication:
Central analytics:
Bank:
- combine signals;
- warn/decline/challenge under policy.
CoP mismatch
Customer can choose proceed under Rule 13.
Bank should clearly display:
- mismatch/unavailable;
- risk.
Central Risk List
Rule 13 requires participants to populate Central Risk List data according to Fraud Services Manual.
Receiving-side fraud contributes network intelligence.
Fraud after settlement
Customer calls immediately.
Actions:
- secure account;
- open fraud case;
- initiate Rule 7 return request process;
- contact receiving fraud;
- track recovered amount.
Do not tell customer payment was cancelled.
Sanctions
Receiving participant may require additional information under Rule 7 and associated sanctions procedures.
Customer communication:
- under review;
- avoid revealing sensitive screening logic.
Privacy
Central Fraud Services require fraud data contributions.
Participants must manage privacy/legal obligations alongside rule requirements.
10. Architecture, operations and reconciliation
Sending architecture
Customer app
→ authentication
→ payment service
→ CoP
→ fraud / Central Fraud Analytics
→ limits
→ pacs.008 / API
→ RTR Exchange
→ outcome
→ ledger/status
Settlement architecture
RTR Exchange
→ settlement instruction
→ RTR Clearing & Settlement
→ reservation
→ settlement
→ Settlement Outcome Message
Receiving architecture
pacs.008
→ account validation
→ pacs.002
→ settlement outcome
→ ledger posting
→ payee notification
→ exceptions/returns
State model
CREATED
AUTHENTICATED
COP_COMPLETED
FRAUD_ASSESSED
SUBMITTED
ACCEPTED / REJECTED
FUNDS_RESERVED
OUTCOME_POSITIVE
SETTLED
PAYEE_CREDITED
RETURN_REQUESTED
RETURNED
UNKNOWN
Reconciliation
Sending:
- customer debit/reservation;
- pacs.008;
- Payment Outcome;
- Settlement Outcome;
- settlement position.
Receiving:
- settlement outcome;
- customer credit;
- Rule 7 returns.
Direct participant
Reconcile:
- RTR settlement account;
- payment capacity;
- reserved balance;
- settlement.
Indirect
Reconcile:
- sponsor/settlement agent;
- ISP net position;
- net debit cap;
- customer payments.
Reporting
Customers need:
- status;
- statement;
- references.
Operations need:
- UETR;
- fraud assessment reference;
- outcome;
- settlement;
- return case.
11. End-to-end real-time scenarios
Scenario A: successful payment
Elena pays CAD 12,500.
- authenticate;
- CoP match;
- Central Fraud Analytics assessment;
- bank fraud decision approve;
- create pacs.008 with unique UETR;
- Exchange validates;
- receiving participant accepts pacs.002;
- funds reserved;
- positive Payment Outcome;
- settlement;
- Settlement Outcome;
- contractor credited within rule timeframe;
- both customers informed;
- reconcile.
Scenario B: CAD 125,000 payment
RTR Exchange limit = CAD 100,000.
Bank should reject before submission or Exchange rejects for value limit.
Customer chooses:
- Lynx/other appropriate product.
Do not split payment automatically to evade limit.
Scenario C: USD payment
RTR payment obligation must be CAD.
USD is not eligible as the RTR payment obligation. For an international electronic funds transfer, Rule 6 also states that before September 30, 2027 the domestic leg may not be sent through RTR; from that date the Sending Participant must identify the international EFT with the required INTL code under the current companion specification. Use the applicable cross-border or other domestic rail instead.
This is a Payments Canada rule distinction, not a claim that a bank cannot offer USD or cross-border services through another scheme.
Scenario D: wrong account format
Receiving participant rejects pacs.002 with applicable account reason.
No successful payment outcome/settlement.
Sending bank:
- correct customer reservation;
- show rejection.
Scenario E: settled but account restricted
Receiving participant encounters Rule 7 account restriction.
Return initiated under Rule 7.
Original settlement existed.
Return is new event.
Scenario F: app timeout
Payment settles but sender app response lost.
Idempotency/status query proves settlement.
No duplicate.
Scenario G: scam after settlement
Customer genuinely authorized but was deceived.
Fraud case:
- Rule 7 return request;
- receiving participant decision;
- recovery not guaranteed.
Rule-driven state model in more detail
The approved RTR lifecycle is easier to operate when the bank stores each business event independently.
A useful conceptual state chain is:
CUSTOMER_CREATED
CUSTOMER_AUTHENTICATED
COP_RESULT_RECEIVED
CENTRAL_FRAUD_ASSESSMENT_RECEIVED
PARTICIPANT_RISK_APPROVED
PACS008_CREATED
SUBMITTED_TO_EXCHANGE
EXCHANGE_VALIDATED
RECEIVING_ACCEPTED
FUNDS_RESERVED
PAYMENT_OUTCOME_POSITIVE
SETTLEMENT_DIRECTED
SETTLED
PAYEE_CREDITED
Exception branches can include:
EXCHANGE_REJECTED
RECEIVING_REJECTED
SETTLEMENT_CAPACITY_EXCEPTION
RULE7_EXCEPTION
PAYMENT_RETURN_REQUESTED
RETURNED
STATUS_UNKNOWN
The bank should not compress all of these into a single success, failed or pending flag.
Customer channel versus external state
The mobile app is only one observer.
For example, the Exchange may accept and settle a payment while the customer's app loses its response. The app can show an unknown state even though the financial payment is settled.
The bank's authoritative payment state must come from durable payment events, not the device session.
Customer confirmation screen
Because Rule 6 says a payment cannot be cancelled, revoked or amended after it is submitted to the RTR Exchange, the final customer confirmation screen is important.
It should clearly show:
- amount;
- payee;
- account/name confirmation result where applicable;
- fees;
- reference;
- warning for a risky confirmation-of-payee result.
That is the last customer-controlled decision point before submission.
System value limit versus customer limit
The RTR Exchange limit is CAD 100,000.
A bank can set a lower:
- consumer limit;
- small-business limit;
- channel limit;
- risk limit.
The payment service should enforce the lower applicable limit before constructing the outgoing payment.
Do not send a CAD 125,000 transaction to the Exchange merely to receive a system rejection when the bank can reject it earlier and direct the customer to an appropriate alternative rail.
Splitting payments
A customer may ask whether CAD 125,000 can be sent as two smaller payments.
The bank should not automatically split a payment to circumvent the system or customer limit.
Whether separate payments are allowed depends on:
- genuine customer intent;
- product terms;
- fraud controls;
- AML monitoring;
- bank policy.
The bank should also be able to identify suspicious artificial splitting where relevant.
CAD-only validation
Currency validation should occur at:
- channel;
- payment service;
- message validation.
The funding account can be another currency only if the bank has a valid FX process that ultimately creates a CAD RTR payment obligation. The RTR payment itself must be CAD under current Rule 6.
A non-CAD payee account creates a specific Rule 7 situation if the receiving participant chooses not to convert.
UETR generation
The bank should generate and preserve a UETR before submission.
Controls:
- valid format;
- uniqueness;
- immutable association to the business payment;
- searchability.
Internal retries before external submission should preserve one business payment identity and avoid accidentally generating multiple outgoing payments.
Duplicate UETR rule
The Exchange applies the approved 90-calendar-day duplicate check.
That is a network-level safeguard.
The bank still needs earlier duplicate protection using:
- client request ID;
- channel idempotency key;
- bank payment ID;
- replay protection.
Layered controls are stronger because they stop the duplicate before it reaches the rail.
Message-validation pipeline
Before the pacs.008 is introduced to the Exchange, a robust validation chain can include:
- ISO 20022 syntax/schema;
- current RTR usage specification;
- mandatory Rule 6 data;
- CAD currency;
- value limit;
- participant/reachability information;
- UETR uniqueness;
- participant business controls.
A schema-valid message can still be business-invalid.
Receiving participant acceptance
The receiving participant's pacs.002 is a business outcome, not just a network acknowledgement.
It can reject for conditions allowed by Rule 6, including:
- duplicate;
- value limit;
- invalid account;
- wrong currency;
- formatting;
- malicious/harmful content;
- other supported reason.
The sending bank should preserve the external reason code and translate it into plain customer wording.
Receiving-side response monitoring
The bank should monitor:
- time pacs.008 was received;
- time pacs.002 was produced;
- delays or missing response.
Where expected status messages are missing, use the approved status/query processes rather than generating another customer payment.
Payment Outcome Report
A positive Payment Outcome Report reflects more than receiving-bank acceptance.
The approved flow also depends on successful funds reservation under the settlement model.
This helps prevent a customer-facing positive outcome from being created without sufficient settlement capacity.
Settlement Outcome Message
The Settlement Outcome Message is a decisive financial event.
Sending participant:
- can finalize the payment's settlement state.
Receiving participant:
- starts the Rule 6 funds-availability obligation, subject to Rule 7 exceptions.
Reconciliation:
- uses the event as settlement evidence.
Customer status design
A customer-facing model might distinguish:
| Payment state | Customer status |
|---|
| pre-submit validation | Reviewing |
| submitted | Sending |
| receiving reject | Could not send + clear reason |
| settlement pending | Processing |
| settled | Sent/Completed on sender side |
| recipient credited where known | Received |
| external state unknown | Confirming status — do not resend |
| return requested | Return requested |
| return settled | Returned |
Banks can use different wording, but they should not report a payment as failed when its settlement status is unknown.
Rule 13 participant accountability
Central Fraud Services do not replace the sending participant's responsibility.
The participant still owns:
- customer authentication;
- its transaction monitoring;
- local customer/account data;
- the final decision to submit.
Central Fraud Analytics is a shared network-level input to that decision.
MFA or equivalent
Rule 13 requires the sending participant to have and use suitable authentication capability.
A bank may implement:
- device-bound authenticator;
- biometrics;
- passkey;
- OTP with additional controls;
- other industry-appropriate mechanisms.
Training should not prescribe one method as the only compliant design.
Authentication versus authorization versus fraud
Authentication asks:
“Is this Elena?”
Authorization asks:
“Does Elena intend to pay CAD 12,500 to this payee?”
Fraud decisioning asks:
“Even if Elena intends it, is she being deceived or is the transaction otherwise suspicious?”
These are three different controls.
Confirmation of Payee customer journey
The bank should:
- obtain the applicable confirmation result;
- show the customer understandable information;
- explain risk;
- record what was displayed;
- record whether the customer chose to proceed.
The precise result codes and UI wording must follow the current Confirmation of Payee specification/manual. They should not be invented from a training example.
Confirmation of Payee unavailable
If the service is unavailable:
- the bank follows the approved operating procedures and its risk policy.
It should never fabricate a match result.
Confirmation mismatch prevention example
Elena expects to pay North Star Renovations.
The confirmation result indicates the supplied payee details do not align.
Elena calls the contractor and discovers that the invoice email was compromised.
The payment never reaches pacs.008 submission.
This is a control success before settlement risk begins.
Confirmation match does not prove legitimacy
A fraudster can operate an account under a legitimate-looking name.
A match can coexist with an investment scam, romance scam, purchase scam or compromised invoice.
That is why central analytics, local behavior and customer warnings remain necessary.
Central Fraud Analytics orchestration
A conceptual decision sequence is:
Payment proposal
→ central assessment
→ participant local model
→ participant policy
→ approve / challenge / decline
Store:
- central assessment reference;
- local decision;
- rule/model version;
- reason.
Central Risk List value
The Fraud Services framework enables risk information to be shared according to the approved manuals/rules. Rule 13 also requires participants to populate the list as specified and retain all Fraud Data provided to it for at least 13 months. This is a network control; it does not replace local fraud investigation or applicable privacy law.
A receiving account that appears suspicious across multiple institutions can become visible at a network level that one sending bank could not build alone.
Fraud-service latency
A real-time orchestration has a latency budget.
The bank may need to complete:
- authentication;
- payee confirmation;
- central fraud assessment;
- local fraud assessment;
- limits;
- compliance controls;
- message creation.
An ordinary payment cannot wait for a long manual review and still behave as real-time at scale.
Policy should define how higher-risk cases are handled.
Fraud-service outage
If a Central Fraud Service required by Rule 13 is unavailable, the participant should follow Payments Canada operating procedures and its approved bank policy.
It should not silently bypass a required service just to maintain speed.
Sanctions screening in real time
The bank still needs applicable sanctions controls.
The design challenge is:
- low latency;
- false-positive management;
- complete party data;
- specialist escalation.
Legal obligations do not disappear because the customer expects an instant response.
AML monitoring
Some controls act before payment to prevent fraud or prohibited activity. AML behavioral monitoring can also operate near-real time or after the transaction for pattern detection and reporting.
Fraud prevention and AML reporting are related but different.
Rule 8 direct participant liquidity model
A Direct Settlement Participant must maintain sufficient payment capacity.
Operational monitoring should include:
- settlement balance/capacity;
- funds reserved;
- outgoing/incoming velocity;
- thresholds;
- funding actions.
RTR liquidity should be integrated into treasury monitoring rather than treated as a hidden payment-engine field.
Funding through Lynx
Rule 8's funding process connects Lynx and RTR liquidity.
This means the bank's high-value infrastructure and treasury procedures are relevant to real-time settlement funding.
Treasury should plan funding before a weekend or expected volume peak rather than relying only on emergency action.
Defunding
Excess RTR settlement funds may be moved out through the approved process.
The treasury objective is to maintain enough capacity while using liquidity efficiently.
Indirect Settlement Participant
An indirect settlement participant relies on its Settlement Agent.
The ISP should understand:
- current position;
- net debit cap;
- sponsor limits;
- funding/prefunding terms;
- incident contacts.
A customer-facing real-time service can depend on this bilateral settlement relationship.
Settlement Agent concentration
A Settlement Agent supporting many clients should monitor:
- per-client position;
- aggregate position;
- client concentration;
- client funding;
- default risk;
- 24/7 operational coverage.
Net Debit Cap scenario
An ISP approaches its net debit cap.
A new payment may be unable to progress under the applicable settlement rules/arrangement until capacity is available.
The customer should receive an accurate product status, not a misleading “fraud failure.”
Weekend liquidity stress
Saturday evening, a fintech client experiences unexpectedly high outgoing volume.
The Settlement Agent sees:
- rapid net debit;
- liquidity threshold warning;
- concentration at one client.
Response:
- client funding action;
- treasury escalation;
- applicable limits/controls.
This is why a 24/7 front end requires a 24/7 financial-control model.
Funds-availability timer
After receiving the Settlement Outcome Message, the receiving participant must meet the Rule 6 funds-availability requirement subject to Rule 7 exceptions.
The receiving architecture therefore needs:
- available account service;
- real-time ledger;
- exception classification;
- operational monitoring.
A nightly-only posting model is not sufficient.
Posting idempotency
If a settlement outcome event is redelivered, the ledger should use a stable event identity/UETR and return the existing posting result.
A second delivery must not produce a second customer credit.
Receiving account closed or invalid
Where the receiving participant can identify the problem before acceptance, it can reject using the applicable Rule 6 code.
Where a post-settlement condition arises, Rule 7 governs the relevant exception/return treatment.
Receiving account restriction
Rule 7 includes cases where a receiving-participant or payee-account restriction prevents normal credit.
The receiving institution should classify the condition accurately, retain the evidence and follow the approved return/treatment process.
Technical malfunction after settlement
Rule 7 includes an event-beyond-control treatment.
A temporary ledger or technology failure does not automatically mean every affected settled payment should be returned. The receiving participant may need to restore service and make the funds available as soon as reasonably practicable under the applicable rule.
Malicious or harmful content
Rule 6 and Rule 7 include treatments for malicious/harmful content.
Payment systems should protect themselves from harmful data without losing the financial identity of the transaction or creating duplicate corrective actions.
Law and court restriction
Rule 7 recognizes legal restrictions, including contexts such as economic sanctions and AML/ATF.
Payment operations should supply the payment facts while compliance/legal owns the legal disposition.
End-User Error after credit
Elena enters the wrong but valid recipient.
She intended to send CAD 12,500, and the payment settled and credited.
This is not an unauthorized transaction.
Rule 7 recognizes End-User Error as one of the relevant categories for the return-request framework after funds have been made available.
Recovery is not guaranteed merely because the customer made a mistake.
Unauthorized RTR Payment
If Elena did not authorize the transaction:
- secure account;
- identify exact payment;
- open fraud case;
- initiate the applicable Rule 7 return request;
- coordinate with receiving participant;
- handle reimbursement separately under law/product policy.
Authorized RTR Payment Fraud
If Elena authenticated and intentionally sent the payment because a scammer deceived her, the case is different from account takeover.
Rule 7 explicitly recognizes Authorized RTR Payment Fraud.
Successful authentication does not end the fraud analysis.
Processing Error
A participant/system error can include:
- duplicate;
- wrong value;
- wrong routing due to processing defect.
The bank uses the applicable return/recovery process and separately handles customer remediation and incident root cause.
Payment Return Request lifecycle
A controlled case can move through:
RETURN_REQUEST_CREATED
RECEIVING_REVIEW
INFORMATION_REQUESTED
ACCEPTED / REJECTED
RETURN_PAYMENT_CREATED
RETURN_SETTLED
CUSTOMER_OR_BANK_ACCOUNTING_COMPLETED
The request status and the financial return status must remain separate.
Additional-information requests
The receiving participant may ask for more information under the return-request process.
The case should store:
- exact request;
- timestamp;
- response;
- deadlines/extensions where applicable;
- final disposition.
Customer communication on recovery
Safe wording:
“We have asked the receiving institution to return the payment. Recovery is not yet confirmed.”
Unsafe wording:
“Your payment has been reversed.”
Return settlement
When returned value actually settles:
- sending participant receives the money;
- customer or bank exposure is adjusted according to case;
- reconciliation closes both original and return events.
Customer reimbursement before recovery
A bank may decide to reimburse a fraud victim before interbank recovery completes.
If value later returns, it may clear the bank's recovery exposure rather than create another customer credit.
Case management must prevent double payment.
Uncertain-state architecture
Every integration should have:
- command/request ID;
- idempotency key;
- durable event history;
- status query;
- duplicate detection.
A timeout means unknown until proven otherwise.
Unknown-state runbook
- stop customer/automatic retry;
- search original payment ID and UETR;
- check Exchange response;
- check Payment Outcome;
- check Settlement Outcome;
- check ledger;
- classify;
- update the customer.
Lost pacs.002
If expected status does not arrive, the approved status mechanisms should be used.
Do not generate another pacs.008 simply because a response message was lost.
Lost Settlement Outcome
The payment may already be settled.
Reconstruct from authoritative payment/settlement evidence before any retry or customer refund.
Customer app retry
The channel should reuse a client idempotency key.
If the original payment is settled, the app should show the original result.
Reconciliation hierarchy
For one RTR payment:
Customer instruction
↔ authentication and fraud evidence
↔ pacs.008 / UETR
↔ pacs.002
↔ funds reservation / Payment Outcome
↔ Settlement Outcome
↔ customer debit / payee credit
↔ return if any
Every layer should preserve the same core payment identity.
Direct settlement reconciliation
For a direct settlement participant, reconcile:
- opening capacity;
- funding;
- reservations;
- settled outgoing/incoming;
- defunding;
- closing position.
Indirect reconciliation
For an ISP, reconcile:
- customer payments;
- Settlement Agent reports;
- ISP position;
- net debit cap;
- customer ledger.
Fraud-control reconciliation
Where Rule 13 requires Central Fraud Analytics for every RTR Payment Message, the bank should be able to prove that submitted payment population has the required fraud assessment evidence.
Confirmation-of-payee audit
The bank should be able to retrieve:
- CoP service request;
- result;
- customer choice;
- final fraud decision.
This is useful for complaints and fraud investigations.
Continuous accounting date
Payments can settle around midnight.
The bank needs deterministic:
- booking date;
- value date;
- statement date;
- GL business date.
Continuous service cannot depend on a nightly system shutdown.
Operational support coverage
A real-time service needs defined coverage for:
- payments;
- technology;
- fraud;
- treasury/liquidity;
- compliance escalation;
- incident management.
The exact staffing model can use full-time and on-call roles, but critical decisions must be reachable 24/7.
Incident: Exchange connectivity loss
The sending bank should distinguish:
- customer instructions not yet submitted;
- payments with unknown external state.
After restoration:
- submit only items proven unsent;
- query the unknown population.
Incident: receiving-ledger outage
The receiving participant follows the applicable Rule 7 event-beyond-control process, restores service, posts/returns according to the approved rule, and reconciles the affected population.
Incident: Settlement Agent disruption
An indirect participant cannot assume settlement capacity is unchanged.
It activates the bilateral/settlement-agent incident process and communicates customer availability accurately.
Incident: Central Fraud Service outage
The participant follows the RTR operating procedures and its approved risk policy. A required fraud capability is not simply bypassed.
Cyber incident
If a participant suspects credentials or payment infrastructure compromise:
- contain access;
- preserve events;
- stop unsafe submissions if necessary;
- coordinate with Payments Canada/partners under applicable procedures;
- reconcile affected payments.
Business-continuity testing
Test:
- region failure;
- database restore;
- message replay;
- network partition;
- fraud-service failure;
- settlement-agent failure;
- ledger failure.
A test passes only if there is no lost or duplicate financial outcome.
Observability
Technical metrics:
- submission latency;
- pacs.002 latency;
- Exchange rejects;
- Settlement Outcome latency;
- ledger latency.
Business metrics:
- submitted;
- accepted;
- rejected;
- settled;
- payee credited;
- returned;
- fraud outcomes;
- CoP use;
- payment capacity.
Measuring the 60-second rule
The relevant clock is tied to receipt of the Settlement Outcome Message by the receiving participant, subject to Rule 7.
Do not measure from customer button press and call that the same rule-based metric.
Performance testing
Test:
- normal traffic;
- burst traffic;
- corporate peaks;
- weekends;
- failover recovery plus new traffic.
Fraud services, settlement interfaces and ledgers all need sufficient capacity.
Data retention and evidence
Retain according to applicable rules/law/policy:
- customer instruction;
- authentication;
- CoP;
- fraud assessment;
- messages;
- outcomes;
- settlement;
- returns;
- cases.
Access control
Payments operations can view payment state.
Fraud users need fraud detail.
Compliance users need restricted legal/sanctions information.
Treasury needs settlement positions.
Manual financial correction should be separately privileged.
Business analyst functional checklist
- CAD validation;
- applicable amount limit;
- unique UETR;
- authentication;
- CoP;
- Central Fraud Analytics;
- participant fraud decision;
- pacs.008;
- pacs.002;
- reservation;
- Payment Outcome;
- Settlement Outcome;
- payee posting;
- Rule 7 exception;
- return request;
- status query.
Business analyst non-functional checklist
- real-time latency;
- 24/7 availability;
- idempotency;
- resilience;
- observability;
- audit;
- privacy;
- security;
- disaster recovery.
Developer acceptance examples
Given a customer double-clicks Pay, when both channel requests carry the same idempotency key, then only one bank payment exists.
Given settlement occurred but the app response was lost, when the customer queries status, then the original settled payment is returned and no second payment is created.
Given a Settlement Outcome event is delivered twice, when the receiving ledger processes it, then the payee is credited exactly once.
Tester end-to-end matrix
| Scenario | Expected result |
|---|
| low-risk eligible payment | progresses to Exchange |
| CoP concern, customer stops | no pacs.008 |
| customer proceeds after CoP warning | participant fraud decision still applies |
| high fraud risk | challenge/decline per policy |
| CAD 125,000 | reject as over applicable RTR limit |
| USD | not eligible as RTR payment obligation |
| duplicate UETR | Exchange reject |
| invalid payee account | pacs.002 reject |
| settlement capacity insufficient | no valid settled outcome until requirements met |
| settled | Settlement Outcome recorded |
| receiving technical outage | Rule 7 handling |
| wrong recipient after credit | return-request case |
| scam after credit | Authorized RTR Payment Fraud case |
| app timeout | state query, no duplicate |
Go-live readiness checklist
Before production:
- participant onboarding complete;
- direct/indirect settlement model ready;
- settlement account or Settlement Agent arrangement ready;
- ISO 20022 certification complete;
- CoP integrated;
- Central Fraud Analytics integrated;
- Central Risk List processes ready;
- 24/7 ledger ready;
- liquidity monitoring ready;
- Rule 7 operations ready;
- reconciliation ready;
- incident contacts tested;
- customer terms updated;
- support trained.
Controlled launch
During initial production:
- monitor every unusual reject;
- reconcile frequently;
- watch payment capacity;
- monitor fraud;
- monitor customer complaints;
- scale only after financial integrity is proven.
Final payment story
Elena pays CAD 12,500.
The customer experience may take seconds.
Behind those seconds:
- authentication proves the customer;
- CoP gives payee information;
- central and local fraud controls assess risk;
- Rule 6 validates the pacs.008;
- the receiving participant accepts;
- Rule 8 reserves value;
- settlement completes;
- the receiving FI credits the contractor within the rule-based requirement;
- both sides reconcile.
If Elena's app loses the final response, the bank does not “try the payment again.”
It proves what already happened.
That is the defining discipline of real-time payments: speed at the customer edge, certainty at the financial core.
Full operational timeline for one successful RTR payment
A useful readiness test is to place every event on one timeline.
Illustrative sequence after production launch:
T0 — customer taps Pay
- customer has reviewed payee, amount and reference.
T0 + authentication
- sending participant verifies the payor using its approved authentication controls.
Next — confirmation of payee
- result returned;
- customer sees the result/risk information;
- customer chooses whether to continue where Rule 13 requires that choice.
Next — fraud assessment
- Central Fraud Analytics returns a Fraud Assessment;
- sending participant combines it with local fraud information;
- participant makes its decision.
Next — payment creation
- bank assigns payment ID and unique UETR;
- validates CAD and limit;
- creates pacs.008.
Next — Exchange
- message passes RTR Exchange validation;
- forwarded to receiving participant.
Next — receiving response
- receiving participant returns pacs.002 accept/reject.
Next — reservation
- settlement capacity is reserved according to Rule 8.
Next — positive Payment Outcome
- Exchange can provide the positive outcome when required conditions are met.
Next — settlement
- settlement instructions implemented;
- Settlement Outcome Message produced.
Next — payee posting
- receiving participant makes funds available promptly and within the Rule 6 maximum, unless Rule 7 exception applies.
Next — customer reporting
- sender/receiver channels update;
- ledger/statement events recorded.
Next — reconciliation
- one instruction;
- one UETR;
- one settlement;
- one debit;
- one credit.
The timeline is educational rather than a promise of a specific end-to-end number of seconds, because participant/system processing details and service-level rules govern exact timings.
Full timeline for a receiving rejection
Elena enters an invalid payee account.
Sending bank:
- authenticates;
- fraud controls pass;
- submits pacs.008.
Receiving participant:
- validates;
- returns pacs.002 rejection with the appropriate reason.
No successful payment outcome should be presented as settlement.
Sending bank:
- updates payment to rejected;
- releases/corrects any customer reservation;
- tells Elena to correct payee details.
A new corrected payment should have:
- its own payment identity;
- its own UETR;
- fresh fraud/CoP treatment as appropriate.
Full timeline for a scam after settlement
Elena pays a fraudster.
Everything appears technically valid:
- MFA passed;
- customer intended payment;
- pacs.008 valid;
- receiving accepted;
- settlement completed;
- fraudster account credited.
Five minutes later Elena realizes the contractor email was compromised.
The bank should:
- secure Elena's digital access if compromise is possible;
- classify Authorized RTR Payment Fraud if facts support it;
- open urgent fraud/recovery case;
- initiate Rule 7 Payment Return Request for an applicable reason;
- contact receiving-side fraud operations;
- capture original UETR and settlement evidence;
- track the receiving participant's response;
- record any returned amount;
- handle customer reimbursement separately;
- assess AML/reporting obligations separately.
This demonstrates why “authorized” does not mean “not fraud.”
Full timeline for an unknown app outcome
Customer taps Pay.
Bank submits.
The channel connection drops before the app receives status.
Internal state:
The channel must not create a new payment on the customer's next tap if the client request is the same.
The payment service queries:
- Exchange status;
- outcome;
- settlement.
If settlement exists:
If receiving rejection exists:
If still unknown:
- show a controlled pending/confirming state and continue investigation.
This is one of the most important real-time payment implementation patterns.
Real-time customer-support decision tree
Customer says:
“Payment is stuck.”
Support should retrieve:
- payment ID;
- UETR;
- current Rule 6 state;
- customer ledger state;
- any Rule 7 case.
Then classify:
Not submitted
Receiving rejected
Submitted/response missing
- status inquiry; no resend.
Settled
- payment completed at settlement level.
Settled but payee not credited
- receiving-side Rule 7/posting investigation.
Return requested
- recovery pending, not complete.
Returned
- reconcile customer/bank accounting.
Real-time corporate use case
A business uses RTR for a CAD 48,000 supplier payment.
Additional controls:
- maker/checker;
- supplier beneficiary master;
- invoice reference;
- corporate limit;
- fraud.
The underlying RTR rail does not remove corporate authorization.
The bank can expose API:
- request ID;
- status;
- UETR;
- final outcome.
ERP should close invoice only after appropriate completion state.
Business batch illusion
Even if a corporate channel allows a user to submit many RTR payments together, the Exchange operates on individual RTR Payment Messages.
The bank must preserve:
- one UETR per payment;
- one fraud assessment per required payment;
- one outcome/settlement state per payment.
A “bulk upload” at the channel layer does not turn the RTR into a net batch rail.
Remittance and data
A real-time supplier payment can carry structured remittance according to the applicable ISO 20022 specification.
Business benefit:
- recipient can automatically match invoice quickly.
The bank should preserve customer references through:
- pacs.008;
- customer ledger;
- reports.
Do not sacrifice useful data for low latency.
Payment purpose and fraud
Richer payment purpose can support:
- fraud analytics;
- customer understanding;
- reconciliation.
But customers may enter misleading/fraudster-suggested text.
Purpose is one signal, not proof.
Direct participant treasury runbook
At shift/start:
- current RTR payment capacity;
- expected inflows/outflows;
- funding sources;
- alerts;
- Lynx funding availability/process;
- client concentration.
During:
- monitor reserve/settlement velocity;
- respond to threshold.
Incident:
- distinguish settlement-capacity constraint from technology outage.
Indirect participant runbook
Monitor:
- position with Settlement Agent;
- net debit cap;
- prefunding/credit;
- rejected/held payments;
- sponsor availability.
Escalation:
- agent contact;
- treasury/client funding.
Settlement Agent runbook
For each ISP:
- opening position;
- outgoing/incoming;
- cap;
- funding;
- alerts.
Aggregate:
- agent settlement account;
- concentration.
A single ISP surge should not obscure agent's total liquidity risk.
Reconciliation break examples
Break A
pacs.008 submitted but no final outcome.
Action:
- status query/investigation.
Break B
Settlement Outcome exists, sender customer not debited.
Risk:
Break C
Settlement Outcome exists, receiver customer credited twice.
Risk:
Break D
Return settles, sending customer already reimbursed.
Action:
- apply value to bank recovery exposure, not duplicate credit.
Break E
ISP report differs from Settlement Agent position.
Action:
- urgent settlement/reconciliation investigation.
Real-time accounting model
Sending:
- reservation/debit;
- settlement event.
Receiving:
- settlement inflow;
- customer credit.
Return:
- separate reverse-direction payment event.
Do not mutate original ledger entry to pretend the payment never existed.
Statement model
Sender sees:
If returned:
Recipient sees:
- original credit;
- if return after credit, separate debit/return treatment according to process.
Clear statement references reduce customer confusion.
Fraud-loss accounting
Suppose CAD 12,500 scam.
Bank provisionally reimburses customer CAD 12,500.
Receiving side later returns CAD 7,500.
Bank should track:
- customer reimbursement;
- returned recovery;
- residual exposure CAD 5,000 before other adjustments.
The returned value does not automatically go to customer a second time.
Customer-harm monitoring
Monitor:
- duplicate real-time payments;
- delayed funds availability;
- false “failed” after settlement;
- erroneous CoP display;
- fraud warning failures;
- return-request delays;
- customer debit without settlement.
These metrics identify issues uptime does not.
Rule-version governance
RTR rules and ISO specifications will evolve.
Every implementation rule should have:
- source;
- version;
- effective date;
- owner.
Examples:
- value limit;
- reason code;
- message version.
Do not hard-code regulatory/scheme rules without configuration/change governance where practical.
Standards-change regression testing
When Payments Canada updates specifications:
- parse;
- compare business changes;
- update canonical mapping;
- regression test;
- certify as required;
- update runbooks.
Data-quality monitoring
Measure:
- account validation rejects;
- format rejects;
- wrong currency;
- duplicate UETR;
- missing/invalid required fields.
A spike after release likely indicates mapping defect.
Fraud-control monitoring
Measure:
- CoP calls/results;
- customer proceed decisions;
- central assessment;
- local declines;
- fraud loss;
- mule recoveries.
Use results to tune local controls while respecting service rules.
Liquidity monitoring
Measure:
- minimum payment capacity;
- reservations;
- peak outgoing;
- funding events;
- ISP cap utilization.
An instant-payment product can look healthy to customers until liquidity capacity is exhausted; treasury metrics give earlier warning.
Operational-resilience metrics
- Exchange connectivity availability;
- payment-state unknown count;
- average unknown-state age;
- ledger posting latency;
- financial-integrity recovery time after incident;
- duplicate count after DR.
Launch-day command centre
At initial go-live, include:
- payments operations;
- technology;
- fraud;
- treasury;
- reconciliation;
- customer support;
- compliance;
- Settlement Agent/partners as relevant.
Monitor:
- every rejection reason;
- settlement;
- fraud;
- liquidity;
- customer complaints.
Launch rollback misconception
Once individual production payments settle, a “rollback” cannot erase those payments.
A technical rollback means:
- stop/restore software version;
- preserve settled payment history;
- reconcile.
This is a critical production principle.
Certification evidence
Before go-live, retain:
- connectivity tests;
- ISO conformance;
- fraud-service tests;
- settlement tests;
- Rule 7 cases;
- DR;
- operational sign-off.
Customer terms and disclosures
Product terms should explain:
- eligibility;
- limits;
- irrevocability;
- fraud/customer responsibilities;
- return/recovery limitations;
- fees.
Legal/product teams own wording.
Training customer-service staff
Staff must know:
- RTR is not “reversible like a card authorization”;
- timeout is not failure;
- return request is not guaranteed recovery;
- CoP does not guarantee no scam;
- settled payment remains historical.
Training fraud teams
Fraud teams need:
- UETR search;
- Rule 7 return-request process;
- receiving-side contacts;
- central fraud evidence;
- customer reimbursement workflow.
Training treasury
Treasury needs:
- payment capacity;
- funding/defunding;
- Settlement Agent/ISP positions;
- weekend coverage.
Training reconciliation
Reconciliation needs:
- Exchange messages;
- outcomes;
- settlement;
- ledger;
- return.
Advanced test: midnight rollover
Payment settles at 23:59:58.
Receiver credits at 00:00:03.
Test:
- Rule 6 funds availability;
- booking/value date;
- statement;
- GL;
- reconciliation.
No payment should be lost because the accounting date changed.
Advanced test: duplicate app request with different UETR
A defective channel sends the same business instruction twice but generates two UETRs.
The Exchange duplicate-UETR control cannot catch it.
Bank internal idempotency must.
This proves why network and bank duplicate controls are both necessary.
Advanced test: Central Fraud Analytics high risk but local rule allows
The participant must have a clearly governed policy for how central assessment feeds its final decision.
The test validates:
- assessment stored;
- decision explainable;
- policy followed.
Do not assume one score automatically determines outcome unless the approved service/policy says so.
Advanced test: CoP mismatch + customer proceeds
Test:
- warning displayed;
- customer choice recorded;
- local fraud decision;
- payment proceeds only if bank approves.
Later complaint:
Advanced test: receiving technical outage
Settlement completes.
Receiving core unavailable.
Test:
- Rule 7 exception path;
- no duplicate credit on recovery;
- payee eventually credited/returned correctly;
- customer communication;
- reconciliation.
Advanced test: partial fraud recovery
Original CAD 50,000.
Receiving side can return CAD 20,000.
Case:
- return amount;
- bank/customer exposure;
- separate financial entries.
System must support partial recovery if allowed by applicable return process/specification and business handling, rather than assuming every return equals original value.
Advanced test: Settlement Agent client limit
ISP is near cap.
Payment is not able to proceed as normal.
Test:
- correct participant/settlement outcome;
- customer status;
- no duplicate retries;
- position reconciliation after client funds.
Final RTR readiness questions
A bank should be able to answer:
- What exact event tells us the payment is settled?
- What event starts the receiving funds-availability clock?
- What happens if pacs.002 is missing?
- What happens if the app response is missing?
- How do we stop duplicate business instructions with two UETRs?
- How do we prove CoP and fraud controls ran?
- Who owns weekend settlement capacity?
- How do we handle an ISP cap issue?
- What is the Rule 7 return-request workflow?
- How do we reconcile a return after customer reimbursement?
- Can DR reconstruct every in-flight payment?
- Can support explain the state without telling the customer to resend?
If these answers are operationally tested, the bank is much closer to genuine real-time readiness.
RTR quality gate
Before a participant treats the RTR capability as production-ready, it should be able to prove:
- only eligible CAD payments within the applicable system/customer limits are submitted;
- every submitted payment has unique identity and UETR;
- authentication, confirmation of payee and Central Fraud Analytics evidence is retained;
- pacs.002 and outcome states are distinguished from final settlement;
- funds reservation and settlement capacity are monitored;
- receiving-side funds availability is measured from the correct settlement event;
- Rule 7 exceptions and return requests are implemented as controlled cases;
- timeouts never cause blind duplicate sends;
- direct or indirect settlement positions reconcile continuously;
- 24/7 technology, fraud, treasury and support escalation are operational.
The customer may experience the payment as one tap. The bank must be able to reconstruct every event behind that tap.
Practical production acceptance workshop
Use four simulated RTR payments:
- CAD 12,500 normal success;
- CAD 125,000 over the Exchange limit;
- CAD 8,000 app timeout after settlement;
- CAD 20,000 authorized scam reported after payee credit.
For each, the team must show:
- customer instruction;
- authentication;
- confirmation of payee;
- Central Fraud Analytics evidence;
- participant decision;
- pacs.008/UETR if submitted;
- pacs.002/outcome;
- settlement state;
- ledger;
- Rule 7 case if applicable.
The timeout test is the most important: no team is allowed to create another payment until the original state is proven.
RTR handover documentation
Maintain:
- current Rules 6, 7, 8 and 13;
- ISO 20022 specifications;
- system/customer limits;
- CoP/fraud-service operations;
- settlement-capacity procedures;
- direct/indirect settlement model;
- funds-availability monitoring;
- Rule 7 return cases;
- reconciliation;
- 24/7 incident contacts.
Final learning check
Remember:
- the RTR is still a planned Q4 2026 launch at the 5 October 2026 audit date;
- real time does not collapse authentication, acceptance, settlement and posting into one event;
- once submitted to the Exchange the sending participant cannot simply cancel or amend the payment;
- Rule 7 return/recovery is a new process after the original payment state;
- uncertainty is resolved through state evidence and idempotency, never by blind resend.
12. Testing, takeaways and authoritative references
Rule 6 tests
- CAD valid;
- international-EFT indicator rule: before September 30, 2027, do not send the domestic leg of an international EFT through RTR; from that effective date, use the required
INTL Service Level code;
-
100k;
- non-CAD;
- duplicate UETR;
- malformed;
- invalid account;
- pacs.002 accept;
- pacs.002 reject.
Rule 13 tests
- MFA;
- CoP match;
- mismatch and customer choice;
- Central Fraud Analytics unavailable;
- high-risk assessment;
- Central Risk List integration.
Rule 8 tests
- sufficient capacity;
- insufficient capacity;
- indirect net debit cap;
- reservation;
- settlement;
- funding/defunding.
Rule 7 tests
- duplicate before credit;
- foreign currency account;
- harmful content;
- technical outage;
- account restriction;
- legal restriction;
- end-user error;
- unauthorized fraud;
- authorized fraud;
- return request accept/reject.
Resilience tests
- Exchange timeout;
- lost pacs.002;
- lost Settlement Outcome;
- ledger outage;
- fraud service outage;
- CoP outage;
- DR;
- duplicate retry.
Final takeaways
Real time does not mean “no controls.”
It means every control must complete before customer patience expires and every uncertain state must be resolved without creating a duplicate.
At 5 October 2026:
- the RTR By-law and Rules are in force from August 24, 2026;
- Payments Canada still targets Q4 2026 launch with sequenced onboarding;
- banks should be testing the approved rule-based lifecycle, not representing it as current production capability.
Authoritative references
- Payments Canada — RTR Rules and documentation: https://www.payments.ca/systems-services/rules-documentation
- Payments Canada — RTR Rule 6, RTR Exchange: https://www.payments.ca/sites/default/files/rtr_rule6.pdf
- Payments Canada — RTR Rule 7, Funds Availability Exceptions and Returns: https://www.payments.ca/sites/default/files/rtr_rule7.pdf
- Payments Canada — RTR Rule 8, Clearing, Settlement, Funding and Defunding: https://www.payments.ca/sites/default/files/rtr_rule8.pdf
- Payments Canada — RTR Rule 13, Fraud Management: https://www.payments.ca/sites/default/files/rtr_rule13.pdf
- Payments Canada — RTR testing and launch: https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/testing-and-launch
- Payments Canada — By-law and rules approved for RTR: https://www.payments.ca/critical-milestone-achieved-law-and-rules-approved-canadas-real-time-rail
- Bank of Canada — RTR settlement account access policy: https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/bank-canada-settlement-account-access-policy-real-time-rail/
- Canada Gazette — Canadian Payments Association By-law No. 10 — RTR (official text; coming into force August 24, 2026): https://gazette.gc.ca/rp-pr/p2/2026/2026-07-01/html/sor-dors133-eng.html
- Payments Canada — RTR fraud services (central Confirmation of Payee, risk list, analytics and reporting): https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/rtr-fraud
- Payments Canada — RTR access and participation (direct/indirect settlement, connection providers, service-provider responsibility): https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/rtr-access
- Interac — selected RTR exchange solution provider (role distinction from current Interac e-Transfer): https://www.interac.ca/en/content/news/payments-canada-selects-interac-corp-as-the-exchange-solution-provider-for-canadas-new-real-time-payments-system-the-real-time-rail/
- Bank of Canada — retail payments supervision FAQ (RPAA registration and RTR under development): https://www.bankofcanada.ca/2026/08/frequently-asked-questions-about-retail-payments-supervision/
- FINTRAC — Reporting suspicious transactions to FINTRAC: https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/str-dod/str-dod-eng
- FINTRAC — Reporting electronic funds transfers (international EFT reporting): https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/eft-dt/eft-dt-eng
- FCAC — Resolving an unauthorized transaction: https://www.canada.ca/en/financial-consumer-agency/services/resolving-unauthorized-transaction.html
- OSFI — Guideline B-10, Third-Party Risk Management: https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/third-party-risk-management-guideline
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.