Safe, Scalable, Sellable: let’s dive in and find out how banks can overcome the barriers to embedded finance adoption.
Embedded finance initiatives need to meet compliance requirements, be capable of hassle-free roll-out, and capable of satisfying the expectations of end-users: three criteria that are straightforward in theory, but tough to achieve in practice.
Cobbling together solutions based on BaaS components or open banking models is neither feasible nor desirable. The same goes for a major tech overhaul within core banking infrastructure. To get it right, banks need a fresh approach to product design and deployment that’s fit for purpose: building and deploying natively embeddable financial products.
Beware the dangers of inertia…
This was one of the big takeaways from a recent PwC analysis of banks’ attitudes to embedded finance.
PwC describes how customers are increasingly “far more wedded to the product or service they want and need (such as groceries and a house) than they are to the financial product that underpins them (such as payments and mortgages).”
Others are slower to respond. And given the barriers that need to be overcome – not least, the risks that have to be solved for, and the technical ‘connective tissues’ that have to be in place for initiatives to work – this lack of movement is not surprising.
There is an obvious danger here for banks. On the one hand, there are institutions willing and able to build the banking tools of tomorrow – and reap the rewards. Some banks will inevitably opt for the ‘do nothing’ option, the laggards. They will be passing on one of the most lucrative opportunities for generating superior return on equity – done right, embedded finance offers the means to generate significant new revenue streams at very low cost of customer acquisition and servicing.
So how can established players avoid getting stuck in the laggard camp? The good news is that overcoming the barriers to embedded finance implementation is do-able. But this requires a fresh approach to product creation and deployment. Here’s how it’s done…
Embedded finance development and deployment: what are the sticking points?
Is it safe? Is it scalable? And is it sellable? For any retail bank considering potential embedded finance business models or the feasibility of specific embedded channel initiatives, these are the questions that demand answers…
Compliance
With the best will in the world, the banking sector is never going to replicate the “move fast and break things” mentality that the tech sector is known for. And nor it should. On the other hand, what cannot happen is that the perfectly valid compliance- and risk-related objections that stakeholders are going to raise about embedded finance become a temptation to sit back in wait-and-see mode.
Banking executives leaning back on embedded strategy will point out we are not in Payment Services Directive and open banking territory here: no-one is forcing banks to build a new API or enter into any new relationships (at least, not for the time being). For the more risk-averse members of the executive team, the natural reaction might be one of, “Why change anything if we don’t have to?”
Then there are the operational regulatory challenges to address. For instance, acquiring new customers within an embedded context does not absolve you of your know-your-client, wider anti-money laundering and consumer protection obligations – and all the regulatory requirements. Attempts by EMIs and their Banking-as-a-Service partners to delegate these responsibilities in variations of the agency model have led to a string of high-profile cautionary case studies. Meanwhile, from a cybersecurity and data protection perspective, a raft of new embedded finance projects on potentially divergent models and tech stacks could leave you with a far more complex risk environment to manage and a wider attack surface to police.
What banks need
For the most part, the regulatory landscape is geared towards the classic vertically integrated distribution model: i.e. where banks engage with customers exclusively through their own proprietary platforms. Embedded finance is a new departure, so extra care is needed to avoid a dash for innovation derailing into non-compliance.
A compliance-by-design and secure-by-design development process needs to be adhered to for each and every embedded product offering that you roll out.
From sign-up checks through to pathways for redress, 2FA through to data encryption, you need the ability to define what protections you need, and what steps are needed to ensure that these protections are implemented effectively in each embedded setting.
Scalability
On a technical level, for your embedded finance initiatives to work, the right connective tissues will need to be in place to link your institution with prospective embedders. For those decision-makers with responsibility for technical infrastructure and governance, the thought of yet another tech overhaul is probably not an attractive one.
According to an analysis of US institutions in the ABA Banking Journal, more than two in five banks still run their core banking processes on systems that date back nearly four decades. The digital transformation situation is more positive in European banks, but even the newest core banking stacks have not been designed originally with embeddable product delivery in mind. Against this backdrop, banks need to weigh up cost, risk potential and business disruption when considering options for technological changes to facilitate embedded finance projects. It’s likely that you’ll be keen to limit changes to established core systems and focus on possible middleware solutions.
When it comes to possible middleware solutions, could the way forward lie in open APIs, along a similar model to open banking initiatives? The answer to this is a pretty definite no. In terms of bespoke product development, governance, product management and oversight, the embedder/bank relationship is a much more complex one than the basic open banking model.
In open banking, third party UX channels can be used to service existing bank customers, but not to sign up and onboard new customers, particularly for products where eligibility or underwriting criteria are required, let alone formal advice. Another key aspect versus open banking is that embedded finance interactions are not sporadic one-off tasks such as checking a balance or initiating a payment, but encompass potentially anything users currently do in regular and routine ways in the bank’s main digital portals and apps.
It doesn’t stop there – embedded finance use cases imply plenty of new functionality where products have been designed specifically for certain verticals and non-financial UX context, not to mention the need to solve support and troubleshooting – all still within a variety of third party delivery channels, not the bank’s own front-ends. A different technological approach is required to manage embedded finance.
What banks need
If extending open banking APIs is not the answer, then what’s the way forward?
The end goal must always be to ensure effective connection and communication between the fundamental components that enable embedded finance. Alongside this, any new technologies used must also protect the integrity of underlying transactions and customer data, and allow for the creation of visible audit trails.
Bear in mind that to exploit the full addressable market for embedded finance, your long-term aim should be multiple offerings through multiple partner relationships.
With this in mind, it makes sense to consider building up a repeatable process for product creation: a dedicated embeddable product factory, rather than just a series of ad-hoc projects. And in place of open APIs, you should be thinking more along the lines of purpose-built connector architecture: the type of capabilities that enable you to track performance and transactions across all the embedded finance projects you have in play, all in one place.
Sellability
Embedded finance is predicted to generate $230 billion revenue annually by 2025, a 10x increase from $22.5 billion in 2020. Earlier, we touched on what is probably the biggest driver of this growth: the simple fact that most people are far more wedded to the products they want – and the platforms where they choose to spend their time – than the financial products that underpin them.
However, merely having a presence on a nonfinancial platform is not automatically going to earn you a new stream of product sign-ups. The banks most likely to ‘win’ at embedded finance will be those that are able to take a customer-centric approach: it’s about financial product adoption and engagement more than traditional product distribution.
For this, context is everything. Let’s say you have embedded finance partnerships in place with an enterprise resource planning platform, a micro-business accounts SaaS platform and a bespoke travel site. In each case, the product catalogue items that you offer, and the way in which those products are presented will differ considerably. In each case, your offerings must be perceived as fair, relevant, value-adding and tailored to your audience.
What banks need
Earlier, we raised the possibility of a factory approach to embedded finance product creation. This is not in the sense of a production line for the creation of identikit offerings for all distribution channels. In fact, the opposite is true.
Think of your factory as more of a sandbox: a platform for creating, customising and periodically tweaking your offerings so that they are always optimised for whichever audiences and channels they are designed for. The under-the-bonnet elements – e.g. the workflows that govern sign-ups, KYC checks and transaction monitoring – are likely to be the same or almost the same across the majority of your embedded finance estate. However, the way in which those products are presented and configured – e.g. designing credit facilities to match commercial practices within specific industry verticals – can and should differ significantly from case to case for maximum impact.
What happens next?
To avoid languishing in inertia mode, banks need the capacity to create products that are watertight from a compliance point of view, that are attractive to end-users, and that can be produced, deployed and managed at scale… and all of this natively for embedded finance contexts.
The toolkits most often associated with third-party distribution, BaaS and open banking, are destined to fall short in delivering this – albeit for different reasons. BaaS tends to have major problems with the completeness of the model and involves your partners taking on a level of regulatory responsibility that the majority of nonfinancial software companies will have neither the resources nor the inclination to accept. Trying to extend the open banking model, meanwhile, can give you only meagre capabilities that fall short of what’s needed for an attractive, feature-rich embedded finance offering.
Weavr offers a workable alternative in the form of a dedicated platform for the creation, launch, compliance-friendly management and optimisation of all your embedded finance initiatives. To discover more about the factory approach to embeddable product development, speak to us today.
