Open Banking, API Finance and Embedded Finance

Introduction and Context

Financial services are increasingly delivered through digital ecosystems rather than through a single institution’s branch, website or mobile application. A consumer may view several bank accounts in one application, authorize a retailer to initiate a payment from a bank account, obtain insurance during an online purchase, or receive working-capital finance through an accounting platform. These developments are connected by open banking, application programming interfaces (APIs), Banking-as-a-Service (BaaS) and embedded finance.

Open banking is a framework in which customers, subject to legal safeguards and explicit consent, permit regulated third parties to access specified financial data or initiate payments through secure interfaces. It changes the traditional model in which a bank controls the customer relationship, data and distribution channel. The customer becomes the principal decision-maker regarding authorized data use, while banks and third-party providers compete and cooperate within a regulated ecosystem.

The subject is contemporary but not uniform across countries. The European Union’s revised Payment Services Directive and related open-banking requirements, the United Kingdom’s open-banking framework, Australia’s Consumer Data Right and India’s Account Aggregator framework illustrate different institutional designs. The common principles are customer control, secure authentication, standardized access, liability allocation and competition.

Learning Objectives

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

1. Explain consent-based financial-data sharing and distinguish account-information services from payment-initiation services.
2. Describe API standards, authentication, authorization and account aggregation.
3. Analyse BaaS and embedded-finance business models.
4. Evaluate ecosystem strategy, monetization, third-party risk and governance.
5. Assess the development of open finance beyond payment accounts.
6. Apply these concepts to a practical financial-services case.

1. The Open-Banking Model

1.1 Participants and relationships

The principal participants are:

• Data holder or account-servicing institution: commonly a bank that maintains the account and records transactions.
• Customer or data subject: the individual or business that owns the relationship and gives, refuses or withdraws consent.
• Third-party provider (TPP): an authorized organization that receives financial data or initiates payments.
• Account-information service provider (AISP): a TPP that consolidates information from one or more accounts.
• Payment-initiation service provider (PISP): a TPP that initiates a payment at the customer’s request through the customer’s bank.
• Aggregator or platform: an application that presents information or services from multiple providers.
• Regulator and scheme operator: bodies that define authorization, technical, conduct and liability requirements.

Open banking is therefore not simply “making bank data public.” It is controlled access to specified data for a defined purpose and duration. Confidentiality, security and customer choice remain essential.

1.2 Consent as a control mechanism

Valid consent should be informed, specific, freely given, unambiguous and capable of being withdrawn. A well-designed consent journey explains:

• who is requesting access;
• which accounts and data categories are involved;
• the purpose of processing;
• how long access will last;
• whether data will be shared onward;
• how the customer can revoke access; and
• how complaints and liability are handled.

Consent is not equivalent to a general acceptance of terms and conditions. It should be granular. A customer might authorize transaction history but not identity documents, or permit one payment without granting continuing access to account data. The principle of data minimization requires providers to request only information necessary for the stated service.

Consent also has a lifecycle. It is created, authenticated, monitored, renewed where required, amended or revoked. A provider that continues to collect data after revocation may breach privacy, contractual or regulatory obligations. Good systems maintain an auditable consent record containing the customer, scope, timestamp, authentication method, expiry and revocation status.

1.3 Data and payment services

Account-information services support budgeting, financial-health tools, credit assessment and cash-flow forecasting. Payment-initiation services can reduce card dependence and permit a merchant or fintech to initiate a bank transfer with customer authorization. The two services have different risks. Aggregation primarily creates confidentiality, accuracy and profiling risks; payment initiation additionally creates fraud, authorization, execution and reimbursement risks.

A key distinction is between access and ownership. Open banking normally gives an authorized provider a right to access or process data for a specified purpose; it does not transfer legal ownership of the account or grant unrestricted rights to commercialize the data.

2. APIs and Technical Architecture

An API is a defined interface through which one software system requests data or an action from another. In open banking, APIs replace insecure practices such as asking customers to disclose online-banking passwords to an aggregator. The bank authenticates the customer directly, while the TPP receives an authorization token or a controlled response.

A simplified sequence is:

