Open Banking, APIs and Embedded Finance

Introduction and context

Digital banking is increasingly organized around connected services rather than isolated bank products. A customer may use a budgeting application to view accounts held at several banks, obtain credit at an online marketplace, insure a purchase during checkout, or make a payment without visiting a bank website. These experiences depend on application programming interfaces (APIs), customer consent, secure data exchange, and carefully allocated responsibility among banks, technology firms, merchants and regulators.

Open banking is the regulated or market-led sharing of banking data and payment functionality with authorized third parties. Open finance extends this idea to a broader range of financial information, such as investments, pensions, insurance and lending. Banking-as-a-Service (BaaS) allows a regulated institution to provide banking capabilities through APIs to another business. Embedded finance places financial products directly inside a non-financial customer journey.

These models can increase competition, convenience and financial inclusion. They can also create concentration, privacy, fraud, operational and consumer-protection risks. The central professional question is therefore not simply whether an institution should connect to an external provider, but how it should design governance, consent, security, liability, economics and exit arrangements.

Learning objectives

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

1. Explain open banking, open finance, APIs, BaaS and embedded finance.
2. Describe common API standards and the role of authentication, authorization and consent.
3. Distinguish data sharing from payment initiation and account servicing.
4. Evaluate partnership, liability, monetization and third-party-risk decisions.
5. Apply a practical framework to assess an open-banking or embedded-finance proposal.

1. The architecture of connected finance

1.1 What is an API?

An API is a defined interface through which one software system requests data or an action from another system. It specifies permitted operations, message formats, authentication requirements, error responses and service expectations. An API is not merely a screen-scraping tool; it is a governed contract between systems.

A typical account-information request may follow this sequence:

1. A customer selects a regulated third-party provider (TPP) in an application.
2. The TPP redirects or connects the customer to the account-servicing payment service provider (ASPSP), usually the bank.
3. The customer authenticates with the bank and gives explicit permissions.
4. The bank issues an authorization code or token.
5. The TPP exchanges the code for an access token and calls approved API endpoints.
6. The bank validates the token, scope, expiry and risk controls before returning data.
7. The customer or bank can revoke access; the permission eventually expires.

An API request commonly contains an endpoint, method, headers, credentials or token, parameters and a body. Typical methods include GET for retrieval, POST for creating an action, PUT or PATCH for updating a resource, and DELETE for removal. Exact meaning depends on the standard and implementation.

1.2 Open banking, open finance and data portability

Open banking normally concerns payment accounts and payment services. It may support:

• account information services, which aggregate balances and transactions;
• payment initiation services, which initiate a transfer with customer authorization;
• confirmation of funds or account ownership; and
• product comparison, affordability analysis and personal financial management.

Open finance is a broader policy and market concept. It may include bank accounts, credit, investments, mortgages, pensions and insurance. Broader coverage can improve advice and competition, but it also increases the sensitivity, complexity and potential consequences of data sharing.

Data portability is not the same as public disclosure. The customer remains central to the permission decision, and access should be limited to a defined purpose, data set and period. A provider that receives data for cash-flow analysis should not automatically be entitled to use it for unrelated advertising or sell it onward.

1.3 BaaS and embedded finance

In a BaaS arrangement, a licensed bank supplies regulated capabilities—such as accounts, cards, payments, safeguarding or compliance infrastructure—to a distributor or technology company. The non-bank may own the customer interface and brand, while the bank retains regulated responsibilities or performs them contractually.

Embedded finance is the customer-facing result of integrating financial services into a non-financial product. Examples include:

• a retailer offering instalment credit at checkout;
• a ride platform paying drivers into digital accounts;
• a software platform providing expense cards to business users; and
• an online marketplace initiating supplier payments.

BaaS describes an institutional delivery model; embedded finance describes a distribution experience. They frequently operate together but are not identical.

2. API standards and technical controls

2.1 Standards and profiles

