FINTRAC Report Corrections: When to Change, Delete or File a New Report

Introduction

Your compliance team submits a suspicious transaction report at 2 PM on a Tuesday. By Wednesday morning, someone notices the transaction amount is wrong by $50,000. Or a key detail about the client's beneficial owner was incomplete. Or the report was submitted twice by accident. These scenarios happen regularly — and knowing the right response makes the difference between a compliant correction and a missed deadline.

When you discover an error in a FINTRAC report after submission, the correct action depends on the specific problem, the report type, and your submission method. You may need to change the existing report, delete it outright, or submit a separate new report entirely. This distinction matters, because the wrong choice can leave FINTRAC with incomplete information or leave your organization exposed to compliance gaps.

This guide walks through the practical steps to identify which action is appropriate, how to execute each one, and how to maintain the documentation that regulators expect to see.

Quick Decision Table: Corrections, Deletions and New Reports

When to Change a Submitted FINTRAC Report

Changing (or "correcting") a report means you identify it by its original reference number, modify the information that was inaccurate or incomplete, and resubmit it to FINTRAC. The report keeps its original reference and submission date, but now carries corrected data.

You should change a report when:

• The transaction details contain errors — such as an incorrect amount, wrong date, incorrect account number, or misidentified currency.
• Mandatory information was omitted — for example, the client's full name, address, date of birth, identification type, or identification number was left blank or abbreviated.
• Names, addresses, or identification details need updating — if you initially reported a client's address as incomplete and later verified the full postal code or apartment number.
• The STR narrative requires clarification or correction — you initially described the suspicion one way, but further investigation revealed additional facts that strengthen or alter your reasoning.
• FINTRAC issues a change request — either through a formal RRFA (Reports Returned for Further Action) or through direct inquiry, asking you to correct or provide specific information.

When you submit a correction through the FINTRAC Web Reporting System, you will mark the report as a correction and typically record the reason for the change. If you submit corrections via batch (XML format), you include an ActionCode="2" (Change) and resubmit all fields with the corrected information. FINTRAC's batch instructions specify that all applicable fields must be included in the corrected submission.

The timeframe for submitting a correction depends on when you discover the error and which system you use. If FINTRAC sends an RRFA, they will specify a due date. If you discover an error on your own, you should correct it as soon as practicable — waiting months to fix a known error exposes you to both regulatory and operational risk.

When a Report Should Be Deleted

Deleting a report instructs FINTRAC to remove it from their records. This is a permanent action and should be used sparingly. Deletion is appropriate only when:

• The report is a duplicate — the same transaction was submitted twice with identical details or overlapping information.
• The report was submitted in error — you submitted a report for a transaction that, upon review, was not actually reportable under the regulations, or it was filed against the wrong customer entirely.

Do not delete a report simply because your organization later becomes uncomfortable about filing it, or because an investigation concludes the transaction was legitimate. Deletion should be reserved for genuine errors in submission, not for second-guessing the original compliance judgment.

Once deleted, a report cannot easily be recovered. Internally, you must document the reason for deletion, obtain appropriate reviewer approval, and retain that documentation for any future examination by FINTRAC. Deleting a report without proper documentation leaves you unable to explain the action to regulators if asked. Like corrections, deletions can be submitted via the FINTRAC Web Reporting System or via batch (using ActionCode="5"). The process and timeframe are similar to corrections, though the operational urgency may be higher if you've discovered a genuine error.

When to Submit a New Report

A new report has its own reference number, its own submission timestamp, and represents a separate reportable event or transaction. Submit a new report when:

• A second suspicious transaction occurs — even if it involves the same customer, if the transaction is separate and reportable on its own merits, it receives its own STR (or other report type).
• Suspicion continues after the initial report — you filed an STR weeks ago, but the customer's suspicious pattern continues. Subsequent transactions that also meet the reasonable grounds to suspect threshold should be reported as new STRs, not added retroactively to the original.
• A different report type is triggered — a large cash transaction of $10,000 is received (LCTR), and the same activity also meets the threshold for an STR. File both reports with separate reference numbers.
• The original report has already been submitted and acknowledged — if you later discover an issue with the original report, you correct it; you do not attempt to "replace" it with a new report under a different reference number.

