Embedded Finance and BaaS

Visual overview

Embedded Finance and BaaS at a glance — White-label banking, finance in non-finance apps.

White-Label Banking and Finance in Non-Finance Applications

Embedded finance represents one of the most significant transformations in how financial services are delivered and consumed in the modern economy, fundamentally changing the relationship between financial services and their customers. Rather than requiring customers to visit banks or even open banking applications, embedded finance integrates payments, lending, insurance, and banking services directly into non-financial platforms and applications where customers already spend their time and conduct their activities. When you pay through an e-commerce app, obtain financing at a car dealership, or purchase insurance while booking a flight, you are experiencing embedded finance in action—financial services that appear exactly when and where you need them without requiring separate trips to banking channels. Banking-as-a-Service, or BaaS, provides the technological infrastructure that makes this seamless integration possible, creating a multi-layer ecosystem where financial services become invisible and contextual rather than separate and destination-based.

The defining characteristic of embedded finance is its contextuality and timing—financial services appear where they are relevant rather than requiring customers to begin a separate banking journey. Industry forecasts for the size of embedded finance vary widely because analysts define the market differently and forecasts change over time. The durable point is that APIs, platform distribution and regulated partnerships allow more non-financial companies to distribute financial capabilities, while the underlying activity still requires the licences, controls and customer protections applicable to the product.

Several types of embedded finance have emerged as distinct categories, each addressing different financial needs within non-financial contexts and delivering value through convenience, timing, and relevance. Embedded payments enable transactions within applications through services like Apple Pay, Google Pay, and India's UPI integrated into e-commerce checkouts, removing friction from the purchase process and reducing cart abandonment. Embedded lending provides credit at the point of purchase, exemplified by Buy Now Pay Later options at checkout and products like Amazon Pay Later that let customers spread payments over time without leaving the shopping experience or applying separately for credit. Embedded insurance offers coverage at relevant moments, such as travel insurance presented during flight booking or phone insurance offered at device purchase, when customers are already thinking about protection needs and are most receptive to relevant offers. Embedded banking provides checking and savings accounts within non-bank applications, while embedded investments enable stock trading within super apps that bundle multiple services into unified experiences.

Banking-as-a-Service serves as the enabling infrastructure for embedded finance, providing the technological bridges that connect licensed banks with non-bank applications in compliant and secure ways that protect consumers while enabling innovation. The BaaS architecture operates through several interconnected layers that each serve specific functions in delivering financial services to end customers. Licensed banks at the foundation hold the banking licenses, manage regulatory compliance, and provide core banking functions including deposit-taking and lending that require regulatory authorization. These banks expose their services through Application Programming Interfaces to BaaS platforms that serve as middleware, providing developer tools, standardization, and additional services that make bank capabilities accessible to non-bank developers without banking expertise. The BaaS platforms connect via APIs to non-bank applications and fintech companies that build the customer-facing products and experiences that users interact with. Finally, end customers interact with these applications, often unaware that the financial services they are using are provided by licensed banks through complex technological intermediation.

BaaS is often illustrated as layers connecting a regulated financial institution, technology or processing capabilities, a customer-facing product and distribution. Real arrangements do not always contain four distinct entities, and provider roles can change over time. A bank may expose APIs directly to a platform, while another arrangement may use separate BaaS, card-processing, identity and lending providers. The more reliable analysis is to identify who owns each capability—licence, customer onboarding, ledger, payments, cards, fraud, compliance, support and reporting—rather than assume one universal stack.

Several key enablers have made the embedded finance ecosystem possible and are continuing to drive its expansion across industries and use cases. Standardized APIs allow non-banks to access banking functions without building complex custom integrations from scratch, dramatically reducing time-to-market and development costs for companies wanting to add financial services. Open banking regulatory frameworks mandate API availability and data sharing, creating the legal foundation for embedded finance by requiring banks to open access to their systems. Cloud infrastructure provides scalable, pay-as-you-go computing resources that make it economically viable for fintechs to launch and grow without massive upfront capital investment in their own data centers. Payment systems like UPI provide instant, interoperable payment rails that can be integrated into any application, creating network effects that benefit all participants in the ecosystem. Account Aggregator frameworks enable consent-based data sharing that supports better lending decisions and personalized financial services while protecting consumer privacy and control over their information.

