Key takeaways
- OPC approval is mandatory before any personal information is shared between reporting entities.
- FINTRAC must receive a copy on the same calendar day the code is submitted to the OPC.
- RPAA registration does not equal PCMLTFA reporting entity status — eligibility must be confirmed independently.
- Information sharing does not replace STR obligations — each entity makes its own independent reporting decision.
- A code of practice is a living document — material changes typically require resubmission and reapproval.
Most reporting entities see only a portion of suspicious activity. A money services business observes currency conversions that appear routine on their own. A payment service provider sees wire transfers that, in isolation, appear legitimate. But when two reporting entities compare notes — when the MSB's currency transactions and the PSP's international transfers are viewed together — a pattern emerges.
This fragmented visibility is a persistent weakness in financial crime detection. Private-to-private information sharing addresses this gap. Rather than waiting for suspicious activity to surface through formal reporting channels, Canadian reporting entities can establish controlled arrangements to exchange financial-crime intelligence with peers. But this exchange must be structured and governed. Informal sharing through phone calls, emails or personal relationships is not sufficient. An approved code of practice formalises the framework, establishing the legal authority, privacy protections, participant responsibilities and oversight mechanisms that make information sharing lawful and effective.
What private-to-private information sharing means in Canada
Private-to-private information sharing is the direct exchange of financial-crime intelligence between two or more eligible reporting entities, governed by an approved code of practice. It is voluntary, confidential and subject to strict controls on use and disclosure. It operates within the PCMLTFA framework. Section 11.01 of the PCMLTFA permits the disclosure of personal information by a reporting entity to another reporting entity without the individual's knowledge or consent, provided that specified conditions are satisfied. An approved code of practice establishes and documents those conditions.
Information sharing is not a substitute for reporting to FINTRAC. Each reporting entity retains full responsibility for filing suspicious transaction reports (STRs) with FINTRAC when its own analysis establishes reasonable grounds to suspect money laundering, terrorist financing or sanctions evasion. Shared intelligence may inform that decision — but it does not replace it.
How it differs from CDD. Customer due diligence focuses on a single customer's risk profile within one institution. Private-to-private information sharing focuses on patterns and activity that cross institutional boundaries — suspicious flows that become visible only when data from multiple sources are compared. CDD is mandatory and isolated to one entity; information sharing is voluntary and collaborative.
Who can participate
Participation is limited to persons and entities that qualify as reporting entities under section 5 of the PCMLTFA. This includes money services businesses, payment service providers (where activities fall within applicable PCMLTFA definitions), banks and credit unions, trust and loan companies, securities dealers and investment firms, life insurance companies, dealers in precious metals and stones, casinos and gambling businesses, real estate professionals conducting specified activities, accountants and tax advisors conducting relevant activities, and virtual asset service providers and cryptocurrency exchanges where they meet applicable definitions.
Fintech and cryptocurrency businesses are not automatically reporting entities merely because they are regulated or licensed in Canada. A fintech platform or crypto exchange must independently assess whether its activities trigger reporting entity status under section 5. Eligibility requires careful analysis of the entity's specific business model.
PSPs under the RPAA: A PSP registered with the Bank of Canada under the RPAA is not automatically eligible. The PSP must separately determine whether it qualifies as a reporting entity under the PCMLTFA. An RPAA registration does not guarantee PCMLTFA reporting entity status. Technology vendors and service providers may support the technical operation of an arrangement but do not participate as sharing parties unless they separately qualify as reporting entities. Legal professionals must carefully consider privilege implications before any sharing arrangement involving lawyers is established.
When information sharing is useful
Consider this scenario: PSP A sees a customer rapidly converting fiat currency to cryptocurrency and immediately transferring to multiple destination addresses. PSP B, on a separate platform, sees the same customer receiving international wire transfers in one currency and re-transmitting them to a different country, with similar speed and pattern. Neither sequence is inherently suspicious at a single PSP. But when viewed together through information sharing — rapid multi-stage transfers, format shifting, cross-platform movement — the combined activity suggests potential layering. The receiving platform can then adjust monitoring, request additional documentation or determine that enhanced due diligence is required. This is how information sharing fills detection gaps that isolated monitoring cannot address.
Why an approved code of practice is required
Without a code of practice, information sharing is legally risky and operationally indefensible. A documented code provides legal authority (the statutory basis for sharing personal information without consent), a defined purpose (preventing scope creep into general intelligence-gathering), accountability (written assignment of responsibility for administration, oversight and breach response), privacy protection (documented safeguards governing access, use, retention and disposal), auditability (a clear framework for compliance teams and external examiners), incident response procedures, and defensibility if a sharing decision is questioned.
Approval process for a code of practice
- Develop the proposed arrangement. Participating reporting entities define the financial-crime risk, identify participants, confirm section 5 eligibility, and determine what information will be shared and under what safeguards.
- Prepare the code of practice. Draft to address all core components. The code must reflect current FINTRAC guidance and satisfy privacy law requirements.
- Obtain participant acknowledgement. Each participating reporting entity must formally acknowledge its commitment to the code before submission.
- Submit to the Office of the Privacy Commissioner of Canada (OPC). The OPC assesses whether the code satisfies the statutory and regulatory conditions for sharing personal information without knowledge or consent.
- Provide to FINTRAC on the same day. On the same calendar day the code is submitted to the OPC, a copy must also be provided to FINTRAC.
- Do not begin sharing before approval. Personal information must not be shared until OPC approval is formally obtained.
- Respond to clarification requests promptly. The OPC may request additional information about privacy safeguards, security controls or retention provisions.
- Implement approved controls before sharing begins.
- Address material changes. Changes such as adding a new category of information, including a new participant, or altering security controls typically require resubmission to the OPC.
- Plan for reapproval. Approved codes are not permanent. Confirm the applicable reapproval timeline with the OPC as part of your implementation plan.
Core components of the code of practice
Purpose and defined scope. State the specific financial-crime risk or AML/CTF objective the arrangement addresses. The purpose statement defines the boundaries and prevents scope creep into unrelated information uses.
Eligible participants and responsibilities. List the specific reporting entities that may participate. Specify responsibilities of each participant: accuracy of information before sharing, timely notification of changes, compliance with security standards, participation in training and audits, and reporting of breaches or misuse.
Categories of information that may be shared — specified with precision: customer names, aliases, dates of birth and identification numbers; transaction amounts, dates, sources and destinations; beneficiary information; customer risk assessment ratings; specific typology indicators or patterns; aggregated or de-identified transaction data.
Information that must not be shared — explicitly prohibited: information subject to legal privilege; trade secrets; information obtained from law enforcement under confidentiality restrictions; employee personal information; information that cannot be lawfully shared under privacy or other law.
Permitted and prohibited uses. Permitted: detection and analysis of potential money laundering, terrorist financing or sanctions evasion; enhancement of customer risk assessment and transaction monitoring. Prohibited: competitive intelligence, marketing, credit assessment, customer disputes, litigation, or disclosure to external parties without written consent.
Accuracy and correction procedures. Processes for assessing source reliability before sharing, and for notifying affected participants and correcting errors discovered after sharing.
Privacy and data-minimisation controls. Share only the minimum information necessary. Technical controls: encryption, access logging, user authentication. Limit access to staff with legitimate need-to-know. Require confidentiality agreements.
Information security and access controls. Secure database or portal; multi-factor authentication; encryption in transit and at rest; separate storage from general customer files; logging of all access with timestamps and user identifiers; restrictions on download or export without documented justification.
Recordkeeping and audit trails. Every instance of sharing, access and use must be documented. Access logs enable compliance verification and support breach response.
Retention and secure disposal. Define retention periods based on relevance to the identified risk and applicable legal requirements, and how shared information will be securely deleted or destroyed — including what happens if a participant withdraws.
Complaints and breach response. Procedures for handling complaints about accuracy or use of shared information; a mechanism for disputing and correcting records; defined investigation and resolution timelines.
Oversight, monitoring and review. Regular internal compliance reviews; periodic audits of access logs and information use; documented corrective actions; annual meetings of participating entities to discuss emerging issues and regulatory changes.
Privacy conditions for sharing without knowledge or consent
Section 11.01 of the PCMLTFA permits disclosure without knowledge or consent only where all of the following conditions are satisfied simultaneously — failure to satisfy any one means disclosure cannot proceed without consent:
- Lawful authority: disclosure occurs under an approved code of practice established in accordance with PCMLTFA requirements.
- Personal information: the information was collected by the reporting entity during its normal activities.
- Reasonable purpose: disclosure is reasonable for detecting or deterring money laundering, terrorist financing or sanctions evasion.
- Risk to detection or deterrence: seeking the individual's knowledge or consent would compromise or impede that detection or deterrence.
- Approved safeguards: the code establishes privacy and security safeguards appropriate to the sensitivity of the information.
Many reporting entities include a statement in their privacy policies explaining that information may be shared with other financial institutions for AML/CTF purposes under an approved code of practice — demonstrating accountability even though explicit consent is not required.
Step-by-step implementation process
- Define the specific financial-crime risk with a clear written risk statement.
- Confirm participant eligibility under section 5 of the PCMLTFA based on actual activities.
- Identify the minimum information required to address the identified risk (data minimisation).
- Assess legal and privacy authority — consult with privacy and AML counsel.
- Conduct a privacy and security risk assessment to confirm safeguards are adequate.
- Draft the code of practice incorporating all core components.
- Obtain formal participant acknowledgement from each entity.
- Assign accountable owners for administration, privacy compliance, security, audit and breach response.
- Establish technical controls — secure database, access management, encryption, logging.
- Prepare submission materials for OPC review.
- Submit to the OPC and provide to FINTRAC on the same day.
- Train all authorised staff before information sharing commences.
- Conduct a pilot test with a small subset of information to verify that controls and processes work as intended.
Relationship with STR decision-making
Shared information does not replace independent STR analysis. Each participating entity must independently assess whether, based on its own records and reasonable grounds to suspect, an STR is required. Shared intelligence may support that analysis — learning that a customer has similar activity patterns at another platform may strengthen reasonable grounds to suspect — but the entity's own judgment must be primary. Do not file an STR solely because a peer raised a suspicion.
One participant's decision to file an STR does not require other participants to file one. Each entity assesses risk within its own business context. Participants should not disclose whether an STR has been filed in response to shared intelligence, as this risks tipping off customers about regulatory scrutiny.
Common mistakes to avoid
- Inviting ineligible participants — verify section 5 eligibility before including any entity.
- Beginning to share before OPC approval is formally obtained.
- Treating AML purpose as an automatic consent exemption — all section 11.01 conditions must be satisfied.
- Over-sharing information — share only what addresses the identified risk.
- Using vague participant criteria ("relevant financial institutions" is too loose).
- Omitting correction procedures — without a clear process, errors persist and undermine trust.
- Creating unsupported retention periods — justify why the period is appropriate to the specific information and risk.
- Treating shared intelligence as automatically reliable — assess reliability in context.
- Making collective customer decisions — each entity decides independently.
- Assuming information sharing replaces STR obligations.
- Failing to plan for regulatory reapproval — codes are not permanent.
- Copying foreign templates without adaptation — adapt carefully to Canadian requirements.
Implementation checklist
- Section 5 reporting entity eligibility confirmed for all participants
- Financial-crime risk or intelligence gap documented in writing
- Information categories mapped (included and excluded)
- Privacy impact assessment completed
- Legal and privacy authority confirmed through counsel review
- Code of practice drafted incorporating all core components
- Each participant formally acknowledges code commitment
- Accountable owners assigned for each governance function
- Technical infrastructure established and tested
- Security controls implemented (encryption, access logging, authentication)
- Staff trained on code requirements and security obligations
- Code submitted to OPC and copy provided to FINTRAC on same day
- OPC approval obtained before sharing begins
- Monitoring and compliance review schedule established
- Reapproval timeline documented
- Procedures established for material changes
- Breach notification and corrective action procedures in place
How AML advisory support and a fractional compliance officer can help
Developing a code of practice requires expertise in Canadian AML regulation, privacy law, section 5 eligibility assessment and governance design. An AML advisory engagement typically includes regulatory interpretation of PCMLTFA section 11.01 requirements, assessment of participant eligibility and compliance status, privacy and governance design aligned with PIPEDA, drafting of the code of practice, preparation of OPC submission materials, coordination with FINTRAC regarding submission timing, and remediation support if questions arise during operation.
Once approved and operational, a fractional compliance officer can establish and oversee regular compliance reviews and access audits, deliver training to new staff, maintain access logs and audit trails, manage communications with the OPC, FINTRAC and participating entities, monitor effectiveness, respond to breaches, plan for regulatory reapproval, and assess material changes that may require resubmission. Outsourcing compliance oversight provides expert governance without the cost of a full-time hire.
Frequently asked questions
Is a PSP registered under the RPAA automatically eligible to participate?
Can a technology vendor that hosts the shared-information platform also participate as a sharing party?
Can an approved code be expanded to include a new participant after approval?
What happens to shared information when a participant withdraws from the arrangement?
Can shared information be transferred to other jurisdictions or foreign affiliates?
Does receiving shared information require closing a customer's account or taking other specific action?
ComplyFactor supports Canadian reporting entities with the regulatory interpretation, privacy and governance design, and ongoing compliance oversight required to develop and maintain information-sharing arrangements that meet current FINTRAC guidance and Canadian privacy law.
