RTR Participants and Access Model. Map operator, financial-institution and PSP roles, access requirements and bank integration boundaries.
Block 12 · Chapter 57 of 75
Participation in Canada's Real-Time Rail is not a single technical connection. An institution has to fit into a legal, operational, settlement and technology model that answers several different questions: Is it eligible to be a Payments Canada member? Is it an RTR Participant? Does it exchange messages itself or use another organization for technical connectivity? Does it settle through its own Bank of Canada settlement account or through a Settlement Agent? Is it providing RTR payment services to other members? Which competitive service is being used? Who owns the end-customer relationship, fraud decision, liquidity obligation and customer support case?
Release status and evidence boundary (5 October 2026)
The RTR is not yet a live production rail at this audit date. Payments Canada states that launch is targeted for Q4 2026, after testing, with participant onboarding deliberately sequenced; its current launch page identifies initial direct-to-Exchange participants in Q4 2026 and later migration phases in 2027. Current rules and access policies are therefore the authoritative implementation baseline, while production availability, participant reachability and any bank product rollout remain implementation-specific. Do not describe an RTR payment as a current production capability merely because a bank has completed integration testing. Payments Canada RTR system · Testing and launch
The published baseline is specific: RTR Payment Messages are ISO 20022 pacs.008 messages, in Canadian dollars, with a $100,000 exchange and clearing/settlement value limit; the sending participant authenticates the payor and must use Central Fraud Services, and the receiving participant must make funds available promptly and no later than 60 seconds after receiving the Settlement Outcome Message, subject to Rule 7 exceptions. A submitted message cannot be cancelled, revoked or amended by the sending participant. These are scheme rules, not a promise that every customer product or participant will expose the maximum amount or timing. RTR Rule 6 · RTR Rule 7 · RTR Rule 13
Those distinctions became more important as Canada's access framework broadened. Registered payment service providers can now apply for Payments Canada membership and RTR participation, subject to the applicable legal, supervisory and system requirements. A PSP can choose direct or indirect settlement depending on eligibility and operating model. Direct settlement requires an RTR settlement account on the books of the Bank of Canada. Indirect settlement requires an agreement with an approved Settlement Agent. A participant can also use a Connection Service Provider to reach the RTR Exchange; connectivity and settlement are separate design choices.
The current Bank of Canada RTR settlement-account policy recognizes two direct-account forms. An unrestricted settlement account permits an approved holder to settle on its own behalf and, if approved as a Settlement Agent, on behalf of indirect settlement participants. A restricted settlement account permits settlement only on the holder's own behalf. The Bank applies more stringent expectations to unrestricted accounts because failure of a settlement agent can affect multiple indirect participants.
Rule 4, Participant Access, sets the system-access obligations. Among other requirements, participants must be able to support the RTR's always-on model, receive the required ISO 20022 messages through the RTR Exchange interfaces, use Central Fraud Services, meet connectivity and security requirements, complete the required testing and maintain business-continuity capabilities. Direct settlement participants must establish an RTR Settlement Account and indirect settlement participants must designate a Settlement Agent.
This chapter turns those legal and infrastructure concepts into an architecture and operating model. It explains how to design participant master data, settlement-agent relationships, routing, onboarding, certification, controls, 24/7 operations and internal bank boundaries without assuming that "direct connection" means "direct settlement" or that every Payments Canada member has the same RTR role.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- distinguish Payments Canada membership from RTR participation;
- explain how eligible registered PSPs can enter the RTR participation pathway;
- distinguish Sending Participant, Receiving Participant, Direct Settlement Participant and Indirect Settlement Participant;
- explain the role of a Settlement Agent and why it is different from a Connection Service Provider;
- distinguish restricted and unrestricted Bank of Canada RTR settlement accounts;
- explain why unrestricted account holders face stronger capacity and resilience expectations;
- describe the Member Non-Participant service model supported by the RTR Rules;
- explain the difference between customer ownership, message exchange, connectivity and settlement responsibility;
- identify the core onboarding stages from membership through participation approval, testing, attestation and production rollout;
- describe the participant's always-on operational and business-continuity responsibilities;
- explain how the RTR Financial Institution Number Lookup Database supports routing and why participants remain responsible for their submitted data;
- model direct and indirect settlement in payment, liquidity and reconciliation systems;
- identify risks created by settlement-agent concentration, connection-provider dependency and stale reachability data;
- explain how net debit caps and indirect-participant positions protect a Settlement Agent's exposure;
- design an internal participant and routing data model suitable for RTR;
- create realistic participant-onboarding and access test scenarios;
- define bank integration boundaries for channels, payment hubs, fraud, settlement, operations and customer support.
For a focused core session, spend about 10 minutes on Sections 1–2, 15 minutes on Sections 3–5 with the participant and settlement diagrams, 10 minutes on Sections 6–7, 10 minutes on Sections 8–9, 10 minutes on the implementation cases and 5 minutes on takeaways and sources.
Chapter navigator
- Participation starts with roles, not connectivity
- Membership, eligibility and the access pathway
- Direct and indirect settlement participants
- Settlement Agents and Bank of Canada account types
- Connection Service Providers and Competitive Services
- Participant routing, directories and reachability
- Onboarding, testing, certification and change
- Bank integration boundaries and operating ownership
- Liquidity, risk, resilience and incident responsibilities
- Data model, controls and implementation testing
- Practical participant and access scenarios
- Key takeaways and authoritative references
1. Participation starts with roles, not connectivity
Teams often begin an instant-payment project by asking, "How do we connect to RTR?" That is too early.
The correct first questions are:
- what legal entity is the Payments Canada member?
- what RTR role will that entity perform?
- does it send and receive RTR payment messages?
- does it hold its own RTR Settlement Account?
- if not, which Settlement Agent settles for it?
- does it connect directly or through a Connection Service Provider?
- does it provide payment services to another Member Non-Participant?
- which Competitive Service or customer proposition originates the payment?
- who is accountable for fraud, AML, customer support and reconciliation?
A single institution can occupy more than one role. A large financial institution may be:
- a direct settlement participant for its own payments;
- a Settlement Agent for several indirect participants;
- a direct connector to the RTR Exchange;
- a provider of Exchange payment services for Member Non-Participants;
- a provider of customer-facing competitive payment services.
A smaller PSP may be:
- a Payments Canada member;
- an RTR Participant;
- an indirect settlement participant;
- connected through a third-party Connection Service Provider;
- dependent on a bank Settlement Agent for payment capacity and settlement.
These two institutions can both "participate in RTR" while having materially different architecture and operations.
Separate four dimensions
A good architecture separates four dimensions.
Membership
Who is legally a member of Payments Canada?
Participation
Who is approved as an RTR Participant and what role does it perform?
Connectivity
How does the participant technically reach the RTR Exchange?
Settlement
Whose Bank of Canada Settlement Account receives the financial entry?
This prevents common design mistakes. For example, a Connection Service Provider can carry messages without owning settlement. A Settlement Agent can settle for an indirect participant without owning the indirect participant's customer product.
2. Membership, eligibility and the access pathway
RTR access begins before technology onboarding.
Payments Canada membership
The organization needs to meet the applicable Payments Canada membership criteria. The legal membership framework expanded to permit new eligible categories, including registered payment service providers meeting the relevant criteria.
Membership should be treated as a legal-entity attribute. A banking group with several companies should not assume that a group brand is the participant. Contracts, accounts, participant IDs, regulatory obligations and settlement arrangements belong to a specific legal entity.
PSP eligibility
Payments Canada's current PSP participation guidance says a payment service provider seeking RTR participation must:
- be registered as a PSP with the Bank of Canada under the Retail Payment Activities Act;
- meet the applicable PSP criteria;
- be a Payments Canada member;
- have a Bank of Canada settlement account or an agreement with a Settlement Agent.
That makes access broader than the traditional bank-only model, but it does not mean every fintech can immediately connect. Eligibility, membership, system approval and operational readiness still apply.
RTR participation application
Payments Canada describes a pathway that includes:
- prerequisite regulatory registration where applicable;
- Payments Canada membership application and approval;
- RTR Participant application;
- review and conditional approval;
- onboarding activities;
- testing and certification;
- readiness attestation/final approval;
- production-environment testing and sequenced rollout.
The exact dates and readiness sequence are governed by Payments Canada. Project plans should not treat membership approval as production go-live.
Rule 4 operational obligations
Rule 4 should be read as an operating checklist, not only a legal document.
The participant must be capable of:
- complying with RTR Rules and technical specifications;
- operating in the required continuous service environment;
- exchanging ISO 20022 messages through the supported interfaces;
- using Central Fraud Services;
- maintaining connectivity and security;
- meeting testing requirements before message exchange;
- maintaining operational resilience and continuity;
- maintaining the correct settlement arrangement;
- keeping participant and routing information current.
These obligations affect architecture investment before a participant sends its first payment.
Message, status and return controls
The current exchange baseline is narrower than a generic “instant payment API.” Rule 6 permits only the RTR ISO 20022 pacs.008 payment message for exchange. The receiving participant returns a pacs.002 Payment Acceptance Status Message; the Exchange sends payment and settlement outcome messages; and a pacs.028 Payment Status Request is required in the specified uncertain-outcome case. A UETR cannot be reused for another message, and a UETR used in the preceding 90 calendar days is rejected as a duplicate. Once submitted, the sending participant cannot cancel, revoke or amend the message. RTR Rule 6
Rule 7 separates a scheme return from a customer dispute or recovery case. A Sending Participant may send one Payment Return Request within 60 calendar days of exchange, using the original UETR, acceptance date/time, amount and a permitted reason. After the payee has been credited, other exception-based returns and a payee-requested return (within 90 calendar days) follow the rule's procedures; they do not make the original payment freely reversible. Payment operations should preserve the original payment identity and the applicable participant, settlement-agent and contact data. RTR Rule 7
3. Direct and indirect settlement participants
The most important access distinction is often settlement, not messaging.
Direct Settlement Participant
Rule 1 defines a Direct Settlement Participant as a participant whose RTR payment obligations are cleared and settled through its Settlement Account.
That account is on the books of the Bank of Canada.
A direct participant therefore owns several operational responsibilities:
- establish and maintain the Bank settlement account;
- maintain sufficient payment capacity;
- fund and defund under the Bank/RTR procedures;
- manage reservations and settlement positions;
- reconcile settlement activity;
- monitor account and liquidity health continuously.
If it also serves indirect participants, the responsibility expands.
Indirect Settlement Participant
An indirect participant uses a Settlement Agent's Settlement Account for settlement.
This means the indirect participant may still:
- originate customer payments;
- receive incoming payments;
- send/receive RTR messages;
- perform customer authentication;
- perform fraud and compliance controls;
- own customer support;
- perform payment-level reconciliation.
But the system settlement entry is made through its agent's account.
The bank's payment data model should therefore include both:
- participant identity;
- settlement-party identity.
Sending and receiving roles are transaction roles
"Sending Participant" and "Receiving Participant" describe a participant's position in an individual payment message. They do not tell you whether the participant is direct or indirect.
A direct participant can be sending on one payment and receiving on the next. An indirect participant can also be sending or receiving; its settlement agent handles the associated account entries.
Why this distinction matters in investigations
Suppose a payment from PSP A to Bank B is settled through Bank S as PSP A's Settlement Agent.
Customer support at PSP A receives a complaint.
It needs to answer:
- Did PSP A submit the pacs.008?
- Did Bank B accept?
- Did settlement occur?
- Was Bank S's Settlement Account debited?
- Did PSP A's internal position with Bank S update?
- Did Bank B credit the payee?
- Is there a Rule 7 exception?
A data model with only "debtor bank" and "creditor bank" cannot explain the settlement chain.
4. Settlement Agents and Bank of Canada account types
A Settlement Agent is a Direct Settlement Participant approved to clear and settle RTR payment obligations on behalf of Indirect Settlement Participants.
Settlement-agent responsibilities
At a practical level, the Settlement Agent must manage:
- its own payment capacity;
- payment capacity needed for indirect participants;
- indirect-participant net positions;
- net debit caps;
- operational agreements;
- funding strategy;
- incident and contingency impacts;
- reconciliation between central settlement and client/participant positions.
Rule 8 states that a Settlement Agent may set a Net Debit Cap for an indirect participant. Settlement must not cause the indirect participant's ISP Net Position to fall below that cap.
This gives the Settlement Agent a risk-control mechanism over sponsored settlement activity.
Restricted settlement account
The Bank of Canada's current policy describes a restricted RTR settlement account as one used only for the account holder's own settlement.
This can suit an eligible organization that wants direct central-bank settlement for its own RTR obligations without settling on behalf of indirect participants.
Unrestricted settlement account
An unrestricted RTR settlement account can be used for the holder's own payments and, if the holder is approved as a Settlement Agent, for indirect participants.
The Bank applies stronger expectations because a liquidity or operational failure could interrupt several participants at once.
Its assessment includes factors such as:
- financial viability;
- expected own and sponsored flows;
- number/type of indirect participants;
- aggregate net debit caps;
- mechanisms for maintaining payment capacity;
- operational readiness.
Settlement account is purpose-specific
The Bank's policy states the RTR settlement account is to be used for RTR payment activity. It is not an ordinary commercial account or generic treasury account.
This matters for ledger design. Banks should maintain a dedicated account/position model with clear mapping to:
- Bank of Canada account;
- RTR payment capacity;
- reserved balance;
- direct obligations;
- sponsored indirect obligations;
- funding/defunding events.
Lynx relationship
RTR settlement accounts are funded and defunded by Lynx payments.
A direct RTR participant that is not itself a direct Lynx participant needs an arrangement with a Lynx direct participant for the funding/defunding flow.
That creates a second dependency that should be recorded in onboarding and continuity planning.
5. Connection Service Providers and Competitive Services
Settlement and connectivity are different.
Connection Service Provider
Rule 1 defines a Connection Service Provider as an entity identified in the RTR Payment Message that connects a Participant to the RTR Exchange to facilitate exchange on behalf of that participant.
A participant can therefore outsource or externalize connectivity while retaining its scheme responsibilities.
The participant should not treat a CSP as an opaque network pipe. Governance should cover:
- service availability;
- latency;
- security;
- certificate/key management;
- message integrity;
- replay/duplicate controls;
- observability;
- incident escalation;
- continuity/failover;
- change management.
Rule 6 includes the Sending Participant's Connection Service Provider Identifier among the required payment information.
Competitive Service
The RTR framework also recognizes Competitive Services. These can provide customer propositions or payment experiences using the RTR core.
A Competitive Service Identifier is included in the payment data.
Examples of possible business models can include:
- bank account-to-account payment products;
- merchant checkout;
- corporate API payments;
- embedded finance;
- service-specific addressing or initiation experiences.
Do not assume every competitive service uses the same customer limits, fees, authentication or user journey.
Direct connectivity does not mean direct settlement
A PSP could connect directly to the Exchange but settle indirectly through a bank Settlement Agent.
Conversely, a direct settlement participant could use a Connection Service Provider rather than build all network connectivity itself.
That is why the participant master should have separate fields such as:
- exchangeConnectionMode;
- connectionServiceProviderId;
- settlementMode;
- settlementAgentId;
- settlementAccountType;
- competitiveServiceIds.
6. Participant routing, directories and reachability
Instant payments need accurate routing data continuously.
RTR Financial Institution Number Lookup Database
Rule 14 establishes the RTR Financial Institution Number Lookup Database.
Participants provide the information needed for RTR routing and are responsible for its accuracy. Rule 14 states that the RTR Exchange will not validate the routing information submitted by participants.
This is an important operational point: a central directory does not remove participant responsibility for data quality.
Reachability is time-sensitive, but Rule 14 is not a real-time directory
A route may become unavailable because of participant launch phase, temporary restriction/suspension, maintenance or incident, routing-data change, service migration, settlement-agent change or competitive-service configuration. The payment hub must combine current scheme directories and operational status with its own product/account eligibility; it must not hard-code "Institution 123 is RTR-enabled forever."
Rule 14 sets a weekly effective cycle for the RTR Financial Institution Number Lookup Database: participant updates are due before 12:00 ET Thursday, the update report is distributed by 16:00 ET Thursday, final changes are due before 12:00 ET Friday, and the new database becomes effective Monday at 00:00 ET. Participants must provide institution numbers and, where applicable, account-number formats 10 calendar days before first exchange and remain responsible for the accuracy of their submissions. This is a governed batch reference-data process, not proof of live operational availability; incident or restriction handling must follow the applicable rules and service procedures. RTR Rule 14
Effective dating
Recommended directory fields include:
| Field | Why it matters |
|---|
| Participant ID / institution number | primary routing identity |
| Legal entity | contract and regulatory ownership |
| Exchange status | can send/receive now |
| Effective from/to | prevents future/expired routes |
| Settlement mode | direct or indirect |
| Settlement Agent | settlement routing |
| Connection mode | direct or CSP |
| CSP identifier | message requirement |
| Competitive Service IDs | service-specific routing |
| Account format rules | validation |
| Launch/migration phase | controlled enablement |
| Last verified timestamp | operational confidence |
Maker-checker governance
Changes to participant routing should be controlled.
A wrong settlement-agent mapping can create financial exposure. A wrong institution number can misroute or reject payments. A stale account-format rule can create customer failures.
Use:
- authoritative source ingestion;
- maker-checker approval;
- version history;
- effective dating;
- automated validation;
- rollback capability;
- operational alerting on significant change.
7. Onboarding, testing, certification and change
Participation is a lifecycle.
The onboarding-journey diagram above sequences the path from business decision through legal eligibility, testing and certification to production readiness; use it to plan how long each stage really takes before committing to a launch date.
Stage 1 — business decision
The institution chooses:
- customer proposition;
- expected volumes;
- direct/indirect settlement;
- direct/CSP connection;
- competitive-service model;
- settlement-agent relationship if required;
- operating model;
- build versus vendor components.
The settlement decision should happen early because it affects liquidity, contracts, testing and reconciliation.
Stage 2 — legal and regulatory eligibility
Confirm:
- legal entity;
- Payments Canada membership eligibility/status;
- Bank of Canada/RPAA status where applicable;
- Complaints Body membership for consumer/small-business-facing members, and reporting-entity/FINTRAC evidence where applicable under Rule 4;
- participant application prerequisites;
- settlement-account or settlement-agent model.
Stage 3 — participant configuration
Set up:
- participant identifiers;
- institution numbers;
- Exchange configuration;
- CSP;
- Competitive Services;
- settlement-agent relationship;
- account/routing data;
- contacts under Rule 3;
- fraud-service setup.
Stage 4 — technical onboarding
Implement:
- APIs/connectivity;
- ISO 20022;
- security;
- certificates/keys;
- time synchronization;
- message persistence;
- duplicate controls;
- observability;
- operational portals.
Stage 5 — business/system testing
Test:
- message conformance;
- settlement paths;
- fraud;
- limits;
- errors;
- returns;
- status queries;
- incidents;
- resilience;
- reconciliation.
Stage 6 — certification and attestation
Payments Canada's PSP guidance describes testing/certification and readiness attestation before go-live. Teams should retain certification evidence as controlled implementation artifacts.
Stage 7 — production rollout
Production should be sequenced according to approved readiness.
Controls can include:
- participant allow-list;
- amount cap;
- selected customers;
- gradual volume ramp;
- real-time dashboards;
- predefined rollback/restriction criteria.
Change after go-live
Participant changes can include:
- new Settlement Agent;
- restricted to unrestricted settlement account;
- new CSP;
- new Competitive Service;
- institution-number changes;
- merger/legal entity change;
- product limit change.
Rule 4 requires an Indirect Settlement Participant to give the Association at least 30 calendar days' advance notice of a Settlement Agent designation; replacing an agent requires advance notice to both the Association and the existing agent, subject to the rule's exceptions. A cutover plan must therefore preserve the old relationship for in-flight outcomes while the new relationship becomes effective. RTR Rule 4
Each change can affect routing, fraud, settlement and customer terms. Treat them as governed scheme changes, not simple configuration tickets.
8. Bank integration boundaries and operating ownership
A participant's internal architecture should reflect the external role model.
Channel boundary
The channel owns:
- customer experience;
- authentication handoff;
- intent capture;
- confirmation messages.
It should not own scheme routing logic.
Payment-hub boundary
The payment hub owns:
- normalized payment object;
- idempotency;
- product eligibility;
- route selection;
- limits orchestration;
- payment state;
- instruction identity.
It should obtain participant and settlement data from governed reference services.
Fraud boundary
Fraud owns:
- bank risk model;
- device/customer behavioural signals;
- Central Fraud Services integration;
- confirmation-of-payee interaction;
- transaction decision evidence.
Fraud decisioning needs to complete before releasing the payment message.
RTR gateway boundary
The gateway owns:
- ISO 20022 mapping;
- API/network protocols;
- technical validation;
- message authentication;
- acknowledgements;
- supported retries/status queries.
It should not invent customer business decisions.
Settlement/liquidity boundary
Treasury/settlement owns:
- settlement-account capacity;
- reservations;
- indirect positions;
- net debit caps;
- funding/defunding;
- settlement reconciliation.
Operations boundary
Operations owns:
- incident response;
- exceptions;
- Rule 7 cases;
- payment-return requests;
- participant contacts;
- scheme escalation.
Customer-support boundary
Customer support needs a business timeline that translates internal states into human language.
Support should see:
- submitted?
- accepted?
- settled?
- beneficiary credited?
- exception?
- return case?
- next action?
It should not need to read raw XML to answer a customer.
9. Liquidity, risk, resilience and incident responsibilities
Participant choice changes risk.
Direct-participant liquidity risk
A direct participant is responsible for sufficient payment capacity.
If capacity is exhausted:
- outgoing obligations may fail to progress;
- customers experience failed/delayed payments;
- operational escalation begins;
- funding arrangements become critical.
Settlement-agent concentration risk
An indirect participant depends on its Settlement Agent.
If the agent has a major incident or insufficient capacity, multiple sponsored participants can be affected.
The indirect participant needs:
- contractual service levels;
- position visibility;
- alerting;
- incident communication;
- contingency planning.
The settlement agent needs:
- aggregate sponsored-flow forecasts;
- net debit caps;
- per-participant monitoring;
- concentration limits;
- liquidity buffers.
CSP dependency risk
A Connection Service Provider outage can prevent message exchange even when settlement capacity is healthy.
The participant should know whether resilience includes:
- alternate connection;
- alternate CSP;
- direct fallback;
- queue/recovery procedures.
"Settlement account is funded" does not make a disconnected participant available.
24/7 support
Always-on participation requires an always-on responsibility matrix.
At minimum define on-call ownership for:
- network/CSP;
- RTR gateway;
- payment hub;
- fraud;
- account posting;
- liquidity;
- reconciliation;
- security/cyber;
- customer support;
- scheme/participant contact.
Incident classification
Rule 1 distinguishes severe participant incidents, including situations that threaten/harm the RTR and situations where a participant cannot exchange, clear, settle or make funds available.
Internal incident severity should map to scheme reporting/escalation requirements.
10. Data model, controls and implementation testing
Participant master
A useful participant object might contain:
- participantLegalEntityId;
- participantId;
- institutionNumber;
- participantStatus;
- canSend;
- canReceive;
- settlementMode;
- settlementAgentParticipantId;
- settlementAccountType;
- netDebitCapContext;
- connectionMode;
- connectionServiceProviderId;
- competitiveServiceIds;
- effectiveFrom;
- effectiveTo;
- lastAuthoritativeRefresh;
- operationalContactProfile.
Not every consumer of the data needs every field. The master should still preserve the full relationship.
Settlement relationship object
Do not encode sponsorship only as a free-text field on the participant.
A separate relationship object can support:
- indirectParticipant;
- settlementAgent;
- effective date;
- status;
- permitted services;
- net debit cap;
- exposure limit;
- reconciliation account;
- contact/escalation;
- contingency arrangement.
Routing decision
At payment time:
- validate product;
- validate amount/currency;
- resolve receiving institution;
- confirm receive reachability;
- resolve competitive service;
- confirm sending participant route;
- resolve settlement relationship;
- evaluate limits/fraud;
- create pacs.008.
The customer should not be asked to understand these layers.
Core tests
Direct-to-direct
- both participants own settlement accounts;
- outgoing and incoming accounting reconcile.
Direct-to-indirect
- receiver's Settlement Agent account is correctly reflected.
Indirect-to-direct
- sender's agent capacity/net debit cap is checked.
Indirect-to-indirect
- both settlement-agent mappings are correct.
CSP
- correct provider identifier;
- CSP failure/recovery;
- no duplicate after reconnect.
Directory
- new participant effective tomorrow;
- participant suspended;
- Settlement Agent changed;
- invalid/stale routing record.
Account type
- restricted direct participant cannot be configured to settle for another participant;
- unrestricted participant only sponsors where approvals and agreements exist.
Capacity
- indirect participant approaches net debit cap;
- settlement agent capacity low;
- funding event reconciles.
Operational
- participant disabled while payments are in flight;
- incident contact path invoked;
- customer states remain accurate.
Extended participant operating model
The participant framework becomes most useful when it is translated into concrete ownership, data and controls. The following considerations close the gap between legal access and day-to-day operation.
Role matrix for one payment
One RTR payment can involve several legal and technical actors. The bank should be able to identify each role independently.
| Responsibility | Possible actor |
|---|
| Customer relationship | Sending/receiving participant |
| Customer authentication | Sending participant |
| Confirmation of payee | Sending participant using central/approved service |
| Fraud decision | Sending participant |
| Message exchange | Participant, possibly via CSP |
| RTR Exchange operation | Payments Canada |
| Central fraud services | Payments Canada service environment |
| Settlement | Direct participant or Settlement Agent |
| Settlement account | Direct participant / Settlement Agent at Bank of Canada |
| Payee posting | Receiving participant |
| Customer support | Customer's participant |
| Return investigation | Sending + receiving participants |
| Central settlement reconciliation | Direct participant / Settlement Agent |
The table shows why a single field called processor is inadequate.
Participant responsibility remains with the participant
Outsourcing connectivity does not outsource scheme responsibility.
If a CSP:
- delivers a duplicate message;
- loses a response;
- becomes unavailable;
- mismanages a certificate;
- introduces latency;
the participant still needs to know what happened to its payments and meet its obligations.
Contracts with a CSP should therefore cover:
- measurable availability;
- latency;
- incident notification;
- security obligations;
- evidence retention;
- change control;
- disaster recovery;
- audit rights;
- termination and migration support.
A participant should retain enough independent observability to determine whether a problem is:
- internal;
- CSP;
- RTR Exchange;
- settlement;
- receiving participant.
Otherwise every incident becomes a vendor ticket with no business diagnosis.
Settlement Agent agreement as an operating contract
An indirect participant's Settlement Agent agreement should be reflected in systems, not left only in legal documents.
Operational data can include:
- effective date;
- permitted transaction scope;
- net debit cap;
- reporting frequency;
- funding arrangement between participant and agent;
- intraday alert thresholds;
- incident contacts;
- suspension conditions;
- change notice;
- reconciliation file/report;
- service-level expectations.
If the agent changes a Net Debit Cap, the indirect participant's payment release logic and monitoring should understand the new capacity promptly.
Sponsored position visibility
An indirect participant should not operate blind to its sponsored settlement position.
Useful views include:
- current ISP Net Position;
- current Net Debit Cap;
- percentage of cap consumed;
- reserved/pending amount;
- expected incoming value;
- recent rejects due to settlement constraints.
The Settlement Agent needs a portfolio view across all sponsored participants.
This supports two different questions:
Indirect participant:
Can my next payment settle under my current sponsored position?
Settlement Agent:
Can I safely support all sponsored participants and my own obligations?
Restricted and unrestricted account governance
A bank's participant master should prevent role combinations that the underlying account/approval does not support.
If accountType = RESTRICTED:
- sponsoredIndirectParticipants must be empty;
- settlementAgentRole must be false.
If accountType = UNRESTRICTED:
- sponsorship still requires the relevant approval and agreement;
- the mere account type should not automatically create agent authority.
Configuration validation should therefore check both:
- technical capability;
- approved business/legal role.
Member Non-Participant services
The RTR Rules allow a Direct Settlement Participant to provide RTR Exchange payment services for a Member Non-Participant under the applicable framework.
This creates another relationship distinct from indirect settlement.
A bank should not use one generic sponsoredBank table for:
- indirect settlement;
- Member Non-Participant Exchange service;
- CSP connection;
- correspondent relationship.
Each relationship has different legal and operational meaning.
A relationship model should specify:
- service type;
- provider participant;
- client member;
- message role;
- settlement responsibility;
- effective dates;
- limits;
- contacts;
- monitoring.
Participant master data as critical infrastructure
Reference data is often underestimated because it does not itself move money. In RTR it determines whether money is routed to the right participant and settlement relationship.
The participant master should be treated as Tier-1 payment data.
Recommended controls:
- authoritative source;
- maker-checker;
- effective dating;
- version history;
- validation against scheme data;
- no uncontrolled spreadsheet upload to production;
- automated reconciliation between source and consuming systems;
- alert on unexpected mass changes.
A bad payment route can affect thousands of transactions faster than a batch-era reference-data error.
Caching strategy
Low-latency systems often cache participant data.
Caching is acceptable only with controlled freshness.
Define:
- maximum cache age;
- invalidation/change mechanism;
- fallback if authoritative service unavailable;
- version carried with route decision.
Store the route-data version used for each payment. This helps investigations answer:
"Why did the system route this payment to that participant at 14:03 yesterday?"
Effective-dated launch reachability
The phased launch makes effective dating particularly important.
A participant may be:
- approved;
- technically connected;
- not yet enabled for a given product;
- enabled for controlled volume;
- enabled for full volume.
A Boolean rtrEnabled cannot express this well.
A richer reachability record can contain:
- status;
- phase;
- sendEnabled;
- receiveEnabled;
- product/competitive service;
- start timestamp;
- end timestamp;
- volume restrictions;
- reason/source.
This also helps controlled rollout within a bank.
Directory mismatch scenario
Suppose:
- scheme directory says Participant B can receive;
- bank's local cache says not reachable.
The payment hub may wrongly route to another rail.
Conversely:
- local cache says reachable;
- participant has been suspended or changed.
The payment may fail or create operational risk.
Reference-data freshness should therefore be monitored as a service-level measure.
Contact data under Rule 3
Operational contacts are part of participant readiness.
A participant must provide primary and alternate contacts for the RTR Operational Committee, RTR User Group and an always-reachable RTR Emergency Committee contact. It must also maintain function contacts, as applicable, for:
- scheme operations;
- incidents;
- security;
- settlement/liquidity;
- fraud;
- returns/investigations;
- senior escalation.
Contacts need:
- primary;
- backup;
- 24/7 method;
- periodic verification.
A phone number stored at onboarding and never retested is not an incident-management capability.
Certificate and key lifecycle
Connectivity requires security credentials and keys.
Operational requirements should cover:
- issuance;
- storage in secure key infrastructure;
- rotation;
- expiry monitoring;
- revocation;
- emergency replacement;
- separation of test and production;
- dual control for sensitive actions.
Certificate expiry is a predictable failure. Monitoring should warn long before it can disconnect the participant.
Environment separation
Banks should separate:
- development;
- integration test;
- certification/industry test;
- production.
Test participant IDs, credentials and endpoints must not be interchangeable with production.
Synthetic test messages should never be able to create production settlement.
Onboarding evidence pack
For each go-live gate, retain evidence.
Possible pack:
Legal
- membership status;
- participation approval;
- agreements;
- settlement-account/agent approval.
Technical
- connectivity certification;
- ISO conformance;
- security test;
- performance test;
- failover test.
Business
- product requirements;
- customer terms;
- limit approval;
- fraud policy.
Operations
- runbooks;
- contacts;
- incident rehearsal;
- return process rehearsal.
Finance
- accounting;
- settlement reconciliation;
- sponsored-position reconciliation if applicable.
Risk/compliance
- fraud-control standards;
- central fraud integration;
- AML/sanctions approach;
- access control.
The evidence pack helps when people change after launch.
Onboarding should include negative tests
A participant is not ready because it can send one happy-path payment.
Certification/readiness should include:
- duplicate;
- invalid UETR;
- incorrect currency;
- invalid account;
- above-limit;
- receiver rejection;
- status uncertainty;
- settlement-capacity failure;
- indirect net debit cap;
- central fraud adverse result;
- CoP mismatch;
- CSP loss/reconnect;
- core posting failure;
- incident communication.
A participant must demonstrate recovery, not just submission.
Operational readiness rehearsal
Before production, run a tabletop or live rehearsal.
Example scenario:
Saturday 22:30:
- outgoing volumes spike;
- central fraud latency increases;
- a CSP link becomes unstable;
- payment capacity falls into amber threshold;
- customer support receives complaints.
Teams should practice:
- incident command;
- route/product restriction;
- liquidity escalation;
- CSP escalation;
- customer wording;
- reconciliation;
- post-incident recovery.
The exercise exposes ownership gaps more effectively than reading a RACI.
RACI for normal and exception processing
A typical high-level RACI might be:
| Activity | Product | Payments Ops | Fraud | Treasury | Technology | Finance |
|---|
| Customer limit | A/R | C | C | C | I | I |
| Payment routing | C | A/R | I | C | R | I |
| Fraud decision | I | C | A/R | I | C | I |
| Settlement capacity | I | C | I | A/R | C | C |
| Connectivity incident | I | A | I | I | R | I |
| Rule 7 return case | C | A/R | C | I | C | C |
| Settlement break | I | C | I | C | C | A/R |
Exact ownership differs by bank, but ambiguity should not.
Separation of duties
Sensitive participant functions should require appropriate segregation.
Examples:
- operator who changes a settlement-agent mapping should not approve the same change;
- developer should not manually replay production financial messages without controlled operations process;
- treasury funding instruction should follow treasury authorization;
- fraud-rule override should be auditable;
- directory emergency change should have post-event review.
Change management after go-live
RTR participation changes continuously.
Potential changes:
- new participant;
- new indirect relationship;
- changed Settlement Agent;
- new CSP;
- certificate rotation;
- account-type change;
- new Competitive Service;
- revised ISO version;
- revised fraud service;
- new product limit.
Every change should be classified by impact.
A settlement-agent change, for example, affects:
- participant master;
- settlement routing;
- treasury;
- reconciliation;
- contracts;
- operations contacts;
- test cases.
A CSP change affects:
- connectivity;
- credentials;
- network routes;
- operational monitoring;
- recovery.
A standards-version change affects:
- message mapping;
- validation;
- archived samples;
- regression tests;
- operations parsing.
Migration control
When moving between providers or settlement models, define a cutover point.
For example:
- payments submitted before T0 remain under old relationship;
- payments created after T0 use new relationship;
- in-flight statuses can still arrive through old connection;
- both reconciliation paths remain active until all old items close.
A hard switch that deletes the old relationship at midnight can strand late outcomes.
Participant suspension or restriction
A participant can be restricted, suspended or otherwise unavailable under the system framework.
The payment hub needs a response.
Actions can include:
- stop new RTR sends to/from affected route as required;
- preserve in-flight states;
- inform customer channels;
- disable only impacted product/route rather than entire bank;
- retain evidence;
- follow scheme/operations instructions.
Do not continue because a static directory flag still says enabled.
Settlement Agent incident
Suppose an indirect participant is operational but its Settlement Agent experiences a severe incident.
The indirect participant may still have:
- healthy channels;
- healthy fraud;
- healthy Exchange connectivity.
But settlement dependency is impaired.
Customer availability decision must reflect the whole route.
This is why participant health needs dimensions such as:
- exchangeHealth;
- fraudHealth;
- settlementHealth;
- postingHealth.
Multiple Settlement Agents
If the framework/business model allows a participant to maintain different arrangements over time or for different approved contexts, routing must be deterministic.
Never choose a Settlement Agent based on an uncontrolled "first available" list.
Selection criteria should be governed and auditable.
Settlement-agent reconciliation
For an indirect participant, daily/continuous reconciliation should match:
Indirect participant:
- sent/received payment outcomes;
- sponsored settlement position;
- Settlement Agent reporting;
- customer ledger.
Settlement Agent:
- Bank of Canada settlement-account activity;
- own RTR activity;
- each indirect participant's position;
- aggregate sponsored obligations.
A mismatch between central settlement and sponsored sub-ledger is a financial-control break even if customers were credited correctly.
CSP reconciliation
A CSP may provide technical message logs.
The participant should reconcile:
- message created internally;
- message accepted by CSP;
- message delivered/acknowledged externally;
- outcome received;
- outcome delivered internally.
This is transport reconciliation, distinct from financial reconciliation.
Participant observability dashboard
A useful participant dashboard includes:
Reachability
- send/receive enabled;
- directory freshness;
- service status.
Connectivity
- CSP/direct link status;
- certificate expiry;
- message throughput;
- error rate.
Fraud
- central service availability;
- CoP availability;
- assessment latency.
Settlement
- account/agent status;
- capacity;
- ISP position;
- NDC utilization.
Operations
- open incidents;
- aged uncertain payments;
- returns;
- reconciliation breaks.
The dashboard should allow operations to answer "Can we safely send the next payment?" rather than merely "Is the server up?"
Capacity planning
Participant design should forecast:
- transactions per second;
- peak burst;
- message sizes including remittance;
- fraud calls;
- directory calls;
- database writes;
- status inquiries;
- reconciliation events.
Capacity tests should include sudden burst rather than only smooth average load.
A government disbursement or marketplace payout can create burst patterns that do not resemble normal retail traffic.
Exit and portability
Participation architecture should also plan for change or exit.
If a bank replaces:
- CSP;
- Settlement Agent;
- fraud vendor;
- payment-hub component;
it should be able to export/retain:
- payment history;
- UETR;
- statuses;
- settlement evidence;
- case history;
- audit data.
Vendor lock-in that prevents historical investigation is an operational risk.
Design principle: capability over vendor topology
A final architecture principle is to model capabilities rather than vendor names.
For example:
- Fraud Assessment Service;
- Confirmation of Payee;
- RTR Gateway;
- Participant Directory;
- Settlement Position Service;
- Case Management.
Vendors can implement those capabilities, but business requirements should describe the bank's obligation.
This keeps the model stable when providers change.
Additional controls for access, sponsorship and production governance
Legal entity and product hierarchy
Banks frequently build payment products at brand level while scheme participation exists at legal-entity level. The model should preserve both.
For example:
Group brand
→ Canadian bank legal entity
→ Payments Canada member record
→ RTR Participant record
→ settlement account or Settlement Agent relationship
→ Competitive Service
→ customer product
→ customer account
This hierarchy prevents several common errors:
- using the wrong legal entity in participant agreements;
- applying one entity's settlement relationship to another;
- reporting fraud under the wrong participant;
- reconciling central settlement to the wrong general ledger;
- assuming a group-wide customer limit is a scheme participant limit.
The payment should retain the participant legal entity that actually sent or received it even if the customer sees only a group brand.
Product enablement by participant
A participant can be technically capable of receiving RTR messages while a particular customer product is not yet enabled.
Store product reachability separately from participant reachability.
Example:
- Institution B receives RTR for retail accounts;
- corporate product migration is scheduled later;
- one competitive service is enabled;
- another is in certification.
The sending bank should not infer product capability from general participant presence.
Customer account eligibility
The participant's account service should provide a deterministic receive/send eligibility answer.
Possible receive attributes:
- account active;
- account currency;
- canReceiveRTR;
- canReceiveDirectDeposit;
- legal restriction;
- fraud restriction;
- account type;
- customer/product restriction.
Possible send attributes:
- canSendRTR;
- available balance;
- account ownership/authority;
- customer limit;
- user entitlement;
- risk hold.
Eligibility rules should be versioned and testable. Operations should be able to explain why an account was considered eligible at the time of payment.
Participant identifiers and cross-system mapping
Large banks often maintain several identifiers for the same institution:
- Payments Canada institution number;
- internal party ID;
- legal-entity ID;
- routing identifier;
- settlement-agent ID;
- vendor/network identifier.
Do not use names as keys.
Maintain a mapping table with:
- identifier type;
- value;
- owning legal entity;
- effective date;
- source;
- status.
This supports mergers, renaming and historical reconstruction.
Institution-number change
If an institution number or routing relationship changes:
- future-dated payments should use the correct effective version;
- already-submitted payments retain their original routing evidence;
- customer templates may need validation on next use;
- cached directory data must refresh;
- monitoring should detect use of an expired identifier.
Never rewrite historical payments to the new participant identifier.
Settlement-agent due diligence
Selecting a Settlement Agent is not only a technical procurement decision.
The indirect participant should assess:
- financial and operational resilience;
- expected capacity;
- incident history;
- 24/7 support;
- sponsored-participant concentration;
- reporting quality;
- reconciliation support;
- funding model;
- cyber/security posture;
- change and termination process.
The agent, in turn, needs to assess the indirect participant's:
- expected volumes;
- risk profile;
- operating model;
- funding arrangements;
- fraud controls;
- financial capacity;
- incident readiness.
The relationship is a two-sided operational risk decision.
Limit hierarchy for sponsored participants
A Settlement Agent can use a Net Debit Cap, while the indirect participant may also have:
- internal treasury limit;
- product limit;
- customer limit;
- fraud limit.
These controls should not be collapsed.
Example:
- Scheme/system maximum: CAD 100,000 per payment.
- Participant product maximum: CAD 50,000.
- Customer limit: CAD 20,000.
- Settlement Agent NDC headroom: CAD 12,000.
A CAD 15,000 customer payment passes product/customer limits but cannot proceed if settlement conditions would breach the applicable sponsored position.
The customer does not need to see the settlement-agent cap, but the bank needs an accurate customer message such as "Instant payment is temporarily unavailable" rather than "Insufficient customer funds."
Internal transfers and the Rule 1 “On-We Payment” term
If both customers hold accounts at the same institution, the bank may process the transfer internally rather than send an external RTR Payment Message, depending on product design. The route decision should be explicit, the internal transfer should have its own posting and reconciliation path, and it should not generate a fictitious RTR settlement record. A bank should not count every instant internal transfer as an RTR transaction.
Do not confuse that product choice with the defined Rule 1 term On-We Payment. The rule uses that term for a payment where the payor and payee accounts are held with different Participants that use the same Settlement Agent. That is still an RTR scheme payment and must be modelled separately from a same-institution internal transfer. RTR Rule 1
Member Non-Participant routing
When a direct participant provides RTR Exchange payment services for a Member Non-Participant, the customer-facing institution and Exchange-serving participant can differ.
The internal object should preserve:
- member non-participant identity;
- service-provider participant;
- settlement account used;
- customer relationship;
- message responsibility.
Investigations must be able to find the actual processing provider without confusing the end customer's bank/PSP.
Third-party Exchange considerations
RTR Rules recognize a Third-Party Exchange in relevant contexts.
A bank's architecture should therefore avoid assuming every settlement instruction is generated only from one internal customer-payment path.
Where an approved third-party exchange participates, maintain:
- source exchange identity;
- settlement instruction source;
- participant role;
- amount;
- correlation reference;
- settlement outcome;
- reconciliation source.
The same central settlement account may support obligations from more than one approved channel/system context. Treasury reporting should identify the source.
Data classification
Participant/reference information should be classified by criticality.
Critical financial routing data
- participant identifier;
- direct/indirect status;
- Settlement Agent;
- account type;
- net debit cap context;
- effective status.
Critical operational data
- connection route;
- CSP;
- contacts;
- certificate/key status.
Product data
- competitive service;
- enabled products;
- customer limits.
Different teams can own different domains, but one governed participant service should present a coherent view.
Golden source and local copies
A good pattern is:
- authoritative external scheme source;
- controlled enterprise participant master;
- read-optimized local cache in the payment hub.
Do not allow channels, fraud and reconciliation to each build separate manually maintained copies.
If multiple systems need local copies, reconcile them against the golden source and expose version/freshness.
Monitoring sponsored exposure
A Settlement Agent dashboard should show concentration by:
- indirect participant;
- hour/day;
- outgoing vs incoming;
- largest transactions;
- net debit cap utilization;
- failed reservations;
- product/service;
- incident state.
This helps identify a participant whose behavior suddenly diverges from the expected profile.
Settlement Agent fallback planning
A theoretical "backup Settlement Agent" is not useful unless:
- contracts exist;
- scheme configuration supports it;
- routing can be switched safely;
- accounting mappings exist;
- testing has occurred;
- operational staff know the procedure.
If fallback is not actually executable, document the real recovery strategy rather than labelling the architecture "dual agent."
CSP failover
Likewise, CSP redundancy should be tested at transaction level.
A failover test should prove:
- no duplicate message;
- original UETR preserved;
- late responses from old connection still correlate;
- certificate/identity works on alternate path;
- operations can see which path carried the message.
Network failover without payment-state continuity is incomplete resilience.
Customer-support ownership in indirect models
An indirect participant should not tell customers to contact the Settlement Agent for ordinary payment support.
The customer relationship remains with the participant.
Its support team should be able to obtain:
- payment status;
- settlement state;
- return case status;
- reason for service unavailability;
without exposing the internal sponsorship model unless relevant.
This requires good operational integration between participant and agent.
Return cases across sponsored settlement
A post-settlement return involving an indirect participant crosses several layers:
- customer case;
- indirect participant;
- receiving participant;
- Settlement Agent position;
- central settlement;
- customer reimbursement.
The return case must link the original participant identities and settlement-agent relationship that applied at the original transaction time.
If the participant later changes agents, the historical case should still reference the old relationship where relevant.
Audit questions the system should answer
An auditor or incident reviewer should be able to ask:
- Who was the approved RTR Participant on the transaction date?
- Was it direct or indirect settlement?
- Which Settlement Agent applied?
- Which Net Debit Cap/version applied?
- Which CSP transported the message?
- Which Competitive Service originated it?
- Which participant/routing-data version was used?
- Were required testing/certification approvals active?
- Was the participant under any restriction at the time?
- Who changed any relevant configuration?
If answering requires reconstructing spreadsheets and emails, the participant operating model is not mature enough.
Training by role
RTR training should differ by function.
Customer service
- customer statuses;
- irrevocability;
- scam/error support;
- return-request expectations.
Payments operations
- participant roles;
- message/status flow;
- uncertain outcomes;
- incidents.
Treasury
- settlement account;
- payment capacity;
- sponsored exposure;
- funding/defunding.
Fraud
- central services;
- CoP;
- participant controls;
- return/investigation.
Technology
- ISO/API;
- CSP;
- idempotency;
- resilience.
Finance
- central settlement;
- sponsored positions;
- customer posting;
- reconciliation.
Role-specific training reduces the common problem where everyone knows the customer product but nobody understands the settlement dependency.
Participant readiness scorecard
A useful readiness review should score evidence by domain rather than asking one binary question.
Legal and access
- correct legal entity confirmed;
- membership effective;
- RTR participation approval/current status;
- settlement account or Settlement Agent effective;
- CSP/Competitive Service relationships documented.
Payments
- participant and routing data loaded;
- direct/indirect logic proven;
- UETR and status handling tested;
- current ISO 20022 version deployed;
- rejection and status inquiry paths tested.
Settlement
- payment-capacity monitoring live;
- funding/defunding procedure rehearsed;
- indirect positions/NDCs reconciled where applicable;
- treasury escalation contacts active.
Fraud and risk
- CoP integration;
- Central Fraud Analytics;
- participant fraud standards;
- authentication;
- central risk-list/reporting readiness.
Operations
- 24/7 contacts;
- incident runbooks;
- customer-support status mapping;
- return/exception process;
- post-incident reconciliation procedure.
Resilience
- CSP/direct connection failover;
- database/application failover;
- no-loss UETR/payment-state recovery;
- duplicate/replay testing;
- certificate rotation.
Finance
- customer accounting;
- settlement accounting;
- sponsored sub-ledger;
- reconciliation;
- suspense/return accounting.
A participant should not move to production merely because its Exchange connection is green if settlement, fraud or reconciliation evidence remains incomplete.
Readiness evidence should expire
Some evidence becomes stale.
Examples:
- certificate test;
- contact list;
- settlement-agent agreement;
- disaster-recovery test;
- ISO conformance;
- fraud-model approval.
Maintain next-review/expiry dates. Operational readiness is a continuing obligation, not an onboarding event.
Post-launch health review
After initial volume ramp, review:
- actual versus expected volume;
- reject reasons;
- liquidity utilization;
- NDC utilization;
- CSP latency;
- fraud-service latency;
- reconciliation breaks;
- customer complaints;
- incident frequency.
Use the evidence to adjust:
- capacity;
- limits;
- monitoring;
- support staffing;
- routing/reference controls.
Participant decommissioning
If a participant relationship ends:
- stop new effective routing at the agreed time;
- preserve in-flight payment/status handling;
- keep historical settlement-agent/CSP relationships for audit;
- retain required records;
- revoke credentials only after controlled cutover;
- close reconciliation differences;
- update directories and customer products.
Deleting the participant record would destroy historical traceability.
Historical relationship resolution
Every payment should resolve relationships "as of transaction time."
If Participant C changed Settlement Agent from A to B on 1 December:
- November payment investigation must still show Agent A;
- December payment shows Agent B.
This requires effective-dated data, not a mutable current-agent field.
Architecture acceptance questions
Before approval, ask:
- Can we identify the exact legal participant on any payment?
- Can we tell whether it settled directly or indirectly?
- Can we reconstruct the Settlement Agent effective at that moment?
- Can we separate CSP failure from settlement failure?
- Can we see participant reachability version used for routing?
- Can we survive provider/agent change without losing in-flight outcomes?
- Can finance reconcile central settlement to sponsored positions?
- Can support explain a payment without knowing vendor topology?
If not, the participant/access design still contains hidden coupling.
Direct-versus-indirect access decision framework
A participant's access model should be chosen as an enterprise operating decision, not as a technology preference.
When direct settlement may fit
Direct settlement may suit an institution that can support:
- Bank of Canada settlement-account requirements;
- continuous payment-capacity management;
- Lynx funding/defunding arrangements;
- 24/7 treasury and operations;
- settlement reconciliation;
- resilience and security obligations;
- sufficient scale to justify the investment.
Direct settlement gives the institution greater control over its central settlement position, but that control comes with operational responsibility.
When indirect settlement may fit
Indirect settlement can reduce the institution's central settlement infrastructure burden, but creates dependency on a Settlement Agent.
The indirect participant still owns:
- customer authentication;
- product controls;
- fraud decision;
- message exchange according to its model;
- customer support;
- payment investigations;
- customer accounting.
The Settlement Agent owns the central settlement-account role under the approved arrangement.
A strong indirect model therefore requires real-time position visibility and disciplined operational integration between participant and agent.
Cost should include operating risk
A direct-versus-indirect business case should compare more than provider fees.
Consider:
- settlement infrastructure;
- liquidity buffers;
- 24/7 staffing;
- CSP costs;
- resilience;
- sponsored-position reporting;
- incident dependency;
- reconciliation complexity;
- change/certification cost.
A lower direct processing fee can be outweighed by a much larger operating model.
Settlement Agent service-level requirements
An indirect participant should define what it needs from the agent:
- position visibility;
- Net Debit Cap information;
- settlement reporting;
- capacity alerts;
- incident notification;
- after-hours contact;
- change notice;
- reconciliation data;
- dispute/investigation support.
The participant needs enough evidence to answer its customers without waiting for a next-day agent report.
Concentration risk
A Settlement Agent supporting many indirect participants can become a concentration point.
The agent should monitor:
- aggregate sponsored volume;
- peak net debit exposure;
- largest ISP concentrations;
- correlated volume events;
- available payment capacity;
- operational dependency by CSP/channel.
Indirect participants should understand how a major agent incident affects their ability to transact.
Access model review triggers
Reassess the participant model after:
- significant volume growth;
- acquisition or merger;
- new customer segment;
- new Competitive Service;
- settlement-agent service deterioration;
- regulatory change;
- eligibility for direct account access;
- major architecture modernization.
The chosen access model is not necessarily permanent.
Certification matrix
Testing should prove each applicable relationship.
| Scenario | What must be proven |
|---|
| Direct → Direct | correct participant and settlement-account treatment |
| Direct → Indirect | receiver Settlement Agent resolution |
| Indirect → Direct | sender agent position and NDC controls |
| Indirect → Indirect | both agent mappings and positions |
| CSP connection | message continuity and failover |
| Agent change | effective-dated settlement routing |
| Participant restriction | immediate routing/product response |
| Directory change | cache invalidation and audit history |
Production observability
Participant operations should continuously answer four questions:
Can I exchange?
Connectivity and Exchange health.
Can I settle?
Payment capacity, Settlement Agent and NDC state.
Can I control?
Fraud and account services healthy.
Can I account?
Ledger and reconciliation healthy.
A single green "RTR connection" indicator cannot answer all four.
Provider exit planning
If a CSP or Settlement Agent is replaced:
- keep old relationship data;
- define cutover timestamp;
- preserve in-flight status receipt;
- keep old reconciliation active until closed;
- migrate credentials/configuration securely;
- test the new relationship before traffic moves.
Historical payments must remain traceable through the provider relationship that actually applied when they were sent.
Participant data-quality controls
The participant master should undergo automated checks such as:
- direct participant cannot point to itself as indirect Settlement Agent;
- restricted account cannot sponsor an ISP;
- inactive participant cannot be selected for new traffic;
- effective dates cannot overlap incorrectly;
- required CSP identifiers present where applicable;
- unknown institution number rejected;
- settlement relationship exists before product enablement.
These controls prevent configuration from creating financial errors.
Governance forum
A bank with a significant RTR footprint benefits from a cross-functional participant governance forum covering:
- scheme changes;
- participant/reference changes;
- settlement relationships;
- liquidity;
- fraud;
- incidents;
- vendor/CSP performance;
- certification;
- upcoming product releases.
This prevents the external participant model from becoming fragmented across treasury, payments technology and operations.
Core practitioner test
For any live payment, the bank should be able to answer within minutes:
- Which legal entity was the RTR Participant?
- Was it direct or indirect settlement?
- Which Settlement Agent applied?
- Which CSP carried the message?
- Which Competitive Service applied?
- Which routing-data version was used?
- What settlement capacity control applied?
- Which team owns the next action?
If those answers require emails between departments, the access model is not operationally mature.
Access-model documentation standard
Every architecture and operating document should state the access model in one unambiguous sentence, for example:
Legal Entity A is an RTR Participant with direct Exchange connectivity through CSP X and indirect settlement through Settlement Agent B.
or:
Legal Entity C is a Direct Settlement Participant using its own unrestricted Bank of Canada RTR Settlement Account and approved to settle for ISP D.
This simple discipline prevents the vague phrase "direct participant" from being used to mean connectivity in one meeting and settlement in another.
Annual relationship review
At least on the bank's normal governance cycle, review CSP and Settlement Agent arrangements against actual volumes, incidents, resilience tests, service performance, settlement-capacity use and expected product growth. A relationship that was appropriate at launch may become a concentration or scale risk later.
Access-model risk matrix and onboarding controls
Choosing direct or indirect participation changes where risk sits.
| Risk | Direct settlement | Indirect settlement |
|---|
| Central settlement capacity | Participant owns directly | Settlement Agent dependency |
| Liquidity operations | Participant manages own RTR account | Agent relationship and sponsored position |
| Settlement reconciliation | Direct Bank of Canada linkage | Participant plus agent sub-ledger |
| Incident dependency | Own stack / CSP | Own stack plus Settlement Agent |
| Net Debit Cap | Not an ISP constraint | Important sponsored control |
| Cost | Higher infrastructure/operations | Agent service cost/dependency |
| Change control | Own account/configuration | Bilateral plus scheme coordination |
There is no universally better model. The correct choice depends on scale, capability, risk appetite and strategy.
Onboarding control checklist
Before enabling a participant, verify the exact legal entity and identifiers, connectivity mode and production credentials, direct or indirect settlement configuration, settlement-account type or Settlement Agent, effective dates, Central Fraud Services, confirmation of payee, 24/7 contacts, accounting and reconciliation.
Participant change scenario
Assume PSP A moves from Settlement Agent B to Settlement Agent C on 1 March. The migration must coordinate scheme configuration, participant master, settlement-position service, treasury reporting, reconciliation, contracts, operations contacts and in-flight payment handling.
Payments submitted before the effective cutover remain associated with the old relationship for historical evidence. New payments after cutover use the new agent. A design that simply overwrites the current Settlement Agent destroys the audit trail.
CSP migration scenario
A participant changing Connection Service Provider should prove that participant identity, UETR and idempotency stay unchanged; late responses from the old path still correlate; alternate credentials work; operations can see both paths during transition; and no message replay occurs.
The provider changes; the economic payment identity does not.
Reference-data reconciliation
Daily or event-driven checks should compare the participant master against authoritative scheme configuration and flag unknown participants, expired routes, Settlement Agent mismatches, CSP mismatches and unexpected status changes. Reference-data defects can create mass payment failure without any software defect.
Access-model incident classification
A payment can fail because the Exchange connection is down, the CSP is down, the Settlement Agent cannot support settlement, an NDC is exhausted, the participant is restricted or directory data is stale. Each condition has a different owner and remedy even if the customer sees the same temporary-unavailability message.
Exit criteria from early-life support
A new participant should leave heightened monitoring only after stable message success, stable settlement, clean sponsored positions where applicable, stable fraud services, functioning support procedures and consistently clean reconciliation. Connectivity success alone is not enough.
11. Practical participant and access scenarios
Example 1 — PSP chooses indirect settlement
A registered PSP becomes a Payments Canada member and is approved for RTR participation.
It connects through a CSP and uses Bank S as Settlement Agent.
The correct model is:
Customer → PSP product → PSP fraud/payment decision → CSP → RTR Exchange → settlement through Bank S account → receiver.
Bank S does not become the PSP's customer-facing originator merely because it settles.
Example 2 — PSP wants its own settlement account
The PSP applies for an RTR settlement account.
The Bank of Canada evaluates eligibility, due diligence, financial viability, payment-capacity management, operations and legal requirements.
If approved with a restricted account, the PSP settles only for itself.
The architecture must not allow another indirect participant to be configured under it as Settlement Agent unless/until the required unrestricted/agent approvals exist.
Example 3 — bank acts as Settlement Agent
Bank A has an unrestricted RTR settlement account and is approved as Settlement Agent for PSP B.
PSP B sends high outbound volume.
Bank A:
- monitors B's ISP Net Position;
- enforces net debit cap;
- includes B in liquidity forecasts;
- reconciles central settlement to B's sponsored position.
A customer payment can be valid at PSP B yet fail to settle if sponsored capacity conditions are not met.
Example 4 — CSP outage
Participant's core systems and settlement capacity are healthy, but its CSP loses connectivity.
Payments cannot be exchanged.
Operations should report this as a connectivity/Exchange-access incident, not a liquidity incident.
Recovery must preserve message identity and prevent duplicate submission.
Example 5 — settlement-agent migration
Indirect Participant C moves from Settlement Agent A to Settlement Agent B on a defined date.
Changes must align across:
- Payments Canada configuration;
- participant master;
- reconciliation;
- liquidity reports;
- contracts;
- operations contacts;
- production effective date.
A partial change can result in correct Exchange routing but wrong settlement expectations.
Example 6 — stale directory data
Receiving participant changes account-format requirements but sending bank's cache is stale.
Customer enters an account that passes local validation but is rejected downstream.
The long-term fix is governed directory/reference synchronization, not an operations team manually repairing every payment.
Example 7 — group company confusion
A financial group has Bank Canada Inc. and Payments Services Canada Ltd.
Only one legal entity is the RTR Participant.
Developers use group brand as the participant ID.
This breaks contracts, settlement, fraud reporting and reconciliation.
The fix is to model legal entity, brand and product separately.
Example 8 — direct connection, indirect settlement
A PSP builds its own direct technical connection to the RTR Exchange but settles through a bank.
A project document describes it as "fully direct."
That phrase is too ambiguous.
The accurate description is:
- direct Exchange connectivity;
- indirect settlement;
- Settlement Agent = Bank X.
That precision prevents architecture misunderstandings.
12. Key takeaways and authoritative references
RTR participation is a set of roles and relationships, not one connectivity choice.
Payments Canada membership, RTR participation, Exchange connectivity and settlement should be modeled separately. A participant can connect directly and settle indirectly; use a CSP and settle directly; or perform additional roles for other members.
Direct Settlement Participants settle through their own Bank of Canada RTR Settlement Accounts. Indirect Settlement Participants settle through approved Settlement Agents. The Bank's restricted account supports own settlement; an unrestricted account can support own settlement and, when approved, settlement-agent activity for indirects.
A Settlement Agent manages more than an account entry. It manages payment capacity, sponsored positions, net debit caps, reconciliation and resilience. A Connection Service Provider connects participants to the Exchange but does not become the settlement party merely by carrying messages.
Registered PSPs can apply for membership and RTR participation subject to the current requirements. The broadened access model makes accurate legal-entity, participant, settlement and routing data more important, not less.
The practitioner rules are:
- model membership, participation, connectivity and settlement separately;
- identify the exact legal entity behind every participant role;
- distinguish Sending/Receiving Participant from direct/indirect settlement status;
- never equate a Connection Service Provider with a Settlement Agent;
- never configure a restricted account holder as a sponsor for indirect settlement;
- record settlement-agent relationships as effective-dated governed data;
- manage reachability and routing as real-time operational reference data;
- build 24/7 operations before production connection;
- test all direct/indirect settlement combinations;
- make the participant model visible to payment operations and reconciliation, not only network engineers.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.