Real-world examples of embedded finance demonstrate its practical application across industries and use cases, showing how deeply financial services can be integrated into non-financial experiences. Amazon integrates EMI options, Pay Later, and insurance offerings directly into its checkout process, capturing financing demand at the moment of purchase intent when customers are most likely to need payment flexibility. Uber provides instant payments to drivers and offers debit cards for their banking needs, embedding financial services into the gig work experience and helping drivers manage their earnings. Shopify offers merchant lending through Shopify Capital alongside its payment processing services, supporting the businesses that use its platform with working capital they need to grow. In India, Ola has built Ola Financial Services to provide lending and insurance to its driver partners and customers, creating additional revenue streams while meeting the financial needs of its ecosystem. Swiggy offers Swiggy Money and instant payouts to delivery partners, helping gig workers access their earnings immediately rather than waiting for settlement cycles. CRED has expanded from credit card payments to offer Buy Now Pay Later, UPI services, and insurance products, embedding finance into the credit management experience and leveraging its customer relationships to cross-sell additional services.

White-label banking represents a specific form of embedded finance where a licensed bank provides the complete banking infrastructure while a brand provides the customer-facing experience under its own identity. The customer sees only the brand's name and application interface, while behind the scenes the licensed bank handles accounts, compliance, deposits, and lending. Jupiter and Fi Money both operate on this model in partnership with Federal Bank, while Slice partners with North East Small Finance Bank. This arrangement allows non-bank brands to offer banking services under their own identity without obtaining banking licenses themselves, dramatically expanding the range of companies that can offer financial products and accelerating innovation by removing regulatory barriers.

Embedded-finance economics vary by product, risk, funding structure, regulation and commercial contract. A lender may earn interest margin while paying distribution or servicing fees; a BaaS or processing provider may charge fixed, usage-based or revenue-share fees; and the customer-facing platform may earn commercial compensation permitted under the arrangement. There is no universal rupee split for each hundred rupees originated. Sustainable economics should be assessed from actual customer pricing, funding cost, expected losses, processor and partner charges, servicing cost and revenue-sharing terms.

The rapid growth of embedded finance has attracted regulatory attention to ensure proper consumer protection and risk management in this new paradigm where financial services are distributed through non-traditional channels. Regulatory clarity remains one of the biggest challenges, with questions about responsibility when things go wrong and the need for clear disclosure requirements about who is actually providing financial services. Customer confusion is a genuine concern, as users may not always understand which licensed bank holds their deposits or is responsible for their loan, potentially creating expectations mismatches about protection and recourse. Banks must ensure that fintech partners comply with all applicable regulations, creating compliance burdens that extend across the ecosystem. Concentration risk emerges when a few banks power dozens of fintechs, meaning that problems at one bank can affect many fintech customers simultaneously. Data ownership questions—who owns the customer relationship and associated data—remain subjects of negotiation and regulatory interest.

In India, RBI requirements applicable to digital lending and regulated outsourcing have developed over time and should be read from the current operative framework. Key supervisory themes include identifying the regulated lender to the borrower, transparent loan terms and charges, direct and controlled fund flows, customer consent and data governance, grievance handling, regulated use of lending service providers, and defined conditions for permitted default-loss guarantee arrangements. Co-lending and other partnership structures have their own requirements. The exact rule applicable to a product depends on the regulated entities and structure, so current RBI directions should be checked before implementation.

India's BaaS ecosystem, featuring companies like M2P, Zeta, and Setu, is among the most advanced globally and has enabled a wave of innovation that allows virtually any company to embed financial services into their offerings. As the ecosystem matures, the winners will be those who can navigate the regulatory landscape while delivering seamless, contextual financial experiences that truly add value for customers rather than simply adding complexity or creating hidden risks. The future of banking is increasingly distributed, with financial services appearing wherever customers need them rather than requiring customers to come to banking channels. Embedded finance is making that future a reality, transforming the relationship between financial services and customers in ways that will continue to evolve over the coming decade.

Embedded Finance in Real Banking — Product, Risk, Controls, and Operating Architecture

Embedded finance starts with the customer context

Embedded finance means placing a financial capability inside a journey whose primary purpose is something else. A seller on an e-commerce marketplace may receive a working-capital offer while managing inventory. A traveller may buy insurance while booking a flight. A driver may receive earnings into an account linked to a mobility platform. A software company may let a small business initiate supplier payments without leaving its accounting application. The financial service appears at the point of need rather than requiring the customer to begin a separate banking journey.

