Global fintech and funding innovation ecosystem

Canada Open Banking and Consumer Driven Banking Rules

NCFA Regulatory Intelligence - Canada Open Banking And Consumer Driven Banking Rules
NCFA Canada | Regulatory Intelligence | Open Banking and Consumer Driven Banking | Last updated July 18, 2026 | Status proposed regulations
NCFA Regulatory Intelligence
This guide explains Canada’s open banking framework through the proposed Consumer Driven Banking Regulations, including accreditation, consent, data sharing, security, liability, supervision and implementation. Sources include the Canada Gazette, the Regulatory Impact Analysis Statement, the Consumer Driven Banking Act, Finance Canada and Bank of Canada materials.
Canada Open Banking

Proposed Consumer Driven Banking Regulations

Canada Open Banking and Consumer Driven Banking Rules

Canada’s proposed Consumer Driven Banking Regulations establish the operating framework for open banking. They address accreditation, consumer consent, data sharing, security, technical standards, liability, complaints, reporting, national security review and enforcement.

Use this guide to understand the proposed requirements, the implementation work they create and the consultation questions that may affect banks, credit unions, payment service providers, fintechs, consumers and small businesses.

Consultation is open for 60 days through the Canada Gazette online commenting feature and closes August 26, 2026 at 11:59 p.m. EDT. Responses may be submitted through the Canada Gazette online commenting feature or by email to obbo@fin.gc.ca, citing Canada Gazette, Part I, June 27, 2026.

Finance Canada contactKïrsten Fraser, Financial Services Division, Department of Finance Canada

Canada’s Open Banking and Consumer Driven Banking Journey

Canada has advanced from open banking policy development into proposed Consumer Driven Banking Regulations under Bank of Canada oversight. The current stage is consultation on the draft operating rules.
Launch read access and data mobility
Next write access
Consultation2018 to 2022 open banking policy review
Framework2023 to 2024 Consumer Driven Banking design
2026 Currentregulations in consultation Bank of Canada oversight and rules buildout
Read Accesslaunch phase secure data sharing and data mobility
Data Productsnear term verification, cash flow and embedded workflows
Write Accessnext phase payment initiation and account actions
Open Financelonger term broader financial product scope

Impact Analysis

Key figures from the Regulatory Impact Analysis Statement and proposed regulations.
$13.2BEstimated 10 year benefits
$457.7MEstimated 10 year costs
9MCanadians using data sharing services
680Affected businesses in central scenario
578Small businesses affected
$89,133Average annualized small business cost estimate
99.5%Monthly endpoint availability
$10MMaximum entity or ATPSP penalty

Regulatory Intelligence Explorer

Navigate the proposed regulations by topic. Each section separates requirements, implementation work, consultation considerations and NCFA’s strategic perspective.

Overview

Requirements The proposed regulations support implementation of the Consumer Driven Banking Act and create the operating layer for Canada’s open banking framework. They prescribe the data covered by the Act, accreditation information and requirements, accreditation fees, review timelines, revocation notices, accredited third party service provider requirements, national security information requirements, Ministerial review timelines, data sharing duties, exceptions to sharing, service standards, security safeguards, breach reports, responsible officer information, authentication steps, consumer signs, change notices, annual reporting, record keeping, liability related consumer notices, complaint procedures, technical standards body reporting, evidentiary privilege, assessments, administrative monetary penalties and coming into force rules.
  • Definition of Act and prescribed covered data
  • Accreditation applications for federal or provincial financial institutions, RPAA registered payment service providers, other entities and accredited third party service providers
  • Bank of Canada electronic application system, accreditation fee, refusal review and revocation processes
  • National security information package, Ministerial decision period, review period, extensions and review rights
  • Registry based verification before sharing data and exceptions where sharing can be withheld
  • Service standards for response times, endpoint availability, planned outages and traffic management
  • Security safeguards, breach reporting and responsible officer reporting
  • Authentication, acknowledgement and consent connected to secure data sharing
  • Notices, annual reporting, record keeping, liability, complaints, technical standards body reporting, assessments and violations
Implementation Organizations should build a regulatory inventory that maps each requirement to a system, policy owner, evidence file and supervisory reporting obligation. The first implementation work is not only API build. It includes accreditation evidence, national security information, data classification, registry checks, consent design, authentication records, breach playbooks, service monitoring, complaint intake, record retention, change notices, fee modelling, ATPSP contracts and board level accountability.
Consultation Considerations
  • Whether the framework gives enough implementation runway between final regulations, Bank of Canada guidance and coming into force
  • Whether proportionality is strong enough for small firms and RPAA registered payment service providers without reducing consumer trust
  • Whether guidance should clarify connections between fraud, consent, complaints, liability, security events and record keeping
  • Whether the technical standards body, conformance testing and service performance rules should be clearer before launch
  • Whether the cost and reporting model supports competition or favours organizations with existing compliance infrastructure
  • Whether consumers and SMEs will be able to understand which entities are accredited, which data is covered and how complaints or deletion requests work
