Canada’s Open Banking Journey: Interview with Abe Karar, Chief Product Officer, Fintech Galaxy

Originally published at on November 7, 2022


“Open Banking is here to stay! Therefore, all participants should start preparing their strategies now — both Banks and TPPs.” — Abe Karar, Chief Product Officer, Fintech Galaxy

Mahi Sall: Please tell us a bit about yourself?

Abe Karar: As the Chief Product Officer at Fintech Galaxy, I guide the design and development of FINX, our Open Finance platform, with its two key offerings: FINX Connect, our Open Banking API Aggregation solution, and FINX Comply, our Open Banking Regulatory Compliance suite. In addition, I work closely with Regulators, Financial Institutions and FinTechs to drive Open Banking/Open Finance adoption and support the innovation agenda across the region.

Before joining Fintech Galaxy, I spent about 15 years working at some of the largest Financial Institutions in the world, including BMO Bank of Montreal, JP Morgan Chase, Bank of America, First Abu Dhabi Bank (FAB) and Arab Financial Services (AFS). During that time, I have held various leadership roles across Data Analytics, Digital Transformation, Retail, Corporate, Card, Operations, Customer Experience and Risk.

I’m a proud Canadian who spent about half my life in Canada and being able to contribute to the adoption of Open Banking in Canada is an opportunity for me to give back to my country.

Our vision at Fintech Galaxy is to build the most secure, reliable, and developer-friendly Open Finance platform in the world. Our mission is to drive the adoption of Open Banking and Open Finance, put the power back in the hands of the customers (individuals and businesses), and revolutionize inclusive Financial Services.

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.

Abe Karar: Common rules facilitate and simplify the interaction between participants in the Open Banking ecosystem, as it clearly provides a framework to protect consumers and place the liability on the party at fault. This creates a level playing field that generally eliminates the need for bilateral arrangements. However, when market players wish to implement certain use cases that fall outside of Open Banking (e.g., Banking-as-a Service, Open Finance, etc.), then specific bilateral agreements become necessary.

Take, for example, a logistics company providing services to merchants that would like to deliver goods to their buyers. Leveraging Open Banking would allow a regulated entity to enable account-to-account payments while partnering with the logistics company’s banking provider to manage dedicated settlement accounts. This would allow the collection of funds using Payment Initiation Services (PIS), reconcile received funds and facilitate payouts to the merchants at the end of the period. Everything outside the regulated payment flows would fall under bilateral commercial agreements between the merchant, the logistics company, and the banking partner offering the settlement account.

Another example is related to one of the most recent Open Banking use cases in the UK, Variable Recurring Payments (VRPs), where we see the need for the Regulator to intervene in order to streamline common standards and reduce bilateral agreements for better harmony across the ecosystem; otherwise, TPPs would end up in a spiral of counter-productive arrangements.

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?

Abe Karar: When it comes to the accreditation process, we should consider the two key entities involved in Open Banking: ASPSPs and TPPs. In order to smooth out the process, a good approach is to look at some of the best practices from leading markets, such as Australia and the UK.

The Canadian market shares many similarities with its Australian counterpart, so, in my opinion, we should consider the latter as a great point of reference. To operate in a similar setting as that of the Australian Consumer Data Regulation (CDR), Financial Institutions must register as “Data Holders” and meet requirements related to Technology, Consent, Security and Reporting.

Australia began with its biggest four Banks, followed by the rest. Whether it is a government-regulated Bank or not, all “Data Holders” (i.e., all Banks and Financial Institutions in Australia) are subject to complying, with specific commencement dates, with the following:

  • Disclosing consumer data
  • Establishing dispute resolution services
  • Keeping appropriate records
  • Reporting at scheduled intervals
  • Complying with the relevant Privacy Safeguards

On the other hand, “Data Recipients” (i.e., Third-Party Providers in Australia) need to satisfy the following requirements to become accredited:

  • Have taken steps to adequately protect data from misuse, interference, loss, unauthorized access, modification, or disclosure
  • Have an internal dispute resolution process meeting the requirements of the CDR
  • Belong to a relevant external dispute resolution scheme
  • Have adequate insurance to compensate CDR consumers for any loss that might occur from a breach of the accredited data recipient’s obligations
  • Have an Australian address for service

As we see, both Banks and TPPs have their own accreditation exercise, which I believe is natural since they are involved at the two ends of the supply and demand cycle of Open Banking/Finance; however, neither is excluded. This approach ensures that only those in compliance with the regulatory and legal requirements, meant to protect all parties and especially the end-users, are allowed to operate under the Open Banking/Finance framework.

