Open Banking, Open Finance and Embedded Finance

Introduction and context

Financial intermediation is increasingly being reorganized around data, application programming interfaces (APIs), cloud services and digital identity. The traditional bank delivered a relatively complete bundle: deposit-taking, payments, lending, account information, compliance and customer service. In digital ecosystems, these functions can be decomposed and recombined. A bank may provide regulated accounts and payment rails, a technology firm may provide the customer interface, and a specialist may provide credit scoring, fraud detection or financial education.

This decomposition has produced three related but distinct ideas. Open banking permits authorized third parties to access payment-account data or initiate payments through secure interfaces. Open finance extends data portability and permissioned access beyond payment accounts to products such as investments, pensions, insurance and credit. Embedded finance places a financial service inside a non-financial customer journey, such as insurance at the point of purchasing a flight or working-capital finance inside a business-commerce platform.

These models can lower distribution costs, improve user experience and promote competition. They can also create concentration around platforms, obscure responsibility, increase operational interdependence and expose consumers to privacy, fraud and unsuitable-product risks. The central managerial problem is therefore not simply how to connect systems. It is how to design a trustworthy ecosystem in which value, control, liability and regulatory responsibility are allocated clearly.

Learning objectives

By the end of this chapter, the reader should be able to:

1. Distinguish open banking, open finance, Banking-as-a-Service (BaaS), platform finance and embedded finance.
2. Explain the API lifecycle, including discovery, authorization, operation, monitoring, versioning and retirement.
3. Analyze consent, data portability, identity, security and data minimization.
4. Compare platform, marketplace and embedded-finance business models.
5. Evaluate partnerships using strategic, operational, economic and regulatory criteria.
6. Allocate liability and design governance for interoperable financial ecosystems.
7. Apply these concepts to a practical embedded-lending and payments case.

1. From integrated banks to composable finance

A useful analytical distinction is between a product, a capability and a distribution channel. A bank account is a product. Ledger management, payment execution and know-your-customer (KYC) processing are capabilities. A mobile application, merchant platform or payroll system is a distribution channel. Open and embedded models combine capabilities and channels in different ways.

Open banking

Open banking generally refers to regulated, secure access to payment-account information and payment initiation by authorized third-party providers, with the customer’s permission. It is commonly implemented through APIs rather than through screen scraping. The exact scope, licensing requirements and liability rules differ by jurisdiction.

Two principal services are:

• Account information services: aggregation and analysis of balances, transactions and account metadata.
• Payment initiation services: initiating a transfer from a customer’s account to a payee without requiring the customer to use the bank’s own interface for the entire journey.

Open banking does not mean that financial data becomes public. “Open” describes controlled interoperability, not unrestricted disclosure.

Open finance

Open finance applies similar portability principles to a wider set of financial relationships. Potential data domains include savings, mortgages, credit cards, investments, pensions, insurance, and digital assets where law permits. Open finance can support holistic financial planning and more accurate underwriting, but it also raises difficult questions about data standardization, commercial confidentiality, inferred data and the duration of consent.

The move from open banking to open finance is not merely a larger API catalogue. Products differ in valuation, risk, contractual rights and data sensitivity. For example, a transaction history may be relatively standardized, whereas pension rights or insurance claims may require extensive interpretation and may reveal highly sensitive personal circumstances.

Banking-as-a-Service

BaaS is a business arrangement in which a regulated institution supplies banking capabilities—such as accounts, payments, cards, safeguarding or lending infrastructure—to another organization through APIs, operational services or both. The non-bank may own the customer relationship and brand, while the regulated institution performs some or all regulated activities.

BaaS is therefore a supply-side model. Embedded finance is a distribution and experience model. They often appear together, but they are not identical: a bank can provide BaaS without any consumer-facing embedded experience, and a company can embed a financial product through a partnership that is not a full BaaS arrangement.

2. The API and consent architecture

An API is a defined interface through which one software system requests data or an action from another. In finance, APIs normally operate within a wider control architecture comprising identity, authentication, authorization, encryption, audit logging, fraud controls, service-level management and dispute handling.