NCFA Perspective This is a trust and market structure test. Canada is defining the participation standard for a regulated financial data market. The strongest framework will not be the one with the most rules. It will be the one that makes safe participation practical, keeps consumer control understandable and lets credible new entrants compete without pushing the ecosystem into a narrow, incumbent led implementation path.

Application and Data

Requirements The regulations define the Act and prescribe the data to which the consumer driven banking framework applies. Covered data includes data relating to consumers of the covered products or services, account and product identifiers, the terms under which products and services are provided, balances or amounts owing, completed, pending and pre authorized transactions, and information about products or services available or offered to consumers. The data scope is tied to the products and services referred to in the Act and must be shared only through the regulated framework once the relevant duties apply.
  • Identity related data for consumers of covered products or services
  • Account numbers, branch numbers, transit numbers and other product or service identifiers
  • Product and service terms, including fees, interest rates and authorizations
  • Current and past balances or amounts owing
  • Completed, pending and pre authorized transaction data
  • Information about products or services available or offered to consumers, including terms
  • Historical limits apply in the data sharing rules for balances, transactions and available or offered products and services older than 24 months
  • Covered data must be tied to a valid data sharing request, participant verification, consumer authentication and consent
Implementation Participants need a data inventory that maps each covered category to source systems, product owners, API fields, consent screens, retention rules, deletion workflows, complaints, liability records and service monitoring. Data providers should identify where product terms, balances, transaction history and account identifiers are stored, how far history is available, what data is excluded, and how data quality issues will be handled when another participant relies on the information.
Consultation Considerations
  • Whether the covered data categories are specific enough for consistent implementation across institutions
  • Whether the treatment of derived, inferred or enriched data needs clearer boundaries
  • Whether the 24 month historical limit is sufficient for SME finance, lending, accounting and cash flow use cases
  • Whether business accounts, joint accounts, delegated authority and multi user permissions need more detailed guidance
  • Whether future open finance expansion should be signalled earlier to reduce later redesign
  • Whether data quality, correction and dispute processes need a clearer connection to complaints and liability
NCFA Perspective Data scope is the first market boundary. A narrow read access model can still support verification, underwriting, cash flow analysis, switching, accounting and embedded workflows. The larger Canadian opportunity depends on whether this foundation can expand cleanly into write access, payment initiation and broader open finance without rebuilding the trust layer from scratch.

Accreditation

Requirements The accreditation rules prescribe different application pathways for federal or provincial financial institutions, RPAA registered payment service providers, other entities and accredited third party service providers. Applications must be submitted through the Bank of Canada electronic system. Common information includes legal and trade names, formation details, civic and mailing addresses, contact information, website, application contact, organizational and governance structure, regulatory or supervisory oversight, foreign open banking registration or accreditation status, designated officer or employee details, consumer complaint contact information, technical standard evidence and national security information. RPAA registered PSPs and other entities must also provide Canadian place of business declarations, whether they operate from a dwelling house, independent third party confirmation of security safeguards, insurance or guarantee evidence, and integrity and good character policies for individuals with significant responsibility. Other entities must additionally describe how they will meet specified Act requirements, complaint procedures, external complaints body membership status and estimated consumer numbers.
  • Federal or provincial financial institution applications include security compliance declaration, designated officer details, complaint contact, technical standard evidence and national security information
  • RPAA registered PSP applications include Canadian place of business, dwelling house declaration, independent security confirmation, technical standard evidence, insurance or guarantee and integrity policy or good character information
  • Other entity applications include similar information plus descriptions of how they will meet specified duties, complaint procedures, external complaints body membership and estimated consumer numbers
  • RPAA registered PSPs and other entities must maintain place of business, insurance or guarantee and integrity or good character requirements after accreditation
  • The accreditation fee is $2,500 in the first year and then indexed to September CPI, rounded to the nearest $100, with no decrease from the previous year
  • An applicant has 30 days to request Governor review of an accreditation refusal, and the Governor has 120 days after giving an opportunity to make representations to accredit or confirm refusal
  • Participating entities requesting voluntary revocation must provide consumers with name and contact, planned request date, impact assessment, deletion notice and complaint resolution information
  • A participating entity has 30 days to request Governor review of a notice of intent to revoke accreditation, and the Governor has 60 days after giving an opportunity to make representations to revoke or withdraw the notice
  • Former participating entities must notify consumers of revocation date, reasons, impact, deletion request requirement and complaint process
  • Accredited third party service provider applications include legal information, activity description, participating entity relationships, Canadian place of business, independent security confirmation, technical standard evidence, contract and policy information and national security information