Inevitable frustrations might occur during the accreditation process. It’s important to acknowledge them from the start and promptly and adequately address them along the way. Looking at how Banks and TPPs from other regions have handled them might serve as a good example of “How to” or “How not to” do it for Canadian Open Banking ecosystem participants. The following are some high-level challenges and some potential mitigating remedies:

Big-time Investments

Some may regard Open Banking’s adoption in Canada as the “Kodak moment” for Financial Services, but Banks and TPPs will see the costs involved initially with no clear revenue in the short- or medium-term. There will be compliance obligations, which from other markets’ experience, come with high technology costs upfront, without a clear business case to recover these costs or a clear monetization strategy for the Open Banking provider. This lack of visibility is often primarily attributed to a lack of customer focus.

Mitigation: Start thinking about protecting and enhancing the relationship with your end users in the new Open Banking paradigm, especially by ensuring the protection, security and ownership of their data, opening up channels of communication, and ensuring the right liability models are in place. Consider the customer journey in various use cases, from running a business to paying for goods and services. Assess how you can deliver the Open Banking-based upgrades to the customer.

Unifying Data

Another challenge refers to finding a means to pull and consolidate all necessary data from various sources into one single homogenous view. For Banks, this ensures that the data they provide to TPPs is normalized, accurate and easy to extract from its core systems. For TPPs, this brings up the need to ensure they have the knowledge and capability to ingest the necessary data and integrate it into the final source, all while adhering to Banks’ requirements.

Mitigation: Banks must ensure they have all data sharing policies for managing data requests. They should also be technically ready to open access to the data. TPPs must not remain behind and should start testing alongside Banks to determine how this will optimally work. It is expected to go through a phase of “Test-Fail-Learn,” and there will be multiple iterations. However, it’s highly recommended to get started early so that by the time Open Banking regulations arrive, both Banks and TPPs will have covered critical groundwork and be ready to start working together in the new reality.

Compliance and Change

The new regulation brings new rules to the game, which means that much of the way things have been done till now will change. It can be challenging to accept that and initiate the change process, new strategy, organizational structure, policies, and so on. Add all this to the fact that not all Banks are entirely on board with moving from a closed to an open environment, and we’ll be witnessing progress almost at a standstill.

Mitigation: Change is never easy, but it is necessary. Skip the “Resistance” phase and jump right into preparing for it. Have external and internal audits to establish the readiness for the Open Banking programs, look for vulnerabilities, and look for ecosystem enablers/partners in the market to help achieve compliance more effectively and efficiently (e.g., compliance-as-a-service providers, aggregators, etc.). Earmark adequate funding in the budget for all the preparation aspects and adjust your strategies.

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?

Abe Karar: From my point of view, technical standards and common rules are quite complementary; the latter regulates the interaction between Open Banking players, while the former ensures standardization around exposing and consuming APIs, authentication and authorization, consent management, user journeys, and SLAs.

I believe standardized technical specs are critical to reducing friction and driving adoption and coverage since both Banks and TPPs are bound to speak the same language. This leads to building reliable, performant APIs that enable scalability of use cases and value optimization, especially with interactions across regions adopting the same specs.

Just look at today’s environment, where we have various standards, such as Open Banking UK, STET, Berlin Group, Bahrain Open Banking Framework and others, each of which is defined and implemented differently. Despite such standards, the implementation of which seems to vary due to the different interpretations of the various players. As an example, at the beginning of the Open Banking journey, some Banks didn’t even include an IBAN within their API data model.

Therefore, in my opinion, an explicit standard that doesn’t leave much room for misinterpretation is a must. When multiple standards co-exist within a given region, TPPs trying to operate cross-border may need to redo some of their integrations; unless they’re using an aggregator, these TPPs would need to remap the appropriate API endpoints to a given standard, adjust the consent management flows, and align operational and customer experience guidelines.

On the other hand, Open Banking/Finance aggregators establish their simplified API contract independent of the underlying regulatory standard. Depending on where a TPP connects, the aggregation layer will automatically map to the API endpoints based on the appropriate standard. Aggregators are doing that to simplify collaboration between market players, streamline the process and ensure a cohesive and frictionless interaction between TPPs and Banks.

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?

Abe Karar: First, let’s take a moment to clarify what we mean by Screen-Scraping and Modified Customer Interface (MCI). The former refers to the automated process of gathering data from a customer’s Internet Banking portal by simulating their logging in with their credentials and viewing account and transaction information. The latter refers to a secure interface, usually built on top of a Bank’s web or mobile banking interfaces, as a “proxy” with the added functionality of TPP’s certificate validation. This modified interface enables TPPs to access the designated account of a customer through their web or mobile banking only after presenting a valid certificate that identifies them, the TPP, to the Bank. The MCI should hide/block the rest of the information that is out of scope (e.g., user profile details, settings, etc.).