1. The customer selects a service and chooses a bank.
2. The TPP redirects or sends the customer to the bank’s authorization environment.
3. The bank authenticates the customer, often using multi-factor authentication.
4. The customer reviews and approves the requested scope.
5. The bank issues an authorization code or token to the TPP through a secure flow.
6. The TPP requests permitted data or submits an authorized payment.
7. The bank returns a response, status or error.
8. Logs, alerts and consent records support monitoring and dispute resolution.

Figure: A simplified consent-based open-banking interaction.

2.1 API styles and standards

Most financial APIs use HTTPS and structured formats such as JSON. Common design concepts include:

• Resource endpoints: URLs representing accounts, balances, transactions or payments.
• HTTP methods: GET for retrieval, POST for creation or initiation, and PATCH or PUT for permitted updates.
• Status codes: responses indicating success, invalid requests, authentication failure or temporary unavailability.
• OAuth 2.0: a framework for delegated authorization in which a client receives an access token rather than a user password.
• OpenID Connect: an identity layer commonly used with OAuth 2.0.
• Mutual TLS and signed messages: controls that authenticate systems and protect message integrity.
• Strong customer authentication: authentication using at least two independent elements, commonly knowledge, possession and inherence.

Standards reduce integration cost, but a standard does not guarantee safety. Poor authorization, excessive permissions, weak token storage, insecure software dependencies and inadequate monitoring can undermine a technically standardized API. APIs should apply least privilege, short-lived tokens where feasible, rate limits, encryption in transit and at rest, schema validation, replay protection and comprehensive logging.

2.2 Reliability and service quality

A bank API is a critical dependency. Providers should monitor latency, availability, error rates, data freshness and reconciliation differences. A useful operational measure is availability:

Both times must use the same unit, such as minutes, and the measurement window and exclusions must be defined. Availability alone is insufficient: an API can be available but return stale balances or incorrect transaction classifications.

3. Account Aggregation and Financial Data Use

Account aggregation combines information from multiple accounts or institutions into a single customer view. Its applications include personal financial management, affordability assessment, small-business cash-flow analysis, financial advice and fraud detection.

The basic analytical pipeline is:

1. obtain consent and connect accounts;
2. collect and normalize institution-specific data;
3. classify transactions;
4. identify income, recurring commitments and unusual activity;
5. present insights or make a permitted decision; and
6. delete, refresh or retain data according to consent and law.

Normalization is difficult because institutions use different descriptions, posting dates, pending-status conventions, currencies and category codes. A robust system distinguishes transaction date from value date, pending from settled transactions, and merchant name from transaction narrative. It should expose uncertainty rather than present an algorithmic classification as fact.

Aggregation can improve competition and financial inclusion, but it can also intensify surveillance and automated exclusion. A lender using cash-flow data should explain material factors, test model performance across relevant groups and provide a route for correction and human review where appropriate.

4. Payment Initiation

A PISP may enable a customer to pay a merchant directly from a bank account. The customer is authenticated by the bank and confirms the payment details. The PISP should not alter the amount, beneficiary or purpose without authorization.

Important controls include beneficiary verification, transaction signing, duplicate detection, velocity limits, fraud analytics and clear confirmation. Payment status must be reconciled because an API response may indicate that a payment was accepted for processing rather than finally settled. Customer communications should distinguish pending, completed, rejected and reversed payments.

Open-banking payments may be cheaper than card payments in some contexts, but cost depends on bank charges, scheme fees, fraud losses, refunds, reconciliation and customer-support costs. Merchants also compare conversion rates and consumer protections, not just the headline transaction fee.

5. Banking-as-a-Service and Embedded Finance

5.1 Banking-as-a-Service

BaaS occurs when a regulated financial institution provides capabilities—such as accounts, payments, cards, safeguarding, lending infrastructure or compliance support—to another business through APIs, operational services or a technology platform. The customer-facing brand may be a fintech or non-financial company, but regulated responsibilities do not automatically disappear.

A BaaS arrangement should allocate responsibility for customer identification, transaction monitoring, complaints, safeguarding, fraud, disclosures, data protection, operational resilience and regulatory reporting. The regulated bank must maintain effective oversight; outsourcing a process does not normally outsource accountability.

5.2 Embedded finance

Embedded finance integrates a financial product into a non-financial customer journey. Examples include:

• payments within a mobility or marketplace application;
• point-of-sale instalment finance;
• insurance offered during travel or purchase checkout;
• business accounts inside an accounting platform; and
• invoice finance offered when a cash-flow problem is detected.

