Skip to content

Canada · Open banking guide

Getting your architecture ready for Consumer-Driven Banking

Canada is building a national framework that lets consumers and small businesses securely share their financial data with accredited providers. If you’re a fintech, lender or financial institution, it will shape how you handle consent, APIs, identity and security.

By Arshad Ali, Principal Architect · Last reviewed November 2026

Where things stand

  • The Consumer-Driven Banking Act received royal assent in March 2026.
  • The Department of Finance published the proposed Consumer-Driven Banking Regulations in the Canada Gazette, Part I, on June 27, 2026. The public comment period closed on August 26, 2026.
  • The proposed regulations cover scope, accreditation, security, consent, liability, a public registry, fees and enforcement, with different accreditation pathways depending on the type of entity.
  • The Bank of Canada oversees the framework, including accreditation. The rules are expected to come into force in stages, beginning with accreditation.
  • Commentators note a potentially streamlined pathway for organizations already complying with the Retail Payment Activities Act, though consent and other requirements would still apply.

The regulations were still in draft when this page was last reviewed. Check the sources below for the current status.

What it means for your architecture

The legal requirements are for your counsel. The engineering work they imply tends to fall into six areas, most of which take longer to build than teams expect:

01

Consent

Capturing clear, specific consent, recording it, letting customers see and revoke it, and enforcing expiry across every system that touches shared data.

02

Secure data-sharing APIs

Exposing or consuming account data through standardized APIs, with strong client authentication, scoped access tokens and rate limiting.

03

Identity and authentication

Authenticating customers and authorizing third parties using OAuth 2.0 and OpenID Connect patterns, as other open banking regimes do with security profiles such as FAPI.

04

Security and incident handling

Demonstrable security controls, monitoring and a tested process for detecting, containing and reporting incidents.

05

Audit trails and liability

Records that show who accessed what data, under which consent and when, which matter when something goes wrong and liability has to be determined.

06

Data minimization and retention

Collecting only the data a use case needs, and deleting it on schedule or when consent ends.

A readiness checklist

  • Do you know which accreditation pathway applies to your organization?
  • Can you show, for any piece of shared data, the consent it was collected under?
  • Can a customer revoke consent, and does revocation reach every downstream system?
  • Are your APIs protected with modern OAuth 2.0 / OIDC flows and scoped tokens?
  • Do you log data access in a way you could hand to an auditor?
  • Is there a tested incident response plan that covers shared data?
  • Have you mapped which third parties receive customer data from you, and why?

If several of these are a “not yet”, starting the architecture work now leaves time to build it properly rather than in a rush before accreditation.

Why talk to us

Our principal architect worked as a solutions architect on a federated digital identity network used by Tier-1 Canadian banks and government, integrating partners with OAuth 2.0, OpenID Connect, SAML and mTLS, and led a bank-consortium identity proof of concept in Australia. He was also the solution architect for a top Canadian bank’s mortgage platform, integrating 20+ internal and external systems. Consent, identity and secure integration between banks and third parties are exactly the problems this framework raises.

Next step

Getting ready for Consumer-Driven Banking?

Tell us where you are today. We’ll reply with a view on the biggest gaps and whether an assessment makes sense.