Canada’s Open Banking Journey: Interview with Simon Redfern, Founder of The Open Bank Project & CEO of TESOBE
Originally published at https://ncfacanada.org on August 16, 2022
I believe open source is a sustainable force for social good. Open Bank Project was started in 2010 with the aim of raising the bar of financial transparency and enabling greater innovation around banks — Simon Redfern, Founder of The Open Bank Project & CEO of TESOBE
Mahi Sall: who is Simon Redfern?
Simon Redfern: I’m a software engineer, entrepreneur, musician and father living in Berlin, Germany.
In February 2010 I gave my first talk about the Open Bank Project — and evangelized the idea that every bank should have a RESTful JSON API protected by OAuth. Since then, my company TESOBE has worked with banks, regulators and Fintechs around the world providing advisory and technology in both innovation and production settings. I’m a strong believer in open source being a force for social good as well as making good business and security sense.
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. Can you speak about situations that would call for bilateral arrangements in an Open Banking environment that thrives on common rules.
Simon Redfern: I can’t imagine that would be healthy.
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?
Simon Redfern: In my opinion banks should have to jump through the same hoops as any other consumer of APIs. One of the first things banks will want to do is to consume each other’s APIs so that they can aggregate and provide a 360 view to their customers. Making banks also go through an accreditation process will encourage them to lobby for a simple 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?
Simon Redfern: I’m familiar with both UK and PSD2 approaches for having implemented them and their variants.
PSD2 itself was a huge document (75 pages I seem to remember) and unnecessarily hard to navigate. It (deliberately I guess) didn’t even mention the word API, let alone REST API. If a regulator doesn’t specify a standard, others will fill the gap like Berlin Group, STET, Polish API and possibly Open Bank Project did for PSD2.
Personally I’m in favor of explicit standards and I would even remove User Experience requirements (as specified in UK standard) which are fluffy and replace them with onboarding or consent APIs that banks use during the onboarding processes.
In other words, the standard should describe the whole journey with APIs, not just the part of the journey that actually gets data or initiates a payment.
Mahi Sall: In 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?
Simon Redfern: No, and why?
This was a hugely confusing part of the PSD2 document. I can only think it was there as a result of the bank’s lobbying and the reluctance to update their authentication flows. Allowing screen scraping as an alternative would provide an excuse to degrade the quality of the API service and then 3rd parties would be forced to use screen scraping. Screen scraping also breaks the “no credential sharing” principle. If a bank still provides screen scraping pages they should still have to provide first class APIs.
Mahi Sall: Please speak about lessons learned in terms of Open Banking test designs and implementation.
Simon Redfern: I don’t quite understand the question, but my 2 cents about testing would be:
- Provide Swagger / Open API files for the endpoints so that anyone can mock them.
- Provide very clear (no optionality) authentication / authorisation / consent flows.
- Provide clear guidance on the data quality returned via the endpoints.
- Provide a sandbox where 3rd Parties can test the above and read / comment on documentation.
Mahi Sall: As in other jurisdictions, financial inclusion is high on Canada’s Open Banking agenda. Please share examples where Open Banking failed to deliver on this metric. What are some of the key lessons learned that Canada could benefit from?
Simon Redfern: I’m not sure where it has failed but Open Banking does rather focus on accounts that exist. More could be done to provide APIs for helping customers improve / get a credit rating and applying for accounts. Endpoints for Products could help TPPs identify suitable products for the under banked.
Mahi Sall: Chief among the factors affecting the take-off of Open Banking is low adoption by consumers. What could Canada do differently than other jurisdictions in order to pre-empt this risk?
Simon Redfern: Some Banks in the UK did publicly mumble about security which probably didn’t help — but probably the chief obstacle has been the (repeat) heavy authentication hoops that the customer has to jump through. Canada could provide different authentication / consent mechanisms depending on what can be done with the resulting token. Maybe customers could also be given some choice regarding how many hoops they are forced to jump through. It’s the customer’s data after all. Maybe they are OK with a very simple flow to get their balance. Or a simple flow to make a small payment.
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?
Simon Redfern: Quick wins would mean Bank’s own data as open data e.g. Products (financial inclusion use case), Branches & ATMs. Then Account Application (financial inclusion use case). In terms of Customer data, get balance, get transactions.
Mahi Sall: What role does talent play in developing a thriving Open Banking system?
Simon Redfern: There’s a virtuous circle of Talent builds APIs -> Talent builds Apps -> Consumers enjoy Apps -> Bank wants more APIs.
Talent is needed at the TPP to build exciting and easy to use Apps and at the bank to enable the API platform.
Mahi Sall: What are some of Open Banking’s major incidents and how to risk manage them?
Simon Redfern: Not that I know of — but don’t let hackathon participants near your data center with cameras and twitter accounts!
Mahi Sall: Speak about Open Banking limitations and the most common misconceptions people have about it?
Simon Redfern: That it’s only about customer data and not the bank’s own data. In my opinion banks should be mainly API driven, thus opening up many areas of their business to innovation.
Mahi Sall: What does Open Banking mean to banks and fintechs, and how does it affect the relationship between the two?
Simon Redfern: Well, banks will end up being Fintechs too, in that they will consume other Banks’ APIs. In the end there will be little difference.
Mahi Sall: How could banks and TPPs best prepare for Open Banking and extract the most value out of it?
Simon Redfern: Use a sandbox, code an App calling the API complete with dynamic data, onboarding and authentication and watch customers use it.
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?
Simon Redfern: Use API versioning, be very explicit about Auth flows. Start with limited scope (read only / banking open data) for the first release.
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?
Simon Redfern: Use https, REST and JSON, OAuth, MTLS etc. The “rest” doesn’t really matter as it will never be identical.
Mahi Sall: Any final thoughts?
Simon Redfern:
- One thing I’ve seen regulators miss out or ignore is the copyright / attribution of the standard. I’ve several times seen a Swagger file which is clearly based on the UK standards having the copyright set to TBC. Maybe the question could be “Under what license would you like the resulting standard to be provided ?” Related: “Under what license should customer / bank data be provided?”
- Another thing would be to consider multiple financial institutions, banks or brands within one API host. This is not catered to in either the UK or Berlin group standards, which forces implementers to use different hosts or path prefixes which muddies the URL space / naming conventions. Single FI per host might result from strict certificate requirements but you might ask the question: “Should the API standard cater to different bank or financial institution brands being served from one host?” — Aggregators might do this anyway, so why not build it into the standard.
- Lastly : “How should the API standard deal with optional JSON fields?” Important: “How should we monitor Quality of Service and Availability?”
# # #
Links you may be interested in:
Mahi Sall is an Ambassador of the National Crowdfunding & Fintech Association of Canada “NCFA”, and an Expert in Fintech-Bank Partnerships. He is based in Berlin, Germany.