The value proposition is contextual relevance and reduced friction. The danger is that convenience may obscure price, risk, conflicts of interest or the identity of the regulated provider. Product governance must remain visible even when the interface is simple.

5.3 Business-model logic

A platform may earn revenue from subscription fees, payment margins, interchange where applicable, referral commissions, lending interest, insurance commissions, account fees or enterprise API charges. Revenue should be evaluated against total cost and risk, not viewed in isolation.

A simple contribution model is:

Revenue and each cost must be measured over the same period and customer unit. Expected loss is not necessarily equal to realized loss; it is an estimate based on probability of default or fraud, exposure and loss severity. The formula is a management accounting approximation, not a complete profitability or regulatory-capital calculation. Fixed costs, capital costs and customer-acquisition costs must be added for a fuller business case.

6. Ecosystem Strategy and Monetization

Open-finance strategy can be analysed through four questions:

1. Where is value created? For example, better data, faster payments, lower acquisition cost or improved underwriting.
2. Who controls the customer relationship? The bank, fintech, merchant, platform or a shared arrangement?
3. Who bears risk? Liability should be explicit for fraud, outages, privacy breaches, unsuitable products and regulatory failures.
4. What is defensible? Possible advantages include trust, distribution, data quality, compliance capability, liquidity, developer tools and network effects.

Banks may pursue an infrastructure strategy, a partnership strategy, a direct-to-customer strategy or a combination. Fintechs may specialize in user experience, analytics or distribution while relying on regulated infrastructure. Non-financial platforms can embed finance but must avoid treating regulation as a technical feature that can simply be purchased.

Network effects may occur when more participants make an ecosystem more useful, but they are not automatic. Fragmented standards, poor data quality, low consumer trust and high switching costs can prevent scale. Strategic metrics include active consented users, successful API calls, payment conversion, data freshness, fraud loss, complaint rates, partner concentration, contribution margin and retention.

7. Third-Party Risk, Governance and Ethics

Open ecosystems expand the attack surface and create dependency chains. A bank may rely on a cloud provider, API gateway, identity service, data aggregator and fintech partner. Risk management should therefore examine the whole service chain.

7.1 Major risk categories

• Cyber risk: credential theft, token compromise, API abuse, denial of service and insecure code.
• Privacy risk: excessive collection, unauthorized onward sharing, re-identification and indefinite retention.
• Conduct risk: dark-pattern consent, misleading pricing, unsuitable products and unclear responsibility.
• Model risk: inaccurate categorization, biased affordability assessments and opaque automated decisions.
• Operational risk: outages, poor incident response, weak business continuity and data reconciliation failures.
• Concentration risk: dependence on one cloud, aggregator, bank or distribution platform.
• Legal and regulatory risk: licensing failures, cross-border data restrictions, outsourcing breaches and inadequate records.

7.2 A practical control framework

Before onboarding a TPP or BaaS partner, an institution should assess ownership, authorization status, financial condition, security certifications, penetration testing, data flows, subcontractors, incident history, business continuity and exit arrangements. Contracts should define service levels, audit rights, breach notification, data deletion, intellectual-property rights, liability, customer communications and termination assistance.

Continuous monitoring is more effective than one-time due diligence. Institutions should test consent records, sample API calls, review anomalies, conduct access recertification, perform incident exercises and reconcile financial transactions. Boards and senior management need reporting that connects technical indicators to customer and prudential outcomes.

Ethically, customer benefit should not be assumed from increased data use. A provider should ask whether the use is necessary, proportionate, explainable and reasonably expected by the customer. Sensitive financial information can reveal health, religion, political activity or household relationships. Privacy-preserving analytics, aggregation, controlled retention and strict internal access are therefore central design requirements.

8. Open Finance and Contemporary Developments

Open finance extends open-banking principles to additional products such as savings, investments, pensions, mortgages, insurance and business finance. It may improve portability and enable more comprehensive advice, but the sensitivity and complexity of the data increase. Investment holdings, insurance claims and pension information can have greater long-term consequences than a payment history.