The experience can look simple because the platform already knows useful context. A marketplace knows sales history, an employer knows payroll data, and an accounting platform knows invoices. That context can reduce data entry and make the financial offer more relevant. But the simplicity at the surface usually depends on several parties behind the scenes: a regulated bank or lender, a BaaS or processor layer, the non-financial platform, identity and fraud services, payment infrastructure, and sometimes insurers or investment providers.

The core design question is therefore not only how to embed the feature. It is how to divide responsibility so the customer receives one coherent service even though multiple entities participate.

The regulated activity must be identified before the API is designed

An application can call an API in milliseconds, but regulation applies to the underlying financial activity, not to the speed of the interface. Deposit taking, payment services, card issuance, lending, insurance distribution and investment services can each trigger different legal and regulatory requirements depending on jurisdiction.

Product teams should identify which legal entity performs the regulated activity before building the customer journey. If a platform offers a loan, which entity is the lender of record? If it offers an account, which institution holds the deposit? If it offers a payment card, who issues it and who processes disputes? If it sells insurance, is the platform merely introducing the customer or acting in a regulated distribution capacity?

These answers determine onboarding, disclosures, record keeping, complaints, prudential treatment and regulatory reporting. They also influence the technology architecture because some decisions must be made or recorded by the regulated institution rather than solely by the distributor.

Banking-as-a-Service is a capability model, not one fixed four-layer stack

BaaS is often drawn as a simple stack: licensed bank, BaaS platform, fintech or brand, and customer. This is useful for teaching but real arrangements vary. A bank may expose APIs directly to a large corporate platform without an intermediary BaaS provider. A BaaS platform may itself rely on several sponsor banks. Card issuing may be handled by a separate processor while deposit accounts come from one bank and lending from another.

A better way to analyse BaaS is by capability. Which party provides customer onboarding? Which party maintains the account ledger? Which party handles payment connectivity? Who provides card processing, fraud tools, sanctions screening, customer support, statements and reporting? Once each capability has an owner, the architecture can be drawn accurately.

This capability model also makes change easier. If the card processor changes but the deposit bank remains the same, the bank can identify which journeys and controls are affected. Treating BaaS as one monolithic provider obscures these dependencies.

Embedded payments still require a complete payment lifecycle

A checkout button can hide a complex payment chain. The customer authorises a payment, the platform validates the instruction, fraud controls assess risk, funding is checked, the instruction is routed to a bank or payment service provider, clearing or network processing occurs, settlement follows, and the merchant or beneficiary is credited. Refunds, reversals and disputes create further lifecycle events.

The embedded platform should preserve identifiers that connect the customer action to downstream processing. If the customer sees an order number while the bank sees a payment reference and the processor uses another transaction identifier, operations need a mapping among them. Without this, investigations become slow and dependent on manual searches across companies.

Status should also be translated carefully. “Payment accepted” can mean the platform received the instruction, not that the beneficiary has final funds. The app should not display final language before the underlying rail reaches the state the product promises.

Idempotency becomes critical when finance is hidden inside commerce

Commercial applications are designed to retry failed network requests, but blindly retrying a financial instruction can create duplicates. If a payment or loan-disbursement request times out, the caller may not know whether the regulated provider received and processed it.

Embedded-finance APIs should therefore support idempotent request handling. The platform sends a unique business request identifier, and repeated submission of the same request returns the existing result rather than creating another transaction. Status-enquiry APIs provide another safe path when the outcome is uncertain.

This principle applies to refunds, account creation, card issuance and other state-changing operations. The financial provider and platform should agree which identifier represents the business event and how long duplicate protection remains effective.

Embedded lending combines distribution data with ordinary credit risk

A platform may know more about a customer’s commercial activity than a traditional lender. A marketplace can observe seller revenue, refunds and seasonality. A payroll platform can see income history. This information can improve underwriting and reduce application friction.

However, richer data does not eliminate credit risk. The lender still needs a controlled credit policy, validated models, affordability or repayment assessment where applicable, limits, pricing, documentation, disbursement controls and collections. Economic conditions can change relationships that appeared stable in historical data.

The lender of record should own or approve the credit decision framework even if the platform supplies data or customer acquisition. If the platform receives incentives based only on loan volume, governance should prevent those incentives from weakening underwriting quality.

Collections are part of embedded lending from day one

The checkout journey may take seconds, but the credit relationship can last months or years. The operating model needs to define how repayment is collected, what happens after missed payments, how customers can request assistance, and which party communicates arrears or restructuring options.

Where repayment is deducted from marketplace proceeds, the platform should distinguish ordinary merchant settlement from debt repayment. If sales fall sharply, the lender needs an approved process rather than an algorithm that continues extracting amounts without regard to customer circumstances or applicable conduct requirements.

