Missed FINTRAC EFTRs? How to Identify, File and Remediate a Reporting Backlog

Missed EFTR reporting does not resolve itself with time. If you find reportable international electronic funds transfers that never reached FINTRAC, the reporting obligation still stands. Stop the cause, rebuild the full affected population from source records, and re-test each transaction against the EFTR rules. File every outstanding report as soon as it is complete, consider a voluntary self-declaration of non-compliance, and fix the control that failed. Filing late does not erase the original breach, but a well-documented remediation is what FINTRAC can work with and what an examiner will later expect to see.

The response usually runs in this order:

1. Contain the failure so the backlog stops growing.
2. Scope the affected period, channels and systems, and preserve the evidence.
3. Reconcile source transactions against FINTRAC acknowledgements.
4. Re-test reportability for every unmatched transaction.
5. File and track each outstanding report until it is accepted.
6. Disclose and fix through a self-declaration and root-cause correction.

One timing point deserves early attention. For examination purposes, FINTRAC's assessment manual treats the date of its notification call as the start of the examination. If a required report is first submitted after that date, FINTRAC considers that the reporting requirement was not met. A self-declaration received during an examination is assessed as part of it, and FINTRAC then decides whether enforcement action is warranted. This does not mean filing should wait or that it becomes pointless after notification: outstanding reports still have to be submitted. It means late EFTR filing found and fixed before any examination is treated differently from the same issue surfacing during one, although filing early does not guarantee any particular outcome.

Missed, late, rejected or wrong? Classify the problem first

"Missed EFTR" covers six different situations. Each needs a different fix, and mixing them up is how a backlog turns into duplicate reports.

Accepted reports that need changing follow a separate process for correcting previously submitted FINTRAC reports. Rejections tend to share a few data causes, set out in the guide to FINTRAC report validation errors. For backlog purposes the rule is simple: a rejected report counts as unfiled, and FINTRAC examiners specifically look for rejections that were never corrected and resubmitted.

The same logic separates "submitted" from "accepted". A report your system or provider marks as sent has only been transmitted. Treat it as filed only when you hold FINTRAC's acknowledgement and report reference for it. Keep the status and the acknowledgement in separate fields of your register, so a sent report can never be counted as an accepted one by default.

Contain the gap before you reconstruct history

Rebuilding months of history achieves little if the failure is still running. Before the look-back starts:

• Put an interim control on new transfers. If the failed interface or process is still in use, add a temporary manual check, such as a daily extract of international transfers near the threshold reviewed by a named person. This keeps new transactions inside the five-business-day deadline.
• Preserve the evidence. Export source data, interface logs, provider submission logs and rejection notices as they stand. Fixes and clean-ups can overwrite the records you will need to explain the failure.
• Assign ownership. The compliance officer is responsible for implementing the compliance program and should own remediation decisions. Record who decides reportability, who approves filings and who signs off on the declaration. Escalate the scope, the likely disclosure and the resourcing need to senior management early, and keep a dated record of that escalation.
• Check your examination status. If FINTRAC has already called about an upcoming examination, tell the FINTRAC officer immediately.

Reconstruct the population of potentially reportable transfers

FINTRAC tests EFTR completeness by asking for a list of international transfers drawn from your own records, then comparing it with the reports in its database. Mirror that method. Start from source transactions, not from the reports you believe you filed.

The sources usually include the core ledger, customer instruction logs, payout partner and processor files, bank statements, branch and agent logs, reporting-system queues and drafts, and Web Reporting System or API submission history. Where a service provider files for you, add its submission logs.

A workable reconciliation workflow

1. Set the review period. Start at the earliest date the root cause could have operated, such as a system change or a new agent, not the discovery date. End it when your containment control took effect.
2. Extract every international EFT in both directions, one row per transaction, with a stable identifier.
3. Normalize timestamps to your 24-hour window's time zone, and record original currency, amount, exchange rate and rate source.
4. Match source to reports using report reference numbers, transaction reference numbers and acknowledgement status.
5. Match reports back to source to expose duplicates and reports filed against the wrong transaction.
6. Classify each unmatched or uncertain item into one of the six states above.
7. Re-test reportability for those items and record the outcome and reason for each.
8. Have a second person review a sample of the "not reportable" conclusions.
9. Keep transaction counts and report counts separate. A single large transfer that is not aggregated produces one report. An aggregated group of several transfers produces one report for its aggregation type, and the same transfers can appear in more than one report when they qualify under different aggregation types. Your summary should therefore show transactions reviewed, transactions reportable and reports to be filed as three different numbers.

For multi-location businesses, run steps 2 to 5 per branch and per agent before consolidating. Gaps often sit in a single channel, and channel-level results make the root cause easier to see and to document.

Data problems to expect