Important developments include permission dashboards, machine-readable consent receipts, standardized financial-data schemas, real-time payment rails, digital identity, fraud intelligence and programmable compliance. Artificial intelligence can assist transaction classification, fraud detection, customer support and cash-flow forecasting. However, AI does not remove the need for lawful data access, bias testing, explainability, human oversight, model validation and contestability. A model trained on consented data may still generate unfair or inaccurate outcomes.

Regulators increasingly focus on operational resilience, third-party technology concentration, consumer protection and liability across ecosystems. The practical direction of travel is not simply “more openness,” but safer, more interoperable and more accountable data mobility.

9. Illustrative Case: RiverPay Business Finance

Background

RiverPay is a fictional digital platform used by small retailers for invoicing and sales reconciliation. It proposes an embedded working-capital product using consented bank-account and sales data. A partner bank will originate and fund loans; RiverPay will provide the interface and cash-flow analysis.

Problem

Retailers complain that traditional loan applications require lengthy forms and historical statements. RiverPay believes that real-time cash-flow data can reduce processing time. However, the proposal creates risks involving consent, data accuracy, automated credit decisions, fraud and responsibility between RiverPay and the bank.

Analysis

RiverPay maps the data journey and finds that it needs transaction history, account balances and sales receipts, but not unrelated investment or health information. It designs separate consent for data access and for a credit application. Customers can withdraw future access, although data already used for a completed credit decision must be retained where legally required. The partner bank remains responsible for lending compliance and final credit approval.

The parties establish controls for duplicate transactions, pending items, seasonal revenue and multiple business accounts. The model is tested by business size, geography and sector. Applicants receive an understandable explanation of key factors and a process for correcting inaccurate transactions. A manual review is available for borderline cases.

Approach and outcome

The launch begins as a controlled pilot. RiverPay measures application completion, decision time, repayment performance, complaints, data-access failures and disparities in approval outcomes. The bank limits exposure, audits RiverPay’s subcontractors and requires an incident-notification process. The product is paused if data quality or fraud indicators exceed agreed thresholds.

The pilot reduces documentation time and improves visibility of seasonal cash flow, but it also shows that some banks provide incomplete merchant descriptions. RiverPay therefore displays confidence indicators and avoids presenting estimated categories as verified facts.

Learning points

The case demonstrates that embedded finance is an organizational and governance problem as well as an API problem. Clear consent, data minimization, model accountability, partner oversight and customer recourse are necessary for a sustainable proposition. Faster decisions are valuable only when they remain accurate, fair and legally defensible.

Best-Practice Checklist

A responsible open-finance initiative should:

• define a specific customer benefit and lawful purpose;
• request minimum necessary data;
• use explicit, granular and revocable consent;
• authenticate customers through trusted channels;
• apply least-privilege access and secure token management;
• validate, reconcile and label data quality;
• assign responsibility clearly across partners;
• test fraud, bias, resilience and failure scenarios;
• communicate prices, risks and regulated-provider identity;
• maintain complaint, correction and redress mechanisms; and
• monitor outcomes continuously, with an orderly exit plan.

Chapter Summary

Open banking enables controlled, consent-based access to financial data and payment capabilities. Account-information services aggregate data, while payment-initiation services enable authorized bank payments. APIs provide the technical connection, but security depends on authentication, authorization, least privilege, monitoring and operational resilience. BaaS supplies regulated infrastructure to other businesses, and embedded finance places financial products inside non-financial journeys. These models create value through convenience, distribution, data and lower friction, but also introduce third-party, privacy, cyber, conduct, model and concentration risks. Effective ecosystem strategy therefore combines commercial design with clear accountability and customer protection. Open finance extends these principles beyond payment accounts, making data quality, consent governance and ethical AI increasingly important.

Key Terms

Open banking: Consent-based access to financial data and payment services through regulated channels.

Open finance: Extension of open-banking principles to products such as insurance, investments and pensions.

API: A software interface that enables systems to exchange data or request actions.

TPP: An authorized third-party provider accessing data or initiating payments.

AISP: A provider that consolidates information from one or more accounts.

PISP: A provider that initiates a payment at a customer’s request.

Consent: Informed, specific and revocable authorization for defined processing.

OAuth 2.0: A delegated-authorization framework using access tokens.

Strong customer authentication: Authentication using independent factors such as knowledge, possession and inherence.

Account aggregation: Combining information from multiple financial accounts.

Payment initiation: Requesting a bank payment through an authorized interface.