Complaints and disputes also need clear ownership. A merchant may contact the marketplace even though the lender owns the credit agreement. The platform should route the case without forcing the customer to decipher the partnership structure.

Embedded insurance is contextual distribution with insurance obligations behind it

Insurance can be offered at a relevant moment: travel cover during booking, device protection during purchase, shipping protection during checkout. Context can make the product easier to understand because the risk is visible.

The platform must still present the scope, exclusions, price and provider clearly. A pre-ticked insurance option or obscure cancellation path can create conduct risk. The insurer or authorised distributor needs adequate records of consent and policy issuance.

Claims are the real test. The customer should know where to report a loss and should not be trapped between the merchant platform and insurer. APIs can pass claim evidence and status, but final claim decisions may require insurance expertise and policy interpretation.

Embedded accounts need clarity about where the money legally sits

A non-bank platform may show an “account balance,” but that label can represent different structures. It may be a deposit account directly in the customer’s name at a partner bank, an electronic-money balance, a wallet sub-ledger backed by safeguarded funds, or another legally defined arrangement.

Customers should understand the relevant provider and protection. Internally, the platform must reconcile its view to the authoritative record maintained by the regulated institution. If pooled accounts are used, sub-ledger integrity becomes especially important because the platform may hold the detailed customer allocation.

The safest operating model does not rely on the customer-facing database as the sole record of money. Independent bank or safeguarding records should be reconciled at an appropriate frequency and exceptions investigated promptly.

White-label banking should not white-label accountability away

White-label arrangements let a brand present financial services under its own experience while regulated infrastructure is supplied by another institution. This can be efficient, but customer-facing branding should not make responsibility invisible.

Disclosures should identify the regulated provider where required, and support teams should know which issues belong to which party. A fraud report, card dispute, account restriction or complaint should have a defined route. The customer should not be told that “the bank is a third party” after the platform marketed the service as an integrated product.

From the bank’s perspective, white-label distribution is still part of its risk perimeter when it provides the regulated service. It needs oversight of product design, customer treatment, fraud patterns, operational resilience and partner conduct proportionate to the arrangement.

Customer onboarding can be split across parties but not left ambiguous

A platform may collect customer data because it already has a commercial relationship. The bank may need to perform regulated customer due diligence before opening a financial product. The parties should define which data can be reused, what fresh consent or verification is required, and which system stores the authoritative KYC evidence.

If the platform verifies an email address while the bank verifies legal identity, those are different controls. Product design should not describe both generically as “verified.” Where customer information changes, the workflow should determine whether the update must propagate to the bank and whether re-verification is required.

Exceptions need a route to human review. Automated onboarding that cannot handle name mismatch, document quality or risk alerts will either reject good customers unnecessarily or allow weak cases through.

Fraud risk crosses the platform-bank boundary

The non-financial platform may have valuable behavioural signals that the bank cannot see. A marketplace knows account age, seller history and device behaviour. The bank sees account transactions, beneficiaries and broader financial activity. Combining relevant signals can improve fraud detection, subject to legal and privacy constraints.

Responsibilities should be defined before launch. If the platform detects account takeover, can it stop a payment itself, or must it call the bank? If the bank detects suspicious beneficiary behaviour, how quickly can the platform contact the customer? What happens outside normal business hours?

Shared incident playbooks reduce delay. They should also define evidence retention so the parties can investigate disputes and suspected fraud without reconstructing data after the event.

Sanctions and AML controls should follow the actual financial activity

Embedded distribution does not remove sanctions or anti-money-laundering obligations that apply to the regulated entity and product. Screening and transaction-monitoring design should identify where customer data, counterparties and payment information are available.

The platform should not independently close a sanctions alert merely because it lacks enough information to see the reason for the bank’s concern. Likewise, the bank may need contextual data from the platform to understand whether unusual activity has a legitimate commercial explanation.

The operating model should specify which cases can be resolved automatically, which require analyst review, and how enhanced information is requested from the customer.

API security should enforce business authority, not only token validity

A valid API token proves that a calling system is authenticated; it does not prove that the call is allowed to act on every customer or account. BaaS APIs need object-level and business-level authorisation.

A platform request to initiate a payment should be checked against the correct customer, account, product permissions and limits. Administrative APIs deserve even stronger control because they may create accounts, change limits or manage credentials.