Despite earning somewhat of a bad reputation due to the need to share customer credentials, both Screen-Scrapping and MCI have been used for years as alternatives to Open Banking APIs, especially in markets where the Open Banking regulations are not mature enough, and they have also been used as fallback options to existing APIs in Open Banking regulated markets.

However, it’s important to note that neither Screen-Scaping nor MCI can provide the same level of reliability, scalability, quality and security as high-quality, compliant Open Banking APIs. Therefore, Banks should be mandated to provide high-quality, compliant APIs, even if they continue to use the Screen-Scrapping or MCI as a fallback option only.

Mahi Sall: What are some of the lessons you’ve learned in terms of Open Banking test designs and implementation.

Abe Karar: This implementation phase can be described as a “Controlled Production Validation”, where TPPs conduct tests in a controlled production environment to solidify the technical implementation, accreditation process/criteria and supporting policies/regulations.

We see a similar approach adopted in Bahrain and Saudi Arabia under their Regulatory Sandbox, where authorized TPPs are allowed to validate their solution with a select group of customers from selected Banks with contractual agreements and within certain limits, such as the number of authorized transactions per month or the transactions amounts per day, the number of data pulls, etc. TPPs are required to provide a monthly report outlining all validated scenarios, expected outcomes, technical challenges, security, customer experience, etc. This also allows Regulators to observe and learn first-hand, accordingly introducing adjustments to the technical specs, accreditation processes, licensing policies and regulations. However, it’s critical that the testing is expansive and thorough across all scenarios and expected outcomes. More importantly, the enforced limits are not too restrictive not to miss out on capturing some potential issues that may have severe repercussions if they were to occur in production.

Support from the Banks and Regulators is absolutely crucial for the success of this phase. Banks need to provide the right level of support to the TPPs looking to integrate and consume their APIs, and Regulators need to ensure that the Banks are doing their part by providing high-quality APIs, documentation and proper support within reasonable SLAs.

User experience is another critical area of focus. We’ve seen that early on, most Banks just concentrated on becoming compliant with the regulations, ignoring that the journeys and flows should be built for end-consumers. However, user experience has become a hot topic in Open Banking, addressing the known fact that users mostly use mobile banking apps and that App-to-App redirects should be a requirement so that customers have a familiar experience when going through the Open Banking authentication and authorization flows.

One more area to draw on lessons learned from is Change Management. Any regulated access is subject to renewal processes; in other words, to stay secure and compliant, TPPs and Banks are required to renew their Server and Client certificates. While the process is trivial, it is critical when customers rely on processing live API traffic all the time, and scheduled maintenance for these customers is basically the same as downtime.

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?

Abe Karar: First, it’s essential to understand that Financial Inclusion is focused on ensuring that Financial Services are available to more of the world’s population at a reasonable cost. This means that we need to look at both the underbanked (i.e., individuals or business entities with limited access to the whole gamut of financial products and services, such as credit cards, loans, etc.) and unbanked (i.e., individuals or business entities who don’t even have access to Banks accounts and thus solely rely on cash, salary cards or Digital Wallets). This is by no means an easy feat; the World Bank estimates that some 1.7 billion adults worldwide still lack access to a basic Bank account. The MENA region has an estimated 47% of the population that don’t hold an account at a Financial Institution, with an estimated 39% in the Arab world. Open Banking and Open Finance can help with that.

What’s interesting is that the unbanked segment in this region, despite potentially having access to a digital wallet, or a salary card supported by a mobile app, will typically have two main transactions in a month: (1) The deposit of their income (i.e., salary), and (2) the withdrawal of the entire deposited income amount, and then transacting throughout the month using cash. This, unfortunately, eliminates all the behavioural data and analytics that can be used to provide better access to products and services. However, what’s even more interesting is that despite some Open Banking regulatory frameworks supporting alternative payment utilities, with API specifications including an account type/subtype attributes for Digital Wallets, Salary Cards, etc., we don’t see many implementations.

However, if properly implemented, Banks and Financial Institutions can better understand the overall financial footprint by leveraging Open Banking transaction data to offer better access to lending facilities and payment options. However, it’s absolutely imperative to allocate the right time and resources towards enhancing financial literacy of the population, boosting usage, and enhancing overall financial inclusion.

