Canadian Payment Fraud Landscape. Recognize account takeover, social engineering, impersonation, scams, mule activity and rail-specific fraud patterns.
Block 13 · Chapter 61 of 75
Payment fraud in Canada is not one problem and it is not confined to one rail. It can begin with stolen credentials, a compromised device, an impersonation call, a fake supplier invoice, a manipulated payee, a fraudulent merchant, an unauthorized pre-authorized debit, a mule account or a legitimate customer who is persuaded to send money to a criminal.
That distinction matters because different fraud types require different controls. Strong authentication can stop an attacker who stole a password, but it can do little by itself when the genuine customer passes multi-factor authentication and deliberately sends money because a fraudster convinced them that the transfer is necessary. Confirmation of payee can expose a beneficiary-name mismatch, but a perfect name match does not make an investment opportunity genuine. Transaction monitoring can identify an unusual outgoing payment, but receiving-side monitoring may be better placed to identify a mule account receiving dozens of unrelated credits.
The Canadian Anti-Fraud Centre (CAFC) update dated 25 August 2026 reported approximately CAD 351 million in losses reported during the first six months of 2026. Investment fraud was the largest reported loss category at about CAD 139.6 million; spear phishing was about CAD 57.7 million, bank-investigator fraud about CAD 28.6 million, extortion about CAD 25.5 million and recovery fraud about CAD 13.7 million. The CAFC estimates that only 5%–10% of fraud is reported. These figures are not a measurement of payment-system failure; they are evidence of the scale of deception and criminal activity that banks, PSPs, networks and customers must manage.
This chapter gives a banking-operating view of the problem. It separates account takeover from authorized scams, examines impersonation and mule activity, maps fraud patterns to AFT, PAD, Interac e-Transfer, debit cards, wires and real-time payments, and then connects prevention, detection, case management, recovery, customer treatment, reporting and evidence.
The purpose is not to memorize scam names. It is to learn how a payment institution recognizes who is being deceived, which control still has time to act, what payment state exists, and what evidence is needed next.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- distinguish unauthorized payment fraud from authorized payment fraud;
- explain account takeover, credential theft, session hijacking and beneficiary manipulation;
- recognize impersonation, business-email-compromise, invoice diversion, investment and recovery scams;
- explain how mule accounts support fraud ecosystems;
- distinguish sending-side and receiving-side fraud responsibilities;
- explain why fraud risk differs across AFT credits, PADs, Interac e-Transfer, debit cards, Lynx wires and RTR payments;
- identify the control value of authentication, device intelligence, limits, beneficiary controls, behavioral analytics and transaction monitoring;
- explain why confirmation of payee reduces some errors and scams without guaranteeing legitimacy;
- distinguish a fraud decline, payment reject, settlement failure, customer dispute and recovery request;
- connect fraud cases to payment references, settlement evidence and customer ledger entries;
- design a post-event fraud response that contains risk before pursuing recovery;
- explain why reimbursement and interbank recovery are separate financial events;
- understand the difference between fraud monitoring, AML monitoring and sanctions screening;
- identify evidence needed for a fair investigation;
- design practical fraud metrics and operational queues;
- test fraud controls without making every unusual payment a manual review.
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, and the remaining time on practical cases and references.
Chapter navigator
- The Canadian fraud landscape
- Fraud taxonomy: who is deceived or compromised
- Account takeover and digital-channel compromise
- Social engineering, impersonation and business fraud
- Mule accounts and receiving-side risk
- Fraud patterns by Canadian payment type
- Prevention, detection and decisioning
- Post-event response, recovery and customer treatment
- Evidence, reporting and investigations
- Implementation, metrics and testing
- Practical Canadian fraud scenarios
- Key takeaways and authoritative references
1. The Canadian fraud landscape
A payment fraud event normally combines three layers:
- criminal method — phishing, malware, impersonation, forged instruction, stolen card, mule recruitment;
- payment mechanism — Interac e-Transfer, AFT, PAD, card, wire, real-time payment;
- operational consequence — unauthorized debit, authorized scam payment, misdirected value, fraudulent receipt, disputed payment or attempted fraud.
Confusing these layers produces weak controls.
For example, "Interac fraud" is not a single typology. The criminal may:
- take over the sender's online banking;
- deceive the customer into sending voluntarily;
- compromise an email account used to receive a transfer;
- change an Autodeposit registration;
- use a mule account to receive stolen funds;
- send a fraudulent Request Money message;
- imitate a genuine Interac notification in a phishing message.
The rail is the transport. The fraud mechanism sits around it.
Current scale
The CAFC's 25 August 2026 update reported approximately CAD 351 million in losses reported during the first six months of 2026. It reported investment fraud at approximately CAD 139.6 million, spear phishing at CAD 57.7 million, bank-investigator fraud at CAD 28.6 million, extortion at CAD 25.5 million and recovery fraud at CAD 13.7 million. The CAFC estimates that only 5%–10% of fraud is reported.
These numbers should be used carefully.
They tell us:
- social engineering remains economically significant;
- fraud losses are not limited to unauthorized transactions;
- impersonation of banks, government, police and businesses remains a recurring pattern;
- victims may be targeted repeatedly, including by recovery scams.
They do not tell us:
- which payment rail caused the loss;
- how much was recovered;
- whether the customer was reimbursed;
- whether the transaction was unauthorized under a bank agreement;
- whether a control failure occurred.
A bank must classify the actual payment event.
Fraud is an end-to-end operating risk
Fraud prevention involves:
- onboarding;
- authentication;
- device/session security;
- beneficiary management;
- payment limits;
- transaction monitoring;
- receiving-account monitoring;
- customer warnings;
- case investigation;
- recovery;
- reporting.
A payment-engine team that treats fraud as an external API call misses most of the control chain.
2. Fraud taxonomy: who is deceived or compromised
The most useful operational classification begins with one question:
Did the genuine customer intend to make this payment?
Unauthorized payment
The customer did not authorize the economic transaction.
Examples:
- stolen online-banking credentials;
- SIM-swap combined with credential compromise;
- malware controlling a session;
- stolen debit card/PIN;
- attacker adds a new payee and sends funds;
- attacker changes account or Autodeposit information.
Control emphasis:
- authentication;
- device intelligence;
- session monitoring;
- credential-reset controls;
- behavioral anomaly detection;
- customer notification;
- rapid containment.
Authorized payment fraud
The genuine customer authenticated and intentionally released the payment but was deceived.
Examples:
- bank-investigator impersonation;
- police/government impersonation;
- business email compromise;
- supplier-invoice diversion;
- fake investment;
- romance scam;
- purchase scam;
- recovery scam.
Control emphasis:
- beneficiary intelligence;
- confirmation of payee;
- contextual customer warnings;
- behavioral analysis;
- first-time payee risk;
- payment-purpose anomalies;
- transaction velocity;
- network intelligence.
Payment error
Not every loss is fraud.
Examples:
- customer mistypes an email address;
- corporate master data has old bank account;
- duplicate payment from a retry;
- wrong amount;
- wrong beneficiary selected.
The bank should not label an operational error as fraud just to route it into a case queue.
First-party fraud or false claim
The account holder may deliberately misrepresent what occurred.
Evidence matters:
- authentication;
- device;
- approval steps;
- beneficiary history;
- correspondence;
- transaction sequence.
Investigations must be neutral and evidence-led. A successful authentication event is evidence but not, by itself, proof that a disputed transaction was knowingly authorized.
Merchant and account-opening fraud
Payment fraud can begin before the payment.
Examples:
- synthetic identity;
- stolen identity;
- fake merchant;
- mule account opened for criminal receipt;
- legitimate account later sold or controlled by criminals.
This is why onboarding, KYC and fraud operations share data even though their legal obligations are different.
3. Account takeover and digital-channel compromise
Account takeover begins when an attacker gains enough control to act as the customer.
Common attack sequence
- obtain credentials or personal data;
- compromise email, phone or device;
- defeat or manipulate authentication;
- establish a beneficiary or payment instruction;
- move value;
- move received funds onward.
Attackers may use:
- phishing;
- smishing;
- credential stuffing;
- social-engineering of call centres;
- SIM swap;
- remote-access software;
- malware;
- push-notification fatigue;
- stolen session tokens.
Authentication signals
A strong decision uses several layers.
Identity
- password/passkey;
- MFA;
- device binding;
- biometrics where used.
Device
- known/new;
- rooted/jailbroken;
- malware indicators;
- emulator;
- device reputation.
Session
- IP/geolocation;
- impossible travel;
- network reputation;
- navigation pattern;
- recent credential reset.
Payment
- new payee;
- unusual amount;
- unusual time;
- rapid sequence;
- unusual destination.
A bank should not collapse all of this to "MFA passed."
Sensitive-event controls
High-risk changes often deserve stronger control than ordinary login.
Examples:
- reset password;
- change phone number;
- enroll new device;
- add beneficiary;
- change Autodeposit destination;
- raise payment limit.
A useful fraud pattern is:
credential reset → new beneficiary → high-value payment within minutes.
Each event may be valid alone. The sequence is the signal.
Step-up authentication
Step-up can be triggered by risk.
Examples:
- challenge for new payee;
- stronger factor after device change;
- out-of-band confirmation for high-risk corporate instruction.
The design should prevent circular authentication where the same compromised channel approves its own change without independent evidence.
Customer alerts
Alerts should cover significant events:
- new device;
- password reset;
- new payee;
- payment sent;
- Autodeposit change.
The alert should use a trusted channel and give a clear action when the customer does not recognize the event.
Recovery starts with containment
After suspected takeover:
- lock or restrict compromised access;
- invalidate sessions/tokens;
- secure contact details;
- preserve logs;
- identify related payments;
- prevent further beneficiary changes;
- check receiving accounts where possible.
Chasing the first transfer while leaving the account compromised creates the second transfer.
4. Social engineering, impersonation and business fraud
Social engineering succeeds because the criminal controls the story rather than the account.
Bank-investigator fraud
The fraudster claims to represent:
- bank fraud department;
- police;
- government;
- payment network.
The customer may be told:
- account is compromised;
- money must be moved to a "safe account";
- a test transfer is required;
- investigation must remain secret.
The genuine customer may authenticate perfectly.
Fraud controls therefore need contextual intervention.
A useful warning is specific:
Your bank or police will not ask you to move money to protect it.
A vague "beware of fraud" banner is easier to ignore.
Business email compromise and invoice diversion
Typical sequence:
- criminal compromises or imitates supplier email;
- sends new bank details;
- accounts-payable master is changed;
- next invoice is paid to criminal account.
Controls:
- independent callback using known contact;
- dual approval for supplier-master change;
- confirmation of payee where available;
- cooling period for critical beneficiary changes;
- first-payment monitoring;
- corporate maker/checker.
The control target is the change of destination, not merely the payment amount.
Spear phishing
CAFC's 2026 trend reporting highlights spear phishing.
In payment operations, spear phishing can target:
- CFO;
- treasury;
- accounts payable;
- payroll;
- call centre;
- system administrator.
A believable message may contain real names and invoices obtained from prior compromise.
Investment and recovery fraud
Investment scams may begin with small successful withdrawals to establish trust, then escalate.
Recovery fraud targets a victim who already lost money:
- false law firm;
- false recovery agency;
- false government fee;
- false crypto recovery.
Payment monitoring should consider repeated first-time beneficiaries, escalating values and unusual transaction purpose, but no rule can assume every investment payment is fraudulent.
Romance and emergency scams
Trust can build over weeks or months. Transaction history may therefore look gradual rather than sudden.
Human review should examine context, not stereotype customers.
Customer-choice versus bank decision
A customer warning is not always the final control.
Depending on the product and applicable rules, a bank may:
- allow;
- step-up;
- delay under policy;
- decline;
- restrict channel;
- escalate.
The decision authority must be documented before an incident.
5. Mule accounts and receiving-side risk
A mule account receives and moves illicit value.
It may be:
- opened using stolen identity;
- opened by a willing participant;
- legitimate account recruited later;
- business account compromised;
- account controlled through social engineering.
Receiving-side signals
Signals include:
- many unrelated inbound payors;
- rapid increase from low activity;
- funds moved out shortly after receipt;
- fan-in/fan-out;
- repeated fraud complaints;
- cash/crypto conversion after receipt;
- common device/phone/address links.
Why sender monitoring is insufficient
Sending Bank A may see:
- one new beneficiary;
- one CAD 2,000 payment.
Receiving Bank B may see:
- 30 new senders;
- CAD 60,000 in one hour;
- rapid onward transfer.
The receiving side can detect the network pattern.
Hold and legal authority
Banks must distinguish:
- fraud-risk action permitted by account terms/law;
- AML monitoring;
- sanctions/legal prohibition;
- payment-system settlement finality.
A fraud flag does not automatically create authority to reverse a settled payment.
Network intelligence
Shared fraud intelligence can help identify:
- known mule accounts;
- repeated beneficiary complaints;
- linked devices;
- beneficiary-risk patterns.
For the pre-launch RTR, Payments Canada's approved Rule 13 and planned Centralized Fraud Services define a shared layer for launch. As of this audit date, they are being validated in participant testing rather than operating as a live customer rail. Other rails have different operating models.
Mule investigation
Preserve:
- account opening/KYC;
- inbound payment references;
- outbound movement;
- device/session data;
- linked cases;
- customer communication;
- fraud reports;
- legal/reporting actions.
The receiving bank may be central to recovery.
6. Fraud patterns by Canadian payment type
The rail changes the fraud opportunity and recovery path.
The rail-specific diagram above previews the pattern each subsection details: read each rail's risks against its recovery path before designing controls.
Implementation boundary: typical bank artifacts, not a single mandated architecture
The following is an illustrative institution implementation, not a claim that every bank uses the same API, file name or internal status. Scheme rules, technical specifications, participant agreements and the bank's own contracts control live processing.
| Rail | Customer/channel to payment hub | External or scheme evidence | Fraud and operations handoff |
|---|
| AFT/ACSS | Corporate portal, host-to-host file or bank API; maker/checker, control totals, duplicate and beneficiary-master checks | Submitted file/item and return or adjustment evidence; bank posting and ACSS position/reconciliation records | File-level and item-level decision IDs linked to payment IDs; exception, return and recovery queues |
| PAD | Biller mandate/notice record enters the bank's collection or receiving workflow; account and authority checks precede presentment | PAD item, mandate/agreement evidence, debit posting and Rule H1 reimbursement/return evidence | Authorization dispute, cancellation, return and recourse case; do not classify as card fraud |
| Interac e-Transfer | Online/mobile or business channel authenticates the sender and submits a service request; recipient address and Autodeposit state are resolved by the participating institutions | Service status, recipient/deposit confirmation, bank ledger posting and participant reconciliation; email/SMS is notification, not the funds path | Sender and receiving-side fraud alerts, cancellation where available, recovery request and customer case |
| Lynx/wire | Branch, treasury portal, host-to-host or API instruction passes entitlement, sanctions, fraud and release controls | SWIFT/ISO instruction plus Lynx settlement result and PCRN; settlement-account evidence supports the participant position | Settled payment remains final; investigation and recovery are separate from the original payment record |
| Cross-border wire | Bank channel or correspondent instruction passes sanctions, FX, beneficiary and intermediary routing controls | SWIFT/CBPR+ messages, UETR, correspondent acknowledgements and value-date/FX records | Recall or recovery request is tracked separately from settlement; intermediary response is not guaranteed |
| RTR (pre-launch at audit date) | Planned participant channel and service-provider connectivity; exact production interface and operating procedures must be validated in participant testing | Planned ISO 20022 exchange/clearing/settlement messages, participant and settlement evidence, and Rule 7/13 outputs once live | Centralized fraud services complement participant controls; do not treat testing or approved rules as live customer capability |
AFT credit and direct deposit
Typical risks:
- corporate credential compromise;
- payroll file manipulation;
- beneficiary-master change;
- duplicate file;
- malicious insider;
- batch file substitution.
Controls:
- secure file/API channel;
- maker/checker;
- file totals;
- beneficiary change control;
- duplicate detection;
- limit/velocity;
- release approval.
Batch timing may provide a window to detect problems before final downstream posting, but the bank must use actual system status rather than assume a batch can always be stopped.
PAD
PAD is a payee-initiated debit under authority.
Fraud/error patterns:
- no valid agreement;
- wrong amount/date;
- debit after cancellation;
- fraudulent biller;
- altered account data.
Rule H1 provides specific authorization and recourse protections. For a Personal PAD, Rule H1 section 24 generally gives the Payor up to 90 calendar days after the debit to claim reimbursement for the declared conditions; a Business PAD generally has a 10-Business-Day window. A claim after the applicable window is handled outside the rule, and some Funds Transfer PAD and Cash Management PAD categories have exceptions. The current Rule H1 text is the binding source.
PAD fraud is not the same as account takeover. The core evidence is often mandate/agreement authority.
Interac e-Transfer
Patterns:
- sender account takeover;
- impersonation scam;
- phishing notification;
- email compromise;
- recipient manipulation;
- mule receipt.
Interac explains that funds move through secure payment networks; email/text carries notification rather than the money itself. Autodeposit removes the security-question collection step and can reduce interception risk, while financial institutions still perform fraud checks.
Autodeposit does not prevent a sender from voluntarily paying a scammer.
Debit card
Patterns:
- stolen card/PIN;
- skimming;
- card-not-present credential theft;
- compromised mobile device.
FCAC states that federally regulated institutions must investigate disputed unauthorized card transactions and that using an authentication technology alone does not automatically make the cardholder responsible.
Lynx wire
Risks:
- corporate account takeover;
- BEC;
- beneficiary substitution;
- fraudulent branch instruction;
- insider fraud.
Because Lynx settlement is final between participants, pre-release controls are essential:
- verified instruction;
- dual approval;
- beneficiary validation;
- sanctions/AML controls;
- fraud review;
- limit/entitlement.
A later recovery request does not unwind the original settlement.
Cross-border wire
Adds:
- intermediary chain;
- FX/value date;
- cross-border beneficiary;
- sanctions screening;
- correspondent risk;
- longer investigation chain.
UETR can improve payment identification, but identification is not recovery.
RTR — pre-launch capability, not a live production rail at the audit date
As of 5 October 2026, Canada's RTR is not yet a production rail. Payments Canada targets launch in Q4 2026, with industry solution assurance testing and participant onboarding under way. Its approved RTR By-law and Rules came into force on 24 August 2026, but that legal framework and the centralized fraud services are being validated for launch rather than describing a live customer payment capability. The planned service includes confirmation of payee, a real-time fraud safety score, a risk list and fraud reporting/intelligence. Rule 7 return and exception processes and Rule 13 fraud-management obligations must be applied from the current rule set and procedures when the rail is live; they do not make today's AFT, Interac e-Transfer or wire payments RTR payments. Participant fraud controls, receiving-side monitoring and post-event recovery remain necessary after launch.
Do not present RTR as current production capability in a control requirement or customer communication. Treat message names, participant connectivity, decision latency, settlement-account operation and return handling as implementation requirements to validate during participant testing against the approved rules and procedures.
Cards versus account-to-account
Card networks have dedicated authorization, clearing and chargeback frameworks. Account-to-account rails have different rules. Do not promise a "chargeback" for an e-Transfer or wire merely because the customer knows card terminology.
7. Prevention, detection and decisioning
Fraud controls can be organized by time.
Before the payment
- customer authentication;
- device/session security;
- entitlement;
- beneficiary verification;
- payment limits;
- maker/checker;
- fraud analytics;
- contextual warnings.
During processing
- duplicate detection;
- velocity;
- central/network risk;
- receiving-side analysis;
- unusual routing or amount.
After payment
- fraud reports;
- mule analysis;
- case management;
- recovery request;
- reimbursement;
- AML/STR consideration;
- evidence preservation.
Decision outcomes
A controlled fraud engine should distinguish:
- ALLOW;
- CHALLENGE;
- REVIEW where product timing permits;
- DECLINE;
- RESTRICT;
- TECHNICAL_UNAVAILABLE.
Do not use "FAILED" for all outcomes.
False positives
A control that blocks legitimate customers is not free.
Measure:
- fraud capture;
- false-positive rate;
- challenge completion;
- abandonment;
- manual review;
- complaints;
- support contacts.
Fraud optimization balances loss prevention and legitimate access.
Manual review
Manual review is appropriate for:
- high-value unusual wires;
- complex corporate cases;
- post-event investigations.
It is not an architecture for every real-time retail payment.
Limits
Limits reduce blast radius.
Use:
- per transaction;
- daily;
- channel;
- customer;
- new beneficiary;
- corporate user;
- velocity.
Scheme maximum is not necessarily the right customer maximum.
8. Post-event response, recovery and customer treatment
The first question after a fraud report is:
What is the payment's actual state?
Possible states:
- not released;
- released but cancellable under product rules;
- accepted;
- settled;
- posted;
- available;
- recovered.
Contain first
Secure:
- account;
- credentials;
- devices;
- contact data;
- beneficiary master;
- related sessions.
Trace the payment
Use:
- internal payment ID;
- rail reference;
- UETR where applicable;
- settlement evidence;
- customer statement;
- beneficiary information.
Recovery
Recovery depends on rail and state.
Examples:
- pending Interac e-Transfer may have cancellation options under service rules;
- settled wire requires receiving-side cooperation/recovery mechanisms;
- PAD may have Rule H1 recourse;
- card transaction may have card-network dispute/chargeback mechanisms;
- RTR uses Rule 7 return/recovery processes for defined cases.
Never tell a customer "we recalled it" when the bank only sent a request.
Reimbursement versus recovery
These are different.
Example:
- customer loses CAD 8,000;
- bank reimburses CAD 8,000 under applicable policy;
- receiving institution later returns CAD 5,000;
- bank's remaining loss becomes CAD 3,000.
The customer should not be credited twice.
Customer communication
Use precise states:
- fraud reported;
- account secured;
- payment settled/not settled;
- recovery requested;
- recovery received;
- reimbursement decision.
Avoid:
- "money is frozen" without evidence;
- "recipient bank will return it";
- "MFA proves you authorized it."
FCAC protections
For federally regulated institutions, FCAC guidance on unauthorized card transactions requires investigation of disputed transactions. Consumer rights vary by product and facts. Authorized scam payments are not automatically equivalent to unauthorized card transactions.
9. Evidence, reporting and investigations
A good fraud case file allows another investigator to reconstruct the event.
Customer evidence
- account holder;
- contact history;
- customer statement;
- dispute narrative;
- device loss/compromise;
- warnings shown.
Authentication evidence
- login;
- factors;
- step-up;
- device;
- credential reset;
- session.
Payment evidence
- amount;
- beneficiary;
- payee creation/change;
- customer approval;
- internal reference;
- network/rail reference;
- UETR where applicable;
- settlement/posting timestamps.
Fraud evidence
- model score;
- rules triggered;
- confirmation-of-payee result where applicable;
- warning;
- decision;
- analyst notes.
Recovery evidence
- receiving bank contact;
- return request;
- response;
- amount recovered;
- customer reimbursement;
- remaining loss.
AML/FINTRAC consideration
Fraud and money laundering frequently intersect because proceeds may move through mule accounts.
A fraud case may create reasonable grounds to suspect money laundering, terrorist financing or sanctions evasion. FINTRAC requires an STR when the legal threshold is met, including attempted transactions. There is no monetary threshold for an STR.
Do not submit an STR merely because a transaction was operationally unusual. The compliance function applies the FINTRAC threshold using facts, context and indicators.
Tipping off
Investigation procedures should avoid customer interaction designed in a way that improperly reveals the existence of an STR where that would prejudice an investigation.
10. Implementation, metrics and testing
A bank fraud architecture usually spans:
Channel
- login;
- device;
- payee;
- customer warnings.
Identity
- MFA;
- credential events;
- session.
Payment hub
- amount;
- route;
- entitlements;
- idempotency.
Fraud platform
- features;
- model/rules;
- network signals;
- decision.
Case management
- investigations;
- evidence;
- recovery.
Receiving side
- mule monitoring;
- account restriction under authority.
Reporting
- fraud loss;
- STR workflow where applicable;
- management information.
Data quality
Fraud models need stable definitions.
Examples:
- "new payee" should mean the same in mobile and web;
- "trusted device" needs expiry and revocation rules;
- customer limit history should be available;
- payee changes must be timestamped.
Bad feature data can turn a sophisticated model into random friction.
Testing
Test normal and adversarial journeys.
ATO
- password reset;
- new device;
- new beneficiary;
- payment.
Scam
- trusted device;
- existing login;
- first-time beneficiary;
- customer ignores warning.
Corporate BEC
- supplier master changed;
- maker/checker;
- high-value AFT/wire.
Mule
- multiple unrelated incoming transfers;
- rapid onward movement.
Service outage
- fraud engine slow/unavailable;
- approved degradation policy.
Model governance
Each model/rule set should have:
- owner;
- version;
- validation;
- threshold rationale;
- monitoring;
- rollback.
Emergency rules also need retrospective review.
Privacy and access
Fraud data is sensitive.
Use:
- least privilege;
- controlled retention;
- audit logs;
- restricted case notes;
- separation between production support and investigation roles.
Fraud operating model: from signal to financial outcome
A mature fraud function does not end when a model produces a score. The score begins an operating decision that can affect a customer's access to money, a bank's legal obligations, a payment's settlement state and the accounting treatment of any eventual loss.
Separate five decisions
For each suspicious payment, separate:
- authentication decision — is the person or session sufficiently authenticated?
- fraud decision — does the bank permit this payment to proceed?
- payment decision — can the payment be released to the selected rail?
- post-event case decision — what must be done after a report or alert?
- financial decision — who is credited, reimbursed, recovered from or written off?
Collapsing them creates errors.
Example:
A customer passes MFA but the bank declines the transaction because beneficiary and behavioral signals indicate an impersonation scam. Authentication passed; fraud decision declined. There is no payment settlement or recovery case because value never left.
Another customer sends a payment that settles before a scam is reported. Authentication passed, fraud decision allowed, payment settled, post-event case opens, and the financial decision may later include reimbursement and recovery. Those facts should coexist in the case record.
Fraud case state model
A practical case workflow can use controlled states such as:
- ALERT_CREATED;
- TRIAGE;
- CUSTOMER_CONTACT;
- ACCOUNT_CONTAINED;
- PAYMENT_STATE_CONFIRMED;
- RECOVERY_REQUESTED;
- COMPLIANCE_REVIEW;
- REIMBURSEMENT_DECIDED;
- RECOVERY_RECEIVED;
- LOSS_ACCOUNTED;
- CLOSED.
Payment status must remain separate.
A case can be CLOSED while the original payment remains SETTLED. Closing a fraud investigation does not rewrite payment history.
Severity
Severity should consider:
- value;
- vulnerable-customer concerns;
- number of affected customers;
- active account compromise;
- mule-network reach;
- potential data breach;
- regulatory/reporting implications;
- media/reputation;
- systemic concentration.
A CAD 500 active account takeover affecting hundreds of users can be a more serious incident than one CAD 50,000 isolated scam.
Ownership model
A cross-functional fraud event can involve:
Fraud operations
- classify;
- contain;
- investigate.
Payment operations
- determine transaction state;
- contact rail/counterparty;
- initiate recovery.
Digital security
- secure device/session/credentials.
AML investigations
- assess suspicious activity and reporting threshold.
Customer service
- maintain accurate communication.
Finance
- reconcile reimbursement, recovery and loss.
Legal/compliance
- advise on obligations and complex cases.
Define handoffs before incidents.
Fraud data model and reference preservation
Fraud investigation is fundamentally a correlation problem.
Minimum payment identity
Store:
- bank internal payment ID;
- customer-visible reference;
- rail/network reference;
- UETR where applicable;
- source account;
- destination identifier;
- amount/currency;
- timestamps;
- payment state.
Customer/session identity
Store:
- authenticated customer/user;
- corporate role;
- device;
- session;
- login method;
- step-up method;
- credential/contact changes;
- risk-relevant channel events.
Beneficiary history
Important attributes:
- first seen;
- created by whom;
- changed when;
- prior payments;
- confirmation-of-payee result where available;
- known risk status;
- linked fraud cases.
The fraud value of "new beneficiary" depends on reliable history.
Decision evidence
Store:
- model/rule version;
- features used;
- network intelligence;
- score or risk band;
- rules fired;
- warning shown;
- customer response;
- final decision and reason.
Do not store only a final word such as PASS.
Explainability for operations
Investigators need human-readable reasons:
- new device;
- beneficiary added 4 minutes earlier;
- amount 8x usual;
- recipient linked to two confirmed cases.
They should not need to interpret raw model vectors.
Historical reproducibility
If the model changes tomorrow, the bank should still explain yesterday's decision.
Retain enough version and feature evidence to reconstruct the decision under the original model/rules.
Rail-state versus fraud-state matrix
A fraud action must respect the payment's external state.
| Payment state | Typical fraud action |
|---|
| Created/not released | block or challenge |
| Approved internally, not sent | stop before gateway |
| Submitted but final outcome unknown | investigate status; do not resend |
| Pending/cancellable under service rules | cancel where permitted |
| Settled/deposited | post-event recovery; original history remains |
| Returned/recovered | reconcile recovery and case |
| Customer reimbursed | track bank recoverable/loss separately |
Why "freeze the payment" is dangerous language
After settlement there may be nothing for the sending bank to freeze.
It may be possible to:
- request recipient restriction;
- request return;
- place controls on accounts the bank itself controls;
- engage law enforcement.
But customer-service language must describe confirmed facts.
Duplicate risk during fraud response
Under pressure, teams sometimes create a second payment to "fix" the first.
Before any replacement:
- prove original state;
- understand whether it settled;
- link corrective payment;
- use new payment identity where economically new.
Fraud urgency does not suspend idempotency.
Customer vulnerability and fair treatment
Fraud controls affect people at stressful moments.
Vulnerability signals
Examples:
- elderly customer;
- customer reporting coercion;
- cognitive/communication difficulty;
- recent bereavement;
- repeated victimization;
- scammer instructing secrecy.
These signals can justify enhanced support under bank policy, but investigators should avoid assumptions based on age or demographic alone.
Contact strategy
When contacting a customer:
- use verified bank channels;
- do not ask for passwords/one-time codes;
- explain why contact is occurring;
- verify identity proportionately;
- ask open questions about the payment purpose.
For suspected impersonation:
- ask whether anyone told the customer to move money to protect an account;
- ask whether they were told not to tell the bank;
- explain that genuine bank/police processes do not require a "safe account" transfer.
Warnings
Warnings work best when:
- timely;
- specific;
- relevant to the payment;
- require active acknowledgement when risk is high.
They work poorly when:
- shown on every payment;
- vague;
- too long;
- easy to click through.
Measure whether customers change behavior.
Customer outcome
Case files should state:
- payment state;
- recovery status;
- reimbursement decision;
- complaint/escalation rights;
- next communication date.
"Under investigation" with no next milestone creates avoidable complaint volume.
Receiving-side mule-control operating model
The receiving bank owns information the sending bank cannot see.
Inbound monitoring features
Useful measures include:
- number of unique payors;
- percentage first-time payors;
- total incoming value;
- time from receipt to onward movement;
- cash/crypto/off-us transfer after receipt;
- links to known fraud reports;
- account age;
- device/account network links.
Fan-in/fan-out
Example:
- 20 unrelated payors send CAD 1,500–3,000;
- account sends three CAD 15,000 outbound transfers within an hour.
Each incoming payment can appear normal to a sender. The network pattern is not.
Account action
The receiving bank needs policy/legal authority for actions such as:
- enhanced monitoring;
- restricting digital access;
- holding transactions where permitted;
- customer contact;
- exit/closure;
- regulatory/law-enforcement escalation.
Do not assume fraud suspicion itself creates unlimited authority over settled funds.
Recovery coordination
When another institution requests return:
- validate original payment;
- match amount/reference;
- determine current available funds;
- investigate account;
- respond under applicable rail/process;
- avoid duplicate return.
A mule may have multiple claims against limited remaining value. Case coordination matters.
Network view
Shared intelligence can identify a recipient before an individual institution accumulates enough internal evidence. For RTR, the approved design provides centralized fraud capabilities intended for launch; at this audit date, participant testing is still under way. For other rails, bilateral or network fraud channels may differ.
Corporate fraud and treasury controls
Corporate payment fraud often exploits process rather than consumer credentials.
Role design
Separate:
- payment creation;
- beneficiary maintenance;
- approval;
- release;
- administration.
A single super-user with every privilege defeats maker/checker.
Beneficiary-master change
Require:
- independent validation;
- dual control;
- source evidence;
- timestamp;
- who changed;
- first payment monitoring.
A compromised supplier email should not be able to change destination by itself.
Call-back discipline
Use a phone number from:
- existing validated master;
- independent company directory;
- prior contractual source.
Do not use the number supplied in the suspicious bank-detail change message.
File integrity
For host-to-host/API:
- mutual authentication/certificates;
- signing where used;
- replay protection;
- file hash;
- sequence/idempotency;
- control totals.
Payroll
Payroll has predictable patterns:
- pay dates;
- employee population;
- salary bands.
Fraud controls can compare:
- number of changed accounts;
- new employees;
- unusually large net pay;
- file timing.
But controls must allow legitimate bonus cycles and acquisitions. Context is necessary.
Treasury wire
High-value wires justify:
- stronger beneficiary controls;
- dual approval;
- verbal confirmation under policy;
- transaction-specific fraud review;
- sanctions/AML completion before release.
Fraud controls in ISO 20022 and richer-data environments
Richer payment data can improve fraud analysis, but only if captured correctly.
Useful structured fields
Depending on rail:
- debtor/creditor;
- agents;
- account identifiers;
- purpose;
- remittance;
- end-to-end references;
- addresses.
Do not confuse data richness with trust
A fraudster can populate valid structured data.
Structured beneficiary name:
- easier to compare;
- not proof of legitimacy.
Mapping
Fraud should evaluate the richest authoritative representation available before data is truncated for a legacy leg.
Preserve:
- source data;
- mapped data;
- transformations.
Cross-rail consistency
A beneficiary-risk service should avoid considering:
- same destination on wire as one identity;
- same destination on e-Transfer as unrelated identity;
when data can reliably link them.
Entity resolution can reveal network behavior across rails.
Fraud, AML and sanctions handoff rules
These domains share cases but not conclusions.
Fraud to AML
Escalate when facts suggest:
- laundering of fraud proceeds;
- mule network;
- rapid pass-through;
- structuring;
- suspicious source/destination.
AML then independently determines whether the reasonable-grounds-to-suspect threshold is reached.
Fraud to sanctions
A fraud investigation may reveal:
- sanctioned beneficiary;
- sanctioned jurisdiction issue;
- prohibited party.
Sanctions decision follows applicable law, not the fraud classification.
AML to fraud
Monitoring may find:
- account receiving many victim payments;
- account takeover signals;
- unusual beneficiary changes.
AML can refer to fraud for customer protection/containment.
Avoid duplicate case silos
Use common identifiers and controlled cross-links while restricting sensitive STR information.
Fraud staff do not necessarily need access to STR narrative. They do need to know any operational restriction approved by compliance.
Fraud metrics and management information
Loss metrics
Separate:
- attempted fraud value;
- prevented value;
- gross realized fraud;
- customer reimbursement;
- interbank recovery;
- insurance/other recovery;
- net bank loss.
Control metrics
- MFA challenge rate;
- new-payee challenge;
- decline rate;
- false positives;
- warning abandonment;
- model latency;
- fraud-service availability.
Operations metrics
- case volume;
- first-response time;
- containment time;
- recovery-request time;
- recovery response;
- case age;
- complaint rate.
Receiving-side metrics
- mule alerts;
- accounts restricted;
- confirmed mule cases;
- linked victims;
- recovery returned.
Segment carefully
Compare by:
- rail;
- customer type;
- channel;
- fraud typology;
- amount band.
An overall fraud rate can hide one failing product.
Fraud-control acceptance criteria for business analysts and testers
A fraud requirement should specify more than "screen transaction."
Example:
When a customer initiates a payment to a beneficiary not paid in the previous 180 days, the payment hub must send beneficiary-age, device, session, amount and customer-history features to the fraud decision service before external release. A DECLINE response prevents release and records the decision reason. A service timeout follows the documented degradation policy and cannot silently default to ALLOW.
Acceptance tests
Test:
- known beneficiary;
- first-time beneficiary;
- service timeout;
- duplicate submit;
- customer challenge passes;
- customer challenge fails;
- decision arrives after channel timeout;
- replay after application restart.
Evidence acceptance
For any tested payment, demonstrate:
- input features;
- model/rule version;
- decision;
- payment release or non-release;
- customer message;
- final ledger state.
Negative testing
Fraud systems need tests that deliberately attack controls:
- altered beneficiary after approval;
- repeated payments under limit;
- new device plus payee;
- known mule recipient;
- compromised corporate approver;
- API replay.
Performance testing
Real-time products require:
- p95/p99 decision latency;
- peak throughput;
- dependency timeout behavior.
A fraud service that is accurate but causes payment outages is not production-ready.
Fraud incident runbook
A large fraud event needs command discipline.
Example trigger
Multiple customers report bank-investigator scams sending to a cluster of recipient accounts.
First 30 minutes
- open major fraud incident;
- preserve indicators;
- identify recipient cluster;
- deploy approved rule/risk-list changes;
- contact receiving institutions/network channel;
- prepare customer-support guidance;
- monitor false positives.
Next hours
- identify impacted payments;
- classify settled/pending;
- initiate recovery;
- secure compromised accounts;
- evaluate STR/reporting needs;
- reconcile reimbursements/recoveries.
Post-incident
- root cause;
- control effectiveness;
- warning effectiveness;
- model update;
- procedure changes;
- customer outcomes;
- losses/recoveries.
Change governance
Emergency fraud rules must have:
- owner;
- rationale;
- start time;
- expected impact;
- rollback/expiry;
- retrospective review.
Otherwise temporary controls become permanent hidden logic.
Advanced fraud patterns and control design
The hardest fraud cases combine several legitimate-looking events. This is where sequence analysis and graph context become more useful than one-transaction rules.
Low-and-slow account takeover
An attacker may avoid immediately sending a large payment.
Sequence:
- log in from a device that does not look obviously malicious;
- browse balances;
- change a contact field;
- wait several days;
- add a beneficiary;
- test with a small transfer;
- increase value later.
A fraud platform that only looks at the final transaction can miss the preparation.
Useful controls:
- durable event history;
- risk decay after sensitive account changes;
- customer alerts;
- step-up on payee creation;
- linked-event features.
Payment splitting
A criminal may split CAD 20,000 into:
- five CAD 4,000 payments;
- multiple recipient accounts;
- multiple channels.
Controls should aggregate by:
- customer;
- device;
- beneficiary network;
- time window;
- linked accounts.
Avoid treating each rail as a separate fraud universe.
Dormant account activation
A low-activity account suddenly:
- resets credentials;
- receives transfers;
- sends outward immediately.
This pattern can indicate takeover or mule recruitment.
The appropriate response depends on context:
- returning student?
- seasonal business?
- compromised customer?
Models should generate a risk signal, not a legal conclusion.
Beneficiary hopping
When a known risky beneficiary becomes blocked, fraud may move to:
- related account;
- same device;
- same phone/email;
- same business;
- same receiving pattern.
Graph-based linkage can identify the cluster.
Scam coaching
Fraudsters sometimes tell victims:
- what to say to bank staff;
- how to answer warnings;
- to claim payment is for family;
- to ignore fraud alerts.
A customer's correct answer to a scripted warning is not necessarily evidence that risk disappeared.
This is why warnings should be:
- contextual;
- varied based on observed scenario;
- supported by bank decisioning rather than customer self-certification alone.
Customer authentication design in detail
Factor independence
Strong authentication is weakened if:
- password reset;
- phone-number change;
- OTP delivery;
all depend on the same compromised email or phone.
Design independent recovery pathways for high-risk changes.
Device enrollment
New-device enrollment should consider:
- prior authenticated device;
- recent contact changes;
- risk of SIM swap;
- location/network;
- customer history.
For high-risk cases, enrollment can carry a temporary risk flag into payments for an approved period.
Call-centre authentication
Fraudsters exploit human support.
Avoid relying only on static knowledge questions built from information that may be available from data breaches or social media.
Call-centre procedures should:
- authenticate;
- identify social-engineering indicators;
- restrict high-risk changes;
- record agent actions.
Corporate administrator compromise
The corporate administrator can be more powerful than a payment approver because they may:
- add users;
- change roles;
- reset authentication;
- increase limits.
Monitor:
- admin changes;
- approval-policy changes;
- new users;
- entitlement escalation.
A corporate payment control framework needs security around who can change the controls, not just who can press release.
Beneficiary-risk management
Beneficiary lifecycle
Treat beneficiary as an entity with history:
- created;
- verified;
- first paid;
- last paid;
- changed;
- complaints;
- fraud links.
Confirmation of payee
Where available, distinguish:
- match;
- partial/close match where service supports it;
- no match;
- unavailable/error.
A match means identity information aligned according to service rules. It does not establish:
- invoice validity;
- investment legitimacy;
- absence of scam.
First-time beneficiary controls
Possible controls:
- warning;
- lower limit;
- step-up;
- cooling period under product policy;
- fraud score.
Do not apply one friction level to:
- salary payment;
- rent;
- one-time family transfer;
- corporate supplier;
- house-closing wire.
Use product context.
Beneficiary change in corporate systems
Separate:
- beneficiary creation;
- beneficiary bank-account change;
- beneficiary name/address change.
A changed bank account is often higher risk than a changed mailing address.
Fraud and reconciliation
Fraud teams need reconciled financial facts.
Example accounting chain
Original payment:
- debit customer CAD 12,000;
- settle/pay recipient CAD 12,000.
Bank reimburses customer:
- credit customer CAD 12,000;
- debit fraud-loss/recoverable CAD 12,000.
Recipient bank recovers CAD 7,000:
- receive CAD 7,000;
- credit fraud recoverable/loss CAD 7,000.
Net unrecovered:
The payment ledger should not:
- delete original transaction;
- change amount to CAD 5,000;
- mark payment "reversed" if it was not.
Partial recovery
Case UI needs:
- original loss;
- reimbursement;
- recovered amount;
- outstanding amount.
"Recovered" should support partial values.
Fees
If payment fees are reimbursed:
- record separately;
- define policy.
Exchange rate
Cross-border fraud recovery may occur at a different FX rate.
Record:
- original currency/value;
- recovery currency/value;
- FX difference;
- accounting treatment.
Fraud investigations and external coordination
Counterparty requests
When contacting another bank, provide:
- payment reference;
- UETR where applicable;
- amount/currency;
- timestamp;
- beneficiary;
- fraud typology;
- requested action;
- contact/case ID.
Do not send unnecessary customer data beyond procedure/legal need.
Law enforcement
Procedures should define:
- emergency escalation;
- preservation orders/requests;
- evidence contacts;
- disclosure authority.
Operations staff should not independently disclose confidential data outside authorized channels.
CAFC reporting
Customers and institutions may interact with the Canadian Anti-Fraud Centre according to their reporting procedures. A CAFC report is not a substitute for the bank's own fraud, AML or law-enforcement obligations.
Cross-border coordination
International recovery can be harder because:
- time zones;
- correspondent banks;
- local law;
- FX;
- onward transfers.
UETR can help identify a cross-border payment but does not grant a recall right.
Operational edge cases
Fraud engine approves, channel times out
Customer sees error.
Bank fraud decision = ALLOW.
Payment hub may or may not have released.
Required behavior:
- query payment state;
- do not ask customer to retry blindly;
- use idempotency.
Fraud engine times out, payment not sent
Use approved degradation:
- fail closed;
- challenge;
- lower limit;
- alternate service.
Record:
- dependency outage;
- policy path used.
Fraud decision arrives after payment released
This is a control defect unless explicitly designed.
Investigate:
- asynchronous race;
- timeout configuration;
- release gate.
Beneficiary becomes high risk after payment
Historical payment remains what it was.
Actions may include:
- review recent payments;
- block future payments;
- open cases;
- attempt recovery where warranted.
Do not rewrite earlier fraud scores without recording that the intelligence arrived later.
Customer disputes after long delay
Evidence retention must support:
- authentication;
- payee;
- warnings;
- payment state.
Policy/legal limits may differ by product; customer service should not invent a universal fraud-claim window.
Fraud model validation
Before production
Validate:
- data quality;
- discrimination;
- stability;
- false positives;
- segment behavior;
- latency;
- fallback.
Champion/challenger
A challenger model can run without affecting decisions.
Compare:
- fraud capture;
- false positives;
- segment drift.
Do not switch purely on headline accuracy.
Bias and fairness
Fraud variables can create unintended differential impact.
Govern:
- prohibited/sensitive attribute use;
- proxy effects;
- customer-segment outcomes;
- appeals/review.
The goal is effective fraud prevention with fair customer access.
Drift
Monitor:
- score distribution;
- fraud typology mix;
- feature missingness;
- new-device rate;
- beneficiary patterns.
Criminal behavior changes; static thresholds decay.
Fraud control maturity model
Level 1 — reactive
- reports after loss;
- simple limits;
- manual cases.
Level 2 — rules-based
- velocity;
- device;
- payee;
- basic case management.
Level 3 — integrated
- cross-channel signals;
- network/beneficiary intelligence;
- real-time decisioning;
- rail-aware recovery.
Level 4 — adaptive
- graph/network analytics;
- rapid model/rule response;
- receiving-side mule intelligence;
- closed feedback loop;
- integrated customer outcomes.
Maturity is not measured by the number of models. It is measured by how well the institution prevents harm, explains decisions, recovers value and learns from cases.
Chapter 61 practitioner checklist
Before saying a fraud process is production-grade, confirm:
Before payment
- identity and entitlement known;
- sensitive account changes available as signals;
- beneficiary history reliable;
- fraud decision blocks release when required.
During payment
- decision and payment IDs linked;
- timeouts controlled;
- no duplicate release;
- external state visible.
After report
- account contained;
- payment state confirmed;
- recovery action correct for rail;
- receiving bank/contact route known;
- reimbursement tracked separately.
Evidence
- model/rule version;
- authentication;
- warning;
- customer response;
- beneficiary;
- settlement;
- ledger;
- recovery.
Governance
- rule/model owners;
- change approvals;
- false-positive monitoring;
- incident runbook;
- AML/sanctions referral rules.
A failure in any of these areas does not automatically mean the fraud program is weak, but it identifies the exact capability that needs improvement.
Fraud case quality assurance and closure
A case should not close simply because the analyst has finished typing notes.
Closure checklist
Confirm:
- compromised access is secured;
- all known related payments are classified;
- payment state is evidenced;
- recovery actions are complete or formally outstanding;
- reimbursement decision is recorded;
- AML/sanctions referrals are completed where required;
- customer communication is complete;
- financial loss/recoverable is reconciled;
- control feedback is recorded.
Outstanding recovery after case closure
Sometimes the customer issue is resolved before interbank recovery is complete.
Use a separate financial/recovery work item so:
- customer fraud case can close;
- recovery receivable remains open;
- later value is posted correctly.
Quality sampling
Periodically sample:
- unauthorized cases;
- authorized scam cases;
- high-value corporate cases;
- no-loss cases;
- false-positive declines.
Review:
- classification;
- evidence;
- customer treatment;
- recovery;
- accounting.
Lessons learned
Translate cases into:
- model changes;
- product controls;
- customer warnings;
- staff training;
- beneficiary intelligence.
A case management system that only archives history wastes the most valuable fraud data the bank owns.
Payment fraud data retention and evidence retrieval
Fraud evidence can be distributed across:
- channel logs;
- identity service;
- fraud engine;
- payment hub;
- core ledger;
- network gateway;
- contact centre.
A case should link those records without copying uncontrolled screenshots into personal folders.
Evidence retrieval objective
An authorized investigator should be able to reconstruct:
- login;
- beneficiary event;
- payment;
- decision;
- settlement;
- customer contact;
- recovery.
Time synchronization
System timestamps should use controlled time sources and clear time zones.
During an incident, a 30-second clock difference can reverse the apparent order:
- fraud decision;
- release;
- settlement.
Evidence integrity
Use:
- immutable logs where appropriate;
- controlled access;
- audit of analyst changes;
- original versus enriched values.
Customer-provided evidence
Emails/screenshots/messages can be relevant.
Store:
- original file;
- received timestamp;
- provenance;
- investigator notes.
Do not alter originals.
Fraud and payment product design review
Before launch, ask:
Customer
- who can initiate?
- how authenticated?
- how are payees created?
Payment
- when is release/finality?
- cancellation window?
- recovery process?
Fraud
- key typologies?
- signals?
- decision latency?
- receiving-side controls?
Operations
- case route?
- counterparty contact?
- 24/7 coverage?
Finance
- reimbursement?
- recovery?
- loss?
Compliance
This review should happen before UX is frozen.
Final control principle
Fraud prevention is strongest when the payment architecture preserves three things:
- identity — who acted and who received;
- state — what happened to value;
- evidence — why the bank decided and what it did next.
If any of the three is missing, investigations become slower, customer outcomes become less consistent and control tuning becomes guesswork.
Fraud prevention in customer onboarding and account maintenance
Payment fraud often exploits weaknesses created before the payment day.
New customer onboarding
Fraud controls can assess:
- identity consistency;
- device;
- contact data;
- velocity of account creation;
- linked prior accounts;
- intended account use.
AML/KYC determines regulated customer due diligence; fraud onboarding focuses on impersonation, synthetic identity and misuse. The data can overlap but the decision purposes differ.
Contact information change
Changing:
- phone;
- email;
- mailing address;
can be a precursor to takeover.
Controls:
- authenticate strongly;
- notify old contact where appropriate;
- risk flag for later high-risk actions.
Device recovery
A customer legitimately replaces a phone.
The fraud system should allow recovery without permanently trapping the customer while still recognizing that:
new device + new payee + high value within minutes is elevated risk.
Account closure
Before closing an account after fraud:
- resolve pending payments;
- returns;
- recoveries;
- reimbursement;
- reporting.
Premature closure can orphan later returns.
Fraud control interactions with customer limits and liquidity
Fraud limits affect customer experience but not scheme settlement limits.
Example:
- scheme allows high amount;
- bank customer limit lower;
- fraud system imposes temporary lower limit after risk event.
The channel should explain the product limit without exposing fraud-rule logic.
Corporate temporary limits
During a known BEC wave, bank may:
- reduce first-time beneficiary limit;
- require additional approval.
Changes should be:
- policy-approved;
- time-bound;
- communicated where appropriate;
- monitored for customer impact.
Fraud and liquidity
A fraud hold before release preserves funds in customer's account.
A post-settlement recovery does not restore bank liquidity until value returns.
Treasury/finance may need visibility into large fraud recoverables.
Fraud-control documentation for audit and model risk
Maintain:
Policy
- risk appetite;
- customer treatment.
Standard
- authentication;
- decisioning;
- case handling.
Rule/model inventory
Procedure
Evidence
- decisions;
- cases;
- testing.
Documentation should match production. A policy saying every new payee gets step-up is ineffective if one API channel bypasses it.
Testing with realistic data
Synthetic tests should include:
- long names;
- accented characters;
- corporate accounts;
- shared devices;
- legitimate travel;
- payroll peaks.
Fraud systems that only see neat test data often fail with real identity and beneficiary patterns.
Production monitoring after release
For a changed rule:
- decline rate;
- segment impact;
- fraud;
- complaint;
- latency.
Compare to expected range.
Fraud control design workshop
A useful cross-functional workshop follows one payment end to end.
Ask each team:
- what data do you see?
- what can you stop?
- what evidence do you create?
- what happens if your service is down?
- who handles the customer?
The output is a control map with no unowned stage.
Example output
Channel:
Fraud:
Payment hub:
- enforces decision/idempotency.
Gateway:
Ledger:
Operations:
Receiving fraud:
Finance:
That is stronger than a list of fraud tools.
Fraud data dictionary and investigation acceptance criteria
Fraud teams often lose time because the same word means different things across systems.
Core definitions
Customer ID
Stable bank identity for the customer or corporate entity.
User ID
Individual digital/corporate user that authenticated.
Payment ID
Bank's durable economic payment record.
Beneficiary ID
Stable internal representation of the recipient where the bank maintains one.
Fraud decision ID
Reference to the exact decision event and version.
Case ID
Investigation identifier; several payments may belong to one case.
These should not be collapsed into a single generic transaction number.
Time fields
Preserve:
- initiatedAt;
- authorizedAt;
- fraudDecidedAt;
- releasedAt;
- settledAt;
- postedAt;
- reportedAsFraudAt;
- recoveryRequestedAt;
- recoveredAt.
A timeline makes it possible to determine whether a control ran before or after settlement.
Fraud typology taxonomy
Maintain controlled categories such as:
- account takeover;
- impersonation;
- investment scam;
- romance;
- purchase;
- BEC/invoice diversion;
- mule;
- card compromise;
- PAD authority dispute;
- first-party/false claim;
- operational error.
Allow:
- primary;
- secondary;
- unknown.
Do not force analysts to select a wrong category simply to close a case.
Investigation completeness
Before final decision, the case should answer:
- who initiated/authorized?
- which device/channel?
- which beneficiary?
- what warning/control ran?
- what payment state?
- what settlement evidence?
- what customer says happened?
- what recovery occurred?
Evidence confidence
Classify important evidence:
- system-confirmed;
- customer-stated;
- counterparty-confirmed;
- analyst inference.
This prevents customer narrative from being confused with network settlement fact.
Fraud scenario design for education and operations
When training staff, use scenarios that include ambiguity.
Example: familiar recipient, unusual context
Customer has paid recipient three times.
Fourth payment is ten times normal after a call from "bank security."
Signals conflict:
- known beneficiary;
- unusual amount/purpose.
The analyst should not treat one familiar-recipient feature as decisive.
Example: new device, legitimate travel
Customer abroad replaces damaged phone and sends tuition payment.
Risk features:
- new device;
- new location;
- high amount.
Legitimate evidence:
- established beneficiary;
- prior tuition pattern;
- successful strong recovery.
The control should challenge rather than automatically classify fraud.
Example: corporate batch after acquisition
Beneficiary-change percentage rises because company acquired new workforce.
The bank should allow legitimate business change through documented customer context rather than permanently weakening the rule for all corporates.
This kind of scenario-based design keeps controls risk-sensitive instead of rigid.
11. Practical Canadian fraud scenarios
Scenario 1 — bank investigator impersonation
A Toronto customer receives a call displaying what appears to be their bank's number. The caller says the account is compromised and instructs the customer to move CAD 7,500 to a "secure holding account."
The customer logs into the genuine banking app on a trusted phone and authenticates normally.
The payment is high risk because:
- new beneficiary;
- unusual amount;
- customer is acting under urgency;
- beneficiary may have adverse network intelligence.
A well-designed control does not rely on "MFA passed." It may display a contextual warning, obtain beneficiary intelligence and apply fraud decisioning before release.
If payment settles before the customer reports the scam, operations records:
- genuine authentication;
- scam classification;
- payment state;
- recipient;
- recovery request;
- reimbursement process.
The payment was authorized in the technical sense but induced by deception.
Scenario 2 — payroll file manipulation
A Calgary company's payroll user account is compromised. The attacker changes 12 employee account numbers before Friday payroll release.
The bank's corporate controls identify:
- high percentage of changed beneficiaries;
- beneficiary changes immediately before file release;
- file total consistent with prior payroll.
A simple total-value control would miss the attack.
A stronger design:
- isolates changed beneficiaries;
- requires approval for master-data change;
- compares beneficiary history;
- holds the anomalous subset or file according to product policy.
Scenario 3 — fraudulent PAD complaint
A Vancouver customer sees a debit for a service they say they cancelled.
Operations should not call it "card fraud."
They determine:
- payment is PAD;
- biller;
- agreement/mandate;
- cancellation evidence;
- debit date/amount;
- applicable Rule H1 recourse.
If the Rule H1 criteria are met, reimbursement/reversal follows the rail's rules.
Scenario 4 — mule receiving pattern
A new account receives 24 Interac e-Transfers from unrelated people in two hours, then sends most of the value onward.
Receiving-side analytics flags:
- fan-in;
- new account;
- rapid depletion;
- unrelated senders.
The bank investigates the account and linked activity under its authorities, preserves payment references and supports sending institutions' recovery requests.
The value of receiving-side detection is clear: no individual sending bank could see the whole network pattern.
Scenario 5 — disputed debit-card transaction
A customer disputes a debit-card transaction.
The investigation gathers:
- transaction channel;
- card/PIN/token usage;
- device/terminal evidence;
- loss report;
- prior compromise notification.
FCAC guidance says federally regulated financial institutions must fully investigate disputed unauthorized credit- or debit-card transactions; use of authentication technology alone is not sufficient to assign responsibility.
12. Key takeaways and authoritative references
Key takeaways
- Fraud must be classified by the customer intent, criminal mechanism and payment state.
- Account takeover and authorized scams require different signals.
- Authentication proves identity/session control, not payment purpose.
- Mule detection is a receiving-side responsibility as well as a sending-side problem.
- Different payment rails have different cancellation, finality, return and dispute frameworks.
- Recovery is never the same as simply "reversing" a settled payment.
- Reimbursement and interbank recovery are separate accounting events.
- Fraud, AML and sanctions controls overlap in data but have different legal purposes.
- Evidence should preserve the customer, authentication, beneficiary, fraud decision, payment state, settlement and recovery story.
- Controls should be measured for both fraud capture and customer friction.
Authoritative references
This chapter is educational material. Current legislation, payment-system rules, network requirements, financial-institution agreements and customer terms remain authoritative for live decisions.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.