Machine identities should have least privilege, controlled secrets or certificates, rotation and monitoring. One compromised partner credential should not provide unrestricted access to the provider’s entire banking estate.

API versioning is a customer-resilience issue

BaaS providers change APIs as products evolve. A field may become mandatory, an error code may change, or a new authentication method may be introduced. If consumers are forced to migrate abruptly, customer journeys can break.

Providers should publish version and deprecation policy, offer representative testing environments and communicate material changes. Platforms should maintain an inventory of which product flows depend on each API version.

Backward compatibility should be considered carefully for financial state. A new version that interprets transaction status differently can create misleading customer reporting even when the transport layer remains technically compatible.

Service levels should measure journeys instead of isolated APIs

A sponsor bank can report 99.9% API availability while customers still experience poor service if several dependencies fail sequentially. Embedded-finance service levels should include end-to-end success for important journeys such as account opening, card freeze, payment initiation and balance retrieval.

Latency matters too. An API that takes thirty seconds to return during checkout may technically be available but commercially unusable. Error categorisation helps identify whether the cause is customer input, business rejection, provider failure or downstream infrastructure.

Joint service reviews should look at customer impact and not only contractual component metrics.

Reconciliation proves that the distributed model remains financially whole

Embedded finance creates several records: platform orders, bank transactions, processor records, settlement files, fees, refunds and sometimes customer sub-ledgers. Reconciliation connects them.

For embedded payments, the platform can reconcile initiated payments to bank acceptance, external settlement and merchant credit. For embedded lending, origination, disbursement, repayment, interest and fees need consistent records. For embedded accounts, customer sub-ledgers should reconcile to the sponsor bank position.

Unmatched items should be aged and owned. A reconciliation that merely produces a daily difference without clear investigation is not a strong control.

Accounting economics should be derived from contracts, not generic percentages

There is no universal rule that a bank, BaaS provider and distributor earn fixed rupee amounts from every embedded loan. Economics depend on product type, funding cost, credit risk, interchange, commercial contract, regulation and customer pricing.

The accounting model should identify gross customer revenue, partner fees, processor costs, credit losses, funding costs and any revenue share. This enables the parties to reconcile settlements and management to understand whether the service is sustainable.

A product can have high transaction volume and weak economics if fraud, support or partner costs consume the margin. Scale should therefore be evaluated on a risk-adjusted basis.

Concentration risk can hide behind many different brands

Dozens of apps may appear independent while relying on the same sponsor bank, card processor, cloud provider or identity service. A failure at the shared provider can affect a large customer population across brands.

Banks and platforms should map critical dependencies beyond their direct contract. Material subcontractors and common infrastructure matter. Resilience planning can then identify whether alternative routes, providers or manual contingencies are realistic.

Concentration is not automatically unacceptable, but it should be visible and governed rather than discovered during a sector-wide incident.

Data ownership is less useful than data responsibility

Partnership discussions often ask who “owns the customer data.” In practice, different parties may be controllers, processors, regulated record keepers or contractual users under the applicable legal framework. The more useful operational questions are: who can collect which data, for what purpose, who can change it, how long can it be retained, who handles customer rights, and what happens at termination?

Security classification and access should follow data sensitivity. The platform should not receive complete bank data merely because one API connection exists. The bank should not ingest unrelated marketplace data without a legitimate purpose.

Consent should be enforced in systems, not only captured on screens

A customer may consent to share financial data for a specific purpose or authorise a platform to initiate a certain activity. The technical design should translate that consent into enforceable scope and duration.

If consent expires or is revoked, future access should stop at the API or service layer. A UI flag that says “revoked” while backend credentials continue extracting data is not a functioning consent model.

Records should show what the customer agreed to, when, and which version of terms or permissions applied.

Embedded finance needs a clear complaints architecture

A customer may complain to the platform because that is the brand they know. The issue may actually concern a bank transaction, lender decision, insurer claim or card-network process. The partnership should define intake, ownership, escalation and response.

Complaint categories should be shared enough to identify systemic themes. If many customers report that refunds appear late in the app despite timely bank posting, the issue may be event integration rather than individual payment processing.

Where legal or regulatory deadlines apply, the case-management workflow should ensure the responsible entity receives the complaint with enough time and evidence to act.

Operational resilience must include the partner chain

The customer does not care whether an outage belongs to the platform, BaaS provider or bank. Recovery design should therefore trace the complete service.

If the sponsor bank payment API fails, the platform should know whether it can queue instructions safely, whether the customer should be blocked from submitting, and how uncertain transactions are reconciled. If the platform itself fails, customers may still need emergency channels to block cards or report fraud.