This distinction is critical: correcting information that belonged in the original report is a change; reporting a separate transaction is a new report. Misunderstanding this boundary can result in duplicate reporting or gaps in the record.

Report-Type Examples

Suspicious Transaction Report (STR): Correction and New Reporting

A reporting entity files an STR for a client who suddenly transferred $500,000 overseas with no apparent business justification. A week later, the entity's transaction investigation team confirms the client's legal name is spelled differently than initially reported. The correction is marked on the STR form with the original submission date and time, and the corrected name is resubmitted. Separately: if the same client makes a second transfer of $300,000 a month later, and the entity again has reasonable grounds to suspect, a new STR with a new reference number is filed.

Large Cash Transaction Report (LCTR): Correction

A casino reports a series of cash deposits totaling $15,000 in a 24-hour period. The LCTR is filed listing the transactions. Three days later, the reconciliation reveals one transaction was recorded at the wrong amount — it was $3,000, not $4,000. The LCTR is corrected to reflect the accurate total of $14,000, with the original report reference maintained.

Electronic Funds Transfer Report (EFTR) and Large Virtual Currency Transaction Report (LVCTR): Different Scenarios

An EFTR is filed for an outbound wire of $50,000 to an unknown beneficiary. Upon follow-up, the beneficiary is identified and legitimate. The EFTR is corrected to include the beneficiary's name and account details. An LVCTR is filed for a virtual currency receipt of $15,000 equivalent CAD. The reporting entity's system initially recorded the recipient's wallet address incorrectly. A correction is submitted with the accurate wallet identifier.

Casino Disbursement Report (CDR): Deletion

A casino filed a CDR for a large cash disbursement, but upon audit, discovered the transaction was duplicated in the submission. One CDR is deleted; the other is retained.

Correcting an STR: Specific Considerations

STRs warrant particular attention because the threshold and narrative are central to the report's value to FINTRAC. Missing or inaccurate information in an STR — whether in the transaction details or the narrative explaining your suspicion — should be corrected promptly. A vague narrative that later becomes clear through investigation should be updated so FINTRAC has the full picture.

The reason for the change may be recorded in the correction submission, especially if you use the FINTRAC Web Reporting System. If FINTRAC has issued an RRFA requesting clarification, your response is time-limited. FINTRAC will provide a due date in the RRFA notice; you must meet that deadline.

A common mistake is attempting to replace a filed STR with a new one when subsequent transactions occur. This is incorrect. If weeks after your initial STR, the same customer engages in additional suspicious activity, you file a new STR for the new transaction. You do not repeatedly "correct" or "replace" the original STR. Each suspicious transaction event gets its own report. If a suspicious transaction also triggers a threshold report — for example, a large cash transaction that is also suspicious — you file both the STR and the LCTR (or EFTR, LVCTR) as separate reports with separate reference numbers. Correcting one does not automatically correct the other.

Submission Method Matters: API vs. Web Reporting System

Your organization likely uses either the FINTRAC API report submission (for higher-volume operations) or the FINTRAC Web Reporting System (for lower-volume reporting). Both methods support corrections and deletions, but the operational steps differ.

The FINTRAC Web Reporting System allows you to view previously submitted reports, edit them online, and resubmit corrections. You can mark a submission as a correction and typically add a comment explaining the change. User permissions determine who can create, edit, and approve corrections. The system provides immediate acknowledgements upon resubmission.

FINTRAC API report submission requires you to send corrected reports in XML or JSON format through your system integration. For changes, you include all relevant fields with the corrected information and specify an ActionCode. For deletions, you include minimal header information with the delete action code. Your system receives an acknowledgement message indicating acceptance or rejection. Bulk corrections can be submitted in a single batch file.

If you use batch submissions for one report type but the Web Reporting System for another, corrections must follow the same method for each type. You cannot mix methods for the same report type.