Implementation Applicants should build a complete accreditation evidence file before applying. That file should include corporate and governance documents, regulatory status, technical standard evidence, security confirmation, insurance or guarantee evidence, complaint process, designated officer details, integrity policy, national security information, contracts with participants where relevant and consumer impact notices for potential exit. RPAA registered PSPs should map which information can be reused from RPAA registration and which requirements are new under CDB.
Consultation Considerations
  • Whether application evidence is proportionate across banks, credit unions, RPAA registered PSPs, other entities and ATPSPs
  • Whether the independent third party confirmation of security safeguards should have defined qualifications or assurance standards
  • Whether insurance or guarantee sufficiency needs guidance so applicants can price participation
  • Whether the dwelling house declaration could create unnecessary ambiguity for remote first firms
  • Whether refusal, revocation and review timelines are workable for firms planning launch and funding milestones
  • Whether ATPSP accreditation requirements are clear enough for infrastructure providers that will support multiple participating entities
NCFA Perspective Accreditation sets the practical threshold for market participation. If evidence requirements are too light, the framework risks weak trust. If they are too heavy, innovation may concentrate among large institutions and compliance funded platforms. The policy challenge is not choosing between safety and competition. It is designing entry rules that reward credible operators without making participation uneconomic for the firms most likely to create new consumer and SME products.

Authentication and Consent

Requirements The proposed rules connect data sharing to verification, consumer authentication and consent. A participant receiving a request must verify the requesting entity and confirm through the registry that it is an accredited participating entity and not suspended in a way that prevents receiving data. A participant requesting data must verify the provider and confirm through the registry that the provider is accredited and not suspended in a way that prevents providing data. Authentication requires confirmation of the consumer’s authentication information using multi factor authentication. The consumer must acknowledge the requesting participant’s name, the nature of the request and the accounts from which the requested data will be provided before the data is shared and the consumer is redirected.
  • Requester and provider verification against the registry before sharing
  • Confirmation that accreditation has not been suspended or restricted by Bank conditions
  • Multi factor authentication of the consumer’s authentication information
  • Consumer acknowledgement of the requesting entity, nature of the request and relevant accounts
  • Data sharing only after verification, authentication and acknowledgement requirements are met
  • Renewal may be required after circumstances where data sharing was not required or consent has not yet been renewed
  • Consent evidence must connect to records, deletion requests, liability, complaints and annual reporting
Implementation Participants need registry lookup, accreditation status checks, suspension condition logic, MFA, acknowledgement capture, consent evidence, renewal workflows, revocation and deletion links, exception handling and audit trails. Authentication and consent should not be built as a user interface layer only. They need to produce evidence that can support annual reporting, complaint resolution, breach response, liability allocation and supervisory review.
Consultation Considerations
  • Whether the registry verification workflow is operationally clear for real time data sharing
  • Whether MFA requirements align with existing bank and fintech authentication journeys
  • Whether consumer acknowledgement wording should be standardized enough to prevent confusing consent screens
  • Whether consent renewal triggers and failed renewal situations need clearer examples
  • Whether consumer dashboards, consent receipts and cross provider visibility should be addressed in guidance
  • Whether consent evidence is sufficient to resolve liability, complaint and deletion disputes
NCFA Perspective Consent is one of the highest trust points in the framework. The market will not fail because consent screens are hard to build. It will fail if consumers cannot understand them, if participants cannot prove what was authorized, or if revocation and deletion are too hard to execute. This is where compliance design and product design become the same problem.

Security