Another challenge we’ve seen in MENA is that, with the exception of Saudi Arabia and SAMA’s efforts, Open Banking has primarily targeted Retail use cases and lacks focus on Business use cases. In today’s environment, if you want to pull in transaction data for an SME, there aren’t many FIs that have Open Banking compliant APIs available. Bahrain, for example, has been the leader in bringing Open Banking to the region and the Bahrain Open Banking Framework has been around for almost three years; however, there hasn’t been any significant Corporate/Business use case implemented. For example, SMEs seeking financing would have to go through a traditional paper intensive route, requiring them to provide three years of audited financial statements. However, Open Banking provides a source of truth through a standardized interface, enabling automation and straight-through processing (STP). In addition, Banks and Financial Institutions will rely mainly on Credit Bureau reporting to adjudicate a credit application. However, Credit Bureau reporting may reflect outdated information and doesn’t always provide a complete picture of the SMEs’ financial ability and stability.

Therefore, leveraging Open Banking account/transaction data can provide a better mechanism for Banks and Financial Institutions to assess SMEs’ credit eligibility, enhancing overall financial inclusion.

In conclusion, I would highly recommend focusing on the following lessons learned:

  • Regulators should make Financial Inclusion one of the core mandates for the Banks and TPPs operating with the Open Banking framework
  • Exploit opportunities for leveraging Open Banking for Digital Wallets to extend value-added services to unbanked segments
  • Establish a well-defined and coherent plan for becoming a cashless society
  • Reinforce the use of Open Banking payments as a foundation for digital payments
  • Extend Open Banking use case implementation beyond the Retail consumer segment; Business (SME/Corporate) use cases should be included from the start
  • Introduce Open Finance “Action” APIs to facilitate access to more diversified products and services that are specifically designed for the underbanked and unbanked
  • Ensure that the entire ecosystem is connected and that all Banks and Financial Institutions are complying and implementing the same Open Banking standards

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?

Abe Karar: It’s Imperative first to understand what is causing the low adoption by consumers, whether Retail or Business. The main challenge the market is currently facing in Open Banking is the lack of a comprehensive single unified approach that supports all parties, from complying with local regulations to identifying the relevant business use cases and then ensuring optimal value is delivered to all participants. In other words, there are some fundamental flaws in the existing Open Banking model globally:

Banks and Financial Institutions are not seeing the value

  • Banks and Financial Institutions struggle to provide Value-Added APIs on top of Open Banking to generate revenue, which leads to a higher barrier to entry into Open Banking as a TPP

Not enough quality/support for TPPs:

  • TPPs receive insufficient support from Banks and Financial Institutions outside of minimal compliance requirements
  • Differences in the available API endpoints, data elements, payment products, payment fees for end-users, authentication journeys, and even API onboarding requirements lead to fragmentation in available API features within TPPs offerings

Subpar experience, lack of awareness and lack of large-scale use cases:

  • There is no Change Management in Open Banking certificates handling, which means any service can stop working due to issues with individual TPP certificates for each Bank or problems with the certificate’s renewal process
  • Available payment products and related fees are not known in advance to the end-user, merchant or TPP (i.e., Bank transaction fees, transaction settlement period, eligible payment account, etc.)
  • Open Banking payment journeys, including authentication journeys, are so inconsistent and overcomplicated that users find it easier to use existing outdated familiar payment instruments
  • Having enough use cases on the market to meet demand, and that are part of customers’ day-to-day life, add value and supported by a sustainable fair practices will help with adoption; this is evident with the decision of the UK’s tax authority, HMRC, to enable tax payment using Open Banking, which reached £1 billion (about $1.35bn) in tax — via more than 500,000 individual payments by Sept 2021

No unified solution for Merchants and Business clients:

  • Not all Bank accounts (i.e., investment, saving, mortgage, corporate payment accounts) are available via Open Banking APIs, as well not all details about transactions are always available (e.g., counterparty details)

So, it’s clear that the low adoption risk can only be mitigated with a three-prong approach focusing on (1) the transformation of the Banks/Financials Institutions, (2) offering a better-quality support to TPPs, and (3) providing customers (both Retail and Business) with more awareness, enhanced tools, a better experience, and prevalent use cases that engage and add value.

Banks and Financial Institutions need to understand the value of Open Banking and move away from the mindset that Open Banking is a forced Regulatory checkbox exercise. They need to do more than the bare minimum for compliance and focus on making things easier for TPPs and consumers. Banks and Financial Institutions must do their part, develop innovative use cases and push them into the market. Why stick only to compliance when you could create new strategic revenue streams with the monetization of APIs?

Additionally, issuing some powerful informational campaigns showcasing the value of Open Banking to consumers will accelerate adoption. Users need to understand how Open Banking can help enhance their overall financial well-being; leveraging some of the new and innovative solutions developed by TPPs will allow them to make more informed decisions about their finances, reduce costs, and save more. Based on research conducted by the UK Open Banking Implementation Entity (OBIE), there is a much higher adoption rate of Open Banking when consumers understand the value.