Standards improve interoperability, reduce ambiguity and support secure implementation. Common building blocks include RESTful APIs using HTTPS and JSON, OAuth 2.0 for delegated authorization, OpenID Connect for identity information, and financial-grade security profiles that strengthen authorization-code flows. Many jurisdictions publish their own open-banking specifications, endpoint profiles and certification rules. International initiatives such as the Berlin Group standards and ISO 20022 messaging also influence implementation, although they do not create one universal open-banking API.

A bank should distinguish:

• transport security: protecting data in transit, normally with current TLS configurations;
• application authorization: deciding what an approved client may do;
• customer authentication: verifying the person or organization;
• message integrity and non-repudiation: detecting alteration and supporting evidence; and
• availability controls: rate limits, monitoring, resilience and incident response.

TLS encryption alone does not prove that a request is legitimate. A secure design also validates the client, token, consent scope, transaction context and fraud indicators.

2.2 Authentication, authorization and consent

Authentication answers, “Who is the user or system?” Authorization answers, “What is that party allowed to do?” Consent is the customer’s informed permission for a specified processing activity. These concepts should not be collapsed.

Strong customer authentication commonly uses two or more independent factors from knowledge, possession or inherence. A password and a one-time code delivered through the same compromised channel may not provide the intended independence. Step-up authentication may be appropriate when risk increases, such as a new beneficiary, unusual device or high-value transaction.

Good consent design is:

• specific: it names the purpose and categories of data;
• informed: material consequences are understandable;
• freely given: access to an essential service is not unfairly conditioned on unnecessary permissions;
• revocable: withdrawal is practical and does not require unreasonable effort;
• time-limited: permissions expire or are periodically renewed; and
• auditable: the institution can demonstrate what was presented, accepted and accessed.

Consent dashboards should show active providers, permissions, last access, expiry and revocation controls. A preselected “agree to all” option is weak governance, especially where data use is broad or unrelated to the requested service.

2.3 Data minimization and lifecycle management

Secure sharing includes the entire data lifecycle: collection, transmission, storage, use, onward sharing, retention and deletion. Controls should include data classification, encryption at rest, least-privilege access, pseudonymization where feasible, segregation of production and testing environments, secure key management, vulnerability management and detailed audit logs.

A practical permission model can be represented as:

where u is the authorized user or customer, d is the permitted data set, a is the allowed action, p is the purpose, t is the validity period and e is the authorized recipient or application. The model is conceptual rather than a universal technical specification. A request should be accepted only when its attributes match the active permission and applicable law.

3. Consent and secure data-sharing governance

Consent management must address both customer experience and institutional evidence. The bank should maintain records of consent creation, authentication events, scope changes, data calls, failed attempts, revocation and deletion. It should also reconcile the bank’s permission record with the TPP’s records.

A sound governance process asks:

1. What customer benefit justifies the data access?
2. Is every requested field necessary?
3. Is the recipient authorized and within the relevant jurisdiction?
4. How will the customer authenticate and revoke access?
5. What happens if the TPP suffers a breach or becomes insolvent?
6. How will inaccurate data be corrected?
7. How will vulnerable customers and non-digital customers be supported?

The bank should not treat a consent screen as a substitute for accountability. Where law places duties on multiple actors, each party must understand its own role. Contracts should specify controller and processor responsibilities where relevant, breach notification, audit rights, complaint handling, retention, subcontracting and deletion.

4. Business models and monetization

Open-banking services may create value through subscription fees, transaction fees, interchange, referral income, lending margins, fraud reduction, reduced servicing cost or higher customer retention. A free consumer application may monetize through a business subscription, while a bank may benefit indirectly from better credit assessment or lower payment costs.

Revenue must not undermine customer interests. Important questions include:

• Is the service charging the customer, the merchant, the bank or the TPP?
• Is a recommendation influenced by commission?
• Are customers being encouraged to share excessive data?
• Does a free service depend on targeted advertising or data resale?
• Who bears losses from unauthorized transactions, downtime and failed reconciliation?

A simple partnership contribution model is useful for decision-making:

where V is estimated net partnership value per period, R is relevant revenue or avoided cost, C is operating and technology cost, L is expected loss and remediation cost, and K is capital, compliance and risk-management cost. The expression is a management estimate, not an accounting standard. It should include realistic scenarios rather than only expected average conditions. If values are measured in currency per year, every term must use the same annual basis.