Requirements The regulations prescribe detailed security safeguards for participating entities. Safeguards include vulnerability identification and remediation, regular updates, secure default configuration, security software, robust authentication, access management policies, unique accounts, data encryption and backup, network security controls, external storage policy, bans on unauthorized devices and applications, network traffic monitoring, suspicious content controls, inventory of systems and devices, third party service provider contract protections, employee cyber threat training and an incident response plan with log auditing and periodic exercises based on extreme but plausible scenarios. Safeguards must be proportionate to data sensitivity and network segmentation is permitted. Federal and provincial financial institutions are presumed to have implemented safeguards unless OSFI or the relevant provincial authority has identified deficiencies and directed remediation.
  • Vulnerability management and regular updates
  • Secure configuration by default
  • Security software on relevant systems and devices
  • Robust authentication methods
  • Role based access management policies
  • Unique accounts and minimized shared accounts
  • Encryption and regular backup of stored data
  • Network security controls for data in transit
  • External storage policy
  • Prohibition on unauthorized devices and applications
  • Monitoring and control of network traffic
  • Suspicious content identification, quarantine or blocking
  • Inventory of systems and devices used for sharing and storing covered data
  • Contract terms requiring third party service provider protection of data
  • Employee cyber threat training and ongoing updates
  • Incident response plan with detection, response, recovery, log auditing and scenario exercises
  • Responsible officer or employee details must be provided to the Bank without delay after designation
  • Breach reports to the Bank must include circumstances, known cause, date or period, affected data, number of consumers, potential impacts, mitigation and contact information
Implementation Participants should treat security as an accreditation and operating evidence file. Required work includes asset inventory, vulnerability program, configuration standards, endpoint and system security, identity and access controls, encryption, backup, network monitoring, third party contract review, cloud and vendor risk, cyber training, incident response testing, breach reporting templates and escalation paths to the Bank. Security records should be aligned with annual reporting, complaint records and liability evidence.
Consultation Considerations
  • Whether the required safeguards are specific enough for consistent assurance while remaining technology neutral
  • Whether independent third party confirmation should follow a defined assurance framework
  • Whether breach reporting timing, consumer notification thresholds and report updates need more prescriptive examples
  • Whether third party and cloud contract requirements should include subcontractor and data location obligations
  • Whether small entrants can meet the same security evidence burden without shared infrastructure
  • Whether fraud, identity, authentication and cyber controls should be addressed together in Bank guidance
NCFA Perspective Security is the trust anchor. Consumer driven banking exists partly to replace unsafe credential sharing with supervised data access. That only works if security is operationally real, not a paper control. The framework must be strong enough to protect consumers and flexible enough that security compliance does not become the reason only the largest organizations can participate.

Technical Standards

Requirements The technical standard provisions operate through the Act and the regulations. Applicants must provide evidence of compliance with the technical standard referred to in the Act. Participating entities must declare technical standard compliance in annual reports. Data sharing systems must meet response time expectations consistent with generally accepted international standards, maintain 99.5 percent monthly availability excluding planned outages, and use traffic management only for technical stability or security in a proportionate, non discriminatory way. The technical standards body must submit an annual report to the Bank within seven days after each anniversary of its designation order. That report must describe vulnerabilities in the technical standard or standards body that had or could have had an impact on the security of data sharing, non technical descriptions of changes to data fields, features, functionality or other security relevant aspects of the technical standard, rationale and decision process for those changes, and changes relevant to the body’s designation.
  • Applicants must provide technical standard compliance evidence
  • Participating entities must report annual technical standard compliance
  • API or electronic system response times must align with generally accepted international standards
  • Data sharing systems must meet 99.5 percent monthly availability, excluding planned outages
  • Rate limiting, throttling and preferencing are restricted to stability and security purposes
  • Traffic management must be proportionate, non discriminatory and must not degrade consumer outcomes
  • Technical standards body annual report is due within seven days after each designation anniversary
  • Technical standards body must report vulnerabilities, causes, impacts, mitigation and contact person
  • Technical standards body must describe changes to data fields, features, functionality or security relevant aspects, plus rationale and decision process
  • Technical standards body must describe changes relevant to its designation factors
Implementation Technical teams need API inventory, conformance evidence, performance monitoring, availability measurement, outage notification, traffic management governance, test environment planning, error handling, historical data readiness, change management and documentation that can support Bank supervision. Firms should prepare for technical standard versioning and for annual evidence that systems remained compliant through the reporting year.
Consultation Considerations
  • Whether the technical standards body should be identified or its governance clarified before final implementation planning
  • Whether conformance testing should be mandatory before production access
  • Whether response time expectations should be converted into measurable standards
  • Whether 99.5 percent availability is sufficient for higher value financial workflows
  • Whether public reporting of availability, outages and API performance would strengthen trust
  • Whether technical standard changes should have notice periods, backwards compatibility expectations and migration timelines
NCFA Perspective Technical standards are where the framework becomes real infrastructure. Canada’s competitive position will depend less on whether APIs exist and more on whether standards, testing, versioning and change management let participants build once and scale. Ambiguity here can turn regulatory permission into integration drag.

Liability