A typical account-information sequence is:

1. The customer selects a third-party provider (TPP) and requests a service.
2. The TPP states the requested data categories, purpose and duration.
3. The customer is redirected or otherwise authenticated by the account-servicing institution.
4. The customer grants or refuses consent.
5. The institution issues an authorization result or token with defined scope and expiry.
6. The TPP calls the API and receives only permitted data.
7. Access is monitored, reconciled and terminated when consent expires or is withdrawn.

Payment initiation adds payment details, beneficiary controls, strong customer authentication where required, confirmation and settlement. The institution must distinguish a valid customer instruction from a fraudulent or manipulated instruction; the TPP must also protect the integrity of the payment request.

The API lifecycle

API management should be treated as a lifecycle rather than as a one-time integration project.

Versioning is especially important. A change in a field definition can alter a credit decision even if the API remains technically available. Effective governance specifies semantic as well as technical compatibility, notice periods, deprecation procedures and responsibility for downstream testing.

Consent is a control, not a checkbox

Valid consent should be informed, specific, freely given where applicable, time-bounded or reviewable, and capable of withdrawal. A well-designed consent record answers at least five questions:

• Who granted permission, and how was identity established?
• Which data or action was authorized?
• For what stated purpose?
• For how long and under what frequency limits?
• How can the user view, change or revoke the permission?

Consent should be separated from unrelated terms where law requires this, and interfaces should avoid dark patterns such as making acceptance prominent while hiding refusal. A service should not request continuous access when a one-time data transfer is sufficient. Nor should an organization treat consent as permission to reuse data for every future commercial purpose.

A practical consent object may contain a subject identifier, provider identifier, scope, purpose, start and expiry times, status, authentication evidence and revocation history. It should be auditable without unnecessarily storing raw financial data.

Data portability and minimization

Portability has three dimensions:

1. Technical portability: data is available in a usable, structured and interoperable format.
2. Legal portability: the user has a recognized right or contractual mechanism to obtain and transmit it.
3. Economic portability: switching is affordable and not blocked by unreasonable friction.

Portability does not imply that every dataset must be transferred. Data minimization requires collecting and disclosing what is necessary for a defined purpose. Organizations should distinguish customer-provided data, observed data, derived data and inferred data. A transaction is observed; a risk score is derived or inferred. The latter may be more commercially sensitive and may require special explanation or review.

Security and trust

Core controls include mutual authentication, encryption in transit and at rest, least-privilege authorization, token protection, secrets management, anomaly detection, secure software development, independent testing and resilient recovery. Security must cover the entire chain: TPP, bank, cloud provider, analytics provider and operational support.

Strong authentication verifies the customer using appropriate factors; it does not by itself prove that a payee or application is trustworthy. Fraud controls should therefore include transaction monitoring, behavioral analysis, confirmation of payee where available, velocity limits and human escalation for unusual activity. Artificial intelligence can support anomaly detection and document analysis, but model outputs require validation, explainability appropriate to the use, bias testing and clear accountability. An AI system should not become an unreviewable source of credit exclusion merely because it operates through an API.

3. Business models and value creation

Platform model

A platform connects multiple participant groups and supplies shared rules, identity, technology and governance. A banking platform may connect consumers, merchants, banks, fintechs and service providers. Its value often increases with participation, producing network effects. However, network effects can create gatekeeper power, self-preferencing and dependence on one technical or commercial intermediary.

Marketplace model

A marketplace matches customers with multiple providers, such as lenders, insurers or investment products. It can improve comparison and competition, but the operator must manage ranking incentives, product suitability, disclosure, conflicts and the risk that customers interpret a commercial ranking as an impartial recommendation.

Embedded-finance model

Embedded finance integrates a financial service into an existing non-financial workflow. Examples include:

• pay-by-bank at online checkout;
• invoice finance within accounting software;
• insurance during travel or vehicle purchase;
• corporate cards inside expense-management software;
• savings or investing within a payroll application.

