Accreditation working group meeting 4 – September 20, 2022
This discussion guide is provided to assist working group members in preparing for the accreditation working group’s fourth meeting.
For questions or comments, please contact obbo@fin.gc.ca.
Discussion guide
Certification
It is important to note the difference between accreditation and certification. Accreditation outlines the foundational requirements that certain organizations must meet in order to participate in an open banking system. Certification, on the other hand is the process by which conformance to certain technical requirements are tested and evidenced. These may include customer experience guidelines, operational guidelines, functional requirements of an API and, importantly, conformance to security elements of a technical standard.
Certification can be undertaken in different forms. Under a self-certification model, system participants assess and declare their conformance to a suite of defined test scenarios. Alternatively, a participant’s conformance can also be validated by a governance entity or independent third-party.
In both cases, certification offers advantages. For system participants, it provides assurance that the deployment of their service conforms to the test suite and key requirements of an open banking system. This in turn will increase the overall system performance, namely by improving security, reliability and availability of these services, reducing the volume of complaints across system participants as well as identifying defects earlier in the development lifecycle. Together, these benefits contribute to a more positive customer experience.
Experiences from other jurisdictions can be useful references. The United Kingdom’s Open Banking Implementation Entity (OBIE) supports third-party service providers with tools to ensure their services are properly tested prior to public releaseFootnote 1. The Conformance Certification Service provides a suite of testsFootnote 2 to verify that the OBIE Standard has been correctly implemented. Service providers self-attest their conformance, which is then validated by the OBIE. A key element of this is the security profile conformance where the Open ID Foundation (OIDF) verifies adherence to the Financial-grade API (FAPI). Conformance is mandatory for the nine largest banks in the UK, commonly known as the “CMA9”.
Similarly, the Australian Competition and Consumer Commission manages a conformance test suite for Consumer Data Right (CDR) ecosystem participants. The test varies depending on whether the entity is a data holderFootnote 3 or a data recipientFootnote 4 but remains a requirement for inclusion in the CDR register. It is also important to note that contrary to the UK model, the ACCC does not require FAPI certification via the OIDFFootnote 5.
Discussion
- What tests should form part of the certification process? You may wish to refer to the links for the OBIE Conformance Certification Service as well as ACCC conformance test under footnotes 2, 3 and 4.
- Should certification be a requirement for all ecosystem participants?
- Should the certification process vary depending on the type of participant (e.g. bank, intermediary, fintech)?
- What are the advantages and disadvantages of self-certification as compared to a governance entity or third-party conducted certification?
- How often should certification be conducted? Is it a one-time exercise or should the process be refreshed occasionally? If so, what circumstances would give rise to a new certification test?
Outcomes
Certification
Discussion 1
What tests should form part of the certification process? You may wish to refer to the links for the Open Banking Implementation Entity (OBIE) Conformance Certification Service as well as the Australian Competition and Consumer Competition (ACCC) conformance test under footnotes 2, 3 and 4.
- There was general consensus that technical standards, security, scope, consent and revocation flows should form part of the certification process.
Discussion 2
Should certification be a requirement for all ecosystem participants?
- There was general consensus that all ecosystem participants (including financial institutions that are not subject to accreditation) should require certification.
Discussion 3
Should the certification process vary depending on the type of participant (e.g. bank, intermediary, fintech)?
- Most participants were of the view that the certification tests should apply uniformly in the interest of simplicity, consistency and maintain a level playing field.
- Others noted that the certification process should vary depending on the role of participants in the ecosystem, the size, the nature of participants (data providers versus data recipients), and the type of services provided.
Discussion 4
What are the advantages and disadvantages of self-certification as compared to a governance entity or third-party conducted certification?
- While the speed of self-certification was noted, there was general consensus that a middle ground is preferable, with an independent third-party attesting conformance.
Discussion 5
How often should certification be conducted? Is it a one-time exercise or should the process be refreshed occasionally? If so, what circumstances would give rise to a new certification test?
- There was general consensus that certification should occasionally be refreshed.
- Reasons provided included a change in business model, accreditation revocation, changes to a participant’s technology stack and with the passage of a certain amount of time such as 2-3 years.
Accreditation working group attendees
Members
- Desjardins
- Flinks
- National Bank of Canada
- Plaid
- Scotiabank
- Stripe
- TD Canada Trust
- Vancity Credit Union
- Wealthsimple
- Central 1 Credit Union
Absent
- Laurentian Bank of Canada
External guests
- British Columbia Financial Services Authority
- Competition Bureau Canada
- Financial Consumer Agency of Canada
- Office of the Superintendent of Financial
Institutions
Chair
- Abraham Tachjian, Open banking lead
Secretariat
- Department of Finance Canada
Page details
- Date modified: