Overview of embedded finance integration: What is white-labeling?
When it comes to embedded finance integration, every business will have its own set of requirements and priorities. The good news is there’s an integration for everyone. It might be an entirely bespoke system or an out-of-the-box white-label solution, but finding out what is needed requires businesses to ask the right questions. The first one being: what should an embedded finance integration look like?
An embedded finance integration is relevant for a non-financial company that wants to offer a financial product embedded into their existing platform. It can be as hands-off as a link to a third-party provider, or a fully integrated journey that lives in the embedder's ecosystem.
Buy vs Build: Why does white-labeling matter?
When thinking about adding financing products to the roadmap, the first decision to be made by the product team is whether to 'buy or build'.
When things are moving fast, future-proofing new products and prioritising roadmaps is tricky. There is a lot of pressure from the rest of the business to make decisions fast, but the product team needs to take the necessary time to investigate the right options. With embedded finance currently seeing a boom, there are plenty of choices, and it’s not always clear what makes long-term sense; so here’s a recap of the four main kinds of integrations:
The four kinds of integration
API
- Pros: Flexible, App changes aren’t disruptive, widely available
- Cons: Code-intensive, users are reliant on vendors
Webhooks
- Pros: Real-time data, supports automation
- Cons: Less flexible data manipulation
ISC
- Pros: Broad range of functionality, ready-to-use
- Cons: Requires knowledge of database architecture, requires access to back-end
Orchestration
- Pros: Full automation, manages multiple systems
- Cons: Code-intensive, complex workflows
Regardless of which kind of integration you choose, an important consideration is how much of it you intend to build yourself, and how much you can rely on an out-of-the-box white-label solution. We’ll delve into the nuances of white-labeling below, and you can find out more in our Buy vs Build whitepaper, but for now, let’s consider some embedded finance integration use cases to build an idea of what will drive your decision.
Embedded finance integration use cases
Payments
A crucial consideration for integration is easy access to data. This is exemplified in the transfer of sensitive information and fraud prevention by the payments industry (banks or PSPs). The best way for payment providers to detect and prevent fraud is by mining vast arrays of data for outliers and anomalies. Services like Sift and Seon use API integration to check dozens of financial data points in real-time such as user balance and transaction type.
The reason it is so important for these data points to be available in real-time is because every second counts in fraud. Someone can steal credit card information and spends thousands of dollars in minutes if the transaction is not immediately flagged as suspicious. For challenger banks that are already digitised or traditional banks looking to upgrade, the ability to efficiently detect fraud before lending money or processing transactions is crucial.
E-Commerce
Similarly, real-time access to data points in embedded finance is extremely important for instant decision processing, especially when the main added value of the service is speed. SMEs are a key example, and we have previously discussed why speed and flexibility are so important to them.
For a small business with limited working capital, the ability to access funding depends on lending platforms being able to perform credit checks quickly. Without that, businesses risk being unable to pay for last-minute extra inventory, unforeseen bills, or emergency hires. A well-handled integration makes it possible to approve funding in minutes rather than days - and to a platform with small business merchants, that makes all the difference.
The white-label integration spectrum
There are effectively three options when it comes to embedded finance integration. They range from full white-label solutions to deep integrations:
Minimal Integration
This is in essence a partnership, with partners directing their customers to a landing page hosted by the service provider. While still an embedded offering, this is essentially a referral programme. Naturally, the product won’t be customised or fully seamless, and will still carry branding by the service provider, but it’s easy to set up and a good way to gather learnings from customers with minimal cost and investment.
App or Dashboard
This is the middle way of embedded finance integration. Platforms are able to embed an app or dashboard from the service provider into their main offering, but still hand over data to the provider once it’s gathered. This requires some set-up and configuration work on the part of the platform at the start, but it has the advantage of a smoother experience for customers. More importantly, the embedder has far more visibility on how its users are behaving throughout the process, and can keep improving on it and finding ways to derive business value from it.
Super Embedded
This is the deepest extent of integration and here, the offering is owned and developed in collaboration with the partner. It’s an expensive, labour-intensive solution, but offers the best possible customer journey. Apart from in legal agreements, there’s no indication that the platform is using a service provider to offer the product, as the entire customer journey rests in the partner's domain.
Trade-offs with white-labeling
Every platform will have different needs and priorities when it comes to integration. Having a clear understanding of the pros and cons of white-labeling can help them make the right choice. The main trade-off to consider with the depth of integration in white-label offerings is increased flexibility and ownership over the experience on one hand, and speed and reliance on the specialization of the provider on the other.
With a fully white-labeled solution, customers can pay less while benefiting from the service provider’s hard work. Since each customer is sharing a product with others, each submitting their own data and highlighting the need for various updates, the aggregate product is likely to cater to a range of needs. This said, if a customer requires a specific, expensive upgrade that doesn’t add much value to the solution as a whole, they may be unlikely to get it for the price they’re paying.
More fully embedded solutions naturally have the advantage of near-infinite flexibility. If the customer needs an upgrade, and has the budget, it can be done. They’ll also benefit from offering a more seamless, branded customer experience. However, for a solution like this to be effective, the customer will need to provide considerable amounts of data since they won’t be benefitting from the learnings of others.
.png)
How to choose a quality embedded finance integration
When choosing a quality embedded finance integration, it’s important to know the different options. Here’s an overview of the different kind of APIs and architecture:
APIs
- Open APIs have relatively low authentication and authorisation measures and can be used by any developer, meaning they’re able to share data openly. That means any third-party platform and their customers can quickly benefit from vast quantities of readily available data.
- Partner APIs have increased security measures and are only shared externally with related businesses. They have the advantage of allowing businesses more control over how their data is used, but there’s of course less of it available.
- Internal APIs aren’t intended for use by third parties, making them more efficient, secure, and traceable. They’re scalable and great for streamlining internal data transfers, but wholly supplied and maintained in house.
- Composite APIs are used to bundle calls or requests from multiple APIs and retrieve one unified response from multiple servers. For an embedded finance platform working in wealth management, where multiple services must be integrated, composite APIs are a great solution.
Types of API architecture
- REST stands for Representational State Transfer, and accounts for most web APIs out there today. REST APIs are used for transferring data from a server to a requesting client, and are governed by a set of guidelines for scalable, lightweight, and easy-to-use systems.
- SOAP stands for Simple Object Access Protocol, and is used for transmitting data across networks. Because SOAP architecture strictly defines how messages are sent and what they include, SOAP APIs are more secure than REST APIs, but they tend to be code-heavy and harder to implement. That’s why they’re best implemented for internal data transfers that require more security.
- RPC stands for Remote Procedural Call. Instead of facilitating data transfer like REST and SOAP, RPC simply executes scripts on a server, making it the most straightforward of the three architectures. While useful for internal systems or making basic process requests, they’re limited in security and are used less often than REST or SOAP.
It’s also important to know which factors really matter for a successful integration, like timing and data sharing.
Timing
Real-time reporting is particularly important for embedded finance integration. If an integration isn’t truly real-time, only relaying information at intervals, platforms and customers aren’t reliable receiving the data they need to make important decisions. In the cause of embedded lending, real-time data transfer is especially important as many of the small businesses receiving funding have relatively little working capital. If they don’t have an up-to-date picture of their finances, they can’t make the right decisions for their business.
Data sharing
It’s important to understand how data is being updated and shared in your integration. A system might be able to draw several data points on a regular basis, but it should also be able to provide feedback, updating those data points as required and ideally from multiple sources.
Final thoughts
All of this is important for embedded finance because platforms want to be able to launch new products quickly, offering a seamless, sticky customer experience. With these bases covered, there are significant opportunities to gain market share and open a new revenue stream.
While planning a roadmap towards a full integration can be a difficult process, there are decisions that businesses and product teams can make right away like testing out a white-label embedded finance solution and tapping into customer data with a ready-to-use API.
The best way to begin is with a pilot project and using the learnings to decide the best embedded finance integration for your business.