• Missing references. Build a composite match key from date and time, amount, currency, client and counterparty. Document the rule and flag low-confidence matches.
• Conflicting records. For initiation, the relevant moment is when you initiated the transfer. For final receipt, it is when you received the instructions, which can precede payout. Settlement dates do not trigger the report.
• Time zones. EFTRs require 24-hour window start and end times with a UTC offset. Convert branch and agent times before grouping anything.
• Historical exchange rates. Use the Bank of Canada rate in effect at the time of each transaction, not today's. Where none is published, use the rate you set in the normal course of business at that time.
• Fees. An initiation amount excludes your fees. A final receipt amount is before fees charged to the beneficiary. Getting this wrong can move a transfer across the threshold.
• Client relationships. Duplicate client profiles across branches or apps hide the links aggregation depends on. Resolve them first and record how.

Re-test reportability before you file anything

The full framework is set out in the guide to FINTRAC EFTR reporting rules, and FINTRAC's EFT reporting guidance is the authority to test against. The questions below are the ones that most often change a backlog count.

Was it an international EFT?

Direct deposits, pre-authorized debits, cheque imaging and certain clearing, settlement and intra-group treasury transfers fall outside the definition of an EFT. An international EFT is one that is not a transfer of funds within Canada, so a large domestic transfer does not belong in the backlog.

An MSB that both initiates and finally receives the same transfer decides this using the residential status of the requester and beneficiary. If both are in Canada, nothing is reportable. If one is in Canada and the other is not, a report is due. If both are outside Canada, an MSB reports both the initiation and the final receipt. Foreign MSBs apply a different table.

Initiator, final receiver or intermediary?

Initiation is the first transmission of instructions at the request of a person or entity. Final receipt is the receipt of instructions by the entity that is to remit to the beneficiary. An intermediary files no EFTR but must keep records and pass on travel rule information.

Two errors recur. Routing funds through a bank or payment partner does not displace your own obligation as initiator or final receiver. And transfers your agents conduct on your behalf are your reports, not theirs.

Threshold and 24-hour aggregation

A single international EFT of $10,000 or more, converted to Canadian dollars, is reportable. Two or more smaller transfers become reportable together when they fall within a static 24-hour window, total $10,000 or more, and you know they are linked. For initiations, the link is the same requester, the same party on whose behalf they were requested, or the same beneficiary. For final receipts, it is the same requester or beneficiary.

When rebuilding groups, use your documented window, keep each transaction in one window only, aggregate SWIFT and non-SWIFT together, never combine incoming with outgoing, and look across all locations and agents. The exceptions for public bodies, very large corporations or trusts and regulated pension fund administrators do not cover any individual transfer of $10,000 or more.

Look-backs that reach before mid-2024

The aggregation rules applicable to a historical transaction are those in force at the time it occurred, not the date your business changed its systems. FINTRAC's 24-hour rule guidance explains that the regulatory change of June 1, 2021 could not be applied to EFTRs until FINTRAC released a new EFTR form. Until then, entities were told to continue aggregating EFTs under FINTRAC's earlier policy interpretation. Under that approach, sub-$10,000 transfers were aggregated together, and transfers of $10,000 or more were reported separately. FINTRAC announced completion of the modernized EFTR implementation and published updated EFTR guidance on June 24, 2024. Parts of the 24-hour rule page still carry that transitional language, so for current transactions rely on the EFT guidance itself.

If your backlog includes transfers from before the new form became available, document which aggregation approach you applied to them and why. Where the treatment of transfers near the transition is unclear, raise it with FINTRAC rather than assume.

Every "not reportable" conclusion needs a short recorded reason, such as "both parties in Canada" or "intermediary only". Without them, the reconciliation cannot be verified.

Triage, approve and file the outstanding reports

Prioritize without stalling

Every confirmed missing report is already late, so do not hold filings for a perfect batch. File confirmed reports with complete data first. Recover data for the rest in parallel and file each as it is completed. Resolve unconfirmed-status items with the channel or provider before refiling, and close out items still under review with a documented decision. Target dates for these tiers are internal commitments, not statutory deadlines, and the register should say so.

Filling historical data gaps

FINTRAC's EFTR field instructions use four categories, and each one treats missing information differently:

There is one narrow exception that matters for backlogs. An EFTR can aggregate several transactions within 24 consecutive hours. When the information for a mandatory field was not obtained at the time of those smaller transactions, that field is treated as a reasonable-measures field. The exception does not apply if any transaction in the report is $10,000 or more on its own. FINTRAC describes this exception for mandatory fields only. Nothing in the guidance extends it to mandatory-for-processing or mandatory-if-applicable fields.

In practice, a large backlog is rarely missing information that was never collected. More often the data exists but sits in a payout partner's file, an agent's system or a scanned form. Check those sources before concluding anything is unavailable. Where reasonable measures genuinely apply, keep a record for each report of:

• the field concerned
• the sources searched
• the client or counterparty contact attempts and their dates
• the outcome
• who approved filing without the information

Never enter "N/A", "unknown" or placeholder characters, since FINTRAC requires inapplicable fields to be left blank. A gap in one report should not hold up the others.

Submission and acknowledgement tracking

EFTRs are filed through the FINTRAC Web Reporting System or FINTRAC API report submission, with paper reserved for entities without electronic capability. The API limits differ by endpoint, which matters when sizing a backlog:

• Single-report endpoint: up to 500 transactions per report, within a 25 MB file.
• Bulk submission: up to 5,000 reports per file and up to 5,000 transactions per report, within 300 MB.

The practical limit depends on how much data each report carries. If a report would exceed its limit, the additional transactions go into a new report, linked by a suffix on the report reference number. The wider channel choice is covered in a comparison of FINTRAC API and Web Reporting options. For a backlog, the question is which channel lets you file accurately now. Keying hundreds of reports by hand raises error rates, but an enrolment project should not delay filing.

Whichever channel you use, give every report a unique reference number that traces back to the source identifier. Track each submission to an acknowledgement, because a transmitted report is not an accepted one. If a provider files for you, confirm reports carry your reporting entity information, not the provider's. Keep a copy of each EFTR for at least five years from the date the report was created. For a late report, the period runs from when the report was created, not from when the transfer occurred. This requirement covers the report copy only. It is separate from your obligations to keep records of the transfers themselves and of client identification.

A maker-checker review before submission is a sensible internal control for a backlog, but it is your control, not a legal requirement.

Voluntary self-declaration of non-compliance

FINTRAC's EFT guidance directs entities that discover EFT reporting non-compliance to its voluntary self-declaration of non-compliance process and strongly encourages its use. FINTRAC also stresses that unreported transactions keep their intelligence value, so a declaration never replaces filing.

What FINTRAC asks for

The guidance asks a written declaration to include:

• the reporting entity's name and the submitter's contact details
• for reporting issues, the number and type of reports affected, the period, and why they were not submitted, were late or were incorrect
• a plan to resolve the issues and submit all outstanding or incorrect reports, with measures and timelines

FINTRAC asks for that information only. Do not include client or employee personal information. If it is genuinely needed, say so in your email and FINTRAC will advise how to send it securely.

What it does and does not do

FINTRAC says it will work with you to resolve the issue when the declaration does not repeat an earlier one and was not made after notification of an upcoming assessment. It also weighs each case on its circumstances. Nothing in the guidance promises that a declaration prevents a penalty.

Historical backlogs also cross a legislative boundary. The Strengthening Canada's Immigration System and Borders Act (Bill C-12) received Royal Assent on March 26, 2026. It introduced a new administrative monetary penalty framework under the PCMLTFA. The framework raises maximum penalties, adds ability to pay as a factor, requires compliance agreements for prescribed violations and adds compliance orders as a new tool.

FINTRAC's explanation of the changes says the new requirements apply to violations that occur after March 26, 2026. For violations that occurred entirely before that date, it continues to use its existing penalty policy, amounts and processes. FINTRAC also scopes examination review periods so that each falls within a single framework.

A backlog that spans the date may therefore involve both frameworks. Record each missed report's original deadline in your register so the split is clear. Do not assume either that the new maximums apply to every missed report, or that older violations are excused. How FINTRAC treats any specific case remains its decision.

The guidance sets no deadline for a declaration, and because it expects a filing plan, you need not wait until every report is filed. Send it once you can state the scope with confidence. Updating FINTRAC if the scope later changes materially is sensible practice, though not a stated requirement.

A practical outline

Where the backlog is large, the cause is unclear, or the declaration must sit alongside other findings, AML remediation and advisory support can help scope the review and build the plan before anything goes to FINTRAC.

Worked examples

Both examples are hypothetical and simplified.

Example 1: A report that never left draft

On Tuesday, August 18, 2026, a Toronto remittance MSB initiates a $14,200 CAD transfer to the Philippines at a client's request. The report is prepared, but the assigned reviewer goes on leave and it stays in draft.

• Trigger and deadline: The MSB initiated an international transfer of $10,000 or more, so the report was due within five business days, by August 25.
• Discovery: The September month-end reconciliation, completed on September 30, finds the transfer with no acknowledgement.
• Classification: No submission exists, so this is a missing report, not a rejection or a correction.
• Scope check: A search of every draft and unapproved report across the review period finds no other overdue items, which supports treating it as isolated.
• Filing: A backup approver reviews the report, it is filed, and the acknowledgement is recorded against the transaction.
• Control fix: Approval routing now reassigns drafts automatically when a reviewer is absent.
• Disclosure: The compliance officer sends a short declaration covering the one report, its cause, the filing date and the control change.