The user may value convenience more than a separate financial brand. The distribution partner contributes customer access and contextual data; the regulated provider contributes balance-sheet capacity, licensing, payments, risk management and compliance. The arrangement is commercially powerful because it reduces search and transaction friction, but it can make the financial nature of an offer less visible.

4. Economics and strategic evaluation

Management should assess an ecosystem using both direct economics and risk-adjusted economics. Direct revenue may include interchange, subscription, origination, servicing, referral or revenue-sharing income. Costs include technology, compliance, customer support, fraud losses, partner management and capital or liquidity costs where relevant.

A simple contribution model is:

where C is contribution per customer or transaction, R is revenue, V is variable operating cost, F is allocated fixed cost, L is expected loss and K is the relevant capital, funding or risk-adjustment cost. All terms must be measured over the same period and in the same currency. The formula is a management accounting approximation, not a regulatory capital calculation.

For credit products, expected loss is often represented as:

where PD is probability of default, LGD is loss given default as a proportion of exposure, and EAD is exposure at default. The expression assumes compatible definitions and a sufficiently simple setting; production models may incorporate discounting, time horizons, recoveries, cure rates and multiple scenarios. A contextual data advantage is valuable only if it improves decisions without creating unacceptable discrimination, privacy violations or model risk.

Partnership evaluation should cover five dimensions:

1. Strategic fit: Does the partner provide distinctive distribution, data, balance sheet, trust or technology?
2. Customer value: Is the service cheaper, faster, safer or more suitable?
3. Operational resilience: Can the combined service withstand outages, cyberattack and volume shocks?
4. Regulatory fit: Are licensing, outsourcing, consumer-protection and data obligations understood?
5. Exit feasibility: Can the relationship be migrated or terminated without harming customers?

The last criterion is often neglected. A low-cost partnership may be strategically dangerous if customer records, payment operations or compliance evidence cannot be transferred to an alternative provider.

5. Interoperability, liability and ecosystem governance

Interoperability includes technical, semantic, operational and legal compatibility. Two systems may exchange messages yet remain non-interoperable if they interpret “available balance,” “settled transaction” or “beneficial owner” differently. Governance must therefore address shared data dictionaries, identifiers, error codes, service levels, dispute processes and change control.

Allocation of responsibility

Responsibility should follow control and capability, but contractual allocation cannot eliminate mandatory legal duties. A sound responsibility matrix identifies who controls:

• customer disclosure and suitability;
• authentication and consent capture;
• data accuracy and correction;
• payment execution and reconciliation;
• fraud monitoring and reimbursement;
• cybersecurity and incident notification;
• complaints and redress;
• record retention and audit access;
• business continuity and exit.

A useful principle is that customer-facing organizations must not hide behind a technology provider, while regulated institutions must not assume that outsourcing transfers their regulatory accountability. Contracts should specify service levels, audit rights, subcontracting limits, breach notification times, access to data and logs, testing duties, indemnities, insurance, recovery objectives and termination assistance.

Operational resilience

Ecosystem resilience is constrained by shared dependencies. An institution may appear diversified across many fintech partners while all depend on the same cloud region, identity provider or payment processor. Management should map critical services to people, processes, technology, facilities and third parties. Important measures include availability, recovery time objective (RTO), recovery point objective (RPO), incident frequency, failed-payment rate, consent-error rate and mean time to detect and restore.

Resilience is not identical to availability. A system can be available while returning stale balances or duplicating payments. Integrity, confidentiality, recoverability and customer communication are equally important.

Competition and concentration

Open ecosystems can reduce dependence on incumbent banks, but infrastructure markets may concentrate around dominant aggregators, cloud providers or platforms. Governance questions include access pricing, portability of business customers, interoperability mandates, self-preferencing, exclusive dealing and use of partner data to compete against partners. A platform that both operates the marketplace and sells products through it requires especially strong conflict controls.

Consumer protection and ethics

The customer should know when a financial product is being offered, who provides it, how fees are charged and where complaints should be made. Embedded placement can exploit behavioral biases because the offer appears at a moment of urgency or convenience. Responsible design includes plain-language disclosures, cooling-off or cancellation rights where applicable, affordability assessment, accessibility, vulnerable-customer support and effective redress.