BaaS: Provision of regulated banking capabilities to other businesses through services and APIs.

Embedded finance: Integration of financial products into non-financial customer journeys.

Data minimization: Collecting only data necessary for a stated purpose.

Operational resilience: The ability to continue and recover critical services during disruption.

Third-party risk: Risk arising from reliance on external providers or partners.

Token: A controlled digital credential representing an authorization.

Open-finance ecosystem: Interconnected providers sharing data or capabilities under governed rules.

Review Questions

Short Answer Questions

1. What is the difference between an AISP and a PISP?
2. Why is customer consent more than acceptance of general terms and conditions?
3. Identify three controls used to secure financial APIs.
4. Define Banking-as-a-Service.
5. What is meant by data minimization?

Long Answer Questions

1. Explain the participants, sequence and governance requirements in a consent-based open-banking transaction.
2. Compare account aggregation with payment initiation in terms of benefits and risks.
3. Analyse how BaaS and embedded finance change the traditional banking value chain.
4. Discuss the major categories of third-party risk in an open-finance ecosystem.
5. Explain why open finance creates both opportunities and additional consumer-protection challenges.

Analytical / Application Questions

1. Design a consent and control framework for a budgeting application that connects five banks.
2. A retailer wants to replace card payments with account-to-account payments. What commercial, operational and consumer-protection factors should it assess?
3. Using the RiverPay case, identify which responsibilities should remain with the regulated bank and which may be delegated to the platform.

Multiple Choice Questions with Answers

Question 1

Which service primarily consolidates information from multiple customer accounts?

A. Account-information service

B. Payment-initiation service

C. Card-network service

D. Core deposit service

Correct Answer: A. Account-information service

Question 2

What is the main purpose of an OAuth access token in an open-banking flow?

A. To replace all customer authentication permanently

B. To provide controlled delegated access without disclosing the customer’s password

C. To guarantee that a payment has settled

D. To transfer ownership of a bank account

Correct Answer: B. To provide controlled delegated access without disclosing the customer’s password

Question 3

Which principle requires a provider to request only data necessary for its stated purpose?

A. Data minimization

B. Open access

C. Platform neutrality

D. Interchange pricing

Correct Answer: A. Data minimization

Question 4

Which activity is most characteristic of a payment-initiation service provider?

A. Classifying historical transactions

B. Initiating a customer-authorized bank payment

C. Issuing a pension statement

D. Operating a cloud data centre

Correct Answer: B. Initiating a customer-authorized bank payment

Question 5

In Banking-as-a-Service, which statement is most accurate?

A. Outsourcing a process automatically removes the bank’s accountability

B. A non-financial company becomes a bank merely by using an API

C. A regulated institution provides financial capabilities to another business, often through APIs

D. BaaS excludes compliance and customer-protection responsibilities

Correct Answer: C. A regulated institution provides financial capabilities to another business, often through APIs

Question 6

A system has scheduled service time of 1,000 minutes and unavailable time of 20 minutes. What is its availability?

A. 2%

B. 20%

C. 98%

D. 99.8%

Correct Answer: C. 98%

Question 7

Which is a major risk of using aggregated transaction data for automated lending?

A. The data can never contain errors

B. Incorrect or biased data may produce unfair credit decisions

C. Aggregation eliminates the need for consent

D. The lender cannot use any risk controls

Correct Answer: B. Incorrect or biased data may produce unfair credit decisions

Question 8

What should a customer normally be able to do with an open-banking consent?

A. Withdraw or revoke it through an appropriate mechanism

B. Convert it into ownership of the bank

C. Use it to bypass authentication for all future services

D. Transfer it automatically to every third party

Correct Answer: A. Withdraw or revoke it through an appropriate mechanism

Question 9

Which example best illustrates embedded finance?

A. A bank closing a branch

B. Insurance offered within a travel-booking journey

C. A regulator publishing a consultation

D. A company replacing its accounting software

Correct Answer: B. Insurance offered within a travel-booking journey

Question 10

Why is open finance more complex than payment-account open banking?

A. It involves no customer data

B. It applies only to cash withdrawals

C. It may involve sensitive products such as pensions, investments and insurance

D. It removes the need for interoperability

Correct Answer: C. It may involve sensitive products such as pensions, investments and insurance