Expected loss may be approximated as:

where PD is probability of the loss event, EAD is exposure at the time of event, and LGD is loss given default or incident, expressed as a proportion between 0 and 1. This formula is most directly applicable to credit-risk estimation; operational and fraud losses may require event-frequency and severity models. It should not be presented as a guarantee of actual loss.

5. Liability and third-party risk

5.1 Allocation of responsibility

Liability follows applicable law and the facts of the arrangement; it cannot be transferred completely by contract. Nevertheless, contracts should allocate operational duties clearly. A responsibility matrix may cover:

The customer interface can create “brand confusion”: a customer may believe the retailer, not the bank, is responsible for a deposit or payment. Disclosures must identify the regulated entity, protection arrangements, fees, complaints route and material limitations in plain language.

5.2 Third-party-risk framework

Before onboarding a provider, the institution should conduct due diligence covering ownership, licensing, financial condition, security architecture, privacy practices, resilience, subcontractors, sanctions exposure, fraud controls and regulatory history. Due diligence is not a one-time questionnaire. It should be proportionate to criticality and refreshed throughout the relationship.

Useful controls include:

• service-level objectives and measurable availability;
• penetration testing and independent assurance reports;
• privileged-access management and secure software development;
• concentration and substitutability analysis;
• business-continuity and disaster-recovery testing;
• notification deadlines for incidents and material changes;
• audit, information and regulator-access rights;
• customer-data segregation and deletion requirements; and
• a tested exit plan with data portability and transition support.

A critical provider should have a credible exit strategy. “We can terminate the contract” is insufficient if customers cannot access funds, data cannot be migrated, or no alternative provider exists.

6. A decision framework for partnerships

A bank assessing an embedded-finance proposal can use five gates.

Gate 1: Strategic fit. Does the proposal serve a defined customer need and support the institution’s risk appetite?

Gate 2: Regulatory perimeter. Which entity performs accepting deposits, issuing payment instruments, lending, advising, safeguarding or processing personal data? Are licenses, permissions and disclosures adequate?

Gate 3: Customer and conduct risk. Are pricing, eligibility, marketing, consent, accessibility and complaint arrangements fair? Could the interface induce unsuitable borrowing or obscure the bank’s identity?

Gate 4: Technology and operational resilience. Can the parties authenticate, monitor, reconcile, recover and communicate during an outage or cyberattack?

Gate 5: Economics and exit. Are revenues, costs, losses, capital and dependency acceptable? Can the bank suspend or exit without unacceptable customer harm?

The result should be a documented decision with owners, controls, residual risks and review dates—not merely a commercial approval.

7. Applied case: MarketHub embedded payments and working capital

The following is an illustrative case, not a description of a real institution.

Background

MarketHub, an online marketplace, wants to offer sellers instant settlement, a digital business account and short-term working-capital advances. A licensed bank will provide accounts, payment execution and lending infrastructure through APIs. MarketHub will manage the seller interface and use marketplace transaction data for eligibility assessment.

Problem

The proposal may improve cash flow for small sellers, but it creates risks. Sellers may misunderstand who holds their money. Marketplace data may be used beyond the purpose for which it was collected. A bank outage could interrupt thousands of businesses, and the bank could become dependent on MarketHub for customer support and origination.

Analysis

The parties should separate three permissions: account servicing, payment initiation and credit assessment. A seller choosing working-capital finance should not automatically grant unrestricted access to unrelated personal or employee data. The bank must independently assess affordability and comply with lending obligations; MarketHub’s commercial recommendation cannot replace regulated credit controls.

The contract should identify the bank as the regulated provider of the account and lender, establish safeguarding and reconciliation duties, set support and complaint procedures, and require rapid notification of fraud or security incidents. API scopes should limit MarketHub to necessary balances, settlement records and authorized transaction data. Access tokens should expire, and sellers should have a dashboard to review and revoke permissions.