Joint exercises are especially useful for critical services because they test contact paths and decision rights as well as technology.

Exit strategy should be designed before launch

A partnership can end because of commercial disagreement, acquisition, regulatory change, financial distress or strategic change. Customer financial products cannot simply be switched off at contract termination.

An exit plan should address customer communication, open balances, cards, loans, disputes, data, records, consent, regulatory retention and access revocation. If accounts must migrate to another provider, authoritative balances and in-flight transactions need controlled transfer and reconciliation.

The easier time to design this process is before millions of customers depend on the service.

Product changes need joint governance

A platform may want to change onboarding, pricing or customer messaging quickly. The regulated institution may need to review the change because it affects compliance, risk or contractual terms. Governance should distinguish cosmetic changes from material financial changes so innovation is not unnecessarily slow but important controls are not bypassed.

Release calendars and test environments help when changes span several parties. If the platform launches a new field before the bank API accepts it, the customer journey can fail. Coordinated testing should include both success and error paths.

Embedded finance can improve financial inclusion when distribution solves a real barrier

Embedding finance can reach customers who would not begin a traditional bank application, particularly small businesses or workers already active on digital platforms. Transaction context can support tailored products and reduce documentation burden.

Inclusion should not be measured only by account or loan creation. Product affordability, usability, support, fair treatment and sustained access matter. Fast credit that becomes unaffordable is not a successful inclusion outcome.

A practical scenario: marketplace seller working-capital loan

A seller with a stable marketplace history receives a pre-qualified working-capital offer inside the merchant dashboard. The platform sends permitted sales and settlement data to a regulated lender. The lender applies its approved credit policy and returns the offer terms. The seller sees the lender identity, price, repayment method and key conditions before accepting.

After acceptance, the lender disburses funds to the seller’s account. The platform and lender reconcile the disbursement. Repayment is collected from future marketplace settlements according to the agreement, with each deduction recorded against the loan ledger.

If the seller’s sales collapse, the lender’s collections and hardship processes apply. The platform should not silently increase deductions merely to preserve expected repayment. If the data feed fails, the lender should know that the underwriting or collections input is incomplete.

This single feature therefore joins customer experience, consent, data, credit risk, payments, accounting, collections and complaints.

Another scenario: embedded account in a payroll platform

A payroll platform offers employees an account provided by a partner bank. The employee opens the account in the payroll app, but the bank completes the regulated onboarding and owns the deposit ledger. Salary can be credited directly, and the app displays balance and transactions through APIs.

If the bank restricts the account because of a security concern, the restriction must appear promptly in the platform. If the app loses connectivity, it should not invent a balance from stale partial events without indicating the timestamp. Complaints about salary credit need references connecting payroll instruction, bank payment and customer account.

The customer experiences one product, but service quality depends on precise integration and ownership.

The future of embedded finance is governed distribution

The lasting significance of embedded finance is that financial services no longer need to be distributed only through traditional banking destinations. APIs and partnerships let banking capabilities appear inside commerce, software, employment and other digital contexts.

But the financial risk does not disappear into the interface. The strongest models make the regulated provider, authority, ledger, controls, reconciliation, complaints and recovery paths explicit behind the scenes. Embedded finance succeeds when it makes finance contextual without making accountability invisible.

Embedded Finance Top-Up: Controls for Scale and Complex Partnerships

Partner onboarding should resemble product onboarding, not vendor purchasing

A bank that provides embedded financial capability is not merely buying software from the distributor. The distributor can influence customer acquisition, data quality, transaction behaviour and reputation. Partner assessment should therefore consider the proposed product, customer segment, expected volumes, geographic reach, marketing, operational capability, financial condition and control environment.

The bank should understand how the partner earns money. Incentives can shape behaviour. A distributor paid entirely for loan originations may be motivated to maximise volume, while a platform earning from transaction activity may encourage usage in ways that change fraud or liquidity patterns. Commercial incentives are not inherently problematic, but they should not conflict with customer protection or the regulated institution's risk appetite.

Approval should also identify conditions for launch: transaction limits, initial customer caps, enhanced monitoring or staged rollout can allow the parties to learn before full scale.

Customer terms must match the actual entity structure

Embedded products often have several sets of terms: the platform's commercial terms and the financial provider's regulated product terms. These documents should not contradict one another.

If the platform says a wallet is “free forever” while the underlying bank contract allows certain fees, customer expectations will be misaligned. If the marketplace calls a product a merchant advance but the legal agreement is a loan, the customer should still receive the disclosures required for the actual product.