Here are a few key supporting metrics from the OBIE’s Open Banking Impact Report published in October 2021:

  • 55% have acknowledged a reduction in fees and costs
  • 62% have reduced unnecessary expenses
  • SMEs have noticed a 17% improvement in user experience

Additionally, Businesses, both SMEs and Corporates, in regions where Open Banking has been adopted earlier, acknowledge that it has provided them with improved access to loans, direct settlements, lower payment acceptance costs and more streamlined operational processes; all of which are of huge benefit to any business.

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?

Abe Karar: Considering some of the learnings from other markets, there some key use cases across Retail and Corporate that have proven to deliver value quickly:

Corporate Use Cases:

  • Treasury Management — This allows Businesses to access an aggregate view of their balance and transaction information in real-time. Whilst this information has always been available, it will now become easier to obtain and integrate directly with their back-office systems, hence leading to better and more efficient liquidity management.
  • Merchant Pay-by-Bank — Provides merchants with the ability to easily accept direct Bank account payments online and at the point of sale, hence eliminating the need to accept Credit Cards, and in turn, reducing interchange costs and preventing fraud.
  • Direct Accounting Integration — This allows Businesses to integrate their accounting software with the Open Banking APIs to automate the retrieval of financial transaction history, create useful financial insights, and optimize financial reporting, such as for statements of accounts, balance sheets, and annual taxation reports.
  • Business-to-Business Payments — Provides payment capabilities that enable Businesses (SMEs and Corporates) to easily make payments to other Businesses no matter which Bank they have, hence making it easier to move funds around the banking system.
  • Tax Filing-as-a-Service — Providing reconciliation of a Business Customer’s debits and credits for their selected payment accounts across multiple Banks against their accounts’ payables and receivables, allowing faster, easier and more accurate tax filling submissions, in accordance with all requirements of government tax authority, hence reducing tax leakage, administrative costs and penalties, and enabling better visibility on taxes.
  • Letter of Guarantee-as-a-Service — Enabling Business customers to request their Bank to issue a Letter of Guarantee (LG) and make it available directly to the LG requestor, hence automating the process, minimizing the risk of disputes and fraud, and improving the flexibility and efficiency of handling of LGs.

Retail Use Cases:

  • Extended Customer Attributes — Providing the ability to capture some of the customer’s information (e.g., KYC) to achieve smarter and more secure onboarding to various services that require such information.
  • Digital Identity Verification — Verifies customer identity using Open Banking APIs to match account owner information stored in different places which simplifies onboarding, reduces the cost of manual processes, and removes the hassle of submitting documents in any form. This simplifies onboarding, reduces the cost of manual processes, and removes the difficulty of manually submitting
  • Credit Assessment — Leveraging Open Banking transaction data to augment Credit Bureau information and to enable lenders to make more informed decisions on loan applications, as well as streamline the loan filing process, leading to higher conversion and enhanced customer experience.
  • Robo Advisory — Robo-advisors are digital platforms that provide automated, algorithm-driven financial planning services with little to no human supervision. They collect information from clients and use the data to offer advice and subsequently invest in client assets.
  • Peer-to-Peer Payment — Enables customers to make direct, secure, cost-effective and frictionless account-to-account payment transfers across the Open Banking network. Additional value-added services such as Bill Splitting, RTP (Request-to Pay) and social media integration can be introduced as enhancements.
  • ROSCA — Digital Saving Services often ‘Pooling’, where members pool their money into a common fund, generally structured around monthly contributions, and a single member withdraws the money from it as a lump sum at the beginning of each cycle. Open Banking Account Information Services (AIS) pull transaction data to validate individual risk, and Payment Initiation Services (PIS) to support the movement of money (i.e., pooling and dispersing).
  • BNPL (Buy Now, Pay Later) — This is far from being something new on the market and has been offered for a while using store credit cards. The difference is that Open Banking is revolutionizing the concept and allowing consumers to validate funds, expose their income streams via Account Information Services (AIS) and schedule future payments using Payment Initiation Services (PIS).
  • Statement-as-a-Service — Providing a service to obtain transaction data from their payment accounts to create an e-statement and make it available to the e-statement requestor, removing the need to provide the statement manually.
  • Variable Recurring Payments (VRPs) — Allowing customers to connect authorized payments service providers to their Bank account safely and to make a series of flexible payments on customers’ behalf within agreed parameters, removing the need for SCA for every payment, offering more control and transparency, and enabling sweeping (i.e., automatic movement of money from one of their accounts to another of their accounts). This can facilitate many valuable use cases, such as enhanced savings, avoiding overdrafts, reducing costs of international payments, presenting new options for subscriptions, and introducing tax efficiencies, amongst a myriad of other value-added use cases.