The operational design should include transaction limits, anomaly detection, duplicate-payment controls, idempotency for retried payment requests, daily reconciliation and manual escalation. Idempotency means that repeating the same safely identified request does not create an unintended duplicate action; it is essential when networks fail and clients retry.

Approach and outcome

The bank approves a controlled pilot for a limited seller segment. It sets exposure limits, performs enhanced due diligence, tests disaster recovery, and requires a fallback process for seller withdrawals. It also conducts a customer comprehension test before launch. The commercial model is revised so that MarketHub receives a transparent service fee rather than an undisclosed incentive tied to unsuitable borrowing.

The pilot proceeds only after the bank verifies that customer communications identify the regulated entity, data permissions are granular, and exit arrangements have been tested. The arrangement creates a potentially valuable distribution channel while preserving bank oversight.

Learning points

1. A convenient interface does not remove regulated responsibilities.
2. Data access for payments should not automatically become permission for lending or marketing.
3. Liability, support and exit arrangements must be designed before launch.
4. Partnership economics should include operational, conduct and concentration risk.

8. Challenges, ethics and contemporary developments

Open finance may improve competition but may also widen surveillance and discrimination. Transaction data can reveal health, religion, political activity, employment patterns or financial distress. Automated credit models may reproduce historical inequalities, especially when alternative data is used without explainability or effective challenge mechanisms.

Artificial intelligence can assist fraud detection, customer support, consent-language testing and cash-flow analysis. However, institutions must govern model quality, bias, privacy, explainability, human oversight, data drift and adverse-action explanations. An AI system should not be allowed to expand a customer’s consent merely because a prediction would be commercially useful.

Other contemporary developments include variable recurring payments, real-time payments, digital identity, stronger fraud liability regimes, standardized data-sharing schemes and the movement toward open finance. These developments increase the value of interoperable infrastructure but also make outages and third-party failures capable of spreading rapidly across institutions.

Best practice is therefore based on proportional openness: expose useful capabilities through well-documented interfaces, but apply least privilege, strong authentication, continuous monitoring, resilient operations, clear accountability and meaningful customer control.

Chapter Summary

Open banking enables authorized third parties to access banking data or initiate payments through governed interfaces. Open finance extends sharing to wider financial products. APIs provide the technical contract, while authentication, authorization, consent, encryption, monitoring and resilience provide the control environment. BaaS supplies regulated capabilities to distributors, and embedded finance places those capabilities inside non-financial journeys.

Effective decisions require more than technical integration. Institutions must assess customer benefit, regulatory perimeter, privacy, data minimization, liability, third-party resilience, economics, concentration and exit. Consent should be specific, informed, revocable, time-limited and auditable. Contracts can allocate duties but cannot eliminate legal or ethical accountability. Carefully governed partnerships can increase competition and convenience; poorly governed ones can amplify fraud, privacy breaches, consumer harm and operational disruption.

Key Terms

API: A defined software interface through which systems exchange data or request actions.

Account information service: A service that aggregates or presents account information with authorization.

Account-servicing payment service provider: The institution that maintains the customer’s payment account.

Authorization: Permission granted to a user or application to perform specified actions.

BaaS: Banking-as-a-Service; provision of banking capabilities by a regulated institution through technology interfaces.

Consent: An informed and purposeful permission for specified data processing or activity.

Data minimization: Limiting collection and use to data necessary for a defined purpose.

Embedded finance: Financial services integrated into a non-financial product or customer journey.

Idempotency: A property whereby safe repetition of a request does not create unintended duplicate effects.

Open banking: Controlled sharing of banking data and payment functionality with authorized third parties.

Open finance: Broader sharing of financial data and services across banking and other financial sectors.

OAuth 2.0: A framework for delegated authorization between applications.

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

Scope: The defined range of data or actions permitted by an authorization.

Strong customer authentication: Authentication using independent factors from knowledge, possession or inherence.

Third-party risk: Risk arising from dependence on an external provider or partner.

Token: A credential representing an approved authorization or session.

TPP: Third-party provider authorized to access data or initiate services.

Review Questions