Requirements The liability provisions clarify consumer responsibility and the allocation of responsibility between participating entities. Every participating entity must inform consumers of the consequences of gross negligence or, in Quebec, gross fault in safeguarding authentication information. It must advise consumers of reasonable measures they can take to safeguard authentication information. It must not intentionally mislead consumers about the extent of their liability or adopt policies that presume consumer liability contrary to the Act. Where a consumer is not liable for a financial loss arising from loss, unauthorized access or unauthorized use of data shared under the Act, liability between participating entities is determined by where the loss, access or use occurred. The requester is liable to the extent it occurs in relation to the requester securely receiving or managing the data. The provider is liable to the extent it occurs in relation to provider authentication or secure provision of the data.
  • Consumers must be informed about gross negligence or gross fault consequences for authentication information
  • Consumers must be advised of reasonable safeguarding measures
  • Participants must not mislead consumers about liability
  • Participants must not adopt policies presuming consumer liability contrary to the Act
  • Requester liability follows failures connected to receiving or managing data
  • Provider liability follows failures connected to authenticating the consumer or securely providing data
  • Liability evidence depends on consent, authentication, registry checks, transmission logs, receipt records, complaint files and incident records
Implementation Participants should prepare consumer notices on authentication information, avoid default liability language, align customer support scripts with the Act, and preserve records that show where an event occurred. Liability operations require authentication logs, consent evidence, registry verification, data transmission records, receipt confirmations, access logs, incident investigations, complaint handling and remediation decisions.
Consultation Considerations
  • Whether gross negligence or gross fault communications will be understandable for consumers
  • Whether liability allocation is clear enough for multi party flows involving ATPSPs
  • Whether examples should clarify direct financial loss, unauthorized access, data loss and failed revocation
  • Whether consumer support and complaint processes need stronger alignment with liability rules
  • Whether records required to prove liability should be specified more explicitly
  • Whether fraud and scam scenarios are sufficiently covered by the liability architecture
NCFA Perspective Liability will be tested in edge cases, not in clean diagrams. The strategic issue is whether the framework can resolve consumer harm quickly without turning every incident into a multi party blame exercise. Clear evidence rules can build trust. Unclear responsibility can undermine adoption even if the technology works.

Reporting Requirements

Requirements The proposed regulations require change notices, annual reports and records sufficient to demonstrate compliance. Changes that must be reported include names or contact information, organizational structure, RPAA registration status for entities accredited under the RPAA pathway, Canadian regulatory oversight, foreign open banking registration or accreditation, designated officer contact, complaint contact, external complaints body membership, significant responsibility individuals and integrity status, insurance or guarantee sufficiency, technical standard compliance and national security information. Some changes must be reported within 30 days after they occur, some as soon as feasible after awareness, some at least 30 days before taking effect and some at least 60 days before taking effect. Annual reports must provide monthly metrics on non sharing events, express consents, consent renewals, withdrawals, deletion requests, system availability, data sharing counterparties, successful data provisions and average response time. They must also include changes, policy and procedure updates, breach summaries, planned and unplanned outages, technical standard declaration, financial metrics, supervisory deficiency declarations for financial institutions and security safeguard implementation descriptions for certain accredited entities. Records must be sufficient to demonstrate compliance, kept electronically in a format intelligible to the Bank, retained for five years after they cease to demonstrate current compliance unless otherwise specified, and protected against loss, destruction, falsification, inaccuracy and unauthorized access or use.
  • Notice of change categories cover identity, structure, registration, oversight, foreign accreditation, officers, complaints, EBC membership, significant responsibility individuals, insurance or guarantee, technical standard compliance and national security information
  • Notice timing includes 30 days after occurrence, as soon as feasible, at least 30 days before certain changes and at least 60 days before certain data storage or processing country changes
  • Annual report metrics include monthly non sharing counts and reasons
  • Annual report metrics include express consents, renewals, withdrawals and deletion requests
  • Annual report metrics include uptime, data sharing counterparties, delivery counts and average response time
  • Annual report must include changes, policy updates, breach summary, outages, technical compliance declaration and financial metrics
  • Records must demonstrate compliance with the Act and regulations
  • Records must be electronic and intelligible to the Bank
  • Records must generally be kept for five years after they cease to demonstrate current compliance
  • Records must be protected from loss, destruction, falsification, inaccuracies and unauthorized access or use
  • ATPSPs must keep compliance records, contracts with participants and policies or procedures relating to services they perform for participants, with the same electronic form and protection rules
  • Certain supervisory information, Bank directions, compliance agreements and supervisory correspondence are privileged for civil evidence purposes, with specified exceptions for use by the Minister, Governor, Bank, Attorney General of Canada, participants or ATPSPs in certain proceedings
Implementation Participants need a compliance data model that captures events as they happen. Manual annual reporting will be fragile. Systems should collect consent events, renewal events, withdrawal events, deletion requests, non sharing reasons, uptime, response time, outage data, breaches, policy changes, material changes, complaint records and financial metrics. Record retention and protection should be built into the architecture before production data flows begin.
Consultation Considerations
  • Whether the notice timing categories are clear enough for operational teams to apply consistently
  • Whether annual reporting should align with RPAA and other Bank of Canada reporting regimes where possible
  • Whether public transparency reporting on uptime, outages, complaints and non sharing events would strengthen trust
  • Whether smaller firms need proportional reporting without weakening supervisory visibility
  • Whether five year record retention is practical across all evidence categories
  • Whether privileged supervisory information rules strike the right balance between supervision, litigation risk and transparency
NCFA Perspective Reporting and records are the hidden operating system of regulated open banking. They may matter more than any single product feature because they determine whether trust can be audited, problems can be reconstructed and smaller firms can participate without building a bank sized compliance department.

Complaints

Requirements The regulations require complaint handling information at accreditation and connect complaints to revocation notices, consumer contact information, external complaints body membership and records. Other entity applicants must describe intended complaint procedures, the officers or employees to be designated for complaint responsibilities, and the contact information consumers will use. A participating entity requesting revocation or a former participating entity whose accreditation has been revoked must provide consumers with information about the process for resolving outstanding complaints. Annual reporting must describe changes to complaint related procedures. Record keeping must support compliance and complaint evidence. ATPSPs must keep contracts and related policies or procedures where they perform activities for participating entities.
  • Complaint contact information is required in accreditation applications
  • Other entity applications must describe complaint procedures and designated complaint roles
  • External complaints body membership status is required for certain applicants
  • Revocation and former participant notices must include complaint resolution information
  • Complaint processes connect to annual reporting and record keeping
  • Complaint evidence should align with consent, authentication, data sharing, security, breach and liability records
Implementation Participants should design complaint intake, triage, escalation, evidence review, consumer communication, external complaints body routing, remediation, root cause analysis and reporting. Complaint workflows should identify whether the issue relates to access, failed sharing, revoked consent, deletion, fraud, data quality, breach, liability or service availability.
Consultation Considerations
  • Whether complaint timelines and escalation expectations should be more explicit
  • Whether consumers will know whether to contact the provider, requester, ATPSP, bank or external complaints body
  • Whether SMEs need distinct complaint pathways for business account use cases
  • Whether complaint data should feed into supervisory or public transparency reporting
  • Whether complaints involving data quality, failed sharing, deletion or fraud require specific treatment
NCFA Perspective Complaint handling will be a public trust signal. Consumers rarely judge infrastructure by how it works on a perfect day. They judge it by what happens when something breaks, money is lost, access fails or nobody knows who is responsible.

National Security Review

Requirements The regulations prescribe extensive information for national security review and timelines for Ministerial decisions. Applicants must provide information about legal name, trade names, jurisdictions, addresses, contact information, business activities, financial services, affiliates, ownership and control, individuals or entities with significant voting or ownership interests, board members, highly compensated senior officers, major creditors, state owned enterprise ownership or appointment powers, categories of personal or financial information gathered or planned to be gathered, countries where the applicant or third party service providers store or process that information, and individuals or entities outside employees or agents that may receive access to that information. The Minister has 60 days after receiving the application copy to decide whether to review, with extensions in 60 day periods. If a review proceeds, the Minister has 180 days, with 180 day extensions. Applicants have 30 days to request review of a directive to refuse accreditation. Applicants must provide requested additional information within 30 days. For suspension and revocation, participants or ATPSPs have 30 days to request review of a notice of the Minister’s intent to direct revocation. Former participants and former ATPSPs must provide specified information to consumers or participating entities. Additional information requested by the Bank must be provided within 15 days.
  • Ownership, control, affiliates, significant influence and voting or ownership interest information
  • Countries of residence, citizenship, incorporation or formation for relevant individuals and entities
  • Board member and five most highly compensated senior officer information
  • Five largest creditors and credit agreement terms
  • State owned enterprise ownership, voting interest or appointment powers
  • Categories of personal and financial information gathered or planned, including identifying information, financial data, private communications and geolocation data
  • Countries where applicant or third party service providers store or process information
  • Non employee or non agent individuals or entities that may access the information
  • 60 day Ministerial decision window to review, extendable by 60 day periods
  • 180 day national security review period, extendable by 180 day periods
  • 30 day applicant review request period for refusal directive
  • 30 day period to provide additional requested information under subsection 54(2)
  • 30 day review request period for notice of intent to direct revocation
  • 15 day period to provide additional information requested by the Bank under subsection 71(2)
