RTR Fraud Services and Future Use Cases. Prepare for real-time fraud controls, operational support and future retail and business payment use cases.
Block 12 · Chapter 60 of 75
Real-time payments compress the time available to detect and stop fraud. That does not mean fraud controls become a single score or a single central service. Canada's Real-Time Rail is designed around layered responsibility: each participant remains responsible for its own fraud controls, while Payments Canada's Central Fraud Services provide shared capabilities that participants must use under Rule 13.
The approved 2026 RTR framework is unusually important here because older instant-payment material often talks about fraud in general terms. The current rules are specific. Participants must maintain Fraud Control Standards and review them annually. Sending participants must have the capability to use industry best-practice multi-factor authentication (or equivalent), use it to authenticate the payor before initiating an RTR Payment Message, and continuously monitor transactions to prevent fraudulent messages entering the exchange. They must implement confirmation of payee using the central service or an approved registered third-party service. Rule 13 requires participants to use Central Fraud Analytics for each RTR Payment Message, receive the Fraud Assessment in real time before sending, and decide whether to send using that assessment together with any other information they consider relevant.
The centralized services do not remove participant accountability. Payments Canada describes the RTR fraud model as central services operating from day one and complementing participant controls. The published service family includes confirmation of payee, real-time risk assessment/analytics, a Central Risk List and fraud reporting/intelligence capabilities. Rule 13 also requires participant data contributions and aggregate fraud reporting.
The most difficult fraud problem is not always an unauthorized account takeover. In an authorized push-payment scam, the genuine customer may authenticate successfully and deliberately authorize the transfer because they were deceived by an impersonator, false invoice, fake investment, romance scam or other social-engineering technique. Traditional authentication can therefore prove that the customer pressed "pay" without proving that the underlying payment purpose is legitimate. Real-time fraud design must combine identity, behavioral context, payee information, central intelligence, transaction patterns and customer warnings before the payment is released.
This chapter explains the RTR fraud-control model from customer authentication to post-event recovery. It also looks at future and emerging use cases without treating them as already-live products. Status at the 5 October 2026 audit: Payments Canada says the RTR is scheduled to launch in Q4 2026 and is still in industry solution-assurance testing; it is not described here as a production rail. The approved rules are in force from 24 August 2026, but implementation readiness, participant certification and customer availability are distinct from rule approval. The RTR core infrastructure is designed to support a wide range of retail, corporate, merchant, government and embedded-payment propositions, but each proposition needs its own product rules, fraud design, customer protection, remittance, liquidity, operational and reconciliation model.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- distinguish participant fraud responsibility from Central Fraud Services;
- explain the Rule 13 Fraud Control Standards obligation;
- explain the role of multi-factor authentication or equivalent before payment initiation;
- distinguish authentication from transaction authorization and fraud decisioning;
- explain confirmation of payee and why a match is not proof that a payment is safe;
- explain the customer's ability to proceed despite a confirmation-of-payee result and the bank's continuing risk responsibility;
- explain Central Fraud Analytics and the requirement to obtain a Fraud Assessment before sending;
- describe the Central Risk List at a functional level and the participant's data-quality responsibility;
- explain continuous monitoring before the payment message is introduced to the RTR Exchange;
- distinguish unauthorized payments, authorized payment fraud and end-user error;
- identify account-takeover, impersonation, invoice-redirection, mule-account and social-engineering patterns;
- design real-time fraud orchestration without exceeding payment-latency and availability expectations;
- explain why AML, sanctions and fraud are related but not interchangeable;
- connect post-event fraud investigation to UETR, settlement evidence and Rule 7 return-request processes;
- explain why a return request is not a guaranteed recovery;
- design customer communications that warn effectively without creating false certainty;
- describe future retail, business, merchant, government and embedded-payment use cases;
- explain how richer remittance can improve corporate payment and receivables processes;
- distinguish current RTR capabilities from later product/service innovation;
- design fraud, operational and reconciliation tests for new RTR use cases.
For a focused core session, spend about 15 minutes on Sections 1–3, 15 minutes on Sections 4–6, 10 minutes on Sections 7–8, 10 minutes on Sections 9–10, 5 minutes on practical scenarios and 5 minutes on takeaways and authoritative sources.
Chapter navigator
- Why real-time fraud is different
- RTR fraud responsibility and Rule 13
- Authentication, confirmation of payee and customer warnings
- Central Fraud Analytics and participant decisioning
- Central Risk List, monitoring and fraud intelligence
- Scams, account takeover, mules and transaction patterns
- Post-event investigation, returns and customer recovery
- AML, sanctions, privacy and operational controls
- Future retail, business and embedded-payment use cases
- Implementation, monitoring and test design
- Practical fraud and use-case scenarios
- Key takeaways and authoritative references
1. Why real-time fraud is different
Fraud exists on every payment rail. The RTR changes the control window.
In a batch payment process, suspicious transactions may be identified before a file is released or during a processing window. In a real-time rail, the customer expects a response while still in the digital session. The bank may have only seconds to authenticate, validate the payee, obtain central fraud information, apply its own behavioral model, check limits and decide whether to release the payment.
That creates three simultaneous objectives:
- stop high-risk payments before release;
- avoid unnecessary friction for legitimate customers;
- keep the payment service operational at real-time scale.
A fraud design that blocks too little creates losses and customer harm. A design that blocks too much makes the product unreliable. A design that requires manual review for every unusual payment cannot support real-time volume.
Authorized and unauthorized fraud
A useful first distinction is whether the customer authorized the payment.
Unauthorized payment
- credentials were compromised;
- attacker controls the session;
- customer did not intend the transaction.
Authorized payment fraud
- genuine customer authenticated;
- customer intentionally pressed pay;
- customer was deceived about the recipient or purpose.
This distinction matters because the control signals differ.
Account takeover can be detected through:
- new device;
- credential reset;
- impossible travel;
- unusual beneficiary;
- session anomalies;
- behavior change.
Authorized scams can occur from:
- known device;
- normal IP;
- correct password/MFA;
- customer-selected beneficiary.
In that case, beneficiary and transaction context become more important.
Speed changes recovery economics
Once a payment settles and the receiving participant makes funds available, a fraudster can move value onward quickly.
A mule can:
- withdraw cash;
- send to another account;
- buy crypto or goods;
- split funds across accounts;
- move to another jurisdiction using another rail.
The control strategy therefore prioritizes prevention before release and rapid investigation after notification.
2. RTR fraud responsibility and Rule 13
Rule 13 should be read as a shared-control model.
Participant Fraud Control Standards
Each participant must maintain standards to prevent, detect, investigate and manage fraud.
The standards should connect:
- customer authentication;
- transaction monitoring;
- beneficiary controls;
- fraud decisioning;
- central service use;
- case management;
- reporting;
- customer treatment;
- recovery.
Fraud should not be implemented as one microservice disconnected from payment operations.
Sending participant
The sending participant controls the last decision before the pacs.008 is introduced to the RTR Exchange.
Its responsibilities include:
- authenticate payor;
- use confirmation of payee;
- obtain Central Fraud Analytics assessment;
- continuously monitor transactions;
- combine central and participant information;
- approve/decline/challenge under policy.
This is where the customer account, device, historical behavior and product context are richest.
Receiving participant
The receiving participant also has fraud responsibility.
It can identify:
- mule behavior;
- unusual incoming velocity;
- account recently opened;
- rapid onward movement;
- mismatch between expected profile and received funds;
- linked fraud reports.
Receiving-side controls are important because sending banks cannot see the full beneficiary-account behavior.
Central Fraud Services
The central layer improves network-wide information.
Payments Canada's published fraud-service design includes:
- confirmation of payee;
- real-time transaction-risk assessment;
- centralized risk information;
- fraud reporting/intelligence.
The central layer can observe patterns that one institution cannot.
Example:
- Bank A sees one CAD 2,000 payment to Account X.
- Bank B sees that Account X has received 40 similar first-time payments from different institutions within minutes.
A central or receiving-side view can identify a mule pattern that Bank A alone cannot.
3. Authentication, confirmation of payee and customer warnings
Authentication is necessary but not sufficient.
Multi-factor authentication or equivalent
Rule 13 requires participants to have the capability to use industry best practices for MFA or equivalent, and to use it to authenticate the payor before initiating an RTR Payment Message. Rule 13 also requires each participant to review and adjust its Fraud Control Standards annually.
Possible factors include:
- possession;
- knowledge;
- inherence;
- device binding;
- cryptographic authentication.
The exact authentication design is the participant's responsibility.
Login versus payment authentication
A customer can be logged in but still require step-up authorization.
Risk triggers can include:
- new beneficiary;
- unusually high amount;
- new device;
- changed phone number;
- password reset;
- risky session;
- unusual time;
- unusual transaction pattern.
A bank should record whether step-up occurred and why.
Confirmation of payee
Confirmation of payee helps the payer understand whether the entered recipient information corresponds to the account.
The customer journey should distinguish:
- match;
- close/partial result where applicable;
- no match;
- unavailable/error.
The exact result set and user-interface requirements must follow the approved service specification.
CoP does not prove legitimacy
A perfect name match can still be a scam.
Example:
Fraudster owns account under their own real name and convinces victim to "invest" by sending funds.
CoP can correctly say the account name matches.
The payment can still be fraudulent.
Therefore:
CoP = payee-information control, not fraud guarantee.
Customer can choose to proceed
Rule 13 requires the sending participant to provide the payor with a choice to proceed regardless of the confirmation-of-payee result, while outlining the risks.
That does not mean the bank must send every payment the customer chooses to continue.
The bank still applies:
- fraud decision;
- legal restrictions;
- product terms;
- limits;
- other controls.
The system should store:
- CoP result;
- warning shown;
- customer decision;
- final bank decision.
Warning design
Warnings should be specific enough to change behavior.
Weak:
"Are you sure?"
Stronger:
"The account details do not match the payee information you entered. If someone asked you to ignore this warning, stop and verify the recipient using a trusted contact method."
Warnings can also be contextual:
- bank impersonation;
- investment;
- invoice change;
- urgency;
- remote-access scam.
Avoid overwhelming customers with the same warning on every safe transaction. Repeated generic warnings become background noise.
4. Central Fraud Analytics and participant decisioning
Rule 13 requires Central Fraud Analytics for each RTR Payment Message.
The sending participant obtains a Fraud Assessment before sending and makes its decision using that assessment plus other information.
Fraud assessment is an input
The central assessment should not be treated as:
"central system approved, therefore bank has no responsibility."
The participant has information that the central service may not:
- account balance/history;
- device trust;
- customer profile;
- known corporate workflow;
- recent customer-service call;
- beneficiary saved-list history;
- internal mule data;
- account restrictions.
Decision orchestration can combine these signals.
Example decision model
Conceptually:
Central fraud assessment
- participant behavioral score
- customer/device risk
- beneficiary risk
- transaction amount/velocity
- CoP result
- product/customer limits
→ participant decision
Possible actions:
- approve;
- step-up authenticate;
- present warning;
- decline;
- restrict product temporarily;
- route to post-event monitoring.
Manual review should be exceptional because the rail is designed for real-time processing.
Latency budget
Fraud controls sit directly in the payment path.
Measure:
- CoP response time;
- central analytics response time;
- internal feature retrieval;
- model execution;
- final decision.
A fraud system that takes 12 seconds under normal load can dominate customer experience.
Performance tests should use:
- peak TPS;
- realistic feature loads;
- central-service latency;
- partial dependency degradation.
Fraud service unavailable
A participant needs an approved fallback policy.
Possible policy is not something to invent casually. It should be defined by:
- RTR requirements;
- participant Fraud Control Standards;
- risk appetite;
- service specifications.
Depending on the service and failure, the participant may need to:
- fail closed;
- apply reduced limits;
- temporarily disable RTR sends;
- use an approved fallback.
Operations must know which behavior applies.
Explainability
Fraud analysts need reason information.
Useful internal reasons:
- first payment to new beneficiary;
- device change;
- rapid velocity;
- account takeover signal;
- high-risk recipient;
- central risk hit;
- CoP mismatch;
- anomalous amount.
Do not expose sensitive fraud rules to attackers through customer messages. Customer communication can be broader:
"We could not complete this payment for security reasons."
5. Central Risk List, monitoring and fraud intelligence
Shared intelligence is valuable because fraud crosses institutions.
Central Risk List
Rule 13 includes Central Risk List obligations.
At a functional level, participants contribute and use shared risk information under the service/rule requirements.
The list can help identify:
- known risky accounts;
- fraud-linked entities;
- accounts associated with reported cases.
Participants remain responsible for data quality and their own decision.
Data retention
Rule 13 requires information provided for the Central Risk List to be retained for at least 13 months as specified by the rule.
That means fraud data architecture needs retention and lineage.
Store:
- source case;
- reason;
- effective date;
- updates;
- removal/expiry;
- participant contribution evidence.
Continuous monitoring
Rule 13 requires continuous transaction monitoring.
Real-time monitoring can assess:
- transaction amount;
- beneficiary novelty;
- velocity;
- device/session;
- time of day;
- customer history;
- recipient risk;
- cross-channel behavior.
Post-event monitoring can detect:
- mule clustering;
- fan-in/fan-out;
- rapid onward movement;
- repeated fraud complaints;
- coordinated accounts.
Network intelligence
Fraud patterns can be distributed.
Example:
- 20 customers at 10 banks send small payments to three beneficiary accounts.
- each individual sending bank sees a small number;
- shared intelligence identifies the cluster.
This is one reason centralized services can complement participant controls.
Fraud reporting
Rule 13 requires aggregate fraud reporting. The Association retrieves each participant's aggregate fraud statistics by the 7th calendar day of each month; a direct settlement participant reporting for member non-participants must report those statistics by the same day. A participant may use the Central Fraud Reporting capability to satisfy the obligation. The exact fields and taxonomy remain governed by the current RTR Fraud Services Manual, not by this chapter's illustrative dimensions.
Reporting needs consistent taxonomy.
Possible dimensions:
- authorized vs unauthorized;
- fraud type;
- amount;
- recovered amount;
- customer loss;
- participant loss;
- channel;
- outcome.
The exact required data should follow the current reporting specification.
6. Scams, account takeover, mules and transaction patterns
The patterns-versus-controls diagram above maps each real-time fraud pattern in this section to its primary defenses, so the signal lists below read as a control matrix rather than isolated tips.
Account takeover
Signals:
- credential reset;
- new device;
- SIM/device change;
- unfamiliar IP;
- unusual session;
- beneficiary added immediately before payment;
- rapid drain of balance.
Controls:
- step-up authentication;
- cooling period where policy permits;
- behavioral analytics;
- device binding;
- transaction limit;
- customer notification.
Bank impersonation scam
Fraudster calls customer:
"Your account is under attack. Move your money to a safe account."
Customer logs in normally and authorizes payment.
Signals can include:
- new beneficiary;
- unusual amount;
- full/large balance transfer;
- new payee immediately after inbound phone/social-engineering pattern;
- recipient risk.
Customer warning:
"A bank employee will not ask you to move money to a 'safe account'."
Invoice-redirection fraud
Business receives fake email saying supplier changed bank details.
Customer creates new beneficiary and pays a genuine-looking invoice.
Controls:
- CoP;
- new-beneficiary warning;
- out-of-band supplier verification;
- corporate approval;
- unusual beneficiary-country/account behavior;
- invoice-change workflow.
Richer remittance can help post-event investigation but does not prevent the social engineering by itself.
CEO / business email compromise
Attacker impersonates executive and demands urgent payment.
Signals:
- unusual payment;
- unusual recipient;
- exception to normal approval process;
- urgency.
Control design should preserve corporate maker-checker rather than allowing an "urgent" RTR product to bypass it.
Investment scam
Customer sends repeated payments to an "investment platform."
Signals:
- new recipient;
- escalating amounts;
- high-risk recipient;
- repeated payments after prior warning.
A single transaction may look legitimate. Pattern monitoring matters.
Romance or long-con scam
Transactions can develop gradually over weeks.
Historical relationship and escalating value can be relevant.
Fraud systems need more than a one-payment snapshot.
Mule account
Receiving accounts can be:
- newly opened;
- dormant then active;
- receiving many unrelated payers;
- rapidly sending funds onward;
- frequently cashing out.
Receiving-bank monitoring is essential.
First-party misuse
A customer can make a valid payment and later falsely claim fraud.
Investigation needs:
- authentication;
- device;
- CoP;
- warning;
- customer behavior;
- communication;
- beneficiary evidence.
Customer protection and fraud loss prevention both require reliable evidence.
7. Post-event investigation, returns and customer recovery
Fraud prevention cannot stop every event.
First response
When a customer reports fraud:
- authenticate the customer safely;
- identify exact transaction/UETR;
- determine whether original payment settled;
- classify authorized vs unauthorized claim;
- secure compromised access if needed;
- contact/follow receiving-participant fraud process;
- initiate Rule 7 return-request process where appropriate;
- record customer-reimbursement decision separately;
- report/escalate under applicable requirements.
Speed matters because the beneficiary may move funds onward.
Payment Return Request
Rule 7 permits a Payment Return Request within 60 calendar days from the original exchange date, for defined reasons including Authorized RTR Payment Fraud and Unauthorized RTR Payment.
The receiving participant normally has 10 calendar days to:
- accept;
- reject;
- request extension.
An extension cannot run beyond the rule-defined 30-calendar-day maximum from receipt. No decision by then is deemed rejected.
A return request is an investigation/recovery request.
It is not:
- automatic reversal;
- guaranteed refund;
- cancellation of original settlement.
Recovery amount
Possible outcomes:
- full recovery;
- partial recovery;
- no recovery.
The fraud case should store:
- original amount;
- requested amount;
- recovered amount;
- customer reimbursement;
- bank loss;
- outstanding recovery.
Customer reimbursement
Customer reimbursement policy can differ from interbank recovery.
If the bank credits the customer before recovery:
- customer gets funds;
- bank carries recoverable/loss;
- later return must not credit customer again.
Finance needs a separate reimbursement object/journal.
Evidence package
Fraud investigation should collect:
- customer authorization;
- authentication;
- CoP result;
- warnings;
- central fraud assessment;
- participant decision;
- pacs.008/UETR;
- settlement outcome;
- customer debit;
- receiving information available through process;
- customer report;
- return request/response;
- recovery.
This supports fair and consistent decisions.
8. AML, sanctions, privacy and operational controls
Fraud and financial crime overlap but are not the same control.
Fraud
Focus:
- deception;
- unauthorized activity;
- account takeover;
- scams;
- mule behavior;
- transaction abuse.
AML / ATF
Focus:
- suspicious movement of proceeds;
- customer/activity profile;
- laundering typologies;
- reporting obligations;
- source/use of funds.
Sanctions
Focus:
- prohibited/restricted parties;
- legal obligations;
- asset/payment restrictions;
- screening and escalation.
One payment can trigger multiple controls.
A mule payment can be:
- fraud;
- suspicious AML activity;
- linked to sanctioned party.
Systems should share data where legally permitted but preserve decision ownership.
Privacy
Fraud services process sensitive data.
Controls should cover:
- purpose limitation;
- access controls;
- retention;
- encryption;
- secure data sharing;
- audit;
- customer rights/notice where applicable.
Do not give every payments-operations user access to detailed fraud intelligence.
Model governance
If machine-learning or statistical models are used:
- document inputs;
- validate performance;
- monitor drift;
- test false positives/negatives;
- control versions;
- review bias/fair-treatment implications;
- maintain human oversight appropriate to risk.
The bank should know which model version made the decision for a disputed payment.
Operational security
Fraud controls can themselves be targets.
Attackers may try to:
- disable rules;
- manipulate risk lists;
- compromise privileged users;
- flood the service;
- learn thresholds.
Protect:
- fraud configuration;
- central-service credentials;
- case-management access;
- model deployment;
- risk-list changes.
Use segregation of duties and audit.
9. Future retail, business and embedded-payment use cases
The RTR is infrastructure. It enables products but does not automatically define them.
Person-to-person account transfer
Possible proposition:
- bank-account transfer;
- immediate recipient funds;
- rich reference;
- CoP before send.
Fraud focus:
- impersonation;
- account takeover;
- mule recipient.
Supplier payment
Business pays supplier immediately.
Value:
- faster cash flow;
- precise remittance;
- invoice reconciliation;
- ability to pay closer to due date.
Controls:
- corporate entitlement;
- supplier-master change;
- CoP;
- invoice fraud;
- amount limit;
- ERP idempotency.
Payroll correction or urgent wage
A company may need to correct one missed employee payment without waiting for next batch.
RTR could complement AFT payroll rather than replace bulk payroll universally.
Use case:
- one urgent correction;
- controlled corporate approval;
- immediate credit.
Bulk economics may still favor AFT for normal payroll.
Insurance or emergency disbursement
An insurer could send:
- emergency accommodation funds;
- claims payment;
- refund.
Controls:
- beneficiary verification;
- claim-system integration;
- duplicate payout prevention.
Merchant account-to-account payment
A merchant or competitive service could initiate a customer payment journey using the core infrastructure.
Product design needs:
- customer consent;
- merchant identity;
- refund/return handling;
- customer dispute expectations;
- reconciliation;
- settlement timing.
Do not assume RTR automatically provides card-style chargeback protection.
Marketplace payout
Platform pays:
- sellers;
- gig workers;
- creators.
Benefits:
- rapid settlement;
- API automation;
- remittance.
Risks:
- account takeover;
- fake seller;
- mule accounts;
- high-volume burst;
- duplicate payout.
Government disbursement
Potential:
- benefit;
- emergency relief;
- refund;
- grant.
Requirements:
- scale;
- availability;
- beneficiary accuracy;
- fraud;
- accessibility;
- reconciliation.
Corporate treasury movement
Within current limits and participant/product design, RTR can support selected time-sensitive business transfers.
It does not replace Lynx for high-value payments above RTR limits.
Route choice should consider:
- amount;
- urgency;
- beneficiary reachability;
- remittance;
- product agreement.
Bill payment / request-driven payment
Competitive services can build user experiences around:
- bill presentation;
- request-to-pay;
- customer approval;
- RTR execution.
The request and the payment should be separate objects. A request is not money movement.
Embedded finance
ERP, accounting platforms and vertical SaaS can embed payment initiation.
The bank still needs:
- customer consent;
- authentication/authorization;
- API security;
- fraud;
- idempotency;
- account controls.
"Embedded" does not mean controls disappear.
Cross-border domestic leg
Rule 6 includes a future effective date for use of RTR as a domestic leg of an international electronic funds transfer under the rule conditions. The rule text makes this effective 30 September 2027.
Before that effective date, the RTR should not be described as already supporting that domestic leg.
Future architecture should be date-aware and use the required service-level/data treatment when the provision becomes effective.
10. Implementation, monitoring and test design
Fraud orchestration architecture
A sending-bank fraud orchestration layer can coordinate:
- customer authentication;
- CoP;
- central analytics;
- bank internal features/model;
- transaction limits;
- final decision;
- decision evidence.
Keep payment hub and fraud responsibilities separated but tightly integrated.
What is a participant implementation, and what is not yet production
The approved RTR operating model is more specific than a generic “real-time API.” Payments Canada describes three primary actors: end users, RTR participants and Payments Canada as system operator. A participant can connect directly or through a connection service provider, and can settle directly through its Bank of Canada settlement account or indirectly through a settlement agent. A third-party payment-solution provider may offer a competitive service or, in some models, connect directly to the RTR Exchange on a participant's behalf; the participant remains responsible for outsourced functions under the RTR legal framework.
The published PSP participation guide says the RTR Exchange and RTR Clearing and Settlement can be reached through APIs, including SFTP, or user portals. For direct exchange connectivity it describes an encrypted site-to-site VPN and REST APIs carrying ISO 20022 messages that are encrypted, digitally signed and validated. Among the National Payment Fraud Services components, the guide says that Central Fraud Analytics, Confirmation of Payee and the Central Risk List are API-accessible; the services also have portal access. These are implementation requirements and design options for participating institutions, not evidence that a bank has already deployed a particular vendor or customer channel.
The payment-hub path should therefore correlate the customer/channel instruction, authentication and consent, CoP request/result, Central Fraud Analytics request/assessment, participant decision, pacs.008 UETR, pacs.002 acceptance or rejection, reservation/settlement outcome, payee posting and operational/ledger events. Payments Canada describes the RTR as 24/7/365, but response targets and dependency behavior are in the service-level documentation rather than a generic “instant” promise. Rule 6 permits only the RTR pacs.008 as the payment item for RTR clearing and settlement, requires the prescribed ISO 20022/API format and required identifiers, sets Canadian-dollar currency and a $100,000 RTR Exchange Value Limit, and makes a message non-cancellable, non-revocable and non-amendable once sent to the exchange. Rule 8 requires direct participants to maintain settlement-account funds and payment capacity; reservation occurs before settlement, and funding/defunding uses the Bank of Canada settlement account and Lynx, subject to the applicable account agreement and operating procedures. These are scheme/system rules. Internal account posting, fraud thresholds below the system limit, ledger design, customer channels, and service-level budgets remain bank-specific implementation choices.
Production boundary: until the announced Q4 2026 launch and a participant's completed testing, certification and rollout, examples in this chapter are target operating designs or fictional scenarios. Do not describe CoP, Central Fraud Analytics, Central Risk List, RTR settlement or a competitive service as a live customer capability merely because the rules and technical specifications are approved.
Synchronous versus asynchronous controls
Synchronous
must complete before send:
- authentication;
- required CoP interaction;
- central fraud assessment;
- participant send decision.
Asynchronous
can continue after payment:
- network pattern analytics;
- mule detection;
- case enrichment;
- regulatory reporting;
- model feedback.
Do not put every analytical process in the real-time critical path.
Monitoring metrics
Track:
- fraud decline rate;
- challenge rate;
- CoP match/mismatch/unavailable;
- central fraud assessment distribution;
- false positive rate;
- confirmed fraud rate;
- authorized vs unauthorized;
- mule detections;
- return requests;
- recovered amount;
- customer reimbursement;
- fraud loss;
- decision latency.
Segment by:
- customer type;
- channel;
- amount band;
- beneficiary age;
- device risk;
- competitive service.
False positives
A high fraud decline rate is not automatically good.
Measure:
- legitimate customers blocked;
- abandoned payments;
- support contacts;
- repeat attempts;
- override outcomes.
Fraud optimization should reduce loss while preserving legitimate access.
Test scenarios
Authentication
- trusted device;
- new device;
- MFA failure;
- session takeover.
CoP
- match;
- mismatch;
- service unavailable;
- customer proceeds after warning.
Central analytics
- low risk;
- high risk;
- timeout;
- inconsistent data.
Behavior
- first-time payee;
- unusual high amount;
- rapid repeated transfers;
- new beneficiary after credential reset.
Mule
- many inbound unrelated payers;
- rapid onward movement;
- risk-list hit.
Post-event
- unauthorized claim;
- authorized scam;
- end-user error;
- processing error;
- full/partial/no recovery.
Resilience
- fraud service outage;
- central service degradation;
- duplicate request;
- replay;
- delayed response.
Deeper fraud operations and use-case engineering
Fraud control timing
A real-time fraud decision should be designed as a sequence of bounded operations.
Example internal timing model:
| Control | What must happen |
|---|
| Authentication | establish customer/user authority |
| Beneficiary verification | obtain/present CoP result where required |
| Central analytics | obtain Fraud Assessment |
| Participant features | retrieve recent behavior, device, account and payee signals |
| Decision | approve, challenge or decline |
| Audit | persist decision evidence before payment release |
The target latency for each component is a bank engineering decision, but the overall path should be load-tested at peak volume.
A service that normally responds in 100 ms but occasionally takes 20 seconds can still create a poor customer and operational outcome. Monitor percentiles, not just averages.
Fail-safe design
Every critical fraud dependency needs a defined failure mode.
Ask:
- If CoP is unavailable, can the payment continue under current service rules?
- If Central Fraud Analytics is unavailable, what does the approved operating procedure require?
- If internal device intelligence is unavailable, does the bank reduce limits or stop?
- If a fraud decision is completed but the response to the payment hub is lost, can the decision be recovered without running inconsistent logic again?
The answer should be encoded in policy and runbooks.
Do not allow individual developers to decide at runtime that a missing fraud response means approve.
Decision consistency
If a payment is retried technically, the fraud orchestration layer should know whether:
- the original decision is still valid;
- a fresh assessment is required;
- the payment details changed;
- the decision window expired.
If amount or beneficiary changes, the bank should treat it as a materially changed payment and apply the appropriate new authorization/fraud process.
Fraud case identity
Create a fraudCaseId separate from:
- paymentId;
- UETR;
- customerComplaintId;
- returnRequestId.
One fraud case can include:
- several payments;
- multiple customer contacts;
- one or more receiving institutions;
- several recovery attempts.
Conversely, one payment can have:
- fraud case;
- customer reimbursement case;
- operational return case.
Explicit linkage avoids overloading UETR as a case number.
Scam typology as structured data
Fraud case taxonomy should be structured.
Example categories:
- account takeover;
- bank impersonation;
- government impersonation;
- investment scam;
- romance scam;
- invoice redirection;
- business email compromise;
- marketplace scam;
- remote-access scam;
- family/emergency impersonation;
- mule activity;
- first-party misuse;
- other.
Consistent taxonomy supports:
- model feedback;
- reporting;
- customer education;
- risk-list quality;
- loss analysis.
Authorized payment fraud evidence
For an authorized scam, useful evidence includes:
- customer authentication method;
- device/session history;
- payee creation time;
- CoP result;
- warning text/version;
- customer response to warning;
- fraud assessment;
- prior payments to beneficiary;
- call-center contacts;
- external fraud intelligence.
The purpose is not to blame the customer. It is to reconstruct what happened and determine the appropriate bank and interbank response.
Unauthorized payment evidence
For account takeover, useful signals include:
- credential event;
- device enrollment;
- password reset;
- login location;
- session fingerprint;
- beneficiary creation;
- MFA method;
- unusual account activity;
- customer denial of authorization.
The bank should secure the account immediately as well as investigate payment recovery.
Mule-account lifecycle
Mule detection is not only a transaction rule.
A mule account can exhibit lifecycle indicators:
- rapid onboarding;
- unusual changes to contact details;
- sudden high inbound traffic;
- unrelated payer names;
- short holding time;
- rapid cash-out;
- transfer chains;
- repeated customer complaints;
- links to previously risky devices/accounts.
Receiving institutions can use account-level network analysis in addition to per-payment scoring.
Network graph concepts
Fraud analytics can model:
- account nodes;
- customer nodes;
- device nodes;
- phone/email nodes;
- payment edges;
- IP/device relationships.
Patterns can reveal:
- one device controlling many accounts;
- many victims paying one recipient;
- rapid fan-out from one recipient;
- circular movement.
Graph analysis can be powerful, but the bank must still govern:
- data quality;
- privacy;
- model explainability;
- false positives.
Velocity controls
Velocity should be multi-dimensional.
Examples:
- payments per minute;
- amount per hour/day;
- number of new beneficiaries;
- number of distinct payers to recipient;
- rapid onward movement;
- multiple failed/declined attempts.
A threshold that only checks "more than five payments" may miss one very large scam.
Beneficiary age
A newly created beneficiary can carry higher risk.
Useful features:
- first payment to beneficiary;
- time since beneficiary added;
- prior verified payment;
- beneficiary reused across customers;
- CoP history.
Corporate supplier-master controls can use a similar concept:
recently changed supplier bank details deserve stronger verification.
Device and session risk
Signals may include:
- known/trusted device;
- device change;
- emulator/root/jailbreak indicators where relevant;
- remote-access software signals where legally/technically available;
- IP reputation;
- impossible travel;
- session behavior.
No single signal should automatically define fraud without policy.
Customer education as a control
Customer education is strongest when connected to the exact decision moment.
Examples:
- new payee;
- CoP mismatch;
- large first payment;
- bank-impersonation indicators.
Contextual messages can say:
- "Never move money because someone claiming to be your bank tells you to."
- "Verify changed supplier bank details using a phone number you already know."
- "Investment returns that require urgent transfer should be independently verified."
Generic annual security banners have less impact than timely warnings.
Friction by risk
A mature model uses proportionate friction.
Low-risk:
Medium-risk:
- stronger warning or step-up authentication.
High-risk:
- decline/restrict and offer secure support.
This avoids treating every payment like fraud while protecting unusual events.
Corporate fraud design
Corporate RTR controls should include:
- user entitlement;
- maker-checker;
- payment limit;
- beneficiary-master governance;
- API credential security;
- file/job authorization;
- duplicate invoice/payment detection;
- out-of-band verification for bank-detail changes.
A corporate API should not bypass controls merely because the caller is a server rather than a human.
API compromise
If an API key/certificate is compromised, an attacker can automate payments quickly.
Controls:
- scoped credentials;
- mutual TLS/signing where applicable;
- IP/network controls;
- transaction limits;
- rate limits;
- anomaly detection;
- key rotation;
- rapid revocation.
Monitor machine behavior just as retail channels monitor devices.
Marketplace and platform risk
Platforms can create distinct fraud patterns:
- fake seller;
- stolen customer account;
- payout-account takeover;
- collusive buyers/sellers;
- mass payout fraud.
The bank should know whether the platform or bank is responsible for:
- seller KYC;
- payout authorization;
- fraud screening;
- customer complaint;
- return coordination.
Product contracts and technical integration should align.
Merchant refund design
If an RTR-based merchant payment product offers refunds:
- refund is a new payment/return process under the product design;
- preserve original payment reference;
- prevent duplicate refund;
- reconcile merchant account;
- distinguish customer goodwill refund from Rule 7 fraud recovery.
Do not assume card chargeback semantics.
Request-to-pay safety
A request-to-pay-like service can be useful but can also become a scam channel.
Controls can include:
- requester identity;
- customer display;
- amount/purpose clarity;
- expiry;
- customer explicit authorization;
- fraud checks at resulting payment.
A payment request is not authorization to move money.
Government use-case controls
Government disbursement can create:
- high volume;
- burst traffic;
- attractive fraud target;
- account-detail manipulation.
Controls:
- authoritative beneficiary source;
- duplicate prevention;
- strong file/API authorization;
- staged release;
- reconciliation;
- contingency for invalid accounts.
Insurance disbursement controls
Claims payments can be vulnerable to:
- claim fraud;
- beneficiary-account change;
- social engineering.
The insurer/bank integration should preserve:
- claim ID;
- approved payee;
- amount;
- remittance;
- duplicate payout control.
Payroll correction controls
A payroll correction should link to:
- employee;
- payroll run;
- original failed/missed item;
- authorized approver;
- correction reason.
This prevents "urgent payroll correction" from becoming a bypass around corporate payment controls.
Supplier payment and remittance
Rich remittance can improve supplier experience.
A corporate RTR payment can carry:
- invoice references;
- purchase order;
- payment purpose;
- reconciliation data.
The receiver can use the data for straight-through cash application.
Fraud controls should ensure remittance does not create false confidence about payee legitimacy. A beautifully structured invoice can still be fraudulent.
Cross-border future capability controls
For the future domestic leg of an international electronic funds transfer:
- effective date matters;
- required service-level code/data matters;
- sanctions/AML information must align with applicable requirements;
- source cross-border payment must correlate to domestic leg;
- duplicate and reconciliation controls must span both legs.
Do not design the future feature as "convert international payment to normal domestic RTR and drop the original context."
Fraud reporting data architecture
Fraud reporting needs stable dimensions.
Possible data model:
- fraudCaseId;
- UETR;
- fraudType;
- authorizedFlag;
- dateDetected;
- amount;
- customerLoss;
- bankLoss;
- amountRecovered;
- returnRequestStatus;
- channel;
- competitiveService;
- beneficiaryParticipant;
- risk-list contribution;
- reportingPeriod.
The exact regulatory/scheme fields must follow the current reporting specification, but structured internal data avoids manual monthly reconstruction.
Recovered amount tracking
Recovery can arrive in stages.
Case:
- original CAD 10,000;
- CAD 4,000 recovered day 1;
- CAD 2,000 recovered day 5;
- customer reimbursed CAD 10,000.
Finance should show:
- total recovered 6,000;
- bank loss/recoverable 4,000 subject to policy;
- no duplicate customer credit.
Fraud loss reconciliation
Reconcile:
- settled fraudulent payment;
- customer reimbursement;
- interbank return;
- insurance/recovery if any;
- charge-off/loss account.
Fraud-case status alone is not financial reconciliation.
Central Risk List data quality
Poor data can harm other participants.
Before contributing risk information:
- verify case basis;
- use correct identifiers;
- record source;
- apply required retention/update rules;
- correct errors promptly.
Shared fraud intelligence amplifies both good and bad data.
False-positive governance
Review false positives by:
- rule/model;
- customer segment;
- amount;
- beneficiary type;
- channel.
If one rule blocks many legitimate corporate payroll corrections, tune the control rather than instructing operations to override every case manually.
Model drift
Fraud behavior changes.
Monitor:
- model score distribution;
- approval/decline rates;
- confirmed fraud capture;
- false positives;
- emerging scam types.
Model governance should include:
- periodic validation;
- controlled retraining;
- challenger testing;
- rollback.
Human investigation
Automation cannot resolve every fraud case.
Investigators need:
- payment timeline;
- customer history;
- beneficiary risk;
- fraud signals;
- central intelligence;
- communications;
- return status.
Case queues should prioritize:
- high amount;
- rapid recovery opportunity;
- vulnerable customer;
- linked mule network;
- regulatory urgency.
Customer communication after fraud
Good communication should distinguish:
- case opened;
- payment settled;
- return requested;
- receiving participant investigating;
- partial recovery;
- reimbursement decision;
- case closed.
Avoid:
"Refund in progress"
when only a return request was sent.
Law enforcement and reporting
Where applicable, banks may need to cooperate with law enforcement or regulatory/financial-intelligence reporting obligations. A fraud alert is not automatically a FINTRAC Suspicious Transaction Report: FINTRAC's threshold is reasonable grounds to suspect a transaction is related to money laundering, terrorist activity financing or sanctions evasion. The same transaction may require both an EFT report and an STR, and listed-property restrictions and reporting can apply separately. The operational case should preserve facts, context, indicators and report references without promising that every fraud complaint will be reported to FINTRAC.
Operational systems should support:
- evidence export;
- access control;
- case chronology;
- immutable payment references.
The specific obligation depends on the institution, activity and law; do not hard-code one generic "report to police" step for every fraud case.
24/7 fraud operations
If customers can send payments at 03:00 Sunday, fraud operations need a plan for:
- automated decisions;
- severe alerts;
- compromised account support;
- high-value scam report;
- central-service incident;
- mule-account freeze/review subject to policy/law.
A Monday-morning fraud team is not a complete operating model for a 24/7 rail.
Fraud incident dashboard
Show:
- central service health;
- CoP health;
- decision latency;
- approval/decline/challenge;
- top risk reasons;
- confirmed fraud;
- active mule alerts;
- return requests;
- recovery;
- open high-severity cases.
Combine operational and risk metrics.
Scenario-based testing
Test realistic stories rather than isolated fields.
Bank impersonation
- known device;
- new beneficiary;
- CoP mismatch;
- high amount;
- customer chooses proceed;
- internal model decline.
Investment scam
- CoP match;
- first payment;
- multiple escalating payments;
- central risk flag on third payment.
Account takeover
- password reset;
- new device;
- beneficiary created;
- max-value attempt.
Mule
- receiving account gets many unrelated payments;
- rapid outward flow.
Corporate invoice fraud
- supplier details changed;
- corporate maker approves;
- checker sees CoP warning.
The expected result should include customer message and evidence, not only model score.
Red-team testing
Security teams can simulate:
- credential theft;
- API key compromise;
- session hijack;
- fraud-rule manipulation;
- risk-list abuse;
- insider override.
The objective is to test the complete control chain.
Fraud service performance testing
Load test with:
- normal peak;
- burst peak;
- central analytics latency;
- CoP latency;
- partial timeout;
- retry storm.
Verify:
- no bypass;
- no duplicate payment;
- controlled customer response;
- stable queue;
- proper metrics.
Privacy testing
Test:
- least-privilege views;
- masked data;
- export controls;
- audit of investigator access;
- retention/deletion policies.
Fraud data is sensitive and should not become a broad operational data lake.
Use-case launch checklist
For every new RTR product ask:
Customer
- who initiates?
- who authorizes?
- what confirmation/warning is shown?
Risk
- fraud typologies?
- CoP?
- central analytics?
- internal model?
- limits?
Payment
- amount/currency?
- participant reachability?
- remittance?
- UETR/idempotency?
Settlement
- expected volume?
- burst?
- liquidity?
Operations
- exceptions?
- return?
- customer support?
Finance
- fees?
- accounting?
- reconciliation?
Compliance
- AML/sanctions/privacy/regulatory treatment?
The same rail can support many products only if each product is designed deliberately.
Fraud-control requirements by payment stage
Before the customer enters payment details
Fraud prevention starts before the payment screen.
Controls can include:
- secure customer onboarding;
- strong credential/device enrollment;
- account-change monitoring;
- contact-detail change controls;
- beneficiary-master governance for corporates;
- education on impersonation and remote-access scams.
A compromised identity that is not detected until the final payment click gives the bank less time to intervene.
While the customer creates the payment
Capture risk context:
- device/session;
- payee novelty;
- amount compared with normal behavior;
- recent account changes;
- recent failed authentication;
- payment purpose/product.
The bank should not collect a purpose field and then ignore it. Where legally and operationally appropriate, purpose can be one feature among many, while recognizing customers may enter inaccurate/free-text information.
At beneficiary creation
New-beneficiary events deserve their own controls.
Possible actions:
- CoP;
- warning;
- step-up authentication;
- cooling/limit under bank policy;
- out-of-band corporate verification;
- beneficiary risk check.
Store beneficiary-created timestamp separately from payment timestamp.
Immediately before submission
The final fraud decision should use the exact amount and beneficiary that will be placed in the pacs.008.
If the payment hub changes:
- amount;
- beneficiary;
- destination account;
after the fraud decision, invalidate/re-run the appropriate control path.
A risk decision on CAD 500 to Beneficiary A cannot authorize CAD 5,000 to Beneficiary B.
After submission but before settlement
Once the RTR message is submitted, the Sending Participant cannot simply cancel it.
Operational monitoring still matters:
- detect status anomalies;
- detect possible duplicate technical attempts;
- watch customer report arriving immediately after submission.
If a customer reports fraud in this narrow window, operations should follow the defined process rather than promising an instant recall.
After settlement
Post-event controls can still:
- detect mule behavior;
- block further related customer activity;
- secure compromised accounts;
- initiate return/recovery;
- contribute central risk intelligence;
- identify linked victims.
Prevention of the next payment can be as important as recovery of the first.
Fraud-control evidence matrix
| Stage | Key evidence |
|---|
| Authentication | method, device, result, timestamp |
| CoP | request, result, warning, customer decision |
| Central analytics | assessment/reference |
| Participant decision | score/rules/reason/version |
| Payment | payment ID, UETR, amount, beneficiary |
| Settlement | outcome/time |
| Customer report | claim type, time, narrative |
| Recovery | return request, response, recovered amount |
| Reimbursement | decision, amount, journal |
This matrix should be searchable for investigations.
Fraud case service levels
A bank can define operational targets such as:
- compromised-account security action immediately;
- high-risk beneficiary escalation promptly;
- return request as soon as required facts are available;
- customer updates at defined intervals.
The exact targets are institution policy, but cases should not sit in an undifferentiated queue.
Vulnerable-customer considerations
Some customers can be more susceptible to impersonation or coercion.
Customer-protection design can include:
- clearer warnings;
- easy access to human support;
- trusted-contact processes where lawful/product-supported;
- stronger challenge for unusual payments.
Controls should avoid discriminatory assumptions and be based on documented customer-support and risk policies.
Social-engineering signals from customer interaction
Call-center or branch events can become relevant fraud context.
Example:
- customer calls saying someone from "security" is on another line;
- minutes later initiates a new-payee RTR transfer.
If systems permit lawful sharing of this signal, it can strengthen a fraud decision.
This requires integration between customer service and fraud, not just payment-message data.
Cross-channel velocity
A customer can attempt:
- mobile payment;
- web payment;
- API/payment file.
Velocity controls should aggregate across relevant channels.
An attacker should not be able to evade a daily limit by switching interfaces.
Beneficiary-level exposure
Monitor recipient exposure across senders where the participant has visibility.
Useful measures:
- number of unique payors;
- amount received;
- first-time payor share;
- complaint count;
- rapid outward movement.
Receiving-side models can be especially strong here.
Fraud feedback loop
Confirmed cases should feed:
- internal model training;
- rules;
- customer education;
- risk-list contribution where required;
- product-limit review;
- operational training.
False positives should also feed back.
The feedback loop should be controlled, with quality review so a mistaken fraud classification does not contaminate future decisions.
Product-level fraud appetite
Different products can have different risk characteristics.
Examples:
- consumer P2P;
- corporate supplier API;
- marketplace payout;
- government disbursement.
Define:
- max amount;
- customer eligibility;
- beneficiary rules;
- fraud thresholds;
- challenge method;
- recovery process.
Do not use one generic retail fraud policy for every RTR product.
Release governance for fraud changes
A new fraud rule can stop a large percentage of real-time payments immediately.
Deploy with:
- peer review;
- simulation/backtest;
- controlled rollout;
- monitoring;
- kill/rollback capability;
- audit.
Emergency rules still need documented authorization.
Model and rule version on each decision
Store:
- modelVersion;
- ruleSetVersion;
- centralAssessmentReference;
- finalDecisionVersion.
When a customer disputes a payment months later, the bank can reproduce which control logic was active.
Fraud and payment observability correlation
Operations should correlate:
- payment latency;
- fraud latency;
- decline rate;
- central-service errors.
If payment latency rises at the same time as fraud-service p99 latency, the cause is visible.
Without correlation, teams may investigate the gateway while the bottleneck is fraud.
Future-use-case pilot controls
For a new product, start with controlled scope:
- selected customers;
- lower limits;
- defined participants;
- enhanced monitoring;
- daily review;
- explicit success/stop criteria.
A pilot should measure:
- adoption;
- fraud;
- false positives;
- settlement liquidity;
- reconciliation;
- support demand.
Scale only after both customer value and control performance are understood.
Fraud economics, model governance and use-case controls
Real-time fraud management should be measured as both a risk discipline and a payment-product discipline.
Fraud loss is more than stolen principal
A fraud event can create:
- customer loss;
- reimbursement;
- unrecovered bank loss;
- investigation cost;
- customer-support cost;
- regulatory/reporting work;
- reputation impact;
- operational restrictions on otherwise legitimate customers.
A fraud programme should therefore optimize total customer and bank harm, not merely decline rate.
Prevention versus friction
A control can reduce fraud and still damage the product if it blocks too many legitimate payments.
Track:
- confirmed fraud capture;
- false-positive decline;
- challenge completion;
- customer abandonment;
- support calls after decline;
- recovery rate;
- complaint rate.
A model that declines 10% of legitimate transactions to stop a small additional loss may not be acceptable.
Central assessment plus local context
Central Fraud Analytics has a network perspective; the participant has customer context.
A participant may know:
- customer has paid this supplier monthly for years;
- device is trusted;
- corporate approver pair is normal;
- customer called support minutes earlier;
- beneficiary was added after credential reset;
- transaction is unusual for this account.
The final decision should combine the central assessment with these local signals under the participant's policy.
Confirmation of payee decision states
Store CoP separately from fraud.
Possible internal representation:
- MATCH;
- CLOSE/PARTIAL where supported;
- NO_MATCH;
- UNAVAILABLE;
- ERROR.
Then store:
- warning shown;
- customer proceeded/cancelled;
- bank fraud decision.
This prevents a later investigator from seeing "payment passed CoP" and incorrectly concluding it was safe.
Scam intervention
For suspected authorized scams, useful intervention can include:
- contextual warning;
- step-up authentication;
- forced pause under bank policy;
- secure customer-support contact;
- specific question such as "Did someone claiming to be your bank tell you to move this money?"
The intervention should target known scam techniques without revealing fraud-engine thresholds.
Mule-network control
Receiving-side monitoring should look beyond one transaction.
Signals can include:
- many unrelated first-time payors;
- sudden increase in inbound volume;
- short time-to-onward-transfer;
- linked devices/contacts;
- multiple fraud reports;
- fan-in followed by rapid fan-out.
Central/shared intelligence can strengthen the receiving bank's view.
Central Risk List governance
Before contributing or acting on shared risk information, participants need:
- reliable identifiers;
- evidence/source;
- effective timestamp;
- correction/removal process;
- retention control;
- access control.
Poor-quality shared data can create false positives across the ecosystem, so contribution quality is itself a control.
Model change management
Every production fraud model or rule set should have:
- version;
- owner;
- validation evidence;
- approval;
- deployment date;
- monitoring;
- rollback.
For major changes, compare expected impact on:
- decline rate;
- fraud capture;
- customer segment;
- transaction latency.
Emergency scam rules still require a documented owner and retrospective review.
Real-time latency budget
Fraud orchestration should set latency objectives for:
- CoP;
- central analytics;
- internal feature retrieval;
- model/rules;
- final decision.
Monitor p95/p99.
A central or internal dependency that becomes slow can create a payment-service incident even if it is technically "available."
Fraud-dependency incident policy
For each dependency, document the approved behavior.
Examples:
- fail closed;
- temporary product restriction;
- lower internal limit;
- approved alternate control.
Never create an undocumented production bypass because a service is slow.
Recovery economics
For a scam payment of CAD 10,000:
- customer may be reimbursed CAD 10,000;
- bank may recover CAD 6,000;
- remaining CAD 4,000 is loss/recoverable according to policy.
The accounting should represent:
original settled payment;
customer reimbursement;
interbank recovery;
remaining loss.
Do not treat "case closed" as proof that finance reconciled.
Return-request prioritization
When fraud is reported, speed matters.
Prioritize cases based on:
- amount;
- time since settlement;
- recipient risk;
- known linked cases;
- vulnerable-customer considerations;
- probability that value is still recoverable.
The case system should generate and track the Rule 7 return-request deadlines automatically.
Customer-support language
Support should distinguish:
Payment settled
The original transfer completed.
Return requested
The receiving participant has been asked to return funds.
Return accepted
Receiving side agreed, but financial value should still be tracked.
Funds recovered
Returned value is actually received/reconciled.
Customer reimbursed
Bank credited customer under its applicable policy.
These are different facts.
Use-case risk matrix
| Use case | Dominant risks | Key controls |
|---|
| Consumer P2P | impersonation, ATO, mule | MFA, CoP, behavior, beneficiary risk |
| Supplier payment | invoice diversion, BEC | maker-checker, supplier verification, CoP |
| Payroll correction | insider/bypass, duplicate | entitlement, payroll linkage, idempotency |
| Marketplace payout | fake seller, payout ATO | platform controls, beneficiary risk, API security |
| Merchant A2A | social engineering, refund abuse | consent, merchant identity, refund linkage |
| Government disbursement | beneficiary data fraud, mass duplicate | authoritative data, controlled bulk orchestration |
| Embedded API | credential compromise, automation abuse | scoped credentials, rate/amount controls, anomaly detection |
The rail is common; the fraud model is product-specific.
Future international domestic-leg data controls
The Rule 6 effective date is stated in Section 9; the controls below are future-design requirements, not current production capability.
A future design must retain:
- original international payment context;
- required originator/beneficiary data;
- sanctions/AML evidence;
- domestic UETR/correlation;
- settlement linkage.
Do not flatten a cross-border payment into an apparently ordinary domestic transfer and lose the information needed for transparency.
Pilot success criteria
Before scaling a new use case, measure:
- payment success;
- customer adoption;
- fraud rate;
- false positives;
- payment latency;
- liquidity impact;
- reconciliation breaks;
- customer-support volume;
- operational incidents.
A successful pilot is not "transactions moved." It is "transactions moved safely and could be supported and reconciled."
Fraud learning loop
Every confirmed fraud case should feed:
- typology statistics;
- model/rule review;
- customer-warning review;
- beneficiary-risk intelligence;
- operations training;
- product-limit review.
Every false positive should feed the same loop from the opposite direction.
The goal is continuous adaptation rather than permanent accumulation of rules.
Human review boundaries
Manual review should be reserved for cases that genuinely need judgment.
Real-time transaction flow cannot depend on ordinary payments waiting for an analyst.
Design:
- automated pre-send decision;
- exception/manual investigation where needed;
- rapid post-event recovery.
This preserves both speed and control.
Final fraud-readiness question
For every RTR product, ask:
If a genuine customer authenticates correctly but is being socially engineered into sending money to a mule, what information would cause us to intervene before settlement—and what can we do if we learn about it five minutes later?
A credible answer requires authentication, CoP, central fraud intelligence, participant analytics, receiving-side monitoring, investigation and recovery to work as one joined process.
Fraud acceptance criteria for each new RTR product
Before a product is enabled, fraud and product owners should sign off a concrete control model.
At minimum answer:
- How is the payer authenticated?
- When is step-up authentication required?
- How is confirmation of payee presented?
- What happens on mismatch or unavailable result?
- How is Central Fraud Analytics called and correlated?
- Which participant signals are added?
- What can automatically decline the payment?
- What is the service-outage policy?
- How are mule signals handled on incoming payments?
- How is post-event recovery initiated and tracked?
If any answer is "operations will decide manually," the real-time design needs refinement.
Scam-specific customer journey testing
Test warnings with real human-readable scenarios, not only backend scores.
Examples:
Bank impersonation
Customer is told by a caller to move funds to a "safe account." The interface should challenge the exact behavior without implying that a successful CoP match makes it safe.
Invoice diversion
Corporate beneficiary details changed recently. CoP and corporate maker-checker should make the change visible before release.
Investment scam
First payment may appear normal; repeated escalating payments and beneficiary intelligence should influence later decisions.
Recovery dashboard
Fraud operations should see:
- original UETR;
- settlement time;
- customer report time;
- return request sent;
- receiver response due;
- extension if any;
- amount recovered;
- reimbursement amount;
- outstanding loss;
- linked beneficiary-risk actions.
The dashboard should age cases against rule and internal deadlines.
Product-level fraud review
After launch, compare expected and actual:
- fraud rate;
- authorized versus unauthorized mix;
- CoP mismatch rate;
- central-assessment distribution;
- false positives;
- recovery rate;
- customer reimbursement;
- manual case volume.
Use this review to adjust product limits, customer warnings and model controls rather than only adding more fraud rules.
Fraud scenario matrix and future-product guardrails
Fraud controls should be validated against scenarios that differ in who is compromised or deceived.
| Scenario | Customer authenticated? | Customer intended payment? | Main control opportunity |
|---|
| Account takeover | attacker may pass controls | No | device/session/MFA/behavior |
| Bank impersonation | Yes | Yes, but deceived | contextual warning, beneficiary risk |
| Invoice diversion | Yes | Yes, wrong beneficiary | CoP, supplier-master controls |
| Investment scam | Yes | Yes, deceived | pattern, warnings, beneficiary intelligence |
| Mule receipt | Receiving side | N/A | receiving analytics, network intelligence |
| First-party false claim | Yes | Yes | evidence and investigation |
Authentication therefore cannot be the final fraud decision.
Evidence required for fair investigation
A disputed payment should retain authentication, device/session evidence, beneficiary creation or change time, CoP result, warning and customer response, central assessment, participant decision, UETR, settlement outcome, customer report time and recovery actions.
Incoming fraud controls
Receiving participants should monitor sudden inbound velocity, many unrelated payors, recipient account age, rapid onward movement, linked devices/accounts and previous complaints. Network safety improves when the receiving bank detects mule patterns rather than relying only on the sender.
Corporate supplier payment guardrails
Use corporate entitlements, maker-checker where required, supplier bank-detail change controls, CoP, file/API idempotency, rich remittance validation and business-specific fraud monitoring. Do not remove corporate approval merely because the rail is fast.
Marketplace payout guardrails
Define platform and bank responsibilities, secure API credentials, validate payout beneficiaries, monitor burst volume, prevent duplicate payouts, plan settlement-capacity peaks and reconcile the platform job to individual RTR payments. A platform batch is still many individual real-time economic payments.
Merchant account-to-account guardrails
Define payer consent, merchant identity, refund model, dispute expectations and reconciliation. Do not copy card chargeback language into an RTR proposition unless the product itself creates those contractual rights.
Fraud service resilience
Test CoP latency, central analytics degradation, participant fraud-service failover, stale risk-list data and decision replay. Approved fallback behavior must remain consistent with Rule 13 obligations and bank policy; an outage must never create an undocumented control bypass.
Recovery performance measures
Track time from customer report to case creation, time to return request, receiving-participant response, amount recovered, amount reimbursed, unresolved loss and linked mule-account actions.
Use-case approval test
Before any future RTR proposition is marketed, product, fraud, payments, treasury, operations and finance should jointly answer: Is it permitted and technically available now? What is the amount limit? Who owns authorization? What fraud typologies dominate? What happens after error or scam? How is settlement funded? How does the customer reconcile? What does support say when outcome is uncertain?
If the team cannot answer all eight, the product idea is ahead of its operating model.
11. Practical fraud and use-case scenarios
Example 1 — account takeover
Attacker gains credentials.
New device logs in.
Password recently reset.
New beneficiary is added.
CAD 9,500 RTR payment attempted.
Controls:
- step-up authentication;
- device risk;
- behavioral anomaly;
- central analytics;
- beneficiary risk.
Bank declines before pacs.008.
No RTR settlement occurs.
Example 2 — bank impersonation scam
Customer receives call claiming to be from bank security.
Fraudster tells customer to send CAD 7,000 to a "safe account."
Customer authenticates correctly.
CoP may show recipient's real account name, which does not match the "bank security" story.
Bank shows strong warning.
Customer can choose to proceed under CoP interaction, but the bank's fraud engine can still decline based on scam indicators/risk.
Example 3 — supplier invoice fraud
Corporate user receives fake supplier email.
New bank details entered.
CoP mismatch appears.
Maker proceeds; checker notices mismatch and calls supplier using known phone number.
Payment is stopped before release.
The corporate approval workflow prevented an authorized scam.
Example 4 — mule account
Receiving bank sees one account receive:
- 35 RTR payments;
- from 30 unrelated senders;
- within 25 minutes;
- followed by rapid outgoing transfers.
Receiving fraud controls escalate and the account is investigated according to policy/law.
Central/shared intelligence can help other participants identify the recipient risk.
Example 5 — fraud discovered after settlement
Customer reports scam 20 minutes later.
Sending bank:
- opens fraud case;
- identifies UETR;
- confirms settlement;
- contacts receiving-side process;
- sends Rule 7 return request where appropriate;
- separately applies customer-reimbursement policy.
Original payment remains settled in history.
Example 6 — central fraud service latency
Central analytics response time increases sharply.
Payment queues start growing.
The bank follows its approved fallback/availability policy rather than silently bypassing the required control.
Operations monitors:
- fraud-service latency;
- payment latency;
- timeout/decline behavior;
- customer impact.
Example 7 — marketplace payout burst
Marketplace releases 20,000 seller payouts.
Payment hub must handle:
- idempotency;
- participant reachability;
- fraud;
- settlement capacity;
- burst traffic;
- reporting/reconciliation.
One failed API call should not resend the whole batch.
RTR is transaction-based, even if the business initiates many payments from a file or API job.
Example 8 — payroll correction
Employer's normal AFT payroll missed one employee.
Employer creates an RTR correction payment.
Corporate entitlements require two approvals.
Payment includes payroll reference/remittance.
Employee receives funds quickly.
This is a complementary instant use case, not evidence that all payroll should move from AFT.
Example 9 — CAD 150,000 supplier invoice
Corporate wants instant supplier payment of CAD 150,000.
The approved Rule 6 RTR Exchange Value Limit is CAD 100,000 per RTR Payment Message (the Payments Canada FAQ describes this as the initial launch limit).
Bank should offer another eligible route such as a wire/Lynx-based product if appropriate.
Do not split automatically into two RTR payments to evade limit.
Example 10 — future international domestic leg
In 2026, product team proposes using RTR as domestic Canadian leg of an international electronic funds transfer.
Rule 6 has a future effective date for that functionality.
The bank records it as future roadmap work, not current production capability.
12. Key takeaways and authoritative references
RTR fraud management is a layered participant-and-central-service model.
Participants remain responsible for their own Fraud Control Standards. Sending participants authenticate the payor, continuously monitor transactions, implement confirmation of payee, obtain Central Fraud Analytics assessment for each RTR Payment Message and make the final send decision using central and participant information.
Confirmation of payee improves payee verification but does not prove legitimacy. A correct match can still be an authorized scam. Customers may be allowed to proceed after a CoP result under the rule design, but the bank still applies its own risk and legal controls.
Centralized intelligence is valuable because scams and mule networks cross institutions. Central Fraud Analytics, Central Risk List information and fraud reporting complement device, customer, account and behavior signals available only to the participant.
Post-event handling needs speed and precise evidence. UETR links the original payment to the investigation. Rule 7 supports defined return and Payment Return Request processes, including fraud reasons, but a request is not a guaranteed recovery and does not undo the historical settlement record. Customer reimbursement and interbank recovery should be accounted for separately.
Future RTR propositions can include supplier payments, urgent payroll corrections, payouts, merchant account-to-account payments, government disbursements and embedded finance. Each needs its own fraud, customer, operational, liquidity and reconciliation design. The RTR is the infrastructure; the product is built above it.
The practitioner rules are:
- never treat authentication as proof that a payment is legitimate;
- treat CoP as payee verification, not a fraud guarantee;
- combine central fraud assessment with participant context;
- keep fraud decisions in the real-time path but keep non-critical analytics asynchronous;
- monitor receiving-side mule behavior as well as sending-side account takeover;
- preserve UETR and evidence for rapid investigation;
- distinguish unauthorized fraud, authorized scam and end-user error;
- distinguish return request, actual recovery and customer reimbursement;
- design each new use case with its own risk and reconciliation model;
- clearly label future rule capabilities as future until their effective date.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.