How embedded finance partnerships work in practice

Embedded finance gets discussed as a distribution strategy. It is also, and more importantly for the institutions trying to execute it, a technical architecture problem. 

The commercial case is well established. What gets discussed less is what it takes to actually build and operate an embedded finance partnership; what the API architecture needs to look like, where the integration complexity lives, what data flows need to be in place, and what happens to your core banking system when you try to run a B2B2C model on top of it. 

This article is written for product and technology teams at banks and lenders in emerging markets that are either evaluating embedded finance partnerships or are mid-implementation and running into the infrastructure constraints that most guides don’t cover. 

What an embedded finance partnership actually is  

In a standard B2C model, a bank acquires a customer directly. The customer downloads the app, opens an account, and uses the bank’s products. The bank owns the relationship end to end. 

In a B2B2C embedded finance model, the bank provides financial infrastructure to a platform and that platform delivers the financial product to its end customers. The bank never directly acquires the customer, the platform does. However, the bank does provide the product, regulatory licence, balance sheet, and core banking infrastructure. 

From a technical architecture perspective, this creates a fundamentally different set of requirements: 

• The platform needs to call your APIs in real time: When a marketplace seller qualifies for embedded working capital, the credit decision and disbursement need to happen within the merchant’s checkout or dashboard experience, not after a redirect to your app. This requires low-latency, well-documented, stable APIs that a third-party engineering team can build against without your engineers holding their hand. 
• Your core needs to manage accounts it didn’t originate: The customers being served through the embedded channel were acquired by the platform, not by you. But their accounts, their loan records, their transaction histories, and their KYC data all need to live in your core banking system, correctly attributed to the originating channel, queryable by the platform through appropriate access controls. 
• Data needs to flow in both directions: The platform sends you customer events. This bidirectional event stream is what makes the embedded product feel seamless to the end customer. Without it, you have an integration. With it, you have a product. 
• The accounting needs to separate cleanly:When you run multiple embedded partners on the same core, each partner’s customers and transactions need to be separately attributed in the general ledger. This is not just a reporting requirement, it is a regulatory requirement in most markets, and it becomes material when partner contracts have revenue sharing provisions based on transaction volumes. 

The four integration layers every embedded partnership requires 

Regardless of the specific use case, whether it’s embedded lending, embedded wallets, embedded payments, or embedded insurance, every embedded finance partnership involves the same four integration layers. The implementation complexity and the risk of failure both concentrate on how well each layer is designed and maintained. 

Layer 1: Identity and onboarding  

The platform already has a relationship with its customers. It knows who they are, has verified their identity for its own purposes, and has some level of trust established. The question is how much of that existing identity and verification work the bank can rely on and what additional KYC the bank needs to do for regulatory compliance. 

In most emerging markets, this is where the integration gets complicated fast. CBN requires BVN and NIN validation for Nigerian customers. BSP requires PhilSys verification for Philippine customers. OJK has its own eKYC requirements. The platform’s identity verification may satisfy some of these requirements but not all. The integration needs to be designed so that: 

• Identity data the platform has already collected can be passed to your KYC system without the customer re-entering it 
• Additional verification steps required by your regulator can be embedded in the platform’s onboarding flow rather than redirecting to your app 
• The resulting KYC record meets your compliance requirements and can be audited independently of the platform’s records 
• If the platform’s customer changes their identity information on the platform side, the change is reflected in your core in a controlled way 

The cleanest implementations use a webhook-based architecture where the platform’s onboarding flow calls your KYC API at the point where verification is needed, receives a result in real time, and completes the customer journey without interruption. The messiest implementations involve periodic batch exports from the platform, manual reconciliation against your KYC records, and a two-day gap between when a customer was onboarded on the platform and when their account is available in your core. 

Layer 2: Product and eligibility  

This is where the embedded finance product logic lives: the credit decisioning, the limit calculation, the pricing, the product terms. And it is where the product/technology tension in embedded finance is most visible. 