Internal Correction Workflow

A systematic workflow protects your organization and creates an audit trail that regulators expect to see.

1. Identify the issue. Someone discovers an error: a typo in the transaction amount, a missing client detail, a duplicate submission, or a FINTRAC RRFA requesting clarification. Document the discovery — when it was found, who found it, and what the problem is.
2. Confirm the original report. Pull the original submission. Record its reference number, submission date and time, and current status in your system.
3. Decide: change, delete, or create new. Apply the logic outlined earlier. Document your reasoning. If there's any doubt, consult your MLRO or compliance officer.
4. Record the reason. Write a brief, clear reason: "Correction: Client's middle initial was missing and has been added." or "Deletion: Report was duplicate submission of reference [original ref]."
5. Obtain reviewer approval. Your MLRO or designated reviewer approves the action in writing or via system workflow.
6. Submit the action. Submit the correction or deletion through your reporting channel (Web Reporting System or API).
7. Capture the acknowledgement. FINTRAC will send an acknowledgement confirming receipt. Save this file or screenshot in your audit trail.
8. Update your internal reporting register. Log the correction in your transaction reporting register or AML database: original reference, date corrected, nature of correction, approver, and acknowledgement received.
9. Review for cascading effects. Ask: did this transaction trigger other reports? If you corrected an amount in an STR, does a related LCTR or EFTR also need updating?

Evidence to Retain

FINTRAC may request documentation of your reporting and corrective actions during an examination. Retain:

• The original submitted report — saved as it was when first filed, including the original reference number and timestamp.
• The corrected version — showing the updated information.
• Reason for the correction — a note or comment documenting why the change was necessary.
• Reviewer and approval records — initials, signature, date, or system audit log showing who approved the correction.
• FINTRAC's submission acknowledgement — confirming the correction or deletion was received.
• FINTRAC RRFA or change request (if applicable) — if FINTRAC asked for the correction, save that notice.
• Related transaction records — the underlying banking or transaction documents that support the corrected information.
• Date discovered — when the error was identified.
• Date corrected — when the correction was submitted to FINTRAC.

Common Mistakes to Avoid

• Creating a new report when the original should be changed. If you discover that a client's address was wrong on an STR filed three weeks ago, you correct the STR. You do not file a brand-new STR with a different reference number. Doing so creates a duplicate reporting event and confuses the audit trail.
• Deleting a report without documenting the reason. If you delete a report because it was a duplicate or submission error, you must record this internally. A deletion with no supporting documentation raises questions during an examination.
• Reusing the same report reference incorrectly. If you correct a report, its reference number stays the same. Do not attempt to re-assign the same reference number to a different transaction.
• Failing to report subsequent suspicious transactions. If you file an STR and later the same customer engages in new suspicious activity, you must file a new STR. Burying the new activity inside a comment or narrative revision to the old STR is non-compliance.
• Correcting the threshold report but not the related STR (or vice versa). If a single transaction triggered both an LCTR and an STR, and you discover an error in the amount, both reports may need correcting.
• Losing the acknowledgement or correction history. System shutdowns, staff turnover, or file management failures can result in lost evidence. Implement a backup protocol to preserve critical documents.
• Assuming a system warning or error message means the report was rejected. Sometimes systems generate warning messages but still accept the report. Always confirm acceptance via the official acknowledgement.

FINTRAC Report Correction Checklist

• ☐ Error or issue identified and documented (date, discoverer, description)
• ☐ Original report reference number and submission date confirmed
• ☐ Decision made: Change / Delete / File New Report (documented)
• ☐ Reason for action recorded in clear language
• ☐ MLRO or compliance reviewer has approved the action
• ☐ Correction submitted via appropriate method (Web Reporting System or API batch)
• ☐ FINTRAC acknowledgement received and filed
• ☐ Internal reporting register or AML database updated with correction details
• ☐ Related reports reviewed for consistency (e.g., LCTR + STR for same transaction)
• ☐ All evidence (original report, corrected version, approvals, acknowledgement) retained