In the physical world, banks need to “show up” with a physical branch in the high street to reach customers. Now banks need to “show up” in the digital world. This is done with APIs that plug in to other platforms. That way banks remain relevant and provide credit, identity and other services in the new connected space. All real-estate platforms, e-commerce shopping platforms, bicycle-rental platforms, holiday home rental platforms, travel sites … need financing and insurance (for that expensive TV or holiday), as well as identity (who is buying ? are they creditworthy ? where should the goods be shipped to ?). Banks can (and surely should) provide these services. If they do not, others will step in (Facebook identity, financing by PayPal/Klarna) and banks are relegated to being a commodity for low level services and compliance.
Options for Regulator and Market going forward
The trend of connecting financial services into other industries’ services is variedly called platformisation of banking, API-ification of banking, banking-as-a-service, payments-as-a-service, embedded banking … and is widely seen as the future of financial services. Everything is becoming connected – banks can not remain silos. They cannot continue to just offer an isolated payment button (even if it is instant, adheres to ISO20022, has the latest QR-code, …).
But how to connect FinTechs, Platforms, Banks and all Services given there is not “the” single API, the single standard, the single connector, the single platform or the single bank?
Ideally anyone who is properly authorised should be able to access any bank and vice versa. Not only in the local region, but potentially anywhere in the world.
For those of us who think that Open Banking (which is driving this development) is a huge opportunity to increase services to consumers and to develop new business we feel it is critical to solve this problem of reach soon and avoid any fragmentation.
There are principally two alternatives for industry and regulators to achieve this goal, notably
- Define one single API for all banks/ASPSP, to allow any FinTech/TPP to access any ASPSP in a uniform way
- Let the market evolve, each in its own way, and encourage the developments of commercial connectivity solutions (“hubs”) to provide integration where there is market need
Then allow these regional hubs which connect to local communities to be interconnected for cross-border and international/global reach.
Model 1 – one standard API
If a single API had been defined at the outset back in 2013 when PSD2 was starting, then this would be the ideal solution. Indeed some still hope that this may be the ideal final end state. A TPP/FinTech anywhere could immediately access any bank in a single standard way. All market parties could then focus on the many topics that really should be of primary concern: not technical API access issues – but instead focus on the development of new business models for customers, great user journeys, solving real problems.
However, there is no generally accepted single API and now much valuable time, effort and management attention is being devoted to this connection topic. Therefore some stakeholders from the regulatory side, from consumer side and from the merchant side are calling for a “single API”. This initially does indeed sound sensible and a way out of the current diversity and complexity.
We believe however that enforcing a single one-size-fits-all standard – after Open Banking is already being rolled out – has some risks, notably holding back the current development of PSD2 and actually hindering competition and innovation in the future. Not only is a single API long and hard to agree upon, and will likely lead to political compromises at best, it would also mean the de-investment of the efforts previously made by local communities who have tried to move ahead and make PSD2 work early.
Consensus processes, by their very nature, take a long time (not only in banking and payments: GSMA also took years to define common roaming standards, we have never standardized the one single European 220V power plug – for good reasons).
Concensus processes also tend to lead to sub-optimal results that are often a lowest common denominator, even with the best will of the participants.
Meanwhile the market stands still awaiting the outcome.
China, however, has managed to define the one, single, state-defined API – after market actors (Baidu, Alibaba, Tencent) initially went their own way. This is now enforced and run centrally by the government’s PBOC People’s Bank of China (also, some say, to facilitate the surveillance of banks, merchants, citizens, platforms by the state). This can surely not be the approach in the West.
Thus, we believe that the call for one API, whilst easily made, and initially sounding attractive, actually will reduce competition, reduce innovation, delay Open Banking’s go to market – indeed actively destroy some developments and investments already made – and should thus be approached with caution at this stage.
Since we surely all agree that the end goal must still be to have a uniform access for all TPPs/FinTechs to reach any bank, we propose to let the following alternative models develop – which solve this regulatory/business goal without technical prescription of a single API standard now.
Darwin should take precedence over top-down enforcement.
Model 2 – let the Market do its work
Surely the preferred approach in any modern market economy is simply to let the market develop where there is user need and where a problem needs to be solved. Only in the case of a proven market failure should the regulator step in and enforce a technical solution.
In our context of PSD2 “letting the market do its work” (to provide reach for TPPs to as many banks as possible) typically means the introduction of connecting overlay services. We have already seen the emergence of such services, e.g. Klarna/Tink/TrueLayer/etc allow a merchant to initiate a payment from any bank connected to the service, regardless of its geographical location, similarly Plaid has gone a long way towards connecting to all banks in US. These overlay services solve a problem for the merchant/FinTech/TPP by providing a uniform access to many banks, even irrespective of their underlying technical connection (API, HBCI, screen-scraping, etc).
These aggregators are proving to be a critical and lucrative market (especially if value-added services such as data cleansing/categorisation, license-as-a-service, etc are provided). This model is somewhat akin to the acquiring market for cards – which provides real value, hence is a model for funding and development, provides ample scope for investment and development and is thus surely a promising way forward.
The main drawback of the “market” approach is that there is no control, so there will be some uncertainty if and when which TPPs will be able to access which banks. Indeed, there is some likelihood that investments will initially flow towards integrating the large economies, larger merchants, larger banks thus further disadvantaging smaller, emerging economies and stakeholders. An clever TPP in an innovative remote region should have the same opportunity as any other and not be at the mercy of purely commercially-driven market initiatives.
Thus this approach has many benefits but may fall short of providing the full reach.
Model 3 – hubs with interoperability
The next stage in the evolution for achieving the reach and connectivity necessary in PSD2 is to leverage the already emerging hubs described above.
These hubs often go well beyond simple access aggregation to yield a number of further significant advantages: all banks under a hub share the cost of compliance, can operate a joint directory, have cheaper and more effective overarching fraud management than if each bank were to do it alone, etc. The TPPs have the advantage that they can reach any local bank easily, in a harmonised way (with uniform APIs, single sandbox, testing, app store) and have a single point of resolution in case of questions/disputes or conflicts.
We thus propose that, instead of throwing the effort invested in these local hubs away (Model 1) or only putting endless intermediating layers on top (Model 2) that these hubs be interconnected.
In practice this could work as follows: a British TPP wishing to access a Polish bank simply connects to its usual UK OB hub, but the UK OB hub will recognize from the destination (target IBAN = “PL….”) that the TPP wishes to reach a non-UK/foreign bank and will thus forward the request on to the appropriate hub serving that geography. Thus, TPPs continue to have a unified interface to their local hub but still achieve reach beyond their local market. A really simple and elegant solution that has been proven many times in other areas of payments and mobile industry and more. For more details on the workings of such interconnected hubs, the reader is referred to the literature.
This model not only leverages existing investments, it also actively promotes competition since hubs will compete to provide the best reach, the maximum number of connected banks, the best performance, the most innovative value-added services.
We suggest therefore that this model of the interconnected hubs, which could be driven by the market under gentle encouragement by the regulator, be the preferred model for attaining reach for the development of the connected digital economy, for embedded finance.
Connecting all parties in the new digital world is of paramount importance. All customers, banks, Fintechs should be able to talk to eachother if they want to. They should, however, not spend time on the connectivity issue but should invest their creativity in solving problems, adding value and establishing new business. Let us not spend too much time in the potentially vain attempt to create the one, single, all-encompassing standard. Let an “adapter” industry develop which connects all parties, all standards and provides value-added services. When such national and local hubs are interconnected we come rapidly into the global connected world that we need. Embedded Finance is ready for take-off.
As mentioned at the outset, we believe that all models will come to play:
- Hubs are already being built to provide access to all local banks (Model 3) satisfying the most immediate need
- The market is already developing overlay services to connect communities (Model 2) especially where cross-border demand exists
- We should now further encourage the interconnection of the hubs and the development of solutions that provide cross-border access (model 3)
- Salmony, October 2021
 although the initiatives by Berlin Group, ISO, W3C, Swift, FAPI, FDX etc are very welcome in this context
 an “adapter” industry solves the problem, not optimally, but this is better than spending years on a concensus process and then replacing all power supplies/appliance cords and ripping out all plugs in Europe
 this is only one example of dozens of such API-aggregators/hubs now emerging … full list available on request CAPS Considerations on Interoperable Hubs under PSD2, April 2018 www.caps-services.com