Digital interfaces should present key terms before acceptance in a form the customer can understand. A link to a long legal document can support the contract but should not be used to hide price, repayment obligation, provider identity or major restrictions.

Embedded finance changes the bank's distribution risk

A bank can traditionally control much of its channel experience through branches, mobile apps and its own website. Embedded distribution places part of that experience in another company's interface. The bank may not control the customer's device, navigation, notifications or marketing context.

This creates distribution risk. The bank needs confidence that required disclosures remain visible, authentication is not weakened, complaints reach the right team and customer data is used appropriately. Screens and journeys can change after launch, so ongoing oversight matters.

Material interface changes may require review because small design choices can change customer behaviour. Pre-selected options, confusing fee presentation or overly aggressive prompts can create conduct risk even when the backend financial product is unchanged.

Revenue sharing should not distort customer outcomes

Partnership economics can include referral fees, revenue share, servicing fees or technology charges. Governance should assess whether remuneration could encourage unsuitable product placement or weak underwriting.

For lending, the regulated lender should retain appropriate control of credit policy and decisioning. For insurance or investment products, distribution incentives should align with applicable conduct and suitability requirements. Payments products should not encourage customers to choose an expensive method solely because it produces higher partner revenue.

Finance teams also need transparent settlement. Gross customer charges, tax, partner shares and processor fees should reconcile to accounting records.

Limits are an important early-stage control

When a new embedded product launches, the bank may not yet have enough data to know how customers will behave. Limits can bound exposure while the operating model proves itself.

Limits can apply to individual transaction amount, daily volume, wallet balance, credit exposure, merchant category, geography or total programme volume. They should be designed around the product risk rather than copied from another channel.

As experience grows, limits can be reviewed. Raising them should be a governed decision based on fraud, credit, operational and customer-service evidence, not merely commercial demand.

Settlement design affects partner credit exposure

Suppose an e-commerce platform collects customer payments while merchants expect next-day settlement. If the bank credits merchants before the underlying payment is final, somebody carries settlement or chargeback risk. The contract and accounting model should identify that exposure.

Reserve balances, rolling holds, collateral or delayed settlement can manage risk in some models. The appropriate approach depends on payment method, merchant risk and legal structure.

Embedded finance therefore connects product design to treasury and credit risk even when the customer sees only a checkout screen.

Refunds need end-to-end linkage

A refund starts from a commercial event but creates a financial transaction. The platform should reference the original payment, determine the permitted refund amount and route the instruction to the correct provider.

Partial refunds, multiple refunds and refunds after settlement need defined handling. The customer should see accurate status. The merchant's settlement position and bank ledger should reconcile to the refund.

If the refund API times out, duplicate protection is essential. Repeatedly returning money is as harmful as failing to return it.

Embedded subscriptions create recurring-authority questions

A platform may embed recurring payments for membership, utilities or software. The initial customer authorisation should define the recurring arrangement and the mechanism for cancellation or mandate change.

Banks and platforms need to distinguish a new payment from an authorised recurring instruction. Fraud models may treat them differently. Customer support should be able to identify the merchant or platform subscription behind an unfamiliar debit.

When a recurring authority is cancelled, future attempts should be handled consistently across the platform and payment provider.

Chargebacks can expose fragmented records

Card-based embedded payments may create chargebacks long after the original purchase. The platform holds order data, the processor holds transaction data, and the bank or issuer holds customer and card records.

The case needs a common reference chain. Evidence deadlines can be short, so manual email exchange is weak at scale. Structured case APIs or agreed evidence workflows can improve response.

Chargeback outcomes also need accounting treatment. Merchant reserves, customer credits and scheme settlement should reconcile after final disposition.

Merchant onboarding is its own KYC and fraud problem

Embedded payment platforms frequently onboard merchants or sellers as well as consumers. Merchant due diligence needs to establish the legal business, beneficial owners where required, expected activity and the nature of goods or services.

Fraudsters can create fake merchants to receive stolen-card proceeds or mule funds. Monitoring should therefore examine both payer and merchant behaviour. Sudden volume growth, unusual refund patterns or mismatch between declared business and transactions can justify review.

The platform often has valuable marketplace information, while the financial provider has payment data. Sharing appropriate risk signals can improve detection.

Embedded business banking requires corporate authority controls

A small-business platform may offer accounts and payments within bookkeeping or enterprise software. Corporate users can have different roles, so consumer-style single-user authentication may be insufficient.

