Since the introduction of the smartphone, payment service providers, in competition with each other, have continuously been investing in enhancing customer journeys and introducing new services. These are offered to consumers as seamlessly as possible.
At the same time, traditional payment service providers (banks) started using more services from third-parties, such as payment institutions and technical service providers, including fintechs. This benefited consumer services and contributed to cost control for banks, as they were able to ride on the expertise, innovative applications, and economies of scale of these third-party providers. This development fostered competition and innovation in the market. An additional aspect is that it has made payment chains more complex and fragmented (vertical fragmentation), with risks of less robust and less transparent payment chains.
PSD2 strengthened the development of competition and innovation: new non-bank (licensed) parties could serve consumers and businesses with new services (account information services and payment initiation services) through separate access to the banking environment. Since then, the use of application programming interfaces (APIs) has taken off.
The limited services mandated by PSD2, led to a market demand for more functionalities on top of the mandatory PSD2 services. In response, a number of banks started open API platforms, supplying third-party providers with additional services for a fee. At the request of the ECB, the EC and European stakeholders, the European Payments Council recently developed the SEPA Payment Account Access scheme (SPAA) with premium services for a large number of value-added functionalities on top of PSD2 with standardised APIs. In addition, on the 28th of June, the EC published its proposal for legislation on Open Finance.
One development that has gained momentum in recent years are solutions such as Banking-as-a-Service (BaaS) and Embedded Finance/payments. BaaS changes the traditional banking or payment chain as non-banking providers start offering banking products and services on their own platforms.
In addition, it is easier and cheaper for third-party providers to offer banking and payment services on their platform by using the license of banks than to opt for this themselves and having to set up their own complete infrastructure.
For banks, although they are pushed further back in the value chain, this means the introduction of a new revenue model. For more details about this, see Panagiotis Kriaris’ interview in The Paypers on the 22th of May 2023.
A recent CSI survey found that nearly a quarter (25%) of (US) banks view BaaS as a new revenue stream. Bain & Company foresee a tripling of transactions with Embedded Finance in 2026 (when compared to the situation in 2021), mainly in relation to payments and lending. However, Leibbrandt and De Teran also point out a downside to Embedded Finance: it increases the chances of overspending. Buy Now, Pay Later (BNPL) is an example of this.
Embedded Finance has also now entered the market for small and medium-sized businesses (SMEs) according to research by Connective Payments. As banks have become more cautious about lending to these types of businesses, there are opportunities here for fintechs. A recent market survey by Adyen found that 64% of SMEs are interested in Embedded Finance.
The collaboration between banks and fintechs in BaaS and Embedded Finance leads to a number of benefits (such as better customer experiences, higher conversion rates, and lower development costs for banks), but Baas and embedded models are also not without risks (with regard to the protection of data, funds and customer base, secured processing of transactions, and the overall compliance with financial legislation), as The Paypers previously explained.
The cooperation between parties in an ecosystem is often shaped by a payment scheme. In this regard, a similarity arises between a payment scheme on the one hand, and BaaS and Embedded Finance on the other. Well-known payment schemes are those of the Single Euro Payments Area (SEPA), of Visa and Mastercard, and of iDEAL in the Netherlands. The oversight criteria, which apply to these and focus on risk mitigation, among other things, are also relevant to BaaS and Embedded Finance models.
A comparison between scheme models and BaaS and Embedded Finance models reveals various similarities and differences. The main similarity discussed here is that both models are stacked financial supply chains where several partners (regulated and non-regulated) and their third parties and subcontractors work together to deliver a service. Their aim is to facilitate smooth and reliable transactions to end users against affordable costs. The main difference between the models is that in scheme-arrangements the inherent complexity resulting from the fragmented financial supply chain is governed by uniform and transparent mutual agreements. These include common standards and agreed (self) regulatory practices, that apply to all participants.
This scheme approach with uniform rules and regulations and standards contributes to transparency, operational reliability, and reduced legal ambiguity. Also, this leads to overall lower costs for scheme partners and third parties.
The advantage for the (existing) partners in the ecosystem is that they can take advantage of the uniform rules. Furthermore, they can rely on the open and uniform access rules of the scheme throughout the ecosystem and beyond, instead of each partner in the chain setting up their own rules.The major advantage for everyone is a transparent onboarding and monitoring process, combined with an ensured baseline quality of services supported by adequate risk and compliance controls.
Regardless of the supply chain model, supervised financial institutions are required to oversee their partner- and third and (if applicable) their fourth -party relationships and to manage the associated risks with these parties. As both supply chain models are nowadays characterised by an increasing blurring of the classic supervisory distinction between vendor and service provider relationships, it is becoming increasingly complex and difficult to design this oversight in line with regulatory requirements and within the organisations' risk appetite.
At a first glance, BaaS and Embedded Finance models resemble classical ICT service delivery models (such as Software-as-a-Service (SaaS)). The providing bank could therefore be classified as an ICT service provider to a third party (and vice versa). In practice, the two may indeed be service providers to each other, meaning that the third party, as a technology partner, performs front-end functions such as marketing and sales for its own customers.
At the same time, the bank offers financial services to both the third party and its customers. This scenario requires a different and more risk-based approach to evaluating third-party risk, rather than solely considering it from the perspective of an ICT service provider.
This complication also immediately raises another related key issue namely who is the customer of whom within the service concept in question? Who ’owns’ the end customer and which party in the chain is responsible for service disputes, for example?
Financial institutions increasingly see BaaS and Embedded Finance solutions as an opportunity to increase their returns by partnering (via co-branding or white labelling formulas) with the fintechs and offering value-added services to their end customers.
The key question here is who is the customer of the BaaS and Embedded Finance bank provider? Is this the third party (fintech) or is it the customer of this third party? In both cases, the question is what the regulatory impact of this for the BaaS and embedded provider is.
If the service involves a flow of funds from the provider to the customer of the third party (or vice versa), the sponsor bank as BaaS and Embedded Finance provider should have a role in in ensuring that the customers’ transactions are secure and authorised under AML and sanction screening requirements.
If the service (also) involves a flow of personally identifiable information, the BaaS and the Embedded Finance provider need to consider in which GDPR capacity it and its third parties are acting (e.g. as a processor, controller, or joint controller). This can get complicated because the GDPR capacity depends, in part, on who the seller of the service (the controller) is and to what extent they are involved, as well as who the provider of the service (the processor) is.This shows that the distinction between seller and provider is also relevant from a GDPR compliance perspective.
Another key issue that arises with stacked service models is that they can introduce unfair competition through a lack of reciprocity in data sharing if this is not clearly agreed upon. This could create a situation where the BaaS and Embedded Finance provider is obliged to open customer data upon request and consent of the end customer, but cannot request the same from the third party because there are no agreements on this. This topic is subject to continuous debate between incumbents and fin tech/big techs triggered by the PSD2 and continues in the discussions regarding the PSD3.
The GDRP provision on data portability (Article 20), which could provide a possible solution to create a more balanced situation, does not account for the possibility to meet the needs of automated standard delivery formats with a minimum delivery speed. When a customer makes a data portability request to transfer data from controller A to controller B, he cannot invoke this article because, under this article, neither automated, nor digital portability is required.
Besides operational issues that may arise in the supply chain, such as volume and performance bottlenecks and issues around the quality of connectivity, we also want to draw attention to a topical issue, namely (cyber) security.
An important aspect when working with third parties is assessing their risk appetite regarding (cyber)security-related risks and threats, as well as appraising their resilience to such risks. For example, the hack of the SolarWinds shows how a cyberattack can affect third parties and that the impact could spread in the ecosystem, possibly affecting their end users..
This occurs when criminals infiltrate third-party systems, which then leads to an infection in the systems and databases of other parties in the ecosystem. The hack at SolarWinds and its repercussions for other parties led to meticulous analysis of how software is created, secured, and distributed. The lessons learned lead to the need to closely monitor ICT components in the supply chain.
In this context, it is also important to note the upcoming implementation of Digital Operational Resilience Act (DORA) which came into force on the 16th of January 2023and which will apply from the 17th of January 2025.
The DORA introduces a framework to oversee the systemic and concentration risks arising from the financial sector’s reliance on third-party ICT service providers (article 28) and an EU-level oversight framework for the critical ICT service providers to ensure that the ICT risks these critical providers pose to financial entities are properly managed. Third-Party Risk Management (TPRM) will be included and elaborated upon in a dedicated Regulatory Technical Standard (RTS). This RTS will also be relevant for providers of BaaS and Embedded Services.
These requirements argue for good cooperation, for example through a scheme model as an ultimate form of self-regulation. In this, multiple BaaS and Embedded Finance providers can cooperate based on transparent and uniform rules.
If this should be considered a step too far, each provider of these services should offer this itself towards all parties with whom it does business. In principle, this ’every provider for himself’ mode means higher costs. But even in this case, the provider must be transparent in the arrangements it makes with other chain parties, so that it is clear to all parties what arrangements have been made and what responsibilities this entails in the partnership.
It is therefore important for service providers to exercise caution when entering BaaS or Embedded Finance relationships. Precisely in these areas, the scheme model with established uniform agreements and common technical standards helps to address these challenges effectively.
BaaS and Embedded Finance models have the potential to reshape access to financial services and better meet consumers’ financial needs and promote financial inclusion, as well as provide financial institutions with access to new markets and customers through strategic partnerships.
Providers of these services need to be aware of the key risks around BaaS and Embedded Finance models. For each provider, risk management should be designed accordingly, as should governance, which should preferably foster risk collaboration – and preferably broader collaboration with all parties in the chain.
Policymakers and regulators must ensure that the governance and risk management of financial institutions remain appropriate to facilitate these developments while addressing the increased risks posed by this trend.
For more information see: Piet M. Mallekoote and Suren Balraadjsing, ‘Oversight and risk management of payments schemes’, Journal of Risk Management in Financial Institutions, Volume 15, number 4 (2022). The article can be sent by the authors on request.
About Piet Mallekoote
Piet Mallekoote is an independent advisor. He is the retired CEO of the Dutch Payments Association and Currence (owner of iDEAL).
About Suren Balraadjsing
Suren Balraadjsing is senior auditor risk at Currence. (contributed in a personal capacity)
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now