Canada’s Open Banking Journey: Interview with Francois Lasne, advisory board member of The Berlin Group
Originally published at https://ncfacanada.org on September 12, 2022
“The future of Finance is Open.” — Francois Lasne, Advisory Board Member of The Berlin Group
Mahi Sall: Who is Francois Lasne?
Francois Lasne: I am an advisory board member of The Berlin Group, the largest Open Banking framework in Europe (NextGenPSD2) implemented by more than 75% of European banks. I am also a member of the French API Thinking Collective where I head the API Governance workstream. Currently working at Ingenico to launch a disruptive Payment Platform as a Service (PpaaS) for instore and online merchants. Prior to that I was director of Open API and Open Banking at Finastra.
Mahi Sall: Common Rules represent a key component of Open Banking System Design, with the premise that they create a level playing field which eliminates the need for bilateral arrangements between Open Banking participants. What situations would call for bilateral arrangements in an Open Banking environment that thrives on common rules?
Francois Lasne: Innovation runs fast, faster than regulation. Setting up a regulatory framework that rests on a solid foundation helps stimulate the creation of an ecosystem. That allows fintechs to invest as they will be able to connect / address a larger set of actors.
That said, innovation should not be blocked. If a fintech and a bank have a great idea that goes beyond the scope of regulation, why stop it? A new business idea or new use cases should not be stopped because others are not involved. Fair enough, it gives a competitive advantage, then up to the bank to negotiate if this feature would be exclusive or not, offered for free or not.
It is also important to learn by doing, and once a learning has been ‘validated’, integrate it back into the regulatory framework. Between the UK and the EU there are a lot of differences like Product Information, Branch Locator (mandatory in the UK, not required in France), etc. Shouldn’t a Branch Locator API be allowed in France?
In Europe you have the PSD2 regulatory scope with some value-added services not yet regulated like loan account support. Up to the bank and fintech to propose those services for free or paid. Here the market will make the difference.
Mahi Sall: Another key component of Open Banking System Design is the Accreditation Process. Canada’s Advisory Committee on Open Banking recommended to exempt federally regulated banks from the accreditation process, and similar consideration for provincially regulated financial institutions to be discussed. What major frustration points relative to the accreditation process can be anticipated and how to address them?
Francois Lasne: Accreditation provides trust and limits fraud. The counterpart of trust is validation, and the usual pitfall of validation is process and bureaucracy.
In the EU, the European Central Bank (ECB) delegated the accreditation process to National Competent Authorities (NCA) i.e the national Central Banks of member countries. The process is enforced by eIDAS certificates and requires NCAs to have the capability to warn for revocation of certification.
The process flow is summarized below ( Saltedge illustration):
- TPP to push ask for an authorization and present legal documents and insurance (especially for payment)
- NCA to issue authorization
- TPP to ask for an eIDAS Certificate to regulated entities QTSP (qualified trust service providers)
- QTSP to validate the authorization and issue dedicated eIDAS certificate
- TPP to send eIDAS certificate to bank
- Bank to validate eIDAS certificate
In this process we can see that several parties are involved, and so it requires a proper alignment of the stars. It is also very important to be able to distribute Test Certificates and define happy flow as well as negative flow (wrong certificate, revocation scenario).
Frustration usually happens due to unavailability of the actors, the test environment, or/and a lack of fluidity of the process.
Mahi Sall: The third key component of Open Banking System Design are Technical Specifications & Standards with two approaches currently dominating the landscape: single standard approach (e.g. UK, Australia) and multiple standards (e.g. US, EU). Canada’s Advisory Committee left both approaches open for exploration. Can you speak to the advantages and shortcomings of these approaches?
Francois Lasne: A single standard looks like a much simpler option. But this standard needs to be smart. Open Banking UK is very smart, with good coverage, good documentation. Having a single standard makes things clearer for TPPs, the road is paved and we have directions. It also simplifies the implementation.
Best is when beyond the standard there is a reference implementation or at least a TCK (Test Compliance Kit) as you have for instance for OpenIdConnect. This guarantees less interpretation.
On the other hand, having a single standard puts a lot of pressure on the regulator to provide good API, good documentation and so on. Open Banking UK quality has a cost.
The EU approach was focused on the legal aspects. This led to multiple standard implementations with a fragmentation of the API framework (STET, Berlin Group , Polish API ) and interpretation of the laws (just looking at the number of questions to the EBA — European Banking Authority).
Canada needs to learn from this. There is no point in creating yet another standard. I would encourage Canada to leverage what exists either FDX, Berlin Group or Australia API. Berlin Group being an open-source standard looks more straightforward, so I would recommend a fork (aka a copy), better a collaboration.
Mahi Sall: I n the early days of Open Banking some European banks provided in addition to APIs a Modified Customer Interface (MCI) as alternative means for third party providers (TPPs) to get access to customer data. Would you foresee the need for Canadian banks to deploy fallback options to existing APIs?
Francois Lasne: Master Yoda says: “ Do or Do not, there is no try “. Fallback is not a good option, meaning that it is complexifying integration and entering into a gray zone. As a regulator I don’t want to evaluate the quality of fallback options, as it would be a case-by-case study. This will be breaking the fluidity and adoption of API. You might end up with everyone doing fallback, which in a way would be defeating the purpose of regulation.
Mahi Sall: What are some of the lessons you’ve learned in terms of Open Banking test designs and implementation.
Francois Lasne: As we deal with API and testing, both parties i.e. producers (Banks) and consumers (TPPs) need to be ready on time. What we’ve learned is that testing needs to be prepared in advance, especially the security infrastructure like certificates as well as the business domain. There were also huge differences between “Sandbox” and production data. Testing in production with a real production system is always better. What is the point of code against a sandbox replying to a static response? Better having an agreed scenario on dedicated test users and accounts, and then no surprise when doing the production. It is so frustrating to have everything working with a sandbox, only to have to redo all the testing campaigns against the production environment.
Mahi Sall: Drawing upon your observations, what are some of the quick wins in terms of Open Banking use cases that banks and fintechs should prioritize rolling out? Mahi Sall: Speak about Open Banking limitations and the most common misconceptions people have about it?
Francois Lasne: Let’s learn to walk before running, so starting with the basics i.e. account information data (all kinds of accounts, no need to restrict) will enable a lot of use cases e.g. cashback , account aggregation, scoring and so on. Then payments, both immediate and cross border targeting for sure reduction of cost. Having basic static data like product information is great as well.
Francois Lasne: One of the biggest misconceptions about Open Banking is that people believe that their data will be shared and resold as Google is doing whether or not they consent. Open Banking is more about users taking back ownership of their data that banks hold. With Open Banking users are the legitimate owners of their data, and it is only with their consent that it gets shared with providers of their choice.
Also people do not see the benefits of Open Banking because they are used to paying with credit cards. Despite the prefix ‘open’, Open Banking is actually much more secure than credit cards for making payments online.
Lastly, people fail to see an economic incentive. Here merchants should promote Open Banking by offering discounts, a way of passing on to customers the savings on the fees they’ve made, which otherwise would have been paid to card network providers.
Mahi Sall: What does Open Banking mean to banks and fintechs, and how does it affect the relationship between the two?
Open Banking enables banks to externalize their innovation labs to fintechs for free, at zero risk!
Francois Lasne: Banks might see Open Banking as a threat, as they need to provide ‘their’ data for free. But what we have seen in the EU is that Open Banking was a fabulous driver for innovation. All banks now in the EU provide account aggregation as part of their mobile apps. Most of them are pushing new services like cashback based on Open Banking, statement categorization while some are pushing green indicators and so on.
Also a lot of corporate flow goes to API for ERP connection. API has to be seen by banks as a new vector of distribution of their services. It has become the new virtual branch, the same way as mobile.
For TPPs we can see 2 approaches:
- Those wanting to partner as much as possible and get integrated inside a bank’s mobile app. Those are on the bank side, hence not a threat, rather an opportunity for banks! It is a bit like a way for banks to externalize their innovation labs to fintechs without cost!
- On the other side are fintechs that are more on the consumer side targeting for instance corporates with ERP integration.
Mahi Sall: How could banks and TPPs best prepare for Open Banking and extract the most value out of it?
Sitting in the middle are the aggregators. These are playing a very important role because as a TPP I would rather go to an aggregator who has set up all the plumbing instead of trying to connect directly with all banks on my own.
Francois Lasne: Banks need to have an API framework in place, run tests and provide support. Launching an API is like launching a new product. We all know that adaptation (so called bug) is required at the beginning, so be ready for some support activity. The same goes with onboarding as the onboarding might not be fully standardized.
TPPs being usually smaller are more agile and able to adapt, they will chase banks. Do not focus on a particular one, instead target multiple Banks as one might get stuck for a while. Starting several threads would be a safe path.
Mahi Sall: Given the very tight schedule of Canada’s Open Banking roadmap, where do you think the balance must be struck to meet deadlines without significant trade-offs?
Do not reinvent the wheel, leverage previous experiences.
Mahi Sall: What must be thought of and accounted for at this early stage of Open Banking in Canada in order to ensure compatibility and interoperability at regional/international level?
Francois Lasne: One key big accelerator would be to adopt or partner with an already existing big standard i.e. Berlin Group, OB UK or FDX. This would significantly reduce the design phase, although a bit of adaptation will be required, but the basis and documentation is solid.
Francois Lasne: Think big!
Do not focus only on regional payment schemes but make the framework flexible enough so that it can be extended. Then you may provide a discovery mechanism so that by code the TPP can discover whether or not this bank supports this feature.
# # #
Links you may be interested in:
Mahi Sall is an Ambassador of the National Crowdfunding & Fintech Association of Canada “NCFA”, and an Expert on Fintech-Bank Partnerships. He is based in Berlin, Germany.