Implementation Applicants should prepare a national security file before applying, not after questions arrive. That file should include ownership charts, control analysis, citizenship and residency information, affiliates, creditors, SOE exposure, data categories, data storage and processing locations, cloud and vendor access, third party access, board and senior officer information, and change monitoring. Deal teams should assess how fundraising, acquisitions, data residency, vendor changes and cross border processing could affect review risk.
Consultation Considerations
  • Whether the national security information package is proportionate for lower risk applicants
  • Whether significant influence, creditor exposure and third party access require clearer guidance
  • Whether data residency and cross border processing expectations should be clarified before applications begin
  • Whether the 60 day and 180 day review timelines could materially affect investment, partnership and launch planning
  • Whether applicants should have a pre filing process or informal guidance pathway for complex ownership structures
  • Whether national security review should be harmonized with broader financial infrastructure, digital identity and cloud risk policy
NCFA Perspective This connects open banking to financial infrastructure security. It is not a side process. National security review can affect who enters the market, which investors participate, where data is processed, which vendors are acceptable and how exits are structured. If handled clearly, it can strengthen trust. If handled opaquely, it can slow capital and partnership formation.

Assessments and Fees

Requirements The regulations set an indexed accreditation fee and annual assessments. The accreditation fee is $2,500 in the year the section comes into force. In later years it is calculated as $2,500 multiplied by the ratio of the September all items CPI for Canada in the year before application to the September CPI in the year the section comes into force, rounded to the nearest $100, with no decrease from the previous year. Participating entity assessments are calculated as base assessment plus variable assessment minus interim assessments. Base assessments depend on total asset value. Entities with at least $1 trillion in assets pay a $150,000 base amount; $100 billion to under $1 trillion pay $100,000; $10 billion to under $100 billion pay $50,000; $1 billion to under $10 billion pay $20,000; and under $1 billion pay $10,000. Variable assessment shares allocate remaining Bank costs after deductions by asset tier using 0.4, 0.3, 0.2 and 0.1 factors for the larger asset tiers, while the under $1 billion category has no variable amount. Subsidiary assets are excluded where the subsidiary is itself a participating entity. ATPSPs are assessed $10,000 per year less interim assessments. The external complaints body is assessed $50,000 per year less interim assessments, reduced proportionally for a partial year. Information requested about assets must be provided by March 31 following the relevant calendar year when requested by December 31, or within 15 days for other requests. If asset information is not provided on time, the entity is treated as being in the highest asset category for assessment purposes.
  • $2,500 first year accreditation fee
  • CPI indexed accreditation fee after first year, rounded to nearest $100 and not allowed to decrease
  • Participating entity assessment equals base assessment plus variable assessment minus interim assessment
  • Base assessment tiers of $150,000, $100,000, $50,000, $20,000 and $10,000 based on total assets
  • Variable assessment shares of 0.4, 0.3, 0.2 and 0.1 for larger asset tiers
  • No variable assessment for entities with less than $1 billion in assets
  • ATPSP annual assessment of $10,000 less interim assessments
  • External complaints body annual assessment of $50,000 less interim assessments, prorated for partial year designation
  • Asset information deadline of March 31 in specified cases and 15 days in other cases
  • Failure to provide asset information can result in assessment as if the entity were in the highest asset category
Implementation Participants should model accreditation fees, annual assessment tier, possible variable assessment, interim assessments, ATPSP fees, external complaints body implications, insurance or guarantee costs, technical build, security assurance, reporting systems and compliance staffing. Smaller firms should assess whether direct participation, ATPSP services, partnership or staged entry creates a viable cost structure.
Consultation Considerations
  • Whether the base assessment tiers are proportionate for mid sized and smaller participants
  • Whether the zero variable assessment for under $1 billion firms is enough to support competition
  • Whether ATPSP fixed fees support shared infrastructure economics
  • Whether asset based assessment is the right proxy for supervisory cost or market impact
  • Whether fee predictability is sufficient for early entrants and investors
  • Whether the highest tier default for missing asset information is too punitive or necessary for compliance discipline
NCFA Perspective The fee schedule is only one part of participation cost. The strategic issue is total regulatory operating cost. If cost scales poorly, Canada could see a market where participation is open in law but concentrated in practice. Shared infrastructure, clear guidance and proportionate reporting may determine whether smaller innovators can enter.

Administrative Monetary Penalties

Requirements The regulations designate violations for contraventions of a long list of Act provisions, specified regulation provisions, non compliance with compliance agreements and non compliance with Bank directions. The designated Act provisions include obligations related to accreditation, suspension conditions, former entity notices, ATPSP activities, prescribed information, data sharing, use of registry, privacy, security, designated officer, breach reporting, authentication, consent, deletion, notices, liability, complaints, records, technical standards, reporting, Bank information requests and other framework duties. The designated regulation provisions include failure to notify another participating entity of non sharing reasons, data sharing service standards, responsible officer information, specified reporting and notice provisions, record keeping provisions and ATPSP record keeping provisions. The Act provides maximum penalties of up to $1 million for individuals and up to $10 million for participating entities or ATPSPs.
  • Contraventions of numerous Act provisions are designated as violations
  • Contraventions of selected regulation provisions are designated as violations
  • Non compliance with compliance agreements is designated as a violation
  • Non compliance with specified Bank directions is designated as a violation
  • Regulation violations include non sharing notice failures, service standard failures, officer reporting failures, notice failures, annual reporting failures and record keeping failures
  • Maximum penalty of $1 million for individuals
  • Maximum penalty of $10 million for participating entities or ATPSPs
  • Penalty exposure connects to accreditation, data sharing, registry use, privacy, security, breach reporting, authentication, consent, deletion, liability, complaints, technical standards, reporting, records and Bank information requests
  • Coming into force is staged by Act sections, with most regulations coming into force when section 44 of the Act comes into force, data sharing and many operational obligations when section 76 comes into force, and assessment provisions when section 140 comes into force
Implementation Participants should map every designated violation to an internal control, evidence record and accountable owner. Enforcement readiness should cover consent, registry checks, non sharing notices, uptime, breach reporting, annual reporting, records, complaints, officer information, Bank information requests, compliance agreements and directions. Boards and senior leaders should understand which failures create individual or organizational exposure.
Consultation Considerations
  • Whether violation categories are clear enough for participants to map controls before launch
  • Whether penalty exposure is proportionate across firms of different size and role
  • Whether remediation and self reporting should affect penalty treatment
  • Whether public enforcement disclosure will be used to strengthen market discipline
  • Whether staged coming into force gives firms enough time to build controls before penalties apply
  • Whether individual exposure could affect senior officer recruitment and governance design
NCFA Perspective Penalty risk is less about the headline maximum and more about whether an organization can prove it had controls, records and remediation processes in place before something went wrong. Enforcement should strengthen trust without chilling responsible innovation. That balance will matter as Canada tries to turn regulatory credibility into market adoption.

Related NCFA Intelligence

Open Banking in Canada Opportunity BriefCommercial opportunity layer connected to this regulatory guide Open the brief
Financial Innovation MapWhere consumer driven banking fits in the broader fintech innovation ecosystem View the map
Research LibrarySupporting reports, market evidence and policy research Research library
Fraud regulatory perspectiveTrust, fraud controls and consumer protection context for Canada’s open banking strategy Read the fraud perspective

From Regulation to Opportunity

Canada’s proposed Consumer Driven Banking Regulations create readiness questions across accreditation, consent, data scope, APIs, cybersecurity, reporting, liability, supervision, national security review and enforcement. NCFA tracks commercial opportunities separately in the Open Banking in Canada Opportunity Brief, where regulatory evidence connects to product opportunities, investment themes, implementation gaps and emerging market signals.

Open the Opportunity Brief

Sources include the Canada Gazette, Part I publication for the proposed Consumer Driven Banking Regulations, the Regulatory Impact Analysis Statement, the Consumer Driven Banking Act, Department of Finance Canada materials and Bank of Canada supervisory materials. This NCFA guide is for general information and ecosystem intelligence only. It is not legal, financial, investment, compliance or professional advice.

NCFA Jan 2018 resizeThe National Crowdfunding & Fintech Association (NCFA Canada) is a financial innovation ecosystem that provides education, market intelligence, industry stewardship, networking and funding opportunities and services to thousands of community members and works closely with industry, government, partners and affiliates to create a vibrant and innovative fintech and funding industry in Canada. Decentralized and distributed, NCFA is engaged with global stakeholders and helps incubate projects and investment in fintech, alternative finance, crowdfunding, peer-to-peer finance, payments, digital assets and tokens, artificial intelligence, blockchain, cryptocurrency, regtech, and insurtech sectors. Join Canada's Fintech & Funding Community today FREE! Or become a contributing member and get perks. For more information, please visit: www.ncfacanada.org

NCFA Financial Innovation MapNCFA Innovation Opportunity BriefsNCFA Fintech Insights

NCFA Fintech WhispererNCFA Fintech Fridays PodcastNCFA Weekly Newsletter

 

Leave a Reply

Your email address will not be published. Required fields are marked *