The system should support account entitlements, maker-checker approval, transaction limits and authorised signatories according to the bank product. A platform administrator should not automatically become authorised to move company money simply because they administer the software subscription.

Corporate authority should be recorded in a way that remains valid when employees change roles or leave.

Data quality becomes a partnership control

Embedded lenders and banks often rely on data supplied by the platform. If sales, payroll or invoice data are missing or misclassified, automated decisions can be wrong.

Data contracts should define fields, units, timing, corrections and quality thresholds. The receiving institution should detect unusual gaps or changes rather than assuming every feed is complete.

Material decision models should know how to behave when data is unavailable. Using stale values silently can be riskier than sending the case to exception.

Model risk can cross organisational boundaries

A platform may create a score that the bank uses in underwriting or fraud decisions. Even if the bank did not build the model, it should understand enough about purpose, inputs, limitations and performance to use it responsibly.

Contracts should support validation information and change notification. A vendor should not materially change a model overnight without the regulated user understanding the impact where the model influences customer outcomes.

Monitoring should detect performance drift across customer segments and economic conditions.

Partner incidents need one customer-facing narrative

If a BaaS provider fails, the bank may know the technical cause while the customer-facing brand sees only API errors. The two parties should establish incident communication quickly and agree what customers will be told.

Messages should state service impact rather than expose internal blame. “Transfers are delayed and we are working with our banking provider” is more useful than contradictory statements from each company.

Internally, accountability remains important. Post-incident review should identify which party failed, whether contract obligations were met and how controls will improve.

Regulatory reporting data should be designed into the interface

A regulated institution may need customer, transaction and product data for reporting. If the platform does not capture a required field reliably, teams can be forced into manual reconstruction.

Data requirements should therefore be part of API and product design. The platform can validate required information at source, while the bank maintains mappings and lineage into its reporting environment.

Changes to customer-facing fields should be assessed for downstream reporting impact.

Reconciliation should include fee and revenue share

Financial reconciliation is incomplete if principal amounts match but fees do not. Embedded arrangements often contain merchant fees, customer fees, bank charges, network charges and partner revenue share.

Settlement reports should explain how the net amount was derived from gross activity. Finance should be able to trace a contractual rate to the amount paid or received.

This becomes particularly important after refunds or chargebacks because the original fee may be retained, reversed or adjusted under the contract.

Programme governance should combine business and control data

A partnership steering forum should not review only customer growth and revenue. It should also examine fraud, complaints, credit performance, exceptions, service incidents, reconciliation breaks, security findings and regulatory issues.

Seeing these measures together helps leaders identify when commercial success is creating control strain. A programme growing faster than support capacity may need operational investment before further expansion.

Embedded finance should have a controlled kill switch

In a severe incident, the institution may need to stop a specific capability without disabling the entire platform. For example, new loan originations can be paused while existing repayments continue, or high-risk outbound payments can be stopped while balance access remains.

Such controls should be designed before the incident. Emergency suspension should have clear authority, technical implementation and customer communication.

A kill switch is not a substitute for resilience, but it can limit financial loss while teams investigate.

The bank should know the end customer even when distribution is indirect

Depending on the product and law, the regulated institution may need sufficient information about the end customer even when another platform owns the primary relationship. Relying only on the distributor's aggregate account can be insufficient for regulated account or lending activity.

The onboarding architecture should therefore ensure required identity, consent and product evidence reaches the party responsible for it. Data minimisation still applies: the bank needs the data required for its obligations, not every behavioural field the platform holds.

Successful embedded finance becomes invisible for the right reason

The customer should not need to think about APIs, sponsor banks or settlement files during normal use. The service feels simple because identity, authority, money movement and control are integrated correctly.

When something goes wrong, however, the architecture should become visible to operations immediately. Teams should know the regulated provider, transaction reference, ledger state and complaint owner. This combination—simple customer experience with explicit internal accountability—is what allows embedded finance to scale safely.

Final embedded-finance accountability check

Before an embedded product is treated as mature, the bank should be able to trace one customer action across the distributor, regulated provider, transaction processor, ledger, settlement record and servicing owner without relying on informal explanations. The same chain should show who can suspend the service, who resolves a customer complaint, who owns a reconciliation break and which party must preserve evidence after an incident. This final accountability test matters because embedded distribution can make the customer journey look simple while responsibility is spread across several organisations. Scale is safe only when that distributed operating model remains visible and controllable inside the bank.