Example 2: Unseen rejections and an unmapped agent channel

In 2026, a multi-location MSB's external provider has its EFTR submissions rejected for nine weeks after a schema update. The rejection notices go to an unmonitored shared mailbox. Separately, one agent location runs a standalone system that never fed the central ledger.

The team extracts all transfers flagged as potentially reportable across the affected systems for the nine weeks: those at or above $10,000, plus smaller transfers linked to a requester, third party or beneficiary in the same window. They then test whether each transfer is truly international and whether the MSB has an initiation or final-receipt reporting obligation. That gives 227 transactions to review: 186 individually at or above $10,000, and 41 smaller ones.

• Overlap check: The team confirms that none of the 58 large transfers falls in the same window as a group for the same party. Each is therefore filed in its own report.
• Re-filing the rejected reports: The 58 rejected reports already contained complete data and only needed reformatting for the new schema.
• Missing data in the aggregated groups: Two of the six group reports had beneficiary information missing for agent-channel transfers. The team recovered the required details from the agent's payout records rather than treating them as unavailable. For each remaining gap, it checked the field's category in FINTRAC's field instructions. One gap was in a field the instructions classify as reasonable measures. The team recorded its search of agent records and two dated client contact attempts, and the compliance officer approved filing that report without the item. Every report is filed with all mandatory, mandatory-for-processing and applicable mandatory-if-applicable fields completed.
• Declaration: It states 64 reports covering 75 transactions, both causes, the period and a dated filing plan.
• Control fixes: Rejection alerts now go to named staff, the agent system feeds the ledger, vendor terms guarantee access to submission logs, and any schema change requires a reporting impact check.

Remediation evidence and governance

A backlog register ties the work together. Keep one row per transaction with these fields, adapted to your systems:

Senior compliance staff use the register to report progress to senior management, to support the self-declaration, and to answer an examiner who later tests whether past reporting issues were fixed, which the assessment manual describes as a specific test. It also gives the next effectiveness review something concrete to test.

Backlogs often reveal that nobody had the time or authority to watch reporting. If that is the real gap, ongoing compliance officer oversight belongs in the remediation, not in a separate project.

Preventing another reporting backlog

Remediation addresses the past; prevention stops the gap reopening. Since March 26, 2026, the PCMLTFA requires compliance programs to be reasonably designed, risk-based and effective, which is hard to claim for a process that can fail silently for weeks. The controls that matter most:

• Transaction-to-report reconciliation at a frequency matched to volume, the same completeness test FINTRAC applies.
• An exception queue with ageing, so unreported items become more visible as deadlines approach.
• Rejection monitoring routed to named people and tracked to resolution.
• Change management with a reporting impact check before any schema change, migration, new corridor, product or agent.
• Full channel coverage, so every source of international transfers feeds reportability testing.
• Vendor oversight, including log access, confirmation that reports carry your entity information, and output testing. You stay legally responsible for provider submissions.
• Quality assurance and training on initiation, final receipt and aggregation edge cases.
• Independent testing in your two-year effectiveness review of reporting completeness and timeliness, not just procedures on paper.

Frequently asked questions

Does a transfer that was later returned or cancelled still need an EFTR?

It depends on whether the transfer was initiated. FINTRAC's guidance says a returned EFT does not affect the original initiation, which must be reported whether the transfer completed or came back. Initiation, however, is the first transmission of instructions. If a client cancelled before any instructions were transmitted, there was no initiation to report. Keep both kinds of item in the reconciliation population. For cancellations, keep evidence of the timing, such as message logs showing that nothing was sent. Cancelled requests remain relevant to suspicious transaction monitoring, because an STR can cover attempted transactions.

Should the backlog review also consider suspicious transaction reporting?

Yes. Reviewing historical transfers together can reveal patterns invisible one at a time, such as linked beneficiaries or structuring. An EFTR does not satisfy the separate STR obligation, and where reasonable grounds to suspect arise, the STR must be submitted as soon as practicable, ahead of the threshold backlog.

If a missed transfer was funded in cash or virtual currency, is another report missing too?

Possibly. FINTRAC's guidance gives the example of a client who provides $10,000 or more in cash and asks you to initiate an international EFT. That requires both a Large Cash Transaction Report and an EFTR. The same pairing applies to a Large Virtual Currency Transaction Report where the funding was in virtual currency. The assessment manual tests for both reports together. When the reconciliation finds a missed EFTR, check the funding leg of the same transaction against your LCTR or LVCTR records before closing it.

If your backlog started with fragmented data, missed aggregation or untracked rejections, ComplyFactor provides FINTRAC reporting workflow support, including report-specific validation, maker-checker review, submission and acknowledgement tracking, and advisory help with reporting backlog remediation. Reporting decisions and legal responsibility remain with your business.