Fraud Controls Across EFT, PAD, Interac and Wires. Apply authentication, transaction controls, monitoring, decisioning, holds and post-event response by payment type.
Block 13 · Chapter 62 of 75
Fraud controls should follow the payment's operating model. A control that is effective for a card authorization can be irrelevant to a pre-authorized debit. A control that is effective for a corporate AFT payroll file can be too slow for an Interac e-Transfer. A wire can justify manual review that would make a retail instant-payment product unusable.
The practical design question is therefore not simply "what fraud controls do we have?" It is:
Which controls must act before this payment becomes difficult or impossible to stop, which signals are available at that point, and what recovery rights exist after the payment progresses?
This chapter compares four major operating contexts: AFT/EFT-style credit processing, PAD collections, Interac e-Transfer and wire payments. It also connects those controls to customer channels, authentication, beneficiary management, limits, fraud analytics, holds, post-event response and evidence.
The term EFT needs care in Canada. In ordinary banking language it can be used broadly for electronic transfers. Under FINTRAC's legal definition, however, "electronic funds transfer" has a specific scope and excludes direct deposit, pre-authorized debit, cheque imaging, certain clearing/settlement transfers and qualifying internal treasury movements. This chapter uses AFT when discussing Payments Canada's batch credit/debit rails and reserves FINTRAC terminology for the AML chapter.
How to read this chapter. Statements identified as regulatory describe legislation or regulator guidance; scheme statements describe Payments Canada or Interac rules and service behaviour; bank-specific implementation statements are design patterns, not universal Canadian requirements. Scenario amounts, names and event sequences are fictional teaching examples unless a source is cited. Current facts are checked against sources available on 2026-10-05.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- compare fraud exposure across AFT credits, PADs, Interac e-Transfer and wires;
- design controls at initiation, authorization, release, processing and post-event stages;
- distinguish customer authentication from payment approval and fraud decisioning;
- explain maker/checker, entitlement and corporate master-data controls;
- design file-level and item-level controls for AFT;
- explain why PAD fraud is tightly connected to mandate/agreement evidence;
- identify Interac e-Transfer account-takeover, phishing, scam and mule patterns;
- explain why Autodeposit can reduce interception risk without preventing sender deception;
- identify wire-specific beneficiary and business-email-compromise risks;
- distinguish hold, decline, reject, return, recall request and reimbursement;
- design false-positive and service-degradation controls;
- connect fraud case evidence to payment references and accounting;
- define useful fraud tests for each rail.
Chapter navigator
- Why fraud control must be rail-specific
- A common layered fraud-control model
- AFT credit and corporate-file controls
- PAD authorization and collection controls
- Interac e-Transfer fraud controls
- Wire and Lynx fraud controls
- Limits, monitoring, holds and decisioning
- Post-event response and recovery by rail
- Operations, evidence and customer communication
- Testing, tuning and implementation
- Practical multi-rail fraud scenarios
- Key takeaways and authoritative references
1. Why fraud control must be rail-specific
Every payment has a control window.
AFT file:
- often created before the value date; exact lead times and cutoffs are bank/product rules;
- validated in batch;
- may contain hundreds or thousands of items;
- fraud may be file-wide or item-specific.
PAD:
- payee initiates under standing authority;
- fraud question often becomes "was this debit authorized by the agreement?";
- consumer recourse depends on Rule H1.
Interac e-Transfer:
- customer generally expects immediate digital processing;
- sender account takeover and authorized scams matter;
- recipient may use Autodeposit;
- pending versus deposited state changes cancellation/recovery options.
Wire/Lynx:
- high value;
- strong entitlement/dual approval common;
- beneficiary validation important;
- settlement final between participants once settled;
- recovery after settlement requires a new process rather than editing history.
The irreversible point differs
Fraud controls should be strongest before the point where the bank loses unilateral control.
For a corporate file, that may be the file release/cutoff.
For a PAD, that includes biller onboarding plus presentment controls because the payor did not initiate each debit.
For Interac, the critical window is before acceptance/Autodeposit.
For Lynx, it is before final interbank settlement.
This concept is more useful than copying a standard fraud checklist across every rail.
2. A common layered fraud-control model
Although controls differ, the layers are reusable.
Layer 1 — customer and user identity
Consumer:
- login;
- MFA;
- device;
- credential reset;
- contact change.
Corporate:
- user ID;
- role;
- entitlement;
- maker/checker;
- delegated authority.
Layer 2 — payment authority
Questions:
- may this user debit this account?
- may they use this product?
- is a second approver required?
- does a PAD agreement exist?
- is the biller sponsored and authorized?
Layer 3 — beneficiary/payee
Questions:
- new or existing?
- recently changed?
- payee name/account match where service exists?
- known risk?
- unusual country/agent?
- mule signals?
Layer 4 — transaction
- amount;
- velocity;
- frequency;
- purpose;
- time;
- channel;
- file pattern;
- historical behavior.
Layer 5 — release
- limit;
- fraud disposition;
- sanction/AML controls where applicable;
- approval;
- cutoff;
- external routing.
Layer 6 — receiving side and post-event
- inbound anomaly;
- mule risk;
- posting;
- customer report;
- recovery;
- reimbursement.
3. AFT credit and corporate-file controls
AFT credit is commonly used for:
- payroll;
- supplier payments;
- benefits;
- recurring disbursements.
The fraud unit is not always one payment. It may be the file.
Corporate authentication
Strong controls include:
- secure portal or host-to-host/API credentials;
- corporate user entitlement;
- approval matrix;
- MFA;
- service-account key/certificate management.
A valid corporate credential does not automatically make every file safe.
Maker/checker
Maker/checker reduces insider and credential-compromise risk by separating:
- file creation;
- release approval.
For larger corporates:
- maker;
- checker;
- releaser;
- administrator.
The most dangerous role may be the person who can change entitlements or supplier masters.
File-level controls
Check:
- file ID;
- expected originator;
- item count;
- total value;
- duplicate file hash/reference;
- value date;
- unusual volume;
- unusual debit account;
- number of changed beneficiaries.
A file with normal total value can still be fraudulent if beneficiary accounts were replaced.
Item-level controls
Check:
- beneficiary;
- amount;
- first-time destination;
- unusual payment;
- duplicate item;
- changed master data.
Payroll fraud
A common attack is beneficiary substitution:
- employee name remains;
- salary amount remains;
- account changes.
Control:
- employee bank-detail change approval;
- out-of-band confirmation;
- change audit;
- first payroll after change monitoring.
Supplier fraud
Business email compromise often targets supplier bank-detail changes.
Good practice:
- callback to known number;
- dual control;
- do not accept a bank-detail change solely from reply email;
- monitor first payment after change.
Duplicate protection
A retry after uncertain file upload can create duplicate payroll.
Idempotency keys should exist at:
- file;
- batch;
- item where appropriate.
Operations must query original state before re-uploading.
Processing and settlement evidence
AFT fraud investigation needs:
- source file;
- approval history;
- accepted/rejected items;
- ACSS/clearing-agent evidence;
- customer posting;
- returns.
Scheme/operating boundary: Payments Canada describes ACSS as a retail batch system in which direct clearers enter exchanged item totals, ACSS calculates net balances, and the previous business day’s net balances settle in the morning through direct clearers’ Bank of Canada settlement accounts. Indirect clearers use a direct clearer. This chapter does not invent a universal customer cutoff or posting time: the applicable stream schedule, system-closure calendar and the financial institution’s own cutoffs control.
"File sent" is not the same as every item posted. Reconcile the originator file, item-level statuses, clearing/settlement evidence, customer ledger postings and returns before declaring completion.
4. PAD authorization and collection controls
PAD reverses the initiation direction.
The payee/biller initiates collection from the payor's account under a PAD agreement.
Fraud-control foundation: authority
The first fraud question is:
Did the payee have valid authority to debit?
Evidence includes:
- agreement;
- confirmation;
- customer/payor identity where relevant;
- debit category;
- amount/date terms;
- cancellation.
Biller onboarding
The sponsoring financial institution should treat biller onboarding as a risk decision.
Consider:
- business legitimacy;
- nature of collections;
- complaint history;
- volume/value;
- ability to absorb returns;
- agreement process;
- evidence retrieval;
- technical file controls.
A fraudulent or weakly controlled biller can create thousands of debits.
Debit validation
Before file release:
- originator identity;
- file totals;
- transaction codes;
- account/routing format;
- duplicates;
- limits;
- anomaly against biller profile.
Unauthorized or incorrect PAD
Payments Canada's current consumer guidance explains that Rule H1 protects against improper withdrawals and gives specified recourse for incorrect or unauthorized PADs. The published guide states that customers generally have 90 days from debit for the described personal PAD claims.
Use current Rule H1 for binding detail.
Retry controls
Payments Canada guidance states that where a PAD is dishonoured for insufficient funds, the biller can try the same debit one more time within 30 days and for the exact same amount. This is not a fraud rule; it is an operational rule that prevents uncontrolled re-presentment.
Fraud systems should not misclassify a permitted retry as a duplicate without understanding the original return.
For Rule H1 recourse, do not generalize the consumer 90-day window to every PAD. Payments Canada’s current business guide describes a 10-day claim window for business PADs in specified agreement/notice/cancellation cases, while “no agreement existed” and dishonour have their own rule treatment; cash-management and certain funds-transfer PADs can have narrower recourse. Apply the current Rule H1 category and the customer agreement.
Cancellation
Cancellation of the PAD agreement ends authority for future debits; it does not cancel the underlying contract or debt.
A fraud/operations case should therefore separate:
- payment method authority;
- commercial obligation.
PAD data quality
Critical identifiers:
- biller/originator;
- payor account;
- amount;
- date;
- item reference;
- return/reversal linkage.
A customer dispute becomes expensive when the bank cannot connect debit to agreement and originator.
5. Interac e-Transfer fraud controls
Interac e-Transfer is a digital service layered across participating institutions.
Sender account takeover
Signals:
- new device;
- reset;
- new recipient;
- unusual amount;
- unusual velocity.
Controls:
- MFA;
- risk-based step-up;
- new-payee confirmation;
- limits;
- behavioral monitoring.
Phishing and fake notifications
Interac warns customers about phishing and unexpected notifications.
Important operational fact:
- the email/text is notification;
- funds move over payment networks.
Fraudsters can imitate the notification without interacting with the real service.
Security question interception
Where a recipient is not using Autodeposit, compromise of the notification channel plus a weak security answer can create risk.
Interac promotes Autodeposit because it bypasses the security-question collection flow. Routine fraud checks still apply at participating institutions.
Autodeposit and authorized scams
Autodeposit can reduce interception but does not validate the underlying reason for the payment.
If a victim sends to a scammer's genuine Autodeposit account:
- deposit works exactly as designed;
- recipient name confirmation may help;
- fraud decision must use context.
Request Money
A fraudulent Request Money request should not be treated as authorization to debit.
The payer still decides whether to fulfill.
Customer UX should display:
- requester;
- amount;
- context;
- clear consent.
Business e-Transfer
Business use adds:
- entitlements;
- approvals;
- bulk workflows;
- invoice references;
- recipient master data.
Controls should integrate with corporate roles rather than rely only on consumer-style login.
Cancellation and deposit state
Operational procedures should determine:
- pending;
- accepted/deposited;
- expired/cancelled;
- returned/recovered.
Do not promise cancellation after value is already deposited.
Mule monitoring
Receiving institutions should detect:
- fan-in;
- rapid onward transfer;
- new account;
- many unrelated senders.
This is especially important for authorized scam payments.
6. Wire and Lynx fraud controls
Wires are generally higher value and lower volume than consumer retail transfers.
Initiation channels
- branch;
- corporate portal;
- host-to-host;
- API;
- treasury desk;
- internal operations.
Each needs appropriate authentication.
Beneficiary risk
Wires are highly exposed to beneficiary-change fraud.
Corporate control:
- beneficiary template;
- independent verification;
- dual approval;
- change history;
- first-use review.
Business email compromise
A supplier asks to redirect a CAD 450,000 payment.
The request may be:
- genuine;
- email account compromised;
- spoofed domain;
- insider fraud.
Do not treat email possession as sufficient authority for a material destination change.
Entitlements and limits
Corporate user entitlements should define:
- accounts;
- products;
- single limit;
- daily limit;
- approval requirement;
- beneficiary permissions.
Sanctions and AML
Fraud is not the only pre-release control.
Wire release may depend on:
- sanctions screening;
- AML/KYC obligations;
- fraud;
- funding;
- routing.
A payment should not be released because the fraud engine says low risk if sanctions disposition is unresolved.
Lynx finality
Lynx is Canada's high-value RTGS system. Once a payment settles, the interparticipant settlement is final and irrevocable under the Lynx framework.
Fraud recovery therefore must:
- identify original payment;
- contact receiving side;
- use appropriate return/recovery process;
- preserve original settlement.
Never "edit" settled value.
References and settlement evidence
For a Lynx-settled payment, the PCRN is the unique alphanumeric number generated by Lynx and demonstrates finality/irrevocability between Lynx participants. It is not a universal customer transaction number, and same-institution wires or other wires not processed through Lynx do not receive a PCRN. A UETR may be available on a SWIFT/cross-border leg, but it is not a substitute for PCRN and must not be assumed to exist for every domestic Lynx payment.
Fraud operations should display the internal payment ID, applicable scheme/network references, PCRN after settlement, and UETR only where the relevant SWIFT/cross-border message carries one.
RTR status: current capability versus planned modernization
As of 2026-10-05, Canada’s RTR is not a general production rail. Payments Canada’s system page says RTR is launching in Q4 2026; its testing-and-launch page describes ongoing assurance/testing and a sequenced onboarding plan. Therefore, every RTR reference in this chapter is a forward-looking design or readiness pattern, not a claim that a bank can currently send a live RTR payment. Existing bank real-time products and Interac e-Transfer must not be presented as RTR.
Payments Canada has published an RTR fraud-services design (including confirmation of payee, a transaction safety score, a risk list and reporting/intelligence platform), and RTR Rule 13 is marked implemented August 24, 2026. Those are scheme requirements/capabilities for the RTR rollout; they do not prove that a particular financial institution has enabled them in production. Bank-specific readiness still requires participation, certification, connectivity, settlement-account or settlement-agent arrangements, 24/7 operations and approved fraud fallbacks.
7. Limits, monitoring, holds and decisioning
The control-comparison diagram above frames this section: limits, monitoring, holds and decisioning differ by rail, so each control below should be read as a rail-specific setting rather than a universal rule.
Limit types
Consumer:
- per transfer;
- daily;
- recipient;
- channel.
Corporate:
- user;
- account;
- file;
- item;
- group;
- product.
Limits should consider customer risk and use case.
Velocity
Examples:
- five new recipients in ten minutes;
- 20 payments just below a threshold;
- sudden increase after credential reset;
- file volume triple normal.
Velocity can detect patterns a single transaction score misses.
Holds
A hold must have:
- legal/product authority;
- reason;
- owner;
- duration;
- customer treatment;
- release criteria.
A generic fraud flag should not create indefinite funds restriction.
Decision orchestration
A robust decision combines:
- authentication;
- beneficiary risk;
- amount;
- history;
- device;
- network intelligence;
- product rules;
- fraud model.
The result should be explicit.
Service degradation
Before production, decide what happens when:
- fraud API unavailable;
- device service down;
- beneficiary service slow.
Options may include:
- fail closed;
- lower limits;
- restricted product;
- alternate approved control.
Do not invent a bypass during an incident.
False-positive operations
Every challenge/decline needs feedback.
Track:
- why;
- customer completion;
- analyst decision;
- confirmed fraud;
- false positive.
Use this to tune models.
8. Post-event response and recovery by rail
AFT credit
First:
- determine whether item/file was released;
- confirm clearing/processing state;
- contact receiving institution if recovery needed.
If funds posted, recovery is not guaranteed.
PAD
Use Rule H1 classifications:
- no agreement;
- agreement violation;
- cancellation;
- return/dishonour;
- recourse.
Do not route through card chargeback logic.
Interac e-Transfer
If pending, cancellation options may exist according to service/institution handling.
If deposited:
- treat as post-event fraud/recovery;
- engage receiving institution;
- investigate recipient;
- manage reimbursement separately.
Wire/Lynx
Confirm settlement.
If settled:
- original settlement stands;
- initiate recovery/return request through bank process;
- use internal payment ID and PCRN where Lynx-settled, plus UETR where the relevant SWIFT/cross-border leg provides one;
- do not resend corrected payment until original status is known.
Customer account security
Across rails, secure compromised access before recovery:
- password reset;
- session revoke;
- card/token block;
- contact changes reviewed;
- beneficiary master secured.
Accounting
Maintain separate entries for:
- original payment;
- customer reimbursement;
- recovered funds;
- write-off/loss.
9. Operations, evidence and customer communication
Fraud case management should not require investigators to understand every rail protocol.
The case should present:
Customer
- identity;
- account;
- contact.
Fraud
- typology;
- authentication;
- risk decision.
Payment
- rail;
- amount;
- payee;
- status;
- references.
Settlement/posting
- settled?
- posted?
- available?
Recovery
- request;
- response;
- amount.
Case routing
Route to specialist queue:
- AFT/payroll;
- PAD dispute;
- Interac;
- wire;
- mule/inbound;
- card.
A generic fraud queue can intake, but rail specialists need to own recovery mechanics.
Customer language
Say:
- "We have secured your account."
- "The transfer has already been deposited."
- "We have sent a recovery request."
- "We have not yet received funds back."
Avoid:
- "It is reversed" when only requested.
- "The other bank froze it" unless confirmed.
- "You authenticated so it is your fault."
Complaint handling
Customer disputes may interact with:
- internal complaint process;
- FCAC-regulated protections;
- network commitments;
- account agreement.
Fraud operations should record the legal/product basis of reimbursement.
10. Testing, tuning and implementation
Golden fraud test pack
AFT:
- normal payroll;
- duplicate file;
- 15 changed beneficiaries;
- compromised corporate user;
- file retry after timeout.
PAD:
- valid recurring debit;
- duplicate;
- cancelled agreement;
- no agreement claim;
- permitted NSF retry.
Interac:
- known payee;
- new payee;
- account takeover;
- authorized scam;
- Autodeposit recipient;
- mule receiving pattern.
Wire:
- normal corporate wire;
- changed beneficiary;
- BEC;
- sanctions hold;
- timeout before settlement confirmation;
- settled fraud recovery.
Test the sequence
Do not test only individual rules.
Example:
credential reset → new device → payee change → payment.
The combined risk can be high while each individual event is permissible.
Feature lineage
Document:
- source system;
- definition;
- latency;
- fallback;
- quality threshold.
If "new payee" is unavailable, model behavior must be understood.
Fraud operations testing
Run tabletop exercises:
- fraud engine outage;
- mule surge;
- corporate payroll compromise;
- Interac phishing wave;
- wire BEC.
Verify:
- decision rights;
- customer communication;
- network contact;
- recovery;
- evidence.
Model governance
Track by model/rule version:
- approvals;
- production dates;
- fraud capture;
- false positives;
- rollback.
Separation from AML and sanctions
One case may touch all three, but:
- fraud asks whether payment/customer activity is deceptive/unauthorized;
- AML asks whether activity raises ML/TF/sanctions-evasion suspicion;
- sanctions asks whether prohibited/listed parties/property are involved.
The same payment can have three separate dispositions.
Rail-by-rail control matrix
The same control name can mean different things by rail. A useful design artefact is a matrix that states where the control runs and what it prevents.
| Control | AFT credit | PAD | Interac e-Transfer | Wire/Lynx |
|---|
| Customer authentication | Corporate portal/H2H/API user | Primarily biller/payee onboarding and channel controls | Digital sender session | Branch/corporate/treasury instruction |
| Payment authority | Entitlement + approvals | PAD agreement + biller undertaking | Sender authorization | Mandate/entitlement + approvals |
| Beneficiary/payee control | Supplier/payroll master | Payor agreement and biller legitimacy | Recipient/new-payee controls | Beneficiary verification |
| File/item duplicate | Critical | Critical for collection files | Transaction/idempotency | Transaction/idempotency |
| Transaction monitoring | File + item | Biller + item | Real-time sender/receiver | High-value real-time/pre-release |
| Settlement/finality awareness | Batch/return exposure | Batch + Rule H1 recourse | Deposit/service state | Lynx finality after settlement |
| Post-event recovery | Receiving institution/return process | Rule H1 return/reimbursement paths | Network/bilateral fraud recovery | Receiving-bank cooperation/return |
This matrix prevents architecture teams from saying "we already have fraud monitoring" without identifying where it can act.
AFT fraud operating model in depth
File lifecycle
A corporate AFT file can move through:
CREATED
→ UPLOADED
→ VALIDATED
→ APPROVAL_PENDING
→ APPROVED
→ RELEASED
→ EXCHANGED/PROCESSED
→ POSTED/RETURNED.
Fraud controls are strongest before RELEASED.
File identity
Maintain:
- customer file ID;
- bank ingest ID;
- hash;
- upload timestamp;
- debit account;
- total amount;
- item count;
- value date;
- approval chain.
If the corporate retries after an uncertain upload, the bank should be able to say whether the file already exists.
Duplicate strategy
File duplicate:
- same file hash;
- same originator/file ID;
- same totals/value date.
Item duplicate:
- same originator;
- beneficiary;
- amount;
- payment reference;
- value date.
Do not treat every repeated payroll amount as fraud. Salaries repeat naturally.
Corporate release control
Example entitlement model:
| Role | Create file | Edit beneficiary | Approve | Release | Administer users |
|---|
| Payroll maker | Yes | Limited | No | No | No |
| Payroll approver | No | No | Yes | Yes | No |
| Treasury admin | No | No | No | No | Yes |
The exact model varies, but separation should be deliberate.
Beneficiary-change risk
A strong AFT rule can calculate:
- changed beneficiary count;
- percentage of file changed;
- value going to changed destinations;
- changes within last 24/48 hours.
A normal payroll file with 200 employees and 1 changed account is different from 40 changed accounts.
Host-to-host compromise
If a service credential is stolen, the attacker may bypass human UI controls.
H2H/API needs:
- mTLS/certificates;
- key rotation;
- source restrictions where appropriate;
- signing or integrity controls;
- replay protection;
- transaction limits;
- anomaly monitoring.
AFT failure/recovery
When a suspicious file has already been released:
- confirm actual processing state;
- identify which items are affected;
- contact operations/receiving side under current process;
- prevent duplicate replacement;
- reconcile returns/recoveries.
The bank should not promise a file-level recall merely because the customer asks.
PAD fraud operating model in depth
PAD risk starts before the first debit.
Biller sponsorship
The biller can generate repeated collection risk, so onboarding should include:
- legal/business verification;
- collection purpose;
- customer complaint history where available;
- financial ability to absorb returns;
- agreement template;
- authentication/verification method;
- expected volumes;
- expected average/maximum amounts.
Agreement evidence
Store or require retrievable evidence sufficient for the current Rule H1 framework.
Operational attributes can include:
- payor;
- account;
- payee;
- category;
- start/effective date;
- fixed/variable/sporadic nature;
- cancellation;
- notice/waiver information where applicable.
The authoritative agreement record should not be a free-text note in a call-centre system.
Presentment anomaly
Biller history can identify:
- amount spike;
- unusually early debit;
- duplicate file;
- new payor volume spike;
- high NSF/return rate;
- high unauthorized claim rate.
The sponsoring institution should monitor the biller, not only individual payors.
Return-rate risk
An increasing unauthorized/dispute rate can indicate:
- bad onboarding;
- deceptive biller;
- broken mandate process;
- technical duplicate defect.
Risk policy should define investigation triggers.
Permitted re-presentment
A second debit after NSF can be legitimate under current Rule H1 conditions. Duplicate logic must understand:
- original presentment;
- return reason;
- retry eligibility;
- amount/date relationship.
Otherwise fraud controls can block valid retry while allowing a truly duplicated debit that does not carry correct linkage.
Cancellation evidence
When a customer says "I cancelled," determine:
- cancellation of PAD authority;
- cancellation of underlying service;
- timing;
- whether debit occurred before/after.
The bank resolves the payment claim under applicable rule; it does not decide the commercial contract unless relevant to the payment right.
Interac e-Transfer control design in depth
Sender journey
Typical flow:
- authenticated login;
- select account;
- select/add recipient;
- amount/message;
- fraud/limit checks;
- authorize/send;
- recipient notified or Autodeposit completes;
- confirmations/status.
Fraud checks should sit before the service commits the transfer.
Recipient confirmation
Where sender interface shows a recipient identity/Autodeposit name, it is an opportunity to interrupt:
- typo;
- outdated contact;
- impersonation.
UX should make the recipient visible before final authorization.
New-payee signal
Define "new":
- never paid;
- not paid within defined period;
- payee identifier changed.
Avoid basing it only on contact nickname because criminals can create "Mom" or "Supplier A."
Scam-warning orchestration
Warning should use risk context.
Examples:
Bank impersonation
"Has someone claiming to be your bank or police told you to move money to keep it safe?"
Marketplace purchase
"Have you independently confirmed the seller and item? Interac e-Transfer may be difficult to recover after deposit."
Investment
"Are you being promised guaranteed/high returns or being asked to send to a personal account or crypto intermediary?"
Do not present warnings as legal conclusions.
Autodeposit
Benefits:
- reduces security-question interception;
- removes need for recipient to click a deposit link.
Risks still include:
- sender scam;
- recipient account compromise;
- changed registration;
- mule beneficiary.
Monitor Autodeposit setup/change as a sensitive event.
Request Money
Controls:
- requester authentication;
- request limits;
- customer display;
- decline/ignore;
- anti-spam/abuse monitoring.
Receiving a request does not authorize a debit.
Interac timeout
If sender screen times out:
- query transfer status;
- do not create a new transfer until state known;
- show "processing" rather than "failed" if uncertain.
Duplicate prevention is fraud and customer-protection control.
Wire/Lynx control design in depth
Wire initiation
Collect:
- originator;
- source account;
- beneficiary;
- beneficiary bank;
- intermediary data where relevant;
- amount/currency;
- purpose/remittance;
- value date.
Corporate instruction authenticity
For branch/manual instructions:
- approved signing authority;
- call-back under policy;
- secure instruction channel;
- dual control for manual data entry.
For digital:
- strong authentication;
- entitlements;
- dual approval;
- transaction signing where used.
Beneficiary template
Treat:
- beneficiary creation;
- bank-account change;
- intermediary change;
- country change;
- amount/purpose anomaly;
as risk events.
Large first-time wire
A CAD 900,000 first-time beneficiary may justify:
- manual fraud review;
- independent beneficiary confirmation;
- senior approval.
A similar process would be unacceptable for every CAD 50 consumer transfer. Rail and value determine friction budget.
Finality gate
Before Lynx release:
- fraud cleared;
- sanctions disposition cleared;
- entitlement valid;
- funds/liquidity controls complete;
- instruction complete.
Once Lynx settlement occurs, the fraud team cannot depend on a sender-side "cancel button."
Settlement references
Operations should display:
- internal payment ID;
- PCRN after settlement where the payment used Lynx;
- UETR only where the relevant SWIFT/cross-border leg provides one;
- beneficiary;
- settlement timestamp.
This prevents vague internal statements such as "wire was sent."
Common decision orchestration
A bank with multiple rails benefits from a common fraud decision service, but not a common decision policy for every product.
Common inputs
- customer;
- account;
- device;
- session;
- beneficiary;
- amount;
- velocity;
- customer history;
- rail;
- product;
- channel.
Rail-specific policy
The service can route to:
- consumer e-Transfer policy;
- AFT corporate file policy;
- PAD biller policy;
- wire policy;
- RTR policy.
Decision response
Useful fields:
- decision;
- reason codes;
- model/rule version;
- required action;
- expiry/time-to-live.
Synchronous versus asynchronous
Synchronous:
- needed before real-time release.
Asynchronous:
- can support receiving-side/mule monitoring and post-event review.
Do not place an asynchronous fraud alert behind a final-payment release and call it a preventative control.
Fraud service outage design
Every payment product should have a tested degradation policy.
Options
Fail closed
Suitable where risk/obligation requires.
Restricted mode
- allow known beneficiaries below lower limit;
- block high-risk/new beneficiary.
Only if policy explicitly approves.
Alternate engine
- redundant decision service.
Manual review
- possible for low-volume high-value wires;
- unsuitable for mass instant payments.
Outage evidence
Log:
- start/end;
- impacted products;
- fallback policy;
- payments processed under fallback;
- post-event review.
After restoration, analyze whether fallback payments need targeted review.
Hold design
"Hold" can mean different things.
Pre-release fraud hold
Payment not yet sent.
Bank retains control.
Customer-account restriction
May prevent new debits.
Does not reverse existing settled payments.
Incoming funds hold
Requires applicable authority/policy.
Must respect payment/product rights.
Sanctions block/freeze
Legal control, not generic fraud hold.
Case systems should name the actual action.
False positives and customer recovery
False-positive analysis
Classify reason:
- new customer;
- travel;
- legitimate large purchase;
- payroll/bonus cycle;
- charity/event;
- model feature error.
Feedback
False-positive disposition should feed:
- model tuning;
- rule tuning;
- customer-risk profile;
- feature-quality fixes.
Do not whitelist broadly
A fraudster can reuse a previously safe beneficiary/account after takeover.
Whitelist should be scoped and governed, not "never score this customer."
Cross-rail fraud graph
A criminal can move through several rails:
victim e-Transfer
→ mule account
→ domestic wire
→ cross-border correspondent
→ crypto exchange.
A siloed fraud platform sees four unrelated transactions.
A graph view can connect:
- customer/account;
- recipient;
- device;
- phone/email;
- legal entity;
- payment references.
Graph analytics should support investigation, not replace evidence-based decisions.
Operational reconciliation after fraud events
For each recovered case, reconcile:
original payment
↔ customer reimbursement
↔ receiving-bank recovery
↔ fees/FX
↔ final loss.
Example
Original e-Transfer: CAD 6,000.
Customer reimbursement: CAD 6,000.
Recovery: CAD 4,500.
Finance:
- customer made whole under policy;
- CAD 4,500 reduces fraud loss/recoverable;
- CAD 1,500 remains net loss.
Do not credit the recovered CAD 4,500 again to the already reimbursed customer.
Control ownership and RACI
A useful governance table:
| Capability | Product | Fraud | Operations | Security | Compliance |
|---|
| Customer limits | A/R | C | C | C | I |
| Fraud model | C | A/R | C | C | I |
| Payment status | I | C | A/R | I | I |
| Credential security | C | C | I | A/R | I |
| STR decision | I | C | I | I | A/R |
| Sanctions disposition | I | I | C | I | A/R |
Exact ownership varies. What matters is avoiding gaps.
Business analyst requirements patterns
AFT file requirement
The payment hub must calculate changed-beneficiary count and value versus the previous successful payroll baseline before final release. If configured risk criteria are met, the file must enter FRAUD_REVIEW and cannot be released until an authorized fraud/operations decision is recorded.
PAD requirement
Each PAD presentment must retain a stable reference to the payee/originator and original collection event so a permitted NSF retry, a duplicate and a later Rule H1 claim can be distinguished.
Interac requirement
When the customer selects an Autodeposit recipient, the confirmation screen must display the recipient identity information made available by the service before final authorization, and the event must be recorded with the transfer evidence.
Wire requirement
A beneficiary-bank-account change must be treated as a sensitive master-data event and exposed to the fraud decision and approval workflow for the first payment following the change.
These are testable requirements. "Apply fraud checks" is not.
Comprehensive rail test matrix
AFT
- clean payroll;
- duplicate file;
- altered account;
- 30% changed beneficiaries;
- unauthorized releaser;
- H2H replay;
- partial file rejection;
- timeout/resubmit.
PAD
- valid mandate;
- no mandate;
- duplicate;
- cancellation;
- amount/date violation;
- NSF and permitted retry;
- fraudulent originator spike.
Interac
- known recipient;
- first-time recipient;
- new device;
- credential reset;
- Autodeposit;
- phishing report;
- authorized scam;
- recipient mule;
- timeout.
Wire
- known corporate beneficiary;
- beneficiary change;
- BEC;
- manual branch instruction;
- high-value first-time beneficiary;
- sanctions possible match;
- queued/rejected;
- settled recovery.
Expected evidence for every test
- control input;
- decision;
- reason;
- payment state;
- customer message;
- ledger;
- recovery if relevant.
Payment-state aware fraud runbooks
A runbook should start with the rail state, because the same customer statement — "I did not make this payment" — can require completely different actions.
AFT runbook
File not released
- place controlled hold;
- secure corporate access;
- identify affected items;
- obtain corrected approval.
File released but outcome still processing
- query bank/clearing status;
- avoid duplicate replacement;
- use current operational contact path.
Beneficiary credited
- identify affected credits;
- request recovery through bank process;
- preserve original item references;
- manage customer reimbursement separately.
Returns arriving
- auto-match returns;
- determine whether they relate to fraud, account issues or ordinary processing;
- update exposure.
PAD runbook
Customer reports unknown debit
- confirm PAD versus card/other debit;
- identify payee;
- retrieve applicable authority/agreement evidence;
- apply Rule H1 claim process.
Customer says cancelled
- capture cancellation evidence/date;
- compare debit date and agreement state;
- distinguish payment authority from remaining debt.
Biller has unusual dispute spike
- investigate originator;
- consider sponsorship/limits;
- assess fraud/AML implications.
Interac runbook
Sender account compromised
- secure digital access;
- identify transfer state;
- cancel only if service state permits;
- engage recipient-side recovery;
- investigate recipient/mule.
Authorized scam
- account may not be compromised;
- preserve warning/authentication evidence;
- confirm deposit state;
- initiate recovery;
- determine reimbursement under applicable policy.
Recipient compromise
- secure receiving customer's access;
- inspect Autodeposit/contact changes;
- link inbound transfers and onward movement.
Wire runbook
Instruction not released
- stop payment;
- secure initiation channel;
- validate beneficiary/instruction.
Queued/not settled
- verify actual Lynx status and operational options.
Settled
- use internal payment ID and PCRN where Lynx-settled, plus UETR where the relevant SWIFT/cross-border leg provides one;
- contact receiving participant;
- initiate recovery/return path;
- do not claim unilateral reversal.
Runbook evidence standard
Every action should have:
- timestamp;
- operator;
- reason;
- payment reference;
- customer/account;
- result.
This makes handover possible during long incidents.
Limits as a product and fraud control
Limits are often configured without understanding customer use.
Consumer example
A customer normally sends CAD 500–1,500 monthly.
Possible controls:
- new recipient limit lower than established recipient;
- daily aggregate;
- step-up above behavior threshold.
A hard low limit can make legitimate rent or tuition payments impossible, so limits should be a product/risk decision.
Corporate example
A corporate needs:
- payroll file CAD 4m;
- supplier payments up to CAD 750k;
- individual users with lower authority.
A single account-level daily limit is too crude.
Use:
- user;
- approval group;
- file;
- item;
- beneficiary;
- rail.
Limit increase
Treat limit increase as sensitive:
- strong authentication;
- approval;
- effective time;
- monitoring after change.
Fraudsters often seek to increase capacity before moving funds.
Avoid threshold gaming
If fraud rules fire at exactly CAD 10,000, criminals will learn to send CAD 9,900.
Use:
- behavioral features;
- aggregate value;
- recipient risk;
- randomized/hidden controls where appropriate.
Do not expose fraud thresholds to customers or public documentation.
Beneficiary validation patterns
Static whitelist
Risk:
- beneficiary details can be changed;
- whitelisted supplier can be compromised.
Prefer a beneficiary object with:
- identity;
- account;
- verified date;
- change history.
Independent verification
High-value change:
- callback;
- secure supplier portal;
- trusted directory;
- known contact.
Avoid:
- "reply to this email";
- calling a number supplied only in change request.
Confirmation-of-payee limitations
A name match reduces:
- typo;
- some impersonation.
It does not validate:
- goods;
- investment;
- invoice;
- business relationship.
Fraud messaging should not say "recipient verified safe."
Insider fraud
Not every attacker is external.
Corporate insider
Can:
- create fake supplier;
- redirect payroll;
- approve own payment if role design weak.
Controls:
- segregation;
- periodic entitlement review;
- unusual beneficiary analysis;
- audit logs.
Bank insider
Can:
- override holds;
- change limits;
- suppress alerts;
- access customer data.
Controls:
- privileged access;
- dual control;
- override monitoring;
- staff activity analytics;
- audit.
Override governance
Every fraud override should capture:
- original decision;
- override decision;
- operator;
- reason;
- authority;
- timestamp.
Measure overrides and outcomes.
Channel migration and fraud regression
A bank can move a payment product from legacy portal to new API/mobile UI without changing the rail. Fraud risk can still change.
Migration risks
- missing device signal;
- beneficiary age not mapped;
- new user identifiers;
- changed approval flow;
- different timeout;
- untested duplicate protection.
Regression test
For every channel:
- same economic payment;
- compare fraud features;
- compare decision;
- compare evidence.
A new channel should not silently bypass controls because field names differ.
Fraud feature catalogue
Maintain a governed catalogue.
Examples:
Customer
- relationship age;
- risk segment;
- prior fraud.
Session
- device age;
- IP reputation;
- authentication type.
Beneficiary
- first seen;
- prior successful payments;
- fraud links.
Payment
- amount deviation;
- velocity;
- time;
- channel;
- rail.
Corporate
- user role;
- approval count;
- supplier-change age.
For each feature:
- definition;
- source;
- freshness;
- missing behavior;
- owner.
Missing feature policy
If beneficiary-age feed fails:
- do not silently send zero;
- mark missing;
- use model designed for missingness or approved fallback.
Silent default values can invert risk.
Fraud decision audit sample
An auditor selects a high-risk wire.
The bank should produce:
- customer instruction;
- authenticated user/entitlement;
- beneficiary record and change history;
- fraud inputs;
- model/rule version;
- decision;
- approvers;
- release;
- settlement;
- any later investigation.
For PAD, replace the customer sender instruction with the PAD agreement/biller authority and presentment evidence.
For Interac, include recipient/service state.
The evidence package should match the rail.
Operational capacity planning
Fraud controls can create queues.
Queue drivers
- rule deployment;
- external fraud wave;
- sanctions/list event;
- model drift;
- service outage;
- holiday volume.
Staffing
Measure:
- alerts/hour;
- average handle time;
- peak;
- SLA;
- backlog age.
For real-time products, rely on automated decisions for the main path and reserve manual work for exceptions.
Surge mode
Predefine:
- temporary risk rule;
- extra staff;
- priority customer segments;
- communication;
- rollback.
Surge mode should not mean disabling controls to clear queues.
Customer remediation quality control
After a fraud event, confirm:
- account access secure;
- recipient/payee list reviewed;
- contact data verified;
- compromised cards/tokens handled;
- customer knows safe contact route;
- future monitoring considered.
A reimbursement without security remediation can lead to repeat loss.
Repeat victims
Recovery scams often target previous victims.
Bank systems can flag recent victimization for:
- enhanced warnings;
- support;
- risk context.
Use carefully and avoid unfair permanent restrictions.
Chapter 62 implementation checklist
AFT
- file identity/idempotency;
- maker/checker;
- beneficiary change controls;
- file + item anomaly;
- release gate.
PAD
- biller onboarding;
- agreement linkage;
- presentment anomaly;
- Rule H1 return logic;
- retry classification.
Interac
- session/device;
- recipient confirmation;
- scam warnings;
- Autodeposit event controls;
- mule monitoring.
Wire
- entitlement;
- beneficiary verification;
- dual approval;
- fraud/sanctions gates;
- finality-aware recovery.
Common
- decision evidence;
- service degradation;
- false-positive feedback;
- case routing;
- accounting reconciliation.
If a bank can demonstrate these controls with transaction evidence, fraud management is integrated into payment operations rather than bolted on after the fact.
Rail selection as a fraud variable
The bank's route can change fraud exposure.
A corporate instruction could potentially use:
- AFT;
- Interac business service;
- wire/Lynx;
- RTR product when eligible.
Fraud logic should know the selected rail because:
- limits differ;
- speed/finality differ;
- beneficiary data differ;
- recovery differs.
Do not route to bypass a control
If a wire is held for fraud review, systems should not automatically reroute it to another rail to meet a customer deadline unless the same risk decision is resolved and the alternate route is approved.
Split routing
If a large payment is split into smaller payments:
- preserve common business instruction/reference;
- evaluate aggregate risk.
Splitting should not reduce fraud scrutiny accidentally.
Corporate API fraud and machine-speed payments
APIs allow customers and platforms to initiate large volumes without a human clicking each payment.
API authentication
Controls:
- OAuth/client credentials as appropriate;
- mTLS;
- scopes;
- key rotation;
- IP/network controls where appropriate;
- rate limiting.
Business authorization
Technical API authentication does not prove:
- each beneficiary is valid;
- each instruction is within corporate authority.
Integrate:
- account entitlements;
- amount limits;
- approval policies;
- beneficiary controls.
Compromised API credential
Potential blast radius can be high.
Monitor:
- sudden volume;
- new beneficiaries;
- changed geography;
- unusual time;
- repeated amounts.
Kill switch
Define authority to:
- suspend client credential;
- suspend product;
- restrict new beneficiaries.
A kill switch should be controlled and auditable.
Fraud-control interaction with reconciliation
Reconciliation can be an early fraud detector.
Examples:
- customer ledger debit with no external item;
- unexpected duplicate external item;
- return without original;
- file total mismatch.
These may be:
- technical defect;
- operational error;
- fraud/insider event.
Route unexplained financial breaks for fraud/security consideration rather than assuming all reconciliation exceptions are technical.
Fraud case to reconciliation
Every recovered event should provide:
- original payment ID;
- recovery payment/ref;
- amount;
- reason;
- date.
Finance should auto-match when possible.
Rail-specific customer support playbooks
AFT corporate
Customer asks:
"Did my payroll go twice?"
Support:
- check file IDs/hashes;
- release status;
- duplicate detection;
- item statuses.
Do not infer from two portal clicks.
PAD consumer
Customer:
"I don't recognize this debit."
Support:
- identify PAD;
- name payee;
- explain dispute path;
- avoid card-chargeback terminology.
Interac customer
Customer:
"I sent it to the wrong person."
Support:
- determine pending/deposited;
- explain current options accurately;
- avoid guarantee of recovery.
Wire customer
Customer:
"Supplier says it never arrived."
Support:
- check settlement and the applicable internal/network reference (PCRN for Lynx; UETR only where supplied by a SWIFT/cross-border leg);
- distinguish settled versus beneficiary posting;
- avoid resending.
Correct language is itself a fraud control because it prevents duplicates and false recovery expectations.
Fraud control release governance
Before changing fraud policy in production:
- quantify expected affected volume;
- test by rail;
- check false positives;
- check latency;
- approve;
- define rollback;
- monitor after release.
Emergency rule
Example:
known mule account cluster.
Deploy:
- beneficiary block/hold under policy;
- linked-account detection;
- customer warning.
But define:
- evidence source;
- expiry;
- review.
Testing the fraud/rail boundary
Many defects live between systems.
Test:
- fraud decline but gateway receives payment;
- fraud allow but payment fails;
- fraud challenge times out;
- fraud service reply duplicates;
- payment retries after fraud allow;
- beneficiary changed after fraud scoring but before release.
Expected principle:
the exact payment data that fraud approved must be the data released.
Transaction binding
Use:
- payment ID;
- amount;
- beneficiary hash/reference;
- decision token/version.
If critical data changes after decision, re-evaluate.
Fraud analytics quality by rail
AFT
Useful analytics:
- file baseline;
- changed beneficiary ratio;
- unusual originator activity;
- duplicate patterns.
PAD
- biller dispute rate;
- new payor surge;
- amount/date deviation;
- unauthorized claim trend.
Interac
- device;
- session;
- recipient;
- velocity;
- scam/mule network.
Wire
- beneficiary change;
- user entitlement;
- high-value deviation;
- cross-border/counterparty context.
One model may share features but should not assume identical meaning.
Post-event review for prevented fraud
Do not review only losses.
A stopped high-risk payment can teach:
- attack path;
- beneficiary;
- credential compromise;
- warning response.
Capture:
- prevented value;
- typology;
- control that stopped it.
This helps quantify control effectiveness.
Final practitioner rule
For any payment-fraud control, answer four questions:
- What signal?
- Before which irreversible event?
- What action?
- What evidence?
If any answer is vague, the control is not fully designed.
Multi-rail fraud policy hierarchy
A scalable bank can organize policy into three levels.
Enterprise principles
Apply everywhere:
- authenticated authority;
- fraud decision before irreversible release where possible;
- payment identity;
- evidence;
- customer treatment;
- case management.
Rail standard
Defines:
- control window;
- cancellation/recovery;
- references;
- processing states.
Product configuration
Defines:
- customer limits;
- approval;
- warning;
- segment-specific friction.
This avoids copying rules while allowing product differences.
Fraud orchestration sequence
A typical pre-release orchestration can be:
- validate instruction;
- validate entitlement;
- beneficiary check;
- limit;
- fraud model/rules;
- step-up/challenge if needed;
- other compliance gates;
- final release authorization;
- durable release record;
- external send.
The exact order may vary where controls run in parallel, but no asynchronous race should let the gateway send before mandatory decisions are final.
Parallel controls
Fraud and sanctions may run concurrently for latency.
The release gate waits for both:
- FRAUD=ALLOW;
- SANCTIONS=CLEAR.
If one times out:
- follow its specific contingency.
Payment decision token
One implementation pattern is a short-lived release token binding:
- payment ID;
- amount;
- beneficiary;
- fraud decision;
- timestamp.
Gateway only sends if:
- token valid;
- payment unchanged.
This prevents an amount/payee being modified after fraud approval.
Customer challenge state
When fraud requires step-up:
PAYMENT_CREATED
→ FRAUD_CHALLENGE
→ CHALLENGE_PASSED/FAILED
→ RELEASE decision.
If customer closes app:
- keep payment pending/expired under product rules;
- do not release simply because initial risk score was medium.
Rail-aware fraud reference model
AFT
- file ID;
- batch ID;
- item trace;
- customer reference.
PAD
- agreement/mandate reference;
- originator;
- presentment reference;
- return link.
Interac
- internal transfer ID;
- network/service reference;
- recipient identifier.
Lynx
- internal payment ID;
- PCRN after settlement;
- UETR only if a linked SWIFT/cross-border leg supplies one.
Fraud case model should support all without forcing them into one field called transactionNumber.
Cross-channel duplicate protection
A customer may:
- start payment in mobile;
- see timeout;
- retry in web;
- call branch.
If each channel creates a new ID, duplicates can escape channel-level controls.
Use shared idempotency/business-intent recognition where feasible:
- same account;
- beneficiary;
- amount;
- close time;
- customer reference.
Do not automatically block every similar payment; legitimate repeated payments exist. Trigger confirmation/review appropriately.
Fraud control for returns and refunds
Returns can be abused.
Examples:
- fraudulent refund to a different account;
- employee creates return without original;
- scammer requests over-refund.
Controls:
- link refund/return to original;
- amount <= permitted;
- destination relationship;
- approval.
For rail-generated returns:
- match original payment;
- reason;
- amount;
- identity.
Payment repair desk controls
Manual operations repairs are high risk.
Controls:
- role-based access;
- dual approval above threshold;
- original data preserved;
- reason;
- audit;
- no silent beneficiary substitution.
A repair user should not be able to change payee on a settled/released payment as though editing a draft.
Fraud control tuning by customer segment
Consumer
- device;
- behavior;
- recipient;
- scam.
SME
- user roles;
- supplier change;
- invoice;
- moderate bulk.
Large corporate
- H2H/API;
- entitlement;
- large file;
- beneficiary master;
- treasury workflows.
One consumer-style model cannot understand a corporate payment factory.
Real-time versus batch monitoring
Batch
Allows:
- file profile;
- pre-release review;
- item population analysis.
Real time
Needs:
- low latency;
- automated decision;
- network intelligence.
Hybrid
A corporate may send a bulk instruction whose individual payments execute in real time.
Fraud controls need:
- batch aggregate context;
- per-payment decision.
Fraud testing in CI/CD
For payment code changes, automate:
- mandatory fraud call occurs;
- decline prevents gateway send;
- timeout follows fallback;
- duplicate callback not duplicate debit;
- beneficiary change invalidates prior decision.
Keep a golden test corpus by rail.
Production synthetic test
Where allowed, controlled synthetic transactions can validate:
- end-to-end control services;
- latency;
- monitoring.
Ensure they do not contaminate fraud/AML metrics.
Fraud operations dashboard by rail
Show:
AFT
- file holds;
- changed beneficiary alerts;
- duplicate prevents.
PAD
- biller anomaly;
- unauthorized claim trend.
Interac
- scam/ATO;
- new recipient declines;
- mule alerts.
Wire
- beneficiary-change cases;
- high-value reviews;
- recovery.
Common
- loss;
- recovery;
- false positives;
- service health.
Control mapping to payment lifecycle
A final design workshop should mark every control as:
- preventive;
- detective;
- corrective.
Example wire:
Preventive:
- authentication;
- beneficiary verification;
- dual approval;
- fraud screening.
Detective:
- post-event monitoring;
- receiving-bank fraud report.
Corrective:
- recovery request;
- customer remediation.
A bank with only detective controls on an irreversible payment has designed too late.
Fraud control data contract between systems
A payment hub and fraud platform should have an explicit contract.
Request
Include:
- payment ID;
- customer/user;
- channel;
- rail/product;
- source account;
- beneficiary;
- amount/currency;
- device/session;
- beneficiary age/history;
- entitlement/approval context;
- sensitive recent events.
Response
Include:
- decision;
- reason codes;
- decision ID;
- model/rule version;
- challenge requirement where applicable;
- expiry.
Binding
The payment hub must ensure the request matches the payment ultimately released.
If:
- amount changes;
- beneficiary changes;
- source account changes;
the prior decision may no longer be valid.
Retries
If fraud call times out:
- reuse payment ID;
- avoid creating two decisions for two economic payments;
- apply documented retry/fallback.
Audit
Persist request/response metadata under data-retention/privacy policy.
Fraud control review by rail change
Every scheme/product change should trigger fraud impact assessment.
Examples:
- new AFT format;
- new Interac feature;
- Lynx message change;
- RTR launch;
- new corporate API.
Ask:
- new data?
- new speed/finality?
- new recipient identity?
- new limit?
- new recovery?
- new customer UX?
Example: adding instant corporate payment
A corporate customer previously pays suppliers by AFT with hours of lead time.
New instant product changes:
- decision latency;
- manual review feasibility;
- liquidity;
- beneficiary risk;
- recovery.
Reusing batch fraud process without redesign can be unsafe.
End-to-end fraud control proof
For one test payment, demonstrate:
- customer/user authenticated;
- beneficiary state retrieved;
- fraud request built;
- fraud decision recorded;
- mandatory challenge completed if required;
- release gate verifies decision;
- exactly one external payment sent;
- ledger posted once;
- references available to case management;
- any recovery links to original.
This is stronger than proving that "fraud API returned 200."
Rail-specific control ownership
AFT team
Owns:
- file lifecycle;
- duplicate;
- release;
- clearing/returns.
Fraud team:
- anomaly/compromise decision.
PAD team
Owns:
- biller sponsorship;
- agreement/return mechanics.
Fraud/compliance:
Interac team
Owns:
- service state;
- recipient/notification integration.
Fraud:
Wire team
Owns:
- instruction;
- Lynx status;
- recovery.
Fraud:
Clear ownership reduces cases bouncing between queues.
Exception-driven tuning
A fraud rule may appear effective in loss statistics but cause:
- operations repairs;
- customer complaints;
- missed payroll;
- value-date failures.
Tuning review should include:
- financial fraud outcomes;
- operations impact;
- customer impact.
Example
Rule blocks files with >10 changed beneficiaries.
Large employer has legitimate annual benefits enrollment causing 300 changes.
Rather than disable:
- identify payroll seasonal event;
- corporate-specific baseline;
- customer confirmation.
Fraud-service dependency register
For every external/internal service:
- name;
- owner;
- criticality;
- timeout;
- fallback;
- data;
- SLA;
- incident contact.
Services:
- device intelligence;
- confirmation of payee;
- network fraud;
- model platform;
- case platform.
A real-time payment availability target is only achievable if critical fraud dependencies have compatible resilience.
Customer fraud education at point of payment
Education is strongest when relevant.
New Interac recipient
Show:
- verify contact;
- scams can be hard to recover.
Wire beneficiary change
Corporate UI:
- independently verify changed bank details.
"Safe account" pattern
Show explicit message:
- bank/police will not ask you to transfer money to secure it.
Measure:
- warning shown;
- user cancel;
- user proceed.
Use learning to improve wording.
Fraud recovery control totals
At end of day or near-real-time:
- fraud recovery requests count/value;
- recoveries received;
- unmatched recovery credits;
- reimbursements;
- open recoverable.
A recovery payment without case link becomes unapplied cash or customer miscredit.
Partial and multi-part recovery
One original payment may return:
- CAD 2,000 today;
- CAD 1,000 tomorrow.
Case/accounting must support many recovery events against one original loss.
Fraud operations access control
Roles:
- viewer;
- investigator;
- supervisor;
- recovery specialist;
- model/rule admin.
Restrict:
- balance adjustments;
- beneficiary block management;
- rule deployment.
Log privileged actions.
Fraud release checklist for a new payment product
Before production:
- typologies identified;
- fraud data mapped;
- decisions integrated before release;
- timeouts tested;
- case routing;
- recovery process;
- customer warnings;
- accounting;
- metrics;
- privacy/access;
- model governance.
If recovery ownership is unknown, product is not ready even if fraud scoring is excellent.
Fraud control operational acceptance scorecard
Before declaring the multi-rail control set complete, test the operating evidence rather than only code.
Control presence
For each rail:
- required controls configured;
- owner named;
- decision point before release/finality where appropriate.
Control effectiveness
Prove:
- test fraud is stopped/challenged;
- normal payment passes;
- false-positive handling works.
Resilience
Prove:
- decision-service outage follows policy;
- payment state remains known;
- no duplicate on recovery.
Investigation
Prove:
- case receives rail references;
- analyst sees authentication and beneficiary context;
- recovery path is available.
Accounting
Prove:
- original transaction;
- reimbursement;
- recovery;
- loss;
reconcile separately.
Customer
Prove:
- accurate status language;
- no false recovery promise;
- support knows correct rail.
A payment product is fraud-ready only when all six dimensions work together.
Fraud control evidence pack for production sign-off
For each rail, assemble one approved payment and one prevented/high-risk payment.
Evidence should include:
- channel instruction;
- authentication/entitlement;
- beneficiary history;
- fraud request/response;
- challenge if any;
- release gate;
- external network evidence;
- ledger;
- case/recovery for the high-risk scenario.
The reviewer should be able to prove that the exact transaction approved by fraud was the transaction released.
Operational handover
Before go-live, operations needs:
- alert queues;
- reason-code guide;
- escalation contacts;
- counterparty recovery contacts;
- service-outage procedure;
- customer wording.
A control is not production-ready if only developers know what its error codes mean.
First 30 days
Monitor by rail:
- fraud rate;
- decline/challenge;
- false positives;
- latency;
- service errors;
- cases;
- complaints.
Compare against launch assumptions and tune under governance.
Finality awareness training
Every fraud investigator should know for the rails they support:
- when a payment can still be stopped;
- when it is settled/final;
- what recovery mechanism remains.
That knowledge prevents the two most damaging responses to fraud: blind resubmission and false promises of reversal.
Production verification after fraud-control deployment
After a change reaches production, verify a controlled sample from each rail:
- fraud request reached correct policy;
- decision bound to payment;
- release followed decision;
- case evidence searchable;
- metrics updated.
Compare production decision distribution with pre-release expectations. Unexpected collapse or spike in ALLOW/DECLINE/CHALLENGE can indicate missing features, bad routing or configuration rather than a genuine change in customer behavior.
Control drift
Quarterly or event-driven review should ask:
- does every new channel still call fraud?
- are beneficiary fields still mapped?
- do old rules still match current products?
- have recovery contacts changed?
Fraud control effectiveness decays when payment architecture changes around it.
11. Practical multi-rail fraud scenarios
The following are fictional teaching scenarios, not reports of named customers, banks or incidents.
Scenario 1 — compromised payroll portal
A Winnipeg employer uploads a normal-value payroll file, but 18 beneficiary accounts changed overnight.
Controls:
- user authentication passes;
- file total looks normal;
- beneficiary-change feature detects anomaly;
- maker/checker sees changed-payee count;
- release held.
Lesson: item/master-data intelligence can outperform file-total monitoring.
Scenario 2 — unauthorized PAD
A Montreal consumer says an insurance PAD continued after cancellation.
The bank:
- identifies transaction as PAD;
- obtains biller/originator reference;
- checks applicable Rule H1 claim;
- processes reimbursement/return if criteria met;
- keeps complaint separate from whether the insurance premium remains owed.
Lesson: use PAD evidence and Rule H1, not generic fraud language.
Scenario 3 — Interac scam
A customer sends CAD 4,800 to a supposed government agent.
Authentication and device are normal.
Signals:
- first-time recipient;
- unusual amount;
- customer reacts to urgency;
- recipient has risk signals.
A contextual scam warning and receiving-side intelligence are more relevant than another password challenge.
Scenario 4 — supplier wire diversion
A Halifax importer receives new payment instructions from a supplier mailbox. Amount CAD 375,000.
The maker updates the template. Checker approves invoice.
A separate beneficiary-change control requires callback using the pre-existing supplier contact. Supplier denies the change.
Lesson: approval of the payment is not the same as independent validation of a beneficiary-master change.
Scenario 5 — settled wire fraud
A corporate discovers a fraudulent wire after PCRN confirms Lynx settlement.
Operations:
- do not attempt system reversal;
- secure corporate access;
- contact receiving participant using the internal payment ID and PCRN, plus UETR where the cross-border/SWIFT leg provides one;
- initiate recovery;
- preserve evidence;
- evaluate AML/STR requirements.
Lesson: prevention window has closed; recovery and legal/compliance work begin.
12. Key takeaways and authoritative references
Key takeaways
- Apply fraud controls according to the rail's lifecycle and point of finality.
- AFT needs file and item controls.
- PAD needs strong mandate/agreement and biller controls.
- Interac needs digital-session, recipient, scam and mule controls.
- Wires need strong entitlement, beneficiary and pre-settlement controls.
- Authentication and payment authorization are different.
- Limits reduce exposure but do not identify fraud.
- Holds require authority, reason and expiry/ownership.
- A recovery request is not a recovered payment.
- Reimbursement and interbank recovery are separate accounting events.
- Test fraud sequences, outages and negative paths, not only individual model rules.
Authoritative references
Always confirm the current rulebook, financial-institution procedures and customer agreements before applying a live fraud decision.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.