The platform wants to control the customer experience, which means it wants to call your eligibility API and receive a credit decision or a product offer it can display in its own interface. It does not want to redirect to your app for an application form, nor does it want to wait for an overnight batch to determine eligibility. It wants a synchronous API call that returns a decision in under a second. 

This is technically achievable, but it requires your credit decisioning logic to be: 

• Accessible via API: not locked inside a legacy core that requires a batch run or a human underwriter to produce a decision. Your scoring models and eligibility rules need to be callable programmatically, with the result returned in the API response. 
• Fast enough for real-time use: sub-second response time for synchronous calls, or a webhook pattern for asynchronous decisions where the latency is defined and the platform can handle an async flow. A credit decision that takes 30 seconds is not embeddable in a merchant checkout. 
• Configurable per partner: different embedded partners will have different product requirements. A marketplace might want to offer working capital to traders above a certain revenue threshold with a specific repayment structure. A logistics platform might want a different product entirely. Your product configuration layer needs to support partner-specific parameters without requiring a separate product implementation for each. 
• Observable: every eligibility call, every decision, and every declined application needs to be logged with the inputs and outputs. When a platform’s customer is declined and they dispute the decision, or when your regulator asks to see how credit decisions are being made in your embedded channel, you need a complete, auditable record. 

Layer 3: Transactions and settlements 

Once a customer is onboarded and eligible, the embedded product needs to actually work, disbursements need to reach the customer, repayments need to be collected, balances need to update in real time, and the customer needs to be able to see their current position in the platform interface. 

For embedded lending specifically, the disbursement flow is where most implementation problems concentrate: 

• Disbursement routing: funds need to go from your ledger to the customer’s account or wallet through the appropriate payment rail. In the Philippines, this might be via InstaPay to the customer’s GCash wallet. In Nigeria, via NIP to their account. The integration needs to handle the payment rail selection, the routing, the failure cases, and the reconciliation, all in a way that is transparent to both the platform and the end customer. 
• Repayment collection: how the customer repays is often more complex in an embedded model than in a direct lending model. In an embedded merchant lending product, repayment might be structured as a percentage of the merchant’s daily settlement, intercepted before the funds reach the merchant’s account. This requires a settlement flow integration that is technically complex and operationally sensitive. 
• Real-time balance visibility: the platform needs to be able to show the customer their current loan balance, their repayment schedule, and their payment history in real time, in the platform’s own interface. This requires either a read API that the platform calls to retrieve current account data, or a push notification model where your core sends account events to the platform as they occur. 
• Reconciliation: at the end of each day, the platform’s records and your core’s records need to agree, transaction by transaction. If they don’t, you have a problem that is significantly harder to resolve when it has compounded over weeks than when it is caught immediately. The integration needs a daily reconciliation mechanism, ideally automated, with clear escalation paths for mismatches. 

Layer 4: Reporting and compliance  

Embedded finance partnerships create a regulatory reporting obligation that is shared between the bank and the platform but the regulatory accountability sits entirely with the bank. If the embedded channel’s customers are not being properly reported, or if the credit decisions made in the channel cannot be explained to the regulator, the bank bears the consequence. 

This layer is the most commonly underbuilt in early embedded finance implementations and the most expensive to retrofit. 

• Regulatory reporting by channel: your regulatory reports need to be able to separate customers and transactions by origination channel. The embedded partner’s customers need to appear correctly in your CBN, BSP, or OJK submissions. If your core can’t attribute transactions to the originating channel at the record level, you are producing regulatory reports that don’t accurately reflect your embedded business. 
• Audit trail completeness: every action in the embedded channel needs to be in the same audit trail as your directly originated business, not in a separate log that lives in the platform’s system. 
• Partner-level reporting: the platform will want to see reporting on the performance of the embedded product within their channel: origination volumes, approval rates, repayment rates, portfolio quality. This requires your reporting layer to be able to filter by originating partner and produce partner-facing reports without exposing data from other partners or from your direct channel. 

