FINTRAC, AML and Transaction Reporting. Connect payment processing to client identification, records, prescribed reporting and investigation evidence.
Block 13 · Chapter 63 of 75
Payment processing and anti-money-laundering controls share the same transaction data but answer different questions. A payment engine asks whether an instruction is valid, funded, routable and processable. An AML program asks whether the client, relationship and activity are consistent with known information and whether legal obligations for identification, records, monitoring and reporting have been met.
In Canada, FINTRAC administers the Proceeds of Crime (Money Laundering) and Terrorist Financing Act (PCMLTFA) and associated regulations for reporting-entity compliance. Financial entities must maintain a compliance program, identify clients in prescribed circumstances, keep required records, conduct ongoing monitoring of business relationships, apply enhanced measures to high-risk relationships and submit prescribed reports.
A common implementation mistake is to treat every transfer as an "EFT" for FINTRAC purposes. The statutory/regulatory definition is narrower than everyday banking language. FINTRAC's guidance excludes, among other things, direct deposits, pre-authorized debits, cheque imaging/presentment, qualifying clearing/settlement transfers and certain internal treasury transfers. For reporting purposes, the exact legal definition and current guidance matter.
Another common mistake is to equate threshold reporting with suspicious transaction reporting. An Electronic Funds Transfer Report has threshold and timing rules. A Suspicious Transaction Report has no monetary threshold and is required when there are reasonable grounds to suspect that a completed or attempted transaction is related to money laundering, terrorist activity financing or sanctions evasion. The two reports answer different legal triggers and can both apply to the same event.
This chapter connects FINTRAC obligations to real payment processing: customer initiation, KYC, international EFTs, SWIFT-equivalent transfers, transaction records, 24-hour aggregation, suspicious activity, investigation evidence, case management and reporting architecture.
Scope labels used below: [Regulatory] means a PCMLTFA/regulation or FINTRAC obligation; [System/scheme] means a Payments Canada or other network rule/capability; [Bank-specific] means an implementation choice that must be verified against the institution's product, contract and operating procedures; and [Fictional example] means an illustrative scenario, not a claim about a named institution.
The FINTRAC layer does not replace the payment rail. In a real implementation, an authenticated channel (branch, portal, host-to-host or API) submits an instruction to the bank's payment hub; the hub validates parties and accounts, applies fraud/sanctions/AML controls, selects a route and emits the applicable file or message to a network, correspondent or gateway. The bank then tracks exchange/clearing, settlement-account and liquidity evidence, customer-ledger posting, returns/reversals, disputes and reconciliation. [Bank-specific] Authentication strength, cutoffs, routing, message/file/API contracts, settlement cycles, holds and exception treatment are not inferred from FINTRAC guidance and must not be presented as universal Canadian rules.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain the role of FINTRAC and the PCMLTFA compliance framework;
- distinguish payment-processing terminology from the legal definition of an EFT;
- identify important payment activities excluded from the FINTRAC EFT definition;
- explain when financial entities must verify client identity for international EFTs of CAD 1,000 or more and equivalent SWIFT MT103-type transfers;
- explain record keeping for EFTs of CAD 1,000 or more;
- explain the CAD 10,000 international EFT reporting threshold;
- explain the 24-hour aggregation rule and why it is not simple daily-total logic;
- explain the five-business-day EFTR deadline;
- explain STR reasonable-grounds-to-suspect and no-threshold principles;
- explain "as soon as practicable" for STR submission;
- connect ongoing monitoring to customer and transaction risk;
- preserve data needed for AML investigations without corrupting payment processing;
- design a reporting architecture that separates payment state from regulatory-report state;
- identify other payment-related reports such as listed-person/entity property reports;
- build practical AML/transaction-reporting controls and tests.
Chapter navigator
- Canada's AML/ATF framework and payment operations
- Reporting entities, compliance program and risk assessment
- Client identification and payment records
- What counts as an electronic funds transfer
- Electronic Funds Transfer Reports
- The 24-hour rule
- Suspicious Transaction Reports
- Ongoing monitoring and payment investigations
- Data, evidence, retention and reporting architecture
- Implementation and testing
- Practical Canadian AML/payment scenarios
- Key takeaways and authoritative references
1. Canada's AML/ATF framework and payment operations
FINTRAC is Canada's financial intelligence unit and AML/ATF supervisor for reporting entities under the PCMLTFA.
Payment operations intersect with AML through customer identity, beneficial ownership where applicable, business-relationship information, transaction records, international transfers, ongoing monitoring, suspicious-transaction escalation and sanctions-evasion reporting.
AML is not a payment-authorization service.
A transaction can be technically valid, fully funded and correctly routed while still being suspicious. Likewise, a technically rejected payment can still be reportable as an attempted suspicious transaction if the STR threshold is met.
Five compliance-program components
FINTRAC guidance requires reporting entities to maintain a compliance program including:
- a compliance officer;
- written policies and procedures kept current and approved as required;
- a documented risk assessment;
- an ongoing compliance training program and plan;
- an effectiveness review at least every two years.
The program must cover payment products and channels, not exist only as compliance documentation.
Payment data as compliance evidence
Useful payment evidence includes who instructed, who benefits, accounts, amount/currency, channel, time, purpose/remittance, routing, related transactions, customer risk and investigation notes.
2. Reporting entities, compliance program and risk assessment
Different reporting-entity sectors have different obligations. This chapter focuses mainly on financial entities and payment-related flows.
Risk assessment
FINTRAC requires a documented risk assessment considering clients and business relationships, products/services/delivery channels, geography, relevant affiliates, new technology/developments, National Risk Assessment factors and other business-specific risks.
If risk is high, enhanced measures are required.
New payment product
Before launching a new cross-border API product, AML should assess customer segments, jurisdictions, transaction speed, intermediaries, beneficiary data, limits, data availability, sanctions-evasion risk and monitoring scenarios.
A risk assessment performed after go-live defeats the purpose.
Ongoing monitoring
Ongoing monitoring is intended to detect suspicious transactions, keep client and beneficial-ownership information current as required, reassess client risk, and determine whether activity is consistent with known information.
Frequency depends on risk; high-risk relationships require enhanced measures.
3. Client identification and payment records
Financial entities must verify identity in prescribed situations.
For payment operations, FINTRAC guidance includes:
- initiation of an international EFT of CAD 1,000 or more;
- initiation of another EFT that is a SWIFT MT-103 message or equivalent of CAD 1,000 or more;
- remittance to the beneficiary of an international EFT of CAD 1,000 or more;
- suspicious transactions regardless of amount, subject to stated exceptions.
Identity is not the same as payment authentication
KYC identity is regulated verification of client identity.
Payment authentication is proof that the user/session is authorized to transact.
Both can be required.
EFT records
FINTRAC financial-entity guidance requires records for an international EFT or an EFT that is a SWIFT MT-103/equivalent when initiating at CAD 1,000 or more, for sending an international EFT as an intermediary at CAD 1,000 or more, and for final receipt of an international EFT at CAD 1,000 or more. The required fields and reasonable-measures standard differ by direction, so the payment hub must preserve whether the bank initiated, intermediated or finally received the transfer.
Data can include:
- date;
- amount and type of funds;
- client information;
- beneficiary name/address;
- account details;
- reference numbers;
- exchange rates/source where applicable.
Records generally need to be retained at least five years under the relevant FINTRAC guidance.
Reporting copies
Copies of reports submitted to FINTRAC must also be retained as required.
4. What counts as an electronic funds transfer
FINTRAC's definition matters because it determines which obligations apply.
The guidance describes EFT as transmission of instructions by electronic, magnetic or optical means for transfer of funds, with SWIFT scope focused on MT-103 and equivalent messages.
Important exclusions include:
- beneficiary cash withdrawal;
- direct deposit;
- pre-authorized debit;
- cheque imaging/presentment;
- transfers solely for clearing/settlement obligations between specified entities;
- qualifying internal treasury management among related entities.
Why this matters in architecture
A bank's generic internal label for an electronic transfer cannot determine regulatory reporting.
A regulatory-classification service or controlled rule set should evaluate:
- international/domestic;
- message or transaction type;
- purpose;
- parties;
- legal definition;
- exclusions.
Direct deposit example
A payroll AFT credit may be electronic in ordinary language but excluded from the FINTRAC EFT definition as direct deposit.
Do not create EFTRs simply because money moved electronically.
PAD example
PAD is specifically excluded from the EFT definition.
Suspicious PAD activity can still create STR obligations if the threshold is reached, but it is not an EFTR merely because the debit is electronic.
SWIFT-equivalent transfers
FINTRAC guidance explicitly refers to international EFTs and SWIFT MT-103 messages or equivalent in certain identity and travel-rule contexts.
ISO 20022 migration does not remove the legal obligation; implementation must map the current equivalent customer payment correctly.
5. Electronic Funds Transfer Reports
Threshold
FINTRAC requires reporting of international EFTs of CAD 10,000 or more, subject to detailed rules and exceptions.
Reporting can apply when the reporting entity initiates an international EFT or finally receives an international EFT.
Timing
FINTRAC current guidance states EFTRs must be submitted within 5 business days after the day on which the reporting entity initiates or finally receives the transfer.
Reporting is not a hold
Threshold reporting generally does not mean the payment must be stopped.
The reporting obligation and payment decision are separate unless another control or legal obligation requires a hold.
One payment, multiple obligations
A CAD 25,000 international wire may require:
- KYC/identity obligations;
- a transaction record;
- an EFTR;
- travel-rule data;
- sanctions screening;
- an STR if suspicious.
Do not treat one report as satisfying every obligation.
Report data
The reporting solution should source data from authoritative systems:
- customer/KYC;
- payment;
- beneficiary;
- accounts;
- FX;
- routing;
- third-party determination;
- reporting entity.
Avoid manual rekeying where possible.
6. The 24-hour rule
The 24-hour rule addresses aggregation.
For EFT reporting, FINTRAC guidance applies aggregation to two or more international EFTs that total CAD 10,000 or more within a static, consecutive 24-hour window when the reporting entity knows the applicable requester/on-behalf-of condition. The criteria differ by direction: initiation uses the same requester or the same third party; final receipt uses the same requester. The general 24-hour guidance's beneficiary examples for other report types must not be copied into EFT logic.
This is not simply "sum all payments by account per calendar day."
Outgoing aggregation examples
Multiple initiated international EFTs can aggregate where known to be requested by the same person/entity or requested on behalf of the same person/entity (third party). A same-beneficiary relationship alone is not the current EFT initiation aggregation test.
Incoming aggregation
For finally received international EFTs, aggregation applies where two or more transfers are known to have been requested by the same person/entity. A same-beneficiary relationship alone is not the current EFT final-receipt aggregation test.
Why data quality matters
Aggregation needs normalized requester/conductor identity, third-party information where applicable, timestamps, amount/currency and transaction classification. Beneficiary data remains important for the EFT record and report, but is not a standalone EFT 24-hour aggregation key under the current FINTRAC guidance.
Spelling variations should not defeat aggregation.
Static window
Implementation must follow FINTRAC's current rule and form guidance rather than inventing a rolling-window definition.
Exceptions
FINTRAC guidance describes precise exceptions for initiation at the request of or on behalf of a public body, qualifying very large corporation or trust, or federally/provincially regulated pension-fund administrator, and for final receipt where the beneficiary is one of those categories. The exceptions do not apply when an individual transfer is itself at or above CAD 10,000. Implement the current rule and exception fields; never simplify them into a broad "corporates exempt" rule.
7. Suspicious Transaction Reports
An STR is triggered by suspicion, not amount.
Threshold
The legal threshold is reasonable grounds to suspect that a transaction or attempted transaction is related to the commission or attempted commission of:
- money laundering;
- terrorist activity financing;
- sanctions evasion.
The threshold is above simple suspicion but does not require proof.
Attempted transactions
A transaction does not need to complete.
An attempted suspicious payment can be reportable.
No monetary threshold
CAD 200 can be suspicious.
CAD 2 million can be legitimate.
Threshold monitoring and suspicious monitoring are separate.
Timing
FINTRAC requires STR submission as soon as practicable after measures enabling the reporting entity to establish reasonable grounds to suspect are completed.
FINTRAC explains that submission should be treated as a priority and delays need reasonable explanation.
Reasonable measures to verify identity
For suspicious transactions, financial entities must take reasonable measures to verify identity, with exceptions including where identity has already been verified with no doubts or where attempting verification would tip off the person.
Tipping off
Staff should not reveal the contents or existence of an STR in a way intended to prejudice an investigation.
Payment-support scripts should therefore avoid statements such as:
- "we filed an STR";
- "FINTRAC told us";
- "you are being investigated."
The customer can be told operational facts that policy permits.
STR narrative
A useful STR explains who, what, when, where, why suspicious, related parties/accounts, transaction pattern and indicators/context.
The compliance case should retain the evidence supporting the narrative.
8. Ongoing monitoring and payment investigations
Transaction monitoring should look at activity in client context.
The instruction-to-reporting diagram above connects monitoring context to reporting outcomes: each context signal below should end in a documented reporting decision.
Context
Examples:
- known business;
- expected revenue;
- usual jurisdictions;
- expected counterparties;
- occupation;
- account purpose;
- prior behavior.
Indicators versus conclusions
One indicator rarely proves suspicious activity.
Examples:
- round values;
- rapid movement;
- structuring;
- unusual beneficiary;
- many third parties;
- unusual geography;
- pass-through behavior.
Analysts consider facts, context and indicators.
Fraud and AML overlap
A mule-account fraud case may also be AML-relevant.
Fraud case:
AML case:
- recipient account receives many fraud proceeds and rapidly distributes them.
The same payment references can support both.
Sanctions evasion
Current FINTRAC guidance incorporates sanctions-evasion risk into compliance-program risk assessment and STR obligations.
Case escalation
A payment alert should not automatically file an STR.
Process:
alert → review → gather context → determine threshold → report if required.
9. Data, evidence, retention and reporting architecture
A practical architecture separates payment processing from regulatory reporting.
Payment hub
- instruction;
- status;
- settlement.
KYC/client master
- identity;
- business;
- beneficial ownership;
- risk.
AML monitoring
- transactions;
- scenarios;
- network analytics.
Case management
- investigation;
- threshold decision;
- narrative.
Regulatory reporting
- EFTR;
- STR;
- other prescribed reports.
Immutable payment history
Do not edit transaction data to make a regulatory report easier.
If information changes:
- retain original;
- store corrected/enriched data;
- log provenance.
Reporting state
Keep regulatory-report state separate:
- NOT_REQUIRED;
- PENDING;
- FILED;
- ERROR;
- AMENDED where supported by the reporting process.
A payment being SETTLED does not imply its regulatory reporting is complete.
Retention
FINTRAC guidance generally requires relevant EFT records and copies of EFTRs for at least five years.
Retention policy must map exact record types and legal requirements.
Access
AML case access should be restricted. Payment operations may need transaction state without needing STR narrative.
Reconciliation
Regulatory reporting should reconcile:
- eligible transactions;
- generated reports;
- accepted submissions;
- rejected submissions;
- resubmissions.
A queue with zero errors does not prove every reportable payment was selected.
10. Implementation and testing
Classification tests
Test:
- domestic AFT payroll — no EFTR by the direct-deposit exclusion;
- PAD — excluded EFT;
- international wire CAD 9,999 — below the single-transfer threshold;
- international wire CAD 10,000 — threshold reached;
- multiple international EFTs aggregate under the 24-hour rule;
- suspicious attempted CAD 500 transfer — STR threshold can still apply.
Currency conversion
Threshold assessment for foreign-currency EFTs needs controlled exchange-rate logic consistent with requirements.
Store:
- source amount/currency;
- CAD equivalent used;
- rate/source;
- timestamp.
Data completeness
Test missing:
- address;
- beneficiary;
- account;
- third-party information;
- occupation/business;
- reference.
Mandatory-field handling should follow current FINTRAC form guidance.
Timeliness
Monitor:
- EFTR due date;
- STR case age after RGS threshold;
- filing errors;
- submission status.
Change management
Regulatory forms and guidance evolve.
Version:
- classification rules;
- report schemas;
- code tables;
- validation;
- field mappings.
Controls
Use maker/reviewer controls for rule changes, a regression test pack, production reconciliation and a named regulatory-change owner.
AML obligations mapped to the payment lifecycle
A compliance program becomes operational when obligations are attached to real payment events.
Before initiation
Possible requirements:
- identify/verify client where prescribed;
- understand business relationship;
- maintain current KYC/beneficial ownership according to applicable rules;
- determine client risk;
- capture required payment information.
Payment channels should not wait until a report is due to discover required data was never collected.
At initiation
Capture:
- customer/account;
- amount/currency;
- beneficiary;
- originator;
- destination country;
- account/reference;
- purpose/remittance where provided;
- third-party information where required;
- rate/CAD equivalent for thresholds where applicable.
Classify:
- domestic/international;
- FINTRAC EFT/not EFT;
- reportable threshold candidate;
- travel-rule scope;
- monitoring features.
During processing
Controls may include:
- sanctions;
- fraud;
- AML transaction monitoring;
- travel-rule completeness;
- threshold aggregation.
Do not make the customer channel wait for a regulatory report to be filed unless there is another legal/control reason to hold the payment.
After completion
- generate/complete required report;
- retain records;
- feed ongoing monitoring;
- reconcile reporting population;
- investigate alerts.
Attempted payments
A rejected or abandoned transaction can still be relevant to suspicious transaction reporting.
Therefore event stores should preserve:
- attempted amount;
- parties;
- channel;
- reason stopped;
- customer behavior;
- timestamp.
A payment engine that deletes failed attempts can remove valuable AML evidence.
FINTRAC EFT classification model
Because the legal definition differs from everyday terminology, create an explicit regulatory classification.
Example attributes
- isInternational;
- isSWIFTMT103OrEquivalent;
- isDirectDeposit;
- isPAD;
- isChequeImage;
- isClearingSettlementObligation;
- isInternalTreasuryExclusion;
- reportingEntitySector;
- amount;
- currency.
Classification output
Examples:
- EFT_RECORD_REQUIRED;
- EFTR_SINGLE_THRESHOLD;
- EFTR_24H_CANDIDATE;
- TRAVEL_RULE;
- NOT_FINTRAC_EFT;
- REVIEW_REQUIRED.
The exact implementation must be driven by current legislation/guidance.
Why generic paymentType is dangerous
A bank may call:
- Interac payment = EFT;
- payroll = EFT;
- internal transfer = EFT.
That internal taxonomy is useful operationally but insufficient for FINTRAC reporting.
Maintain regulatory classification as a separate dimension.
ISO 20022 migration
If a bank migrates from MT103 to pacs.008 for cross-border customer payments, the legal obligation does not disappear because the message identifier changed.
The rule engine needs a maintained equivalence mapping based on legal/compliance interpretation and current FINTRAC guidance.
Threshold reporting design
Single international EFT
When amount meets/exceeds threshold:
- create reportable event;
- capture reporting data;
- calculate due date;
- file;
- capture FINTRAC result.
24-hour aggregation
A robust aggregation service needs:
- normalized requester/conductor keys;
- third-party/on-behalf-of relationships;
- static window treatment per current guidance;
- original transactions;
- amount/currency and the controlled threshold value.
Party normalization
Avoid aggregating only by text.
Examples:
"ABC Holdings Ltd."
"ABC HOLDINGS LIMITED"
"ABC Holdings"
may represent same entity.
Use:
- client ID where known;
- entity resolution;
- identifiers.
Beneficiary identity
Beneficiary data is still required for many EFT records and reports and can be difficult when there are multiple accounts, spelling differences or intermediary data. Store the available stable account/reference and normalized identity for reporting and investigations, but do not use a same-beneficiary key as an EFT 24-hour trigger unless current FINTRAC guidance changes.
Window boundary testing
Test transactions at:
- start of static window;
- exactly before/after boundary;
- different time zones;
- daylight-saving changes.
Regulatory time logic should use a controlled clock/time-zone policy.
Corrections/amendments
Reporting systems should retain:
- original submitted report;
- corrections;
- reason;
- acknowledgment.
Do not overwrite the original report payload.
Electronic Funds Transfer Report data lineage
Every EFTR field should have a source.
Customer
Source:
Examples:
- name;
- address;
- DOB/identifier as required;
- occupation/business where required.
Payment
Source:
Beneficiary
Source:
- payment instruction / receiving data.
FX
Source:
Third party
Source:
- customer declaration/KYC/payment context.
Reporting entity
Source:
Data provenance
Store:
- source system;
- source record ID;
- extraction timestamp;
- transformation.
When an auditor asks why a report contained an address, the bank should answer without searching email.
Suspicious transaction decision framework
STR filing requires judgment.
Stage 1 — detection
Source:
- scenario alert;
- fraud referral;
- employee observation;
- law-enforcement information;
- adverse media;
- sanctions alert;
- customer behavior.
Stage 2 — investigation
Gather:
- KYC;
- account history;
- transaction pattern;
- counterparties;
- explanations;
- related accounts;
- external intelligence.
Stage 3 — threshold decision
Document:
- facts;
- context;
- ML/TF/sanctions-evasion indicators;
- why RGS reached or not reached;
- decision date.
Stage 4 — filing
If threshold reached:
- prioritize;
- submit as soon as practicable;
- retain report/case;
- continue appropriate monitoring.
No auto-STR rule
An alert, fraud case or high amount should not automatically produce an STR.
Automated systems can:
- prioritize;
- assemble evidence;
- suggest indicators.
The RGS decision needs governed compliance methodology.
STR narrative quality
A useful narrative tells a coherent story.
Weak
"Customer sent multiple wires. Activity suspicious."
Strong structure
Who
- client and relevant counterparties.
What
When
Where
Why
- inconsistency and indicators.
How
Narratives should use objective facts and explain suspicion rather than paste raw alert codes.
Linkage
Include identifiers that allow FINTRAC to connect:
- account;
- transaction;
- entity;
- related reports where required.
Follow current form requirements.
Ongoing monitoring by customer risk
Low/standard risk
Monitoring:
- transaction scenarios;
- periodic KYC update according to policy;
- trigger-based review.
High risk
Enhanced measures can include:
- higher monitoring frequency;
- additional information;
- senior approval where applicable;
- tighter transaction review;
- documented measures.
High risk does not mean every transaction is suspicious.
Trigger events
Examples:
- ownership change;
- new high-risk geography;
- new payment product;
- unexpected transaction growth;
- sanctions exposure;
- law-enforcement request.
A trigger should update risk assessment when warranted.
Payment typologies and AML indicators
Indicators are contextual.
Pass-through account
- credits received;
- funds move out quickly;
- little economic activity retained.
Can be:
- legitimate payment processor;
- treasury sweep;
- mule/laundering.
Understand customer business first.
Structuring
Transactions may be arranged below reporting thresholds.
Do not treat every CAD 9,900 payment as suspicious. Look at pattern, purpose and customer context.
Funnel account
Many cash/electronic inputs from different locations/users, followed by consolidated movement.
Rapid cross-border movement
Inbound funds followed by international EFT with little relationship to stated business.
Third-party activity
Account regularly used by unrelated persons.
Could be:
- legitimate marketplace/payment processor;
- nominee/mule.
KYC determines context.
Round-dollar corporate wires
Common in legitimate treasury. Not a standalone indicator.
Sanctions-evasion AML integration
Sanctions screening can identify a listed party.
AML monitoring can identify evasion patterns where no direct name match appears.
Examples:
- intermediary entities;
- routing changes;
- ownership opacity;
- attempts to strip party data.
If RGS of sanctions evasion is reached, STR obligations apply under current FINTRAC guidance.
A sanctions block/report and an STR can both exist for the same event with different legal bases.
Regulatory reporting architecture in detail
Source layer
- channels;
- payment hub;
- core banking;
- SWIFT/gateway;
- KYC.
Normalized compliance event
Create an event containing:
- customer;
- payment;
- parties;
- amount/CAD equivalent;
- legal entity;
- classification;
- timestamps.
Rules layer
- record requirement;
- EFTR threshold;
- 24h aggregation;
- travel rule;
- case/alert triggers.
Case/report layer
- AML case;
- STR;
- EFTR;
- Listed Person or Entity Property Report (LPEPR) where applicable.
Submission gateway
- schema validation;
- authentication;
- transmission;
- response.
Reconciliation
- event selected/not selected;
- report created;
- accepted/rejected;
- due/overdue.
Regulatory-report reconciliation
The most important control is population completeness.
EFTR completeness
Compare:
reportable EFT population
versus
submitted/accepted EFTRs.
Break types:
- missing report;
- duplicate report;
- rejected submission;
- wrong amount;
- wrong legal entity;
- late report.
24-hour completeness
Run independent aggregate control:
- expected aggregate cases;
- reports created.
STR
STR population cannot be reconciled simply to transactions because judgment determines RGS.
Reconcile:
- cases where RGS reached;
- required STR;
- filed STR;
- due/timeliness.
Filing acknowledgment
A file marked SENT is not necessarily ACCEPTED.
Store FINTRAC submission outcome.
Due-date engine
EFTR
Calculate five-business-day due date from:
- initiated date; or
- finally received date.
Use current FINTRAC definition and business-day handling.
STR
"As soon as practicable" is not a numeric SLA in legislation/guidance.
Internally:
- record RGS established time;
- prioritize filing;
- monitor delay;
- document reasonable cause.
Do not turn an internal target into a statement that law gives exactly X days.
Listed-person/entity property report
The Listed Person or Entity Property Report (LPEPR) is a separate [Regulatory] obligation. Where the reporting entity must make a disclosure under the Criminal Code, United Nations Act, Special Economic Measures Act or Sergei Magnitsky Law, FINTRAC guidance requires the LPEPR immediately/without delay. Do not reuse EFTR's five-business-day due-date logic. A sanctions-evasion STR and an LPEPR can both be required, but they have different legal triggers and data.
Do not reuse EFTR due-date logic.
Client-identification edge cases
Existing verified customer
Current FINTRAC guidance may allow reliance on prior verification when no doubt exists, according to the applicable requirement.
Systems should expose:
- verified date;
- method;
- status;
- exceptions.
Non-account holder
A walk-in or non-account transaction can create distinct identification obligations.
Channel should know when identity is required before processing.
Corporate client
Need:
- entity identity;
- persons acting on behalf;
- beneficial ownership/relationship obligations as applicable.
Payment approver authentication does not replace KYC.
Failed verification
If required identity cannot be verified:
- follow legal/policy action;
- preserve attempt;
- consider suspicious context.
Do not insert dummy identity data to pass the payment schema.
Record-retention architecture
Immutable archive
Keep:
- payment record;
- required EFT record;
- report copy;
- supporting evidence.
Five-year principle
Apply the current record-specific FINTRAC rules; many required records/copies have at least five-year retention.
Do not create one blanket deletion date if a different obligation or legal hold applies.
Searchability
Records should be searchable by:
- customer;
- account;
- transaction reference;
- report ID;
- date;
- counterparty.
An archive that technically exists but cannot be retrieved is operationally weak.
Privacy and access control
AML data contains sensitive information.
Separate roles:
- payment support;
- AML investigator;
- reporting officer;
- administrator.
Restrict:
- STR narratives;
- law-enforcement requests;
- intelligence.
Audit access.
Need-to-know
A branch employee may need to know:
- payment is held/pending compliance review.
They do not need:
- STR decision;
- confidential intelligence.
Change management for regulatory reporting
Regulatory change inventory
Track:
- legislation;
- regulations;
- FINTRAC guidance;
- reporting forms;
- schema;
- code tables.
Impact assessment
For each change:
- products;
- legal entities;
- data fields;
- rules;
- procedures;
- tests;
- training.
Parallel test
Before a report-schema change:
- generate old/new;
- compare;
- validate with FINTRAC test capability where available;
- ensure no population loss.
Rollback
Reporting change rollback must not lose due reports.
Queue events independently of a specific schema version.
AML operations metrics
Monitoring
- alerts per 1,000 transactions;
- false-positive/closed alert rate;
- high-risk client reviews;
- case age.
Reporting
- EFTR volume;
- 24h aggregated EFTR volume;
- submission rejection;
- late report;
- STR filings;
- time from RGS to submission.
Data quality
- missing beneficiary addresses;
- missing third-party information;
- invalid country codes;
- FX conversion exceptions.
Reconciliation
- reportable but unfiled;
- duplicate reports;
- rejected/aged.
Metrics should be segmented by legal entity/product.
Business analyst requirement examples
EFT classification
For every customer payment event, the compliance-classification service must independently determine whether the event meets the current FINTRAC EFT definition and retain the classification reason, rather than relying solely on the bank's product label.
24-hour aggregation
International EFT events must be available to the aggregation service with stable requester, third-party (where applicable) and transaction identifiers, amount/currency, controlled threshold value and regulatory timestamp so the current FINTRAC static-window criteria can be evaluated. Beneficiary data remains available for the EFT record/report but is not a standalone EFT aggregation key.
STR case
When an investigator records that reasonable grounds to suspect have been established, the case system must timestamp the RGS decision and create a prioritized reporting task without changing the payment's settlement status.
Report acknowledgment
Regulatory-report status must not be marked ACCEPTED until the submission gateway receives and records the corresponding FINTRAC acceptance outcome.
Comprehensive AML test pack
- domestic direct deposit;
- domestic PAD;
- international payment CAD 999;
- international EFT CAD 1,000;
- international EFT CAD 9,999;
- international EFT CAD 10,000;
- foreign-currency threshold equivalent;
- 24-hour aggregation;
- attempted suspicious transfer;
- completed suspicious transfer;
- reporting submission rejection;
- duplicate report prevention;
- missing beneficiary;
- KYC stale/high-risk trigger;
- sanctions-evasion referral.
For each test, assert:
- payment result;
- regulatory classification;
- record;
- report/case;
- due date;
- evidence.
Payment monitoring scenario design
AML transaction-monitoring scenarios should be based on risk and customer context rather than a collection of unexplained thresholds.
Scenario anatomy
A scenario should define:
- risk it addresses;
- population;
- transaction types;
- lookback/window;
- threshold/logic;
- exclusions;
- alert data;
- owner;
- tuning/validation.
Example — rapid movement
Population:
personal and small-business accounts.
Logic:
significant incoming credits from multiple unrelated parties followed by rapid international transfer.
Potential relevance:
mule/pass-through behavior.
False positives:
- marketplace seller;
- payroll processor;
- legitimate treasury account.
Investigation needs the customer's known business.
Example — cross-border change
Customer previously sends only domestic payments.
Suddenly:
- new international beneficiaries;
- high-risk geography;
- materially higher value.
This is not automatically suspicious. It is a trigger to compare with updated business purpose.
Scenario thresholds
Thresholds can be:
- absolute;
- relative to customer history;
- percentile/peer;
- network based.
Do not publish sensitive detection thresholds into ordinary product documentation.
Tuning
Measure:
- alerts;
- cases;
- STR conversion;
- false positives;
- investigator capacity.
High alert volume with no useful cases can reduce effectiveness.
Case-management evidence and decision governance
Case chronology
Every case should have a timeline:
- alert;
- review;
- information gathered;
- customer contact if any;
- RGS decision;
- filing;
- continued monitoring.
RGS decision
Record:
- date/time;
- decision-maker;
- facts;
- indicators;
- rationale.
If no RGS:
- explain why evidence did not meet threshold.
Avoid:
- "not suspicious" with no rationale.
Multiple alerts
One case can contain many alerts.
Do not file one STR per alert automatically.
Related accounts
Link:
- customers;
- beneficial owners;
- counterparties;
- devices;
- addresses;
- payment references.
Case escalation
Complex cases can require:
- sanctions;
- fraud;
- legal;
- law-enforcement liaison.
Use controlled permissions.
Payment monitoring and legal-entity boundaries
Banks may have several reporting entities.
Example:
- Bank legal entity A;
- trust company B;
- securities dealer C.
A centralized monitoring platform must still know:
- which entity has the obligation;
- which report;
- which records;
- which compliance officer.
Do not merge reporting simply because systems are shared.
Intercompany payments
Apply actual legal definitions and exclusions.
A treasury movement may qualify for an exclusion only when the requirements are met.
Labeling it "internal" is not enough.
International payment lifecycle and FINTRAC evidence
Customer initiation
Capture:
- originator;
- beneficiary;
- destination;
- amount/currency;
- purpose;
- account.
Compliance classification
Determine:
- international EFT;
- record requirement;
- travel rule;
- single threshold;
- 24h candidate.
Payment execution
Keep:
- message/reference;
- correspondent/agent data;
- final receipt status if incoming.
Reporting
EFTR uses:
- event type/initiate/finally receive;
- reporting entity;
- transaction and party data.
Monitoring
AML analytics sees:
- history;
- counterparties;
- jurisdictions.
Investigation
UETR/payment reference links the report/case to payment evidence.
24-hour aggregation engineering patterns
Streaming aggregation
As international EFT events arrive:
- normalize keys;
- assign static window according to current rule;
- update totals;
- create report trigger.
Batch control
Independent end-of-window recomputation detects missed events.
Use both where scale justifies:
- streaming for timeliness;
- batch for completeness.
Corrections
If an event amount/party data is corrected:
- preserve original;
- update aggregate under controlled rules;
- determine report amendment impact.
Direction-specific criteria
For EFT initiation, an event can aggregate because the transfers were requested by the same requester or on behalf of the same third party. For final receipt, the current EFT guidance uses the same requester criterion. Store the direction, criterion, static-window start/end (including UTC offset), and every component transaction.
Duplicate input
Aggregation must not double count:
- replayed events;
- duplicate gateway feed.
Use stable event ID.
Currency conversion and threshold control
Source rate
Use the rate methodology approved for FINTRAC threshold/reporting purposes.
Do not mix:
- customer FX rate;
- treasury P&L rate;
- regulatory conversion;
without governance.
Reproducibility
Store:
- original amount/currency;
- CAD equivalent;
- rate;
- source/date/time.
Boundary test
Foreign amount converts to:
- CAD 9,999.99;
- CAD 10,000.00;
- CAD 10,000.01.
Test rounding according to approved methodology.
Payment investigations and RGS
A payment operations investigation may begin because a customer asks where funds are.
It becomes AML-relevant only when facts indicate potential ML/TF/sanctions evasion.
Example:
- wire delayed due beneficiary data repair: operational.
- same customer repeatedly uses unrelated third parties and unexplained countries: AML context.
Avoid turning every operations exception into an AML alert.
Travel rule and AML data consistency
Chapter 64 covers travel rule in depth, but Chapter 63 needs one architectural rule:
The originator/beneficiary information sent with a covered EFT should reconcile to the customer/payment data used for AML reporting and records.
If:
- outbound message has one beneficiary address;
- EFTR has another;
- customer file has a third;
the bank needs data lineage and explanation.
Regulatory reporting failures
Submission rejected
Create owned exception:
- report ID;
- error;
- due date;
- corrected submission;
- acceptance.
Gateway unavailable
Queue reports durably.
Do not lose due reports because external service is down.
Bad data
If source field is invalid:
- correct from authoritative source;
- retain correction evidence.
Do not invent values.
Late report
Escalate:
- reason;
- impact;
- remediation;
- compliance assessment.
Metrics should not hide late reports by resetting due dates.
AML control assurance
First line
Payment/product teams:
- capture required data;
- enforce controls;
- maintain system.
Second line compliance
- policy;
- risk assessment;
- monitoring;
- reporting oversight;
- challenge.
Internal audit/independent assurance
- test control design/effectiveness;
- evidence.
Data owner
Often separate:
- customer master;
- beneficiary;
- transaction.
Clear ownership prevents recurring report errors.
Management information
Senior compliance management should see:
- high-risk customer population;
- monitoring alerts/cases;
- case age;
- STR volume/timeliness;
- EFTR volume/timeliness;
- reporting rejects;
- data-quality issues;
- regulatory change progress.
Numbers need context; more STRs do not automatically mean better compliance.
AML implementation anti-patterns
Anti-pattern: threshold-only AML
Problem:
Only CAD 10k checks.
Why wrong:
STR has no amount threshold and 24h aggregation exists.
Anti-pattern: every electronic payment = EFT
Problem:
Payroll/PAD incorrectly included.
Why wrong:
FINTRAC legal definition/exclusions.
Anti-pattern: delete failed payments
Problem:
Attempted suspicious activity evidence lost.
Anti-pattern: report after settlement means compliance is complete
Problem:
Ongoing monitoring and record obligations remain.
Anti-pattern: STR filing blocks customer payment automatically
Problem:
STR is a reporting obligation; payment restriction needs separate legal/policy basis.
Audit walkthrough
Select an international EFT report.
Auditor should trace:
- payment event;
- customer/KYC;
- EFT classification;
- CAD equivalent;
- threshold/24h decision;
- report fields;
- submission;
- acceptance;
- retained copy.
Select an STR.
Trace:
- alert/referral;
- investigation;
- facts/indicators;
- RGS decision;
- narrative;
- submission/timing;
- continued monitoring.
The bank should produce this evidence without manual reconstruction from multiple emails.
Payment-message modernization and regulatory controls
Modernization changes data formats, not legal obligations.
MT to ISO 20022
When customer credit transfers move from legacy message formats to ISO 20022:
- identify equivalent regulatory event;
- map parties;
- map account/reference;
- preserve travel-rule information;
- maintain EFT classification.
Do not use the message name itself as the legal test.
Structured data benefit
Better:
- debtor/creditor separation;
- addresses;
- agent identification;
- remittance.
This can improve:
- monitoring;
- reporting;
- investigations.
But data completeness must be enforced.
Truncation
If rich data is mapped to a legacy downstream format:
- preserve original;
- screen/monitor appropriate representation;
- report from authoritative data;
- log truncation.
Regulatory reporting should not inherit avoidable data loss from the leanest rail.
RTR status at this chapter's audit date
[System/scheme; current status] As of 2026-10-05, Payments Canada describes the Real-Time Rail (RTR) as launching in Q4 2026, with industry solution-assurance testing and participant onboarding underway. It is therefore not a live production capability to assume in a current payment path on this audit date. Treat RTR exchange, clearing and settlement, 24/7/365 processing, instant delivery, ISO 20022 data, fraud services, finality and irrevocability as planned/launch-readiness capabilities until the official production launch and applicable rules say otherwise.
The official participation model says an eligible PSP must register under the RPAA, become a Payments Canada member, and have a Bank of Canada settlement account or settlement-agent agreement. Direct participants may connect through the RTR Exchange; indirect models and third-party connectivity are also contemplated. [System/scheme] These are access and operating-model facts, not FINTRAC reporting thresholds. [Bank-specific] A bank's authentication, API/file/message adapter, route, release/hold decision, liquidity and settlement-account handling, posting, return/recall/reversal, dispute and reconciliation controls still require institution-specific design and testing.
AML case and payment-support boundary
Payment support can explain:
- payment status;
- missing data;
- operational hold.
It should not disclose:
- STR filed;
- AML investigation details;
- confidential intelligence.
Case flag design
Instead of "AML SUSPECT" visible broadly, expose controlled action:
- COMPLIANCE_REVIEW_REQUIRED;
- CUSTOMER_CONTACT_RESTRICTED where applicable.
Sensitive rationale stays in compliance case.
High-risk relationship monitoring example
Customer:
import/export SME.
Known profile:
- payments to Germany/US;
- CAD 300k monthly.
Change:
- new counterparties in several jurisdictions;
- monthly value CAD 3m;
- third-party incoming credits;
- immediate onward wires.
Response:
- update customer information;
- understand business change;
- enhanced monitoring;
- investigate transactions;
- determine RGS.
Do not file merely because growth is large if legitimate acquisition explains it; document context.
AML data-quality control catalogue
Customer
- missing occupation/business;
- stale address;
- unknown beneficial owner;
- duplicate client.
Payment
- invalid country;
- missing beneficiary;
- missing account/ref;
- inconsistent currency.
Reporting
- rejected field;
- unknown code;
- missing legal entity.
Each issue:
- owner;
- severity;
- remediation;
- aged reporting risk.
Regulatory reporting incident management
A reporting outage can be a compliance incident.
Example
FINTRAC reporting gateway unavailable for 12 hours.
Actions:
- keep reports in durable queue;
- preserve due date;
- monitor service;
- submit when available;
- identify any late reports;
- document reason/remediation.
Do not recreate reports manually if that risks duplicate submissions.
Internal system outage
If report-selection engine fails:
- identify outage window;
- backfill all transactions;
- recompute 24h aggregation;
- reconcile.
A restart without backfill can silently miss reports.
24-hour aggregation case study
Transactions:
09:00 CAD 4,000
12:00 CAD 3,500
16:00 CAD 3,000
Same requester, applicable static window. [Fictional example]
Aggregate = CAD 10,500.
The report engine should:
- identify trigger;
- retain all component transactions;
- avoid one report per payment if current rule requires aggregated treatment;
- preserve which criterion caused aggregation.
If one transaction later reverses operationally, compliance treatment must follow reporting rules; do not delete submitted history automatically.
Suspicious-activity case study: mule
Account receives:
- 14 e-Transfers from unrelated senders;
- 3 cash deposits;
- sends international EFT next morning.
Fraud team has 4 scam complaints linked to incoming transfers.
AML investigator combines:
- victim reports;
- account profile;
- pass-through;
- external transfer;
- customer explanation.
The fraud reports are evidence, not the STR decision by themselves.
If RGS reached:
- file STR as soon as practicable;
- include relevant attempted/completed transactions;
- continue controls under policy.
Audit controls for thresholds and exclusions
Test annually/periodically:
- direct deposit exclusion correctly implemented;
- PAD exclusion;
- international classification;
- MT103 equivalent mapping;
- CAD1k records/identity triggers where applicable;
- CAD10k reporting;
- 24h aggregation.
A code change in payment taxonomy can break reporting even if the regulatory engine code did not change.
Training by role
Front line
- identity requirements;
- do not tip off;
- escalate suspicious behavior.
Payment operations
- transaction classification;
- preserve data;
- payment versus compliance state.
Investigators
- RGS;
- indicators;
- narratives.
Technology
- data lineage;
- due dates;
- reconciliation.
Product
- compliance impact before launch.
Role-specific training is more useful than one generic annual slide deck.
Final FINTRAC payment-control checklist
Before launch/change:
- reporting entity determined;
- product classified;
- KYC trigger;
- records;
- travel rule;
- EFTR;
- 24h rule;
- monitoring;
- STR case workflow;
- reporting gateway;
- reconciliation;
- retention;
- access;
- tests.
This checklist turns legislation into a buildable control set while keeping current FINTRAC guidance as the source of truth.
Large-scale regulatory-reporting data controls
As volume grows, manual checking becomes impossible.
Completeness control
Every source transaction should be in one of:
- not in scope, with classification;
- in scope but below reporting threshold;
- reportable;
- aggregated into reportable population;
- escalated for data review.
Unclassified should be a break.
Control totals
Calculate:
- transaction count/value by legal entity;
- international EFT count/value;
- reportable count/value;
- reports accepted.
A sudden unexplained change can identify feed failure.
Source-to-report lineage
For every report field, support drill-down to source.
For derived fields:
- rule;
- transformation;
- version.
Duplicate reports
Use:
- regulatory event ID;
- report ID;
- submission ID.
Prevent:
- retry creating a second report;
- same payment entering two source feeds.
Late-arriving data
If source transaction arrives after reporting batch:
- evaluate due date from actual event;
- create exception;
- do not move event date to hide lateness.
Reportable-event ledger
A useful compliance pattern is a separate ledger of regulatory events.
Attributes:
- event ID;
- legal entity;
- customer;
- payment;
- event type;
- regulatory classification;
- amount/CAD equivalent;
- occurrence time;
- due time;
- report state;
- report ID.
This ledger is not the financial ledger. It is control evidence for reporting completeness.
Advantages
- independent from payment UI;
- supports backfill;
- allows reconciliation;
- preserves attempted events;
- survives report-schema changes.
FINTRAC form/schema validation
Before transmission:
- mandatory fields;
- code values;
- length/format;
- date;
- country;
- amount.
Business validation
Schema-valid can still be wrong.
Examples:
- originator and beneficiary swapped;
- wrong legal entity;
- CAD equivalent wrong;
- final receipt flagged as initiated.
Build business-rule validation in addition to schema validation.
Cross-border incoming payment reporting
For incoming international EFT:
- identify when reporting entity "finally receives" under current guidance;
- capture received payment;
- classify amount;
- aggregate where applicable;
- report within timing.
Do not use:
- first SWIFT message time;
- beneficiary customer posting time;
as substitutes unless they match the legal definition/approved interpretation.
Correspondent/intermediary flows
Banks may receive payment messages where they are intermediary rather than final recipient.
Classification must understand role.
This is why raw message receipt is insufficient to trigger every EFTR.
Attempted transaction evidence
Channel decline
Customer tries international payment but transaction is stopped by fraud/sanctions/validation.
If AML later considers it suspicious:
- preserve attempted parties/amount;
- reason stopped;
- customer behavior.
Branch inquiry
Customer asks staff to structure several transfers then abandons.
Employee observation can create valuable context even if no digital payment record exists.
Procedures should allow staff referral.
Fraud overlap
A scam victim may attempt payment to a mule; the victim is not necessarily laundering. AML focus may shift to recipient or broader network.
Avoid treating victim status as suspicious without context.
Customer due diligence change events
Payment systems can generate KYC triggers.
Examples:
- customer starts using new countries;
- volume changes materially;
- business product changes;
- beneficial-owner payment patterns.
A trigger should create review workflow; it should not automatically overwrite customer risk.
PEP/HIO and payment monitoring
PEP/HIO obligations are separate from sanctions.
A PEP status can influence:
- customer due diligence;
- risk;
- monitoring.
Do not screen PEP as if automatically prohibited.
Payment system should pass customer-risk context to AML monitoring without confusing legal categories.
Beneficial ownership and payments
Corporate payment counterparties may reveal:
- new subsidiaries;
- related entities;
- changed ownership context.
KYC owns authoritative beneficial-ownership records.
AML monitoring may flag inconsistencies for refresh.
Do not infer legal beneficial ownership from payment frequency alone.
STR continuity after filing
Filing an STR does not necessarily close the case.
Continue:
- monitor;
- review new transactions;
- file additional reports as required under current guidance/procedure;
- preserve links.
Case system should link subsequent relevant transactions.
AML quality assurance
Sample investigations for:
- evidence completeness;
- threshold rationale;
- narrative quality;
- timely filing;
- no tip-off.
Sample EFTR for:
- classification;
- amount;
- parties;
- timeliness;
- 24h aggregation.
QA independence
Reviewer should not simply rubber-stamp own investigation.
Use structured quality criteria.
Technology controls for regulatory reporting
Access
Only authorized roles can:
- change reporting rules;
- edit report;
- submit.
Segregation
Developer should not directly change production regulatory thresholds without governed deployment.
Audit
Log:
- rule changes;
- report edits;
- submissions;
- resubmissions.
Secrets
FINTRAC submission credentials:
- secure vault;
- rotation;
- least privilege.
Payment product onboarding questionnaire for AML
Before new product:
- legal entity?
- customer segment?
- domestic/international?
- FINTRAC EFT classification?
- identity triggers?
- travel rule?
- thresholds/aggregation?
- monitoring data?
- records?
- reports?
- sanctions?
- retention?
Product cannot go live with "AML will monitor it later" if required data is unavailable.
Operational procedure for report rejection
- receive rejection;
- classify validation/business error;
- locate authoritative source;
- correct;
- resubmit;
- confirm acceptance;
- record timing.
If repeated:
- root-cause;
- fix source/mapping.
Do not build a permanent manual reporting team to compensate for bad source data.
Final AML payment architecture principle
The compliance system should be able to answer three independent questions for any transaction:
- What happened to the payment?
- What regulatory classification/reporting obligation applied?
- What suspicious-activity conclusion, if any, was reached?
Keeping these independent prevents payment status from incorrectly dictating compliance outcome.
Control ownership and reporting calendar
A compliance architecture also needs human ownership.
Product owner
Ensures new payment product provides:
- required data;
- correct customer capture;
- compliance integration.
Payment operations
Owns:
- payment state;
- operational repairs;
- references.
AML compliance
Owns:
- monitoring;
- RGS decisions;
- reporting policy.
Regulatory reporting operations
Owns:
- report generation;
- submission;
- rejects;
- reconciliation.
Technology/data
Owns:
- feeds;
- rules implementation;
- lineage;
- system availability.
Annual calendar
Maintain:
- FINTRAC regulatory changes;
- risk assessment review;
- scenario tuning;
- training;
- effectiveness review cycle;
- reporting-system releases.
A calendar reduces last-minute remediation.
Data reconciliation case study
Bank has 100,000 outgoing transactions today.
Classification produces:
- 82,000 not FINTRAC EFT;
- 15,000 in-scope below single threshold;
- 2,700 single-threshold reportable;
- 300 events part of 24-hour aggregate cases.
Control:
100,000 source transactions = all classified buckets.
Then:
expected reports ↔ created ↔ submitted ↔ accepted.
If 50 transactions are unclassified, zero submission errors do not mean the process is complete.
Regulatory rule versioning
Every classification should reference:
- rule version;
- effective date.
When guidance changes:
- old transactions retain old decision evidence;
- new transactions use new rules.
Do not retrospectively re-label history without recording the change.
Operations repair and AML controls
A repaired payment can alter:
- beneficiary;
- amount;
- country.
If regulatory classification/reporting data changes:
- re-evaluate before release;
- preserve prior values.
Payment repair desk must not bypass compliance classification.
Compliance testing after a payment migration
When a rail/message migrates:
- replay representative international EFTs;
- confirm KYC trigger;
- travel rule;
- threshold;
- 24h;
- monitoring features;
- reports.
A technically successful ISO migration can still break regulatory reporting if party fields move.
Final reviewer questions
For any payment, compliance should answer:
- why was it or was it not FINTRAC EFT?
- what record existed?
- did threshold/aggregation apply?
- did monitoring see it?
- was there an AML case?
- was any report required/filed?
- can evidence be retrieved?
If those answers depend on manual interpretation of raw XML, the implementation needs stronger business data modelling.
AML payment-control design review checklist
A formal design review should confirm:
Customer and identity
- required KYC data available;
- identity-verification trigger implemented;
- beneficial ownership/risk context accessible.
Payment classification
- domestic/international;
- legal EFT definition;
- exclusions;
- MT103/equivalent mapping.
Reporting
- CAD 10,000 threshold;
- 24-hour aggregation;
- due date;
- submission/acknowledgment.
Monitoring
- payment features feed AML platform;
- attempted transactions retained;
- legal entity/customer context preserved.
Records
- required transaction record;
- report copy;
- retention;
- search.
Operations
- rejected report queue;
- AML case referral;
- no-tip-off procedure;
- reporting outage runbook.
Testing
- threshold boundaries;
- aggregation;
- exclusions;
- message migration;
- attempted STR;
- data-quality failures.
A product design should not be approved if required compliance data must be reconstructed manually after payment execution.
Example data lineage — international payment
Customer enters:
- beneficiary legal name;
- address;
- account;
- amount/currency.
Channel stores instruction.
Payment hub assigns:
- payment ID;
- route;
- execution status.
Gateway produces:
- external reference/UETR where applicable.
Compliance event enriches:
- customer/KYC ID;
- legal entity;
- CAD equivalent;
- regulatory classification.
EFTR uses:
- source customer data;
- source payment data;
- controlled derived fields.
AML monitoring uses:
- same payment ID;
- customer history;
- counterparties.
This shared identity lets a future STR reference the same economic payment without copying inconsistent fields.
Control failure case — missing source feed
A new API channel launches but does not feed AML monitoring.
Payments execute successfully for two days.
Detection:
- AML transaction counts fall compared with payment counts.
Response:
- stop/assess channel according to compliance risk;
- identify full missing population;
- backfill monitoring;
- evaluate alerts/cases;
- assess regulatory reporting impact;
- fix interface;
- complete incident/root-cause.
This is why payment-to-monitoring control totals are essential.
Final AML learning model
For each payment, think in four layers:
Payment — did value move?
Customer — who and what relationship?
Regulatory event — record/report/travel rule?
Suspicion — do facts reach RGS?
Separating the layers makes Canadian AML controls easier to design, test and explain.
AML operational readiness review
Before a major payment release, compliance and technology should jointly walk one transaction through:
- client identity;
- payment classification;
- travel-rule data where applicable;
- threshold/aggregation;
- monitoring;
- reporting record;
- retention.
Then walk one attempted suspicious transaction that never settles. If the second disappears from monitoring because the payment failed, the architecture has a material evidence gap.
Reporting continuity
Maintain a tested way to identify all reports due during:
- reporting gateway outage;
- source-feed outage;
- planned maintenance.
After recovery, reconcile from source payment population rather than relying on the last processed sequence alone.
Regulatory data ownership
Assign named owners for:
- customer identity;
- beneficiary;
- payment classification;
- FX conversion;
- report rules;
- submission.
Most recurring reporting defects are ownership defects disguised as data defects.
Payment-channel implementation patterns for AML
Different channels should converge onto one compliance event model.
Branch wire
Capture:
- employee/branch;
- customer identity;
- source of instruction;
- beneficiary;
- purpose;
- amount/currency.
The branch should not manually decide whether an EFTR is required. It should provide the data; central classification applies the legal rules.
Corporate portal
Corporate files may contain hundreds of transactions.
Compliance processing should:
- preserve file identity;
- classify each relevant payment;
- retain corporate user/approval context;
- aggregate transactions where current FINTRAC rules require.
A single corporate file can contain both reportable and non-reportable transactions.
API and host-to-host
Machine channels need:
- reliable legal-entity identification;
- customer/account mapping;
- source transaction ID;
- complete beneficiary;
- durable audit trail.
An API client should not be able to omit compliance-critical data because the UI normally makes it mandatory.
Incoming correspondent payment
Separate:
- message received;
- bank's role;
- final receipt;
- beneficiary posting.
Regulatory classification should use the event that current guidance defines, not whichever timestamp is easiest technically.
AML monitoring scenario lifecycle
A monitoring scenario is a controlled production asset.
Design
Document:
- risk typology;
- population;
- logic;
- threshold;
- data;
- exclusions.
Validation
Use:
- known historical cases where permitted;
- synthetic examples;
- false-positive sample;
- segment analysis.
Deployment
Record:
- version;
- approval;
- effective date.
Monitoring
Track:
- alert volume;
- case conversion;
- STR conversion;
- data missingness;
- investigator feedback.
Retirement
A scenario that no longer addresses current risk should be retired under governance rather than left generating noise indefinitely.
AML case handoff to payment operations
Compliance may need payment operations to:
- confirm final state;
- retrieve message;
- explain return;
- identify beneficiary bank.
The request should quote:
- payment ID;
- date;
- amount;
- reference/UETR.
Payment operations should provide facts, not determine whether RGS exists.
Example
AML asks:
"Did this CAD 40,000 wire settle?"
Operations:
"Settled at 14:05 with PCRN X; beneficiary agent Y."
Compliance then incorporates that fact into its analysis.
Regulatory reporting data correction policy
Payment data can be corrected after initial capture.
Examples:
- customer address updated;
- beneficiary address repaired;
- amount corrected before release.
Define which value a report requires:
- value at transaction;
- corrected authoritative value;
- current client data;
according to current form/guidance.
Store:
- original;
- corrected;
- report value;
- rationale.
Do not silently overwrite historical facts.
Testing legal-entity routing
A shared payment platform may serve several bank entities.
Test:
- customer of Entity A does not generate Entity B report;
- report credentials/submission entity correct;
- aggregation does not improperly combine legal entities where obligations are separate;
- records stored under correct entity.
Legal-entity errors can be more serious than field-format errors because they misidentify who had the reporting obligation.
Operational dashboard for compliance reporting
A daily dashboard can show:
EFTR
- due today;
- accepted;
- rejected;
- overdue.
24-hour
- aggregates open/triggered;
- data exceptions.
STR
- cases with RGS reached but report pending;
- aging from RGS.
Data
- missing mandatory fields;
- failed FX conversions.
System
- source feed status;
- submission gateway.
Dashboard figures should reconcile to the regulatory-event ledger.
AML release readiness sign-off
Before production:
- payment taxonomy approved;
- FINTRAC EFT classification tested;
- travel rule tested;
- KYC triggers tested;
- threshold/aggregation tested;
- monitoring feed reconciled;
- report generation/submission tested;
- records/retention verified;
- operations trained;
- outage/backfill rehearsed.
This sign-off makes compliance part of the payment product rather than a downstream reporting project.
11. Practical Canadian AML/payment scenarios
Scenario 1 — international wire above threshold
A Canadian corporate sends CAD 85,000 equivalent to a supplier abroad.
The bank:
- obtains required client information;
- keeps the EFT record;
- performs applicable sanctions controls;
- carries travel-rule information;
- files the EFTR within required timing;
- continues suspicious-activity monitoring.
No suspicion exists, so no STR is required merely because the amount is large.
Scenario 2 — suspicious small transactions
A new account receives multiple small credits and then attempts to send funds internationally to unrelated beneficiaries.
None individually reaches CAD 10,000.
Monitoring identifies:
- pass-through pattern;
- inconsistent customer activity;
- multiple unrelated senders.
Compliance may reach reasonable grounds to suspect and file an STR despite no threshold report.
Scenario 3 — payroll
A company sends domestic direct-deposit payroll through AFT.
Although electronic in ordinary language, FINTRAC's EFT definition excludes direct deposit.
The bank still applies its compliance program, ongoing monitoring and STR obligations when suspicion arises. It does not file an EFTR merely because payroll was electronic.
Scenario 4 — 24-hour aggregation
A customer requests three international EFTs of CAD 4,000 each within the applicable aggregation window. The same requester is known for all three transfers.
The bank's aggregation logic identifies CAD 12,000 total and applies current FINTRAC requirements.
The control must use the actual aggregation criteria, not a simplistic single-transaction threshold.
Scenario 5 — attempted suspicious transaction
A customer requests a transfer but abandons it when normal verification questions are asked. Other facts and linked activity create reasonable grounds to suspect.
An STR can be required for an attempted transaction.
Payment status CANCELLED does not mean compliance case CLOSED.
12. Key takeaways and authoritative references
Key takeaways
- FINTRAC EFT is a legal/regulatory term with specific inclusions and exclusions.
- Direct deposit and PAD are excluded from the FINTRAC EFT definition.
- Applicable EFT records begin at CAD 1,000 in important payment contexts.
- International EFT reporting generally triggers at CAD 10,000, including applicable 24-hour aggregation.
- EFTR timing is five business days after initiation or final receipt.
- STRs have no monetary threshold.
- STRs cover completed and attempted transactions.
- STRs are filed as soon as practicable after the RGS threshold is established.
- Ongoing monitoring is risk-based and must connect activity to client context.
- Payment state and regulatory-report state must be separate.
- Fraud, AML and sanctions investigations can share evidence without becoming the same control.
Authoritative references
This chapter is educational. The PCMLTFA, associated regulations and current FINTRAC guidance are authoritative for compliance decisions.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.