Data-driven personalization can improve relevance but can also reproduce historical exclusion. Organizations should test outcomes across protected and vulnerable groups, document proxy variables, monitor drift and provide meaningful review or appeal channels. Privacy and fairness are not obstacles external to innovation; they are conditions for sustainable trust.

6. Illustrative case: LedgerLink Commerce

The following is a fictional illustrative case.

Background

LedgerLink is a software platform used by 18,000 small retailers. It combines point-of-sale records, invoices and inventory management. Management proposes two embedded services: pay-by-bank at checkout and short-term working-capital advances based on sales and cash-flow data. A licensed bank will hold funds and provide payment and lending infrastructure; a specialist fintech will provide the API gateway and credit model.

Problem

LedgerLink expects higher checkout conversion and new fee income, but the board identifies four risks. First, customers may not understand that the loan is supplied by another entity. Second, the credit model may use detailed transaction data beyond what is necessary. Third, an API outage could interrupt both payments and retail operations. Fourth, responsibility for unauthorized payments and inaccurate credit decisions may be disputed among the three firms.

Analysis

The proposed structure combines embedded finance, BaaS and a marketplace-like selection process. LedgerLink controls the customer journey and possesses contextual data. The bank controls regulated payment and lending functions. The fintech controls integration and model operations. No single party controls the whole customer outcome, so governance must be deliberately shared.

The firms create a data map distinguishing data required for payment execution from data used for underwriting. They design a separate, granular consent journey for optional analytics. The credit model is tested for predictive performance and disparate outcomes, with a human review route for rejected applicants. The bank retains final credit-policy authority and compliance oversight rather than treating the fintech’s score as an automatic decision.

For payments, the bank and fintech implement transaction limits, confirmation controls, duplicate detection, reconciliation and an agreed reimbursement process. The API contract specifies error semantics and prevents a timeout from being interpreted as a successful payment. A joint incident team rehearses cloud failure and cyberattack scenarios. LedgerLink receives dashboards showing payment failures, loan acceptance rates, complaints and data-access events.

Approach and solution

The partnership agreement establishes a responsibility matrix, minimum service levels, audit access, subcontracting approval, customer-notification rules and an exit plan. The user interface names the regulated provider, total cost of credit, key risks and complaint route. The platform is prohibited from ranking or promoting loans solely according to revenue share. A quarterly governance committee reviews model drift, fairness, incidents, complaints and changes to API versions.

Outcome

After a controlled pilot, payment completion improves and retailers report faster access to finance. The pilot also reveals that older business owners abandon the consent journey more frequently. The firms simplify language, add assisted support and remove a nonessential permission. A later model review finds that a sector variable acts as a proxy for geography; it is removed and outcomes are monitored again.

Learning points

The case demonstrates that successful embedded finance is a governance design problem as much as a product-design problem. Data access should be purpose-specific; regulated accountability should remain visible; resilience must be tested across organizational boundaries; and commercial incentives must not undermine suitability or fair access.

7. Implementation framework for managers

A phased implementation can reduce strategic and operational error:

Phase 1: Define the use case. Identify the customer problem, regulated activities, data flows, affected users and measurable outcomes. Establish whether the service is genuinely useful or merely an additional monetization layer.

Phase 2: Design the target operating model. Allocate product ownership, compliance, customer support, data stewardship, fraud operations, technology ownership and financial responsibility. Decide which functions are internal, outsourced or jointly governed.

Phase 3: Perform due diligence. Assess licensing, financial strength, information security, model governance, subcontractors, resilience, complaints history and exit capability. Verify claims through evidence rather than relying on certification labels alone.

Phase 4: Build and test. Use sandbox environments, synthetic or properly controlled data, contract tests, penetration tests, accessibility tests and failure-injection exercises. Test business meaning, not merely successful API responses.

Phase 5: Pilot and monitor. Limit scope and volume. Monitor customer outcomes, not just technical uptime. Useful indicators include authorization completion, data-access errors, payment failures, fraud losses, complaints, time to redress, credit performance and outcome differences across customer groups.

Phase 6: Scale and review. Introduce version controls, independent assurance, periodic consent review, model validation and scenario testing. Reassess whether the partnership remains beneficial as volumes, regulations and dependencies change.

Contemporary developments and limitations

Open finance policy is evolving unevenly across jurisdictions. Some regimes emphasize mandated access, others rely more heavily on market-led agreements. Differences in liability, authentication, data rights and technical standards complicate cross-border operations. Global firms must treat jurisdictional mapping as a continuing activity rather than assuming that one consent design is universally valid.

Real-time payments, digital identity, tokenized assets and artificial intelligence may expand embedded use cases. Yet technical capability does not solve institutional questions about ownership, accountability and redress. Generative AI may improve customer support and developer productivity, but confidential financial data, hallucinated advice, prompt injection and inadequate auditability create significant risks. AI should be introduced through controlled use cases, documented data lineage, human oversight and incident procedures.

The most important limitation of open ecosystems is that access alone does not guarantee competition. Consumers may not switch because of inertia, confusing choices, trust concerns or lack of meaningful interoperability. Similarly, more data does not necessarily produce better finance: it may increase noise, bias and surveillance. Public policy and managerial practice should therefore measure consumer outcomes and market quality, not simply the number of API calls or connected providers.

Chapter Summary

Open banking enables permissioned access to payment-account information and payment initiation; open finance extends portability to broader financial products. BaaS supplies regulated capabilities through partnerships, while embedded finance places those capabilities inside non-financial journeys. Platform, marketplace and embedded models create different sources of value and different governance risks.

The API lifecycle covers design, testing, authorization, operation, change and retirement. Effective consent is specific, informed, auditable and revocable. Data portability requires technical, legal and economic usability, balanced by data minimization and privacy. Interoperability must be technical, semantic, operational and legal.

Partnerships should be assessed for strategic fit, customer value, resilience, regulatory compliance and exit feasibility. Contracts and responsibility matrices should address authentication, data accuracy, payment execution, fraud, complaints, incidents and continuity. Regulated firms retain accountability for outsourced activities, and customer-facing platforms should not obscure the identity of the provider or route to redress. Ethical governance requires fair, accessible and explainable use of data and AI. The durable advantage of open and embedded finance is therefore not connection alone, but trusted coordination across the ecosystem.

Key Terms

Account information service: Permissioned service that accesses account data for aggregation or analysis.

API: Defined software interface through which systems request data or actions.

API lifecycle: The stages of designing, building, operating, changing and retiring an API.

BaaS: Provision of regulated banking capabilities to another organization through technology and operational services.

Consent: A customer’s informed authorization for specified data use or action.

Data minimization: Limiting collection and sharing to what is necessary for a defined purpose.

Data portability: Ability to obtain and transmit usable personal data to another provider.

Embedded finance: Financial service integrated into a non-financial product or workflow.

Interoperability: Ability of systems and organizations to exchange and correctly use information or services.

Marketplace model: Arrangement that matches customers with multiple financial providers.

Open banking: Permissioned access to payment-account data and payment initiation.

Open finance: Extension of open-data and portability principles across financial products.

Platform model: Multi-sided system that coordinates participants under shared technical and commercial rules.

Payment initiation service: Service that initiates a payment from a customer’s account with authorization.

Strong customer authentication: Authentication using appropriately independent factors or evidence.

Third-party provider (TPP): Authorized organization accessing account data or initiating payments for a customer.

Token: Security credential representing an authorized access scope or session.

Operational resilience: Ability to continue, recover and maintain integrity of important services during disruption.

Review Questions

Short Answer Questions

1. Distinguish open banking from open finance.
2. Why is consent more than a checkbox?
3. What is the difference between BaaS and embedded finance?
4. Name four dimensions of interoperability.
5. Why is exit feasibility important in partnership evaluation?

Long Answer Questions

1. Explain the API lifecycle and discuss the governance risks associated with versioning and retirement.
2. Compare platform, marketplace and embedded-finance models in terms of value creation, risk and governance.
3. Discuss how data portability can promote competition while creating privacy and fairness risks.
4. Explain how liability should be allocated among a bank, a fintech infrastructure provider and a customer-facing platform.
5. Evaluate the role of AI in open-finance ecosystems, including its opportunities and control requirements.

Analytical / Application Questions

1. A retailer platform wants to use transaction histories for both pay-by-bank and lending. Design a consent and data-minimization framework that separates essential from optional uses.
2. A payment API is available 99.9% of the time but frequently returns stale balances and ambiguous timeout messages. Assess whether this represents adequate operational resilience and propose controls.
3. Using the LedgerLink case, prepare a responsibility matrix covering customer disclosure, authentication, credit decisions, fraud reimbursement, incident response and complaints. Justify each allocation.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes open banking from open finance?

A. Open banking concerns only cryptocurrency, while open finance concerns deposits.

B. Open banking generally focuses on payment-account data and payment initiation, while open finance extends access across broader financial products.

C. Open banking eliminates the need for customer consent, while open finance requires consent.

D. Open banking is a BaaS arrangement, while open finance is a marketplace.

Correct Answer: B. Open banking generally focuses on payment-account data and payment initiation, while open finance extends access across broader financial products.

Question 2

Which API lifecycle activity primarily addresses safe change without breaking existing users?

A. Customer acquisition

B. Versioning and migration management

C. Balance-sheet provisioning

D. Product ranking

Correct Answer: B. Versioning and migration management

Question 3

Which practice best reflects data minimization?

A. Requesting continuous access to all accounts for future commercial use

B. Collecting only the data necessary for a specified purpose and duration

C. Storing raw financial data indefinitely in case it becomes useful

D. Sharing inferred credit scores without documenting their origin

Correct Answer: B. Collecting only the data necessary for a specified purpose and duration

Question 4

A lender has probability of default of 4%, loss given default of 40%, and exposure at default of $10,000. Under EL = PD × LGD × EAD, what is expected loss?

A. $16

B. $40

C. $160

D. $4,000

Correct Answer: C. $160

Question 5

Which feature most clearly characterizes embedded finance?

A. A financial service is integrated into a non-financial customer journey.

B. A bank closes all external technology connections.

C. A regulator publishes a new capital rule.

D. A customer visits a branch to request a paper statement.

Correct Answer: A. A financial service is integrated into a non-financial customer journey.

Question 6

Why can a regulated bank not generally transfer all regulatory accountability to a BaaS technology partner?

A. Technology partners cannot write software.

B. Mandatory regulatory duties remain with the regulated institution even when activities are outsourced.

C. BaaS contracts are always prohibited.

D. Customers cannot use APIs for regulated services.

Correct Answer: B. Mandatory regulatory duties remain with the regulated institution even when activities are outsourced.

Question 7

Which item is most directly an example of semantic interoperability?

A. Two systems use encrypted network connections.

B. Two systems interpret “settled transaction” in the same way.

C. Two firms have different complaint procedures.

D. A cloud provider increases storage capacity.

Correct Answer: B. Two systems interpret “settled transaction” in the same way.

Question 8

Which governance measure best addresses a platform’s conflict when it ranks products from which it receives the highest commission?

A. Remove all audit logs

B. Permit ranking solely by commission

C. Disclose incentives, establish ranking controls and monitor suitability outcomes

D. Request broader customer permissions

Correct Answer: C. Disclose incentives, establish ranking controls and monitor suitability outcomes

Question 9

In the illustrative LedgerLink case, why was a separate consent journey for optional analytics appropriate?

A. Payment execution never requires authentication.

B. It distinguishes data necessary for the core service from an additional purpose.

C. It allows the platform to avoid all privacy obligations.

D. It guarantees that the credit model is unbiased.

Correct Answer: B. It distinguishes data necessary for the core service from an additional purpose.

Question 10

Which measure is most relevant to an ecosystem’s ability to recover after a major service disruption?

A. Brand color consistency

B. Recovery time objective and tested continuity procedures

C. Number of marketing emails

D. Size of the product catalogue

Correct Answer: B. Recovery time objective and tested continuity procedures