An open-banking roadmap can describe a compelling future. It cannot tell an operations team what to do when a connection fails, access changes or a vendor's answer stops at the edge of its contract.
The Bank of Canada opened consultation on draft accreditation guidelines on November 2. Our read is straightforward: this is a useful moment to move the internal discussion from strategic enthusiasm to an operating model that people can actually review.
What the consultation does, and does not, establish
The Bank is seeking feedback on the clarity, practicality and completeness of its proposed guidance, including implementation considerations. Its consultation page lists separate draft accreditation application requirements for participating entities and third-party service providers.
The deadline for written comments is December 8. The Bank describes these as the first in a series of supervisory guidelines, with further draft consultations to follow, not a completed framework or a universal launch.
That distinction should survive every executive summary. “The regulator is consulting” and “the regulator now requires” are different sentences; swapping them is not harmless shorthand.
Start with the role, not the integration
Our recommendation is to define the institution's intended participation model before approving the next technical workstream. Ask the team to describe one service, the parties involved, and the point at which each party's responsibility begins and ends.
For a proposed lending use case, work through the journey from approved access to information to its use in a decision. Identify who owns the connection, who handles exceptions, and which system remains the authoritative record.
Do not let “we have an API” stand in for that exercise. Connectivity describes a route; it does not assign accountability.
Policy is the moat when it becomes executable
Treat readiness as an operating discipline rather than a document collection exercise. We suggest testing four questions with the people who will run the workflow.
- Purpose: What information does this use case need, and what should remain outside its scope?
- Authority: Who can request, inspect, and use that information, and how will changes in access be handled?
- Evidence: Can a reviewer reconstruct the source, applicable policy, action, and human intervention?
- Exceptions: Who owns incomplete inputs, failed connections, and disputed outcomes?
These are our design questions, not a transcription of proposed regulatory requirements. Their value is practical: they expose gaps before teams turn assumptions into code, contracts or customer promises.
Build on what works; test what could break
An open-banking program should not automatically be an excuse to replace the lending stack. Start by testing whether existing systems can support the intended workflow through controlled interfaces and clearly assigned responsibilities.
For an institution-specific digital twin, model the relevant policy and workflow states using synthetic scenarios. Rehearse missing information, changed permissions, and conflicting inputs; do not assume that testing requires pooling real borrower records.
Evaluate more than speed. A useful pilot scorecard would include exception handling, manual intervention, the completeness of the decision history, and processing time.
Send feedback that an implementation team could use
The Bank explicitly invites comments on implementation and on areas that need more detail. Use that opening to turn internal uncertainty into a specific, reviewable submission.
For each issue, identify the relevant draft passage, explain the operational ambiguity, and describe its consequences. Offer a workable clarification rather than a general request for less friction.
The executive goal is not to claim readiness before the rules are final. It is to know which assumptions are defensible, which dependencies remain unresolved, and who owns the next decision.
FAQs
Are these final open-banking accreditation requirements?
No. The Bank of Canada describes them as draft supervisory guidelines for consultation, with additional draft consultations planned.
Who are the two draft guideline documents for?
The consultation lists participating entity and third-party service provider accreditation application requirements. Teams should review the document relevant to their proposed role rather than assuming every organization has the same path.
When is feedback due?
The Bank requests written comments by December 8, 2026. Our recommendation is to leave time for a joint technology, operations, and risk review before submitting.
Does this mean a lender should replace its existing systems now?
That is not our recommendation. Assess the proposed participation model and existing controls first; make infrastructure changes when a defined operational need and business case justify them.