What breaks in practice and why 

The embedded finance integrations that fail in production almost always fail at one of three points. 

• The data model doesn’t support multi-party attribution: The core banking system was designed for a single channel; the bank’s own direct customer acquisition. When embedded partner customers are added, they sit in the same data model as direct customers with no clean way to separate them. Channel attribution is done through a custom field that was added after the fact, which doesn’t carry through to all reports. Reconciliation becomes manual and regulatory reporting becomes a spreadsheet exercise. 
• The API layer isn’t stable enough for a third-party dependency: The embedded partner has built their product on top of your APIs. When you deploy a platform update that changes an API response format, breaks backwards compatibility, or introduces latency, the partner’s product breaks in production. Their customers see errors. Their engineering team calls yours at midnight. The relationship sours. Embedded finance requires API-first discipline; versioned APIs, backwards compatibility commitments, and change management processes that treat third-party integrations as production dependencies, not test environments. 
• The event model is pull instead of push: The platform has built their product to call your API to check account balances and transaction status. The polling creates load spikes that degrade your core’s performance for all customers. 

What your core needs to support embedded finance at scale 

Given the four integration layers above and the failure modes in practice, the technical requirements for a core banking system to support embedded finance partnerships at scale are specific: 

• Event-driven architecture with webhook delivery: Every significant event in the core needs to be publishable as a webhook to external subscribers. Your embedded partners subscribe to the events relevant to their integration and receive them as they occur. This is the architecture that makes real-time embedded products possible without polling. 
• Stable, versioned, documented APIs. Not APIs that happen to exist, but APIs that are designed for third-party use; with versioning that means old versions keep working when new ones are released, with documentation that a third-party engineering team can implement against without your engineers explaining every endpoint, and with sandbox environments that mirror production so partners can test integrations before they go live. 
• Multi-entity account model: The ability to attribute every account, every transaction, and every customer to an originating partner, in the core data model, not in a custom field bolted on afterwards. This is what makes per-partner regulatory reporting, per-partner reconciliation, and per-partner financial reporting possible without a separate data extraction and transformation exercise for each report. 
• Configurable product logic without release dependency: Different embedded partners will need different product parameters. The ability to configure partner-specific interest rates, credit limits, repayment structures, and eligibility criteria through parameterisation, without requiring a development sprint for each partner, is what makes it operationally feasible to run multiple embedded partnerships simultaneously. 
• A governed data layer for partner reporting:Partners need access to performance data about their embedded product. Your compliance team needs to audit the embedded channel. Your risk team needs to monitor embedded portfolio quality. All of this requires a data layer that is queryable, filterable by partner, and accessible without creating load on the live production system. 

The commercial case only holds if the infrastructure holds 

For banks and lenders in emerging markets, embedded finance is one of the highest-quality growth channels available, offering lower acquisition cost, higher engagement, and customer relationships that are stickier because the financial product is woven into the customer’s existing workflow. 

But the commercial case only holds if the embedded product works reliably in production. A marketplace that offers its merchants embedded working capital, and then has to explain to those merchants why their loan disbursement failed or why their balance is wrong, will terminate the partnership. A bank that cannot produce per-channel regulatory reporting will face examination friction that slows future partnership approvals. 

It’s vital to solve the infrastructure problem first; to build or choose a core with the event architecture, the API stability, the multi-party data model, and the configurable product logic that embedded partnerships require. The commercial opportunity follows because the infrastructure makes it reliable. 

Get the core infrastructure you need to succeed  

For more on the infrastructure that makes embedded finance partnerships operationally sustainable, read the Oradian Growth Playbook for Banks. 

To understand how Oradian’s open API layer, event architecture, and multi-entity data model support B2B2C embedded finance at scale, read about APIs and Integrations. 

And if you’re ready to implement the core you need to truly succeed, book a demo by emailing vanda.jirasek@oradian.com today.