“Driving Financial Services requires Speed, Scale, and Skill — the 3S principle.”

Mahi Sall: What role does talent play in developing a thriving Open Banking system?

Abe Karar: Indeed, talent plays a significant role in developing a prolific Open Banking environment. Open Banking is the framework, but it is the talent that activates, innovates and delivers value on it. It is also important to note that it’s not just technical talent that is critical for developing APIs and innovative solutions on top of them; it is just as crucial to deploy talent that can straddle both business and technology, understand and implement regulatory/compliance requirements, develop new business models, and create exceptional user experiences. Moreover, attracting talent with expertise in implementing Open Banking/Open Finance in other leading markets is one of the most valuable assets that can accelerate the development of the ecosystem in Canada.

Talent will play a critical role in Canada’s Open Banking journey in some of the following contexts:

  • A thorough understanding of Regulations around Data Privacy, Consumer Protection, and Cybersecurity will ensure that regulatory frameworks are clear, concise and strike a balance between risk and innovation
  • A solid grasp of new business models (e.g., platform business models, API business models, etc.) will allow for new revenue streams to evolve and will create new business opportunities for both Financial Institutions and TPPs
  • Customer obsession brings forth some of the best journeys and user experiences, which are essential for adoption and value creation
  • Coopetition coupled with partnerships are crucial for a flourishing Open Banking ecosystem; it takes special talent to uncover these types of relationships and opportunities to bring real value to life

So, in my opinion, the perfect formula of skills for Open Banking talent, is: Practical Experience + Regulatory Understanding + Technical Knowledge + Customer Obsession + Business Value Creation + Partnerships

Mahi Sall: Talk about Open Banking limitations and the most common misconceptions people have about it?

Abe Karar: One of the biggest misconceptions out there is that Open Banking is nothing more than a mandatory regulatory compliance checkbox exercise for Banks and Financial Institutions. As a result, they are doing the bare minimum to keep the Regulators at bay, and in the process, they provide TPPs with limited support, lower quality APIs/SLAs, etc. Many Banks and Financial Institutions lack to see that Open Banking and, more importantly, Open Finance can generate tremendous value across the value chain. However, this depends on having a unified Open Finance technical infrastructure, SLA/support/quality guarantees, and the legal and commercial framework in place. This offers Banks and Financial Institutions an opportunity to consolidate their market position, uplift their competitive advantage, create new product lines/offerings in the market, and improve their relationship with their Retail and Business customers.

There is also another major misconception about data sharing, especially to those unfamiliar with the concept of Open Banking. Natural persons have been taught for decades about how important is to hold their Bank accounts’ data secret, and now, the paradigm has shifted, and they are encouraged to share their data to avail better products and services. Unfortunately, there is a vast gap in awareness and understanding that leads to natural fear around security and privacy. However, we have seen that the level of acceptance of this paradigm shift supported by two powerful forces: (1) Open Banking bringing innovation into the banking sector, on the one hand, and (2) data protection-targeted regulation, including GDPR and others, on the other hand. The truth is that, despite the tension arising around data privacy, security, etc., both Open Banking regulations and data protection legislation worldwide have a similar objective: to give users the power over their own data. However, to achieve the full vision of Open Banking, all market participants need to take a proactive approach to educating consumers on the technical and regulatory mechanisms in place to safeguard data, investing in scalable, stable, secure infrastructure, and leverage some of the Open Banking capabilities and innovations (e.g., Strong Customer Authentication — SCA, Cofractionating of Payee — CoP, etc.) to create solutions that are as safe and secure as they are innovative.

Then there is this whole aspect around data residency and the limitation it brings to some of the Open Banking use cases (e.g., Treasury Management for Businesses operating across the region and globally). In such cases, Open Banking involves providing a single aggregated view of all the accounts balances and transaction data from various Banks operating in different jurisdictions. However, some regulations do not allow for data to leave the country. Take, for example, a corporate client with Bank accounts in three different jurisdictions (e.g., Bahrain, Saudi and UAE), and needs to aggregate all the balances in one view; there has to be a way to accomplish this while working around the data residency requirements. This is also important for specialized processes, such as data enrichment, financial insights, etc., where algorithms require higher processing power and thus need to run on the cloud.