Short Answer Questions

1. Define open banking and distinguish it from open finance.
2. What is the difference between authentication and authorization?
3. State four characteristics of good customer consent.
4. Explain the difference between BaaS and embedded finance.
5. Why is an exit plan important in a critical third-party relationship?

Long Answer Questions

1. Explain the lifecycle of an open-banking API request from customer selection to data access.
2. Discuss the principal technical and governance controls required for secure data sharing.
3. Evaluate the potential benefits and risks of embedded finance for consumers and banks.
4. Explain how liability and responsibility should be allocated between a bank and a TPP.
5. Discuss how open-finance developments may affect privacy, competition and financial inclusion.

Analytical / Application Questions

1. A budgeting application requests five years of transaction history, contact details and location data to provide a monthly spending chart. Assess whether the request satisfies purpose limitation and data minimization. Recommend a redesigned permission scope.
2. A bank is considering a marketplace partner that will originate loans using sales data. Apply the five-gate partnership framework and identify at least six conditions for approval.
3. During a payment outage, a merchant’s application retries requests and creates duplicate payments. Explain how idempotency, reconciliation, customer communication and liability arrangements should address the incident.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an API in open banking?

A. A public database containing all customer transactions

B. A governed software interface for requesting permitted data or actions

C. A replacement for customer authentication

D. A legal license to provide banking services

Correct Answer: B. A governed software interface for requesting permitted data or actions

Question 2

What does authorization primarily determine?

A. Whether a person or system is who it claims to be

B. Whether a customer understands a privacy notice

C. What an authenticated user or application is allowed to do

D. Whether an API is available

Correct Answer: C. What an authenticated user or application is allowed to do

Question 3

Which consent practice is most appropriate?

A. Requesting all available data indefinitely

B. Preselecting unrelated marketing permissions

C. Using specific, time-limited and revocable permissions

D. Allowing only telephone revocation after a written request

Correct Answer: C. Using specific, time-limited and revocable permissions

Question 4

What is the principal distinction between BaaS and embedded finance?

A. BaaS concerns regulated capability provision, while embedded finance concerns its integration into a non-financial journey

B. BaaS is only for cash payments, while embedded finance is only for lending

C. BaaS excludes APIs, while embedded finance requires screen scraping

D. They are legally identical concepts in every jurisdiction

Correct Answer: A. BaaS concerns regulated capability provision, while embedded finance concerns its integration into a non-financial journey

Question 5

Which control most directly limits a TPP to approved categories of data?

A. A broader marketing campaign

B. Permission scopes and least-privilege access

C. Removing audit logs

D. Increasing API response speed

Correct Answer: B. Permission scopes and least-privilege access

Question 6

In the conceptual expression V = R − (C + L + K), what does L represent?

A. Customer lifetime

B. Expected loss and remediation cost

C. Liquidity reserve only

D. API latency

Correct Answer: B. Expected loss and remediation cost

Question 7

A risk estimate has PD = 0.02, EAD = $10,000 and LGD = 0.40. Using EL = PD × EAD × LGD, what is expected loss?

A. $8

B. $80

C. $200

D. $800

Correct Answer: B. $80

Question 8

Why is idempotency important in payment APIs?

A. It encrypts data at rest

B. It ensures that safe retries do not unintentionally create duplicate effects

C. It removes the need for reconciliation

D. It grants unlimited payment authority

Correct Answer: B. It ensures that safe retries do not unintentionally create duplicate effects

Question 9

Which issue is especially relevant when a non-bank controls the customer interface for a bank product?

A. Brand confusion about the regulated provider and complaints route

B. Elimination of all operational risk

C. Automatic exemption from consumer-protection rules

D. Guaranteed customer understanding

Correct Answer: A. Brand confusion about the regulated provider and complaints route

Question 10

Which is the strongest reason to test an exit plan for a critical provider?

A. To increase advertising reach

B. To ensure services and data can transition without unacceptable customer harm

C. To avoid documenting responsibilities

D. To make consent permanent

Correct Answer: B. To ensure services and data can transition without unacceptable customer harm