The identification documents a FINTRAC intake process produces don’t stop being sensitive once the deal closes. Two federal laws govern what happens to them afterward — FINTRAC on how long they must be kept, PIPEDA on how they must be protected and what happens if they’re exposed — and the two obligations run on different clocks.
Key takeaways
The retention clock isn’t the same for every record type, and getting the start date wrong is the common mistake. FINTRAC’s own guidance sets the period at five years across every category, but the trigger differs: a Suspicious Transaction Report copy must be kept “at least five years after the day it was submitted,” while large cash transaction records and receipt-of-funds records run five years “from the date… created.” The category that covers most day-to-day client identification is the information record, and its clock is different again — “five years from the day the last business transaction was conducted” with that client, not five years from when the file was first opened. A repeat client you’ve worked with over several transactions keeps that clock resetting with each new deal, which means the identification documents in an active client’s file may need to be retained well beyond a single transaction’s own closing date.
FINTRAC sets how long to keep the documents; PIPEDA sets how they must be protected while you do. The safeguards principle is one of PIPEDA’s ten named fair information principles, and the standard scales with sensitivity — the more sensitive the information, the stronger the protection required. A government-issued photo ID, a SIN if one was genuinely collected, or a full financial profile all sit well inside “sensitive” by any reasonable read of that standard. In practice, that means access controls limiting who in a brokerage can view a client’s ID documents, secure storage rather than a shared drive with broad access, and a deliberate decision about how long digital copies persist beyond what FINTRAC’s retention clock actually requires — keeping documents indefinitely “just in case” extends the safeguarding obligation and the breach exposure well past the point any law requires it.
PIPEDA doesn’t leave breach response to judgment calls — it’s a codified duty, and the trigger is specific. Section 10.1(1) of the Act requires that “an organization shall report to the Commissioner any breach of security safeguards involving personal information under its control if it is reasonable in the circumstances to believe that the breach creates a real risk of significant harm to an individual,” with the same trigger requiring notice to the affected individual under s.10.1(3). The regulations spell out exactly what that individual notification has to contain: a description of the circumstances of the breach, the date or period it occurred, a description of the personal information involved, the steps taken to reduce the risk of harm, steps the individual can themselves take, and contact information for follow-up questions (Breach of Security Safeguards Regulations, s.3) — a generic notice that information may have been affected, with none of those six elements, does not meet the standard. “Significant harm” isn’t left undefined — the Act itself lists it as including “bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft, negative effects on the credit record and damage to or loss of property.” A stolen laptop holding client ID documents and financial details is a textbook fit for that standard — identity theft and financial loss are both named outright.
Timing has a real but flexible standard: report “as soon as feasible after the organization determines that the breach has occurred,” which is not a fixed number of days but is also not a licence to sit on a known breach while deciding what to do. The penalty for knowingly ignoring the reporting duty is real: s.28 sets a fine up to $10,000 on summary conviction or up to $100,000 on indictment — figures that sit entirely separate from FINTRAC’s own penalty regime, so don’t assume one compliance framework covers the other.
A breach too minor to trigger the reporting duty still isn’t a non-event under the Act. Section 10.3 requires an organization to “keep and maintain a record of every breach of security safeguards involving personal information under its control” — every one, not only the ones that clear the significant-harm threshold — and the prescribed regulation sets that log’s own retention period at 24 months from the date the breach was determined to have occurred. A lost, unencrypted phone that’s recovered five minutes later with no evidence of access might not meet the reporting bar, but it still belongs in a breach log kept for two years, documenting what happened and why it wasn’t reported.
A practical retention and safeguarding routine
Store client ID documents somewhere access-controlled, not a shared inbox or an unsecured folder. Track each client’s last transaction date, since that’s the trigger for the five-year FINTRAC clock on their information record — not the date the file was created. Keep a simple breach log ready before you ever need it, since every incident, however minor, has to be recorded for 24 months regardless of whether it clears the reporting threshold. And review what’s still on file periodically — documents held years past both the FINTRAC retention period and any legitimate business purpose are pure exposure with no offsetting benefit.
This retention and safeguarding obligation is exactly why the collection discipline covered in collecting only what you actually need matters in the first place — every document you hold is something you now have to protect and eventually account for, for years.
Yes, effectively — the information record retention period runs “five years from the day the last business transaction was conducted” with that client, so each new transaction with a returning client extends the clock rather than starting a separate one.
The Act names specific categories — bodily harm, humiliation, damage to reputation, financial loss, identity theft, and damage to the credit record among them — and the test is whether the breach creates a real risk of one of these, assessed in context (the sensitivity of the information, and the probability it will be misused).
Those three provinces have their own substantially similar privacy statutes that generally govern intra-provincial commercial activity instead of PIPEDA — see the OPC’s own note on this. The specific breach-reporting mechanics may differ under the provincial statute; confirm the applicable regime before assuming PIPEDA’s exact sections govern in one of those three provinces.
A short call can help you set up a compliant storage and breach-response process.