Another misconception is that consumers are not ready to adopt Open Banking just yet. Well, that is simply not true. Take Saudi Arabia, for example. A Deloitte FinTech study found that KSA leads the region when it comes to FinTech adoption among consumers for satisfying banking needs; about 82% of respondents were willing to try Open Banking solutions — quite an impressive majority. In this light, it’s important that the core team tasked with implementing Open Banking analyzes the true potential of the market and how Open Banking can become a driver of commercial opportunities for the various participants and incorporates these findings into the Open Banking strategy, design and implementation.

One more misconception, which is quite popular, is that Open Banking is limited to Payment Accounts (i.e., Current, Savings, Credit Cards, etc.). However, there are many opportunities to leverage Open Banking in new, maybe even not yet explored, use cases. For example, we haven’t seen a significant uptake with Digital Wallets, Salary Cards, Loan Payment Accounts, etc., despite being clearly stated as valid scopes of Open Banking within published standards and frameworks, not to mention how Open Banking has already started to see an evolution to include more financial products and services under Open Finances.

Mahi Sall: What does Open Banking mean to banks and fintechs, and how does it affect the relationship between the two?

Abe Karar: Let’s start by saying that both Banks/Financial Institutions and FinTechs/TPPs have a critical role to play in Open Banking; however, it’s important to understand the different viewpoints that each have and what Open Banking really means to each .

For Banks and Financial Institutions, Open Banking means:

  • The necessity to upgrade the infrastructure to ensure more efficient, robust and secure integration with Open Banking APIs
  • Exploring more collaboration opportunities with FinTechs
  • Embracing a shift in mindset and organizational culture and fostering innovation
  • Discovering new monetization models for value-added APIs

For FinTechs/TPPs, on the other hand, Open Banking means:

  • More space for innovation
  • Getting closer to consumers by offering a seamless user experience
  • Increased revenue streams
  • Greater opportunities for cross-border expansions

Drawing on the above, the relationship between Banks and FinTechs should be characterized as “coopetition”. Historically, Banks took an aggressive approach to acquiring FinTechs that posed a threat to eliminate the competition. Then, Banks started to realize that this was not the most effective approach and that they didn’t really need to buy out the FinTechs; instead, they could simply work together — the old saying goes: “if you can’t beat them, you join them.”

It’s interesting to see how, over time, FinTechs and Banks have become complementary in supporting the needs of end-consumers, both individual and business. We have seen many examples in MENA, the UK, Europe and Asia where the cooperation between FinTechs and Banks has proven to be a win-win situation. One good example is seeing how Open Banking facilitates the introduction of new API consumptions patterns, where flipping the supply and demand can bring forth some exciting and value-added propositions:

Banking-as-a-Service (BaaS) — Banks exposing “Action” APIs to FinTechs (TPPs) to enable “write” access to a broader range of financial products and services; eKYC, opening accounts, issuing cards, etc., amongst many other essential capabilities.

FinTech-as-a-Service (FaaS) — FinTechs exposing their APIs to Banks and Financial Institutions to be embedded implicitly into their solutions under a white-labelled partnership model.

Banking-as-a-Platform (BaaP) — Banks are embedding the FinTech APIs into their solutions under a partnership model with explicit branding, which is typically the case with super apps.

One final thought: I’d like to share the 3S principle: Driving innovation in Financial Services requires Speed, Scale, and S kill. Typical Banks have the scale but lack the skill to work with the latest technologies and certainly don’t have the speed of decision making and implementation. FinTechs, on the other hand, have speed and skill; however, they need access to scale through Banks. So, as you can see, it’s a natural complement.

Mahi Sall: How could banks and TPPs best prepare for Open Banking and extract the most value out of it?

Abe Karar: Open Banking is here to stay! Therefore, all participants, Banks/Financial Institutions and FinTechs/TPPs, should start preparing their strategies now.

Banks/Financial Institutions need to develop a robust API strategy in support of Open Banking, Open Finance, Open Data, and eventually the Open Economy:

  • Identify means for real-time verification of TPPs identity and regulatory status to ensure no unauthorized access is granted to consumer data
  • Proactively establish effective risk mitigation practices, especially around fraud, AML, CTF, etc. across key journeys (e.g., Onboarding, Payment Initiation, etc.)
  • Prepare for the cultural and mindset shift towards “Open” Banking and ecosystem collaboration
  • Explore the various types of partnerships that would best serve their short and long-term goals
  • Implement best practices from other similar markets. For example, Australia has been quite successful with its CDR implementation, and its leap into Open Finance and Open Data, and so has the UK with its Open Banking implementation, and Brazil with its Open Finance and Financial Citizenship
  • Look for means to create more value than the Regulatory scope; this will considerably help recover their investments compliance
  • Think ahead; think beyond Open Banking straight into Open Finance, Banking as-a-Service, Open Data, and eventually embedded finance within an Open Economy

FinTechs/TPPs should also start preparing for Open Banking, and ensure that their strategies take into consideration some of the following:

  • Verify if their solutions can leverage Open Banking APIs and, if not, start For example, FinTechs that have historically relied on Screen Scrapping or MCI will now need to redevelop their flows and technology stack to ensure compliance with the regulation
  • Proactively examine some of the existing Regulatory Technical Specs (RTS) from other more advanced jurisdictions, like CDR, and PSD2, to at least have a baseline understanding of what to expect until the Open Banking regulation becomes available in their own jurisdiction
  • Commence the licensing process of being a regulated entity, which includes, but is not limited to, Regulatory Sandboxing, ISO certifications, business model validation, etc.
  • Implement proper Change Management around Open Banking certificates handling, to prevent issues with individual TPP certificates for each Bank or problems with the certificate renewals, and hence ensure service continuity
  • Establish comprehensive policies and liability models, customer dispute processes, customer support channels, vulnerable customer handling, etc.
  • Start spreading awareness about the benefits of Open Banking among their end users; TPPs are asking for access to data, so they need to educate the consumers on why consent should be granted and why it is highly secure.

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?

Abe Karar: I would highly recommend taking a phased approach, starting with the “Big Five” Banks: RBC, BMO, CIBC, TD, and Scotia Bank. This is similar to the approach adopted in the UK, where the implementation of Open Banking started with the CMA9, the nine largest banks regulated by the CMA.

The logic is that Canada’s Big Five represent most of the Canadian market and have the appropriate resources, which will help expedite adoption across the country. However, in my opinion, the key success factor is collaboratively working with the Regulator to construct a National Open Banking Compliance Infrastructure with one unified API gateway, thus reducing integration effort across the network and offering better SLAs, quality and support to the TPPs, as well as better governance, performance monitoring and oversight to the Regulator.

This is typically referred to as a “Consortium” approach, which has been implemented successfully in other jurisdictions around the world, such as LuxHub in Luxemburg, the CBI family of Banks in Italy, and RedSys in Spain; all great examples of how things can be done differently, while striking the right balance for expedited and cost-effective implementation. This consortium approach can be replicated in Canada, either as “Bank-led” by the Big Five, or as “Regulator-led” in a joint venture with the Banks.

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?

Abe Karar: When it comes to Open Banking, the notions of compatibility and interoperability involve having common standards that mimic the specifications of the surrounding regions and global markets. One approach to driving interoperability and compatibility is to develop an Open Banking layer that is agnostic to the various standards leveraged in other jurisdictions — this is typically referred to as an aggregation layer. Such aggregation layers usually have regional coverage and provide connectivity via a unified API, traversing regulatory frameworks. This is exactly what we are doing at Fintech Galaxy with our FINX Open Finance platform — building a homogeneous, secure, affordable, and scalable infrastructure layer across the entire 22 Arab markets in the region, with the vision to expand coverage and connect the ecosystem globally.

Another practical approach for Canadian Banks, especially those who have a presence in other jurisdictions where Open Banking or Open Finance has already been implemented, is to explore the extensibility and backwards compatibility of Open Banking/Finance with their systems in Canada. This will provide an opportunity to test and learn based on best practices and lessons learned, shorten the time to market, and facilitate cross-border interoperability early on.

Lastly, the true answer to ensuring compatibility and interoperability lies in collaboration between the Banks, Financial Institutions and TPPs across the various jurisdictions. The goal should be to work with them, test with them, adjust with them, and work together to arrive at a seamless flow. Imagine how much value this would bring to the customers of these Banks, especially with being able to move their activity from one country to another.

Mahi Sall: Any final thoughts?

Abe Karar: As mentioned earlier, Canada should consider leapfrogging Open Banking straight into Open Finance. In my opinion, even if the roadmap needs to be extended, it should be towards the target state of a globally connected Canadian Open Finance Hub.

There should be a clear strategic path for evolution toward Open Data, and then the Open Economy. Yes, Open Banking/Finance will pull in the overall financial footprint, but what about the data from the rest of the sectors, like healthcare, energy, education, transportation, insurance, etc.? Australia’s CDR is a great example of moving toward Open Health, Open Energy, etc. How does one connect everything and create an Open Economy?

# # #

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.



Fluent in Fintech-Bank Partnerships | Advisor | Ambassador| Audiobookaholic

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mahi Sall

Fluent in Fintech-Bank Partnerships | Advisor | Ambassador| Audiobookaholic