Open Banking

Open banking lets customers authorize regulated or approved providers to access account data or initiate payments through standardized interfaces.

Open banking is a framework that lets a customer authorize an approved third-party provider to access specified bank-account data or, where permitted, initiate a payment through an application programming interface (API). The customer does not transfer ownership of the account to the third party, and the bank or payment institution remains responsible for holding the account and executing services within the applicable rules.

Open banking is not one universal product. Its legal scope, eligible accounts, provider-approval process, consent rules, liability standards, and technical specifications differ by jurisdiction.

Key Takeaways

  • Open banking access should be based on a defined purpose, customer authorization, and an identified provider.
  • Reading account data and initiating a payment are separate permissions; allowing one does not automatically allow the other.
  • An aggregator can combine information from multiple institutions, but it does not necessarily hold customer funds or operate the settlement rail.
  • An API can transmit data or instructions, while the underlying bank and payment system still perform authorization, clearing, and settlement.
  • Readers should verify the provider, requested permissions, access period, revocation method, data-retention policy, and dispute process before connecting an account.

What Open Banking Can Do

CapabilityWhat the customer permitsTypical useWhat it does not necessarily mean
Account-information accessRead specified balances, transactions, or account detailsMulti-bank dashboards, cash-flow analysis, affordability checksThe provider can move money
Payment initiationSend a payment instruction from a selected accountAccount-to-account checkout or bill paymentThe provider holds or settles the funds
Account aggregationCombine data from several connected institutionsA consolidated financial viewEvery balance is current to the same timestamp
Product or service connectionUse authorized data in another financial workflowAccounting, lending, or treasury toolsApproval, pricing, or suitability is guaranteed

These capabilities may appear in one application, but they should remain distinct in the permission screen and in a reader’s analysis.

How an Open Banking Connection Works

  1. Provider selection: The customer chooses a service and identifies the bank account to connect.
  2. Authentication: The customer is redirected to, or otherwise authenticates with, the bank or authorized account provider. A legitimate third party should not need the customer to disclose credentials outside the approved flow.
  3. Consent: The customer reviews the requested data, action, purpose, and access duration.
  4. API request: The third party sends a structured request using an approved interface and access token.
  5. Bank response: The bank validates the request and returns permitted data or accepts a payment instruction.
  6. Ongoing control: The customer may be able to review, renew, or revoke access, subject to local rules and the provider’s process.

Technical access does not eliminate ordinary payment checks. A payment may still be rejected, delayed, returned, or reversed because of insufficient funds, fraud controls, sanctions screening, an invalid beneficiary, or rules of the underlying payment system.

Worked Example: Data Access Versus Payment Initiation

Suppose a small business connects checking accounts at Bank A and Bank B to a cash-management application.

EventPermission involvedFinancial effect
The application retrieves balances and recent transactionsAccount-information accessNo money moves
The dashboard shows Bank A at $18,000 and Bank B at $7,000Aggregation and presentationDisplayed data may have different retrieval times
The owner asks the application to initiate a $3,000 supplier payment from Bank APayment-initiation permissionA payment instruction is sent
Bank A authenticates the instruction and processes it through an applicable payment railBank and payment-system executionFunds move only if the instruction is accepted and settled
The dashboard later refreshes Bank A to $15,000, ignoring fees and other activityNew account-information requestThe display reflects the updated bank record

The example shows why “connected account,” “payment initiated,” and “payment settled” are not interchangeable statuses. The application may organize data and transmit instructions without becoming the deposit-taking bank or the settlement system.

Why Open Banking Matters

For consumers, open banking can reduce repeated data entry and make it easier to compare or manage accounts in one interface. For businesses, it can support bank reconciliation, cash forecasting, accounting integrations, and account-to-account collections. For lenders and analysts, permissioned transaction data may supplement other evidence when evaluating cash flow.

Those uses do not make the data complete or decision-ready by themselves. Coverage may exclude certain institutions, account types, pending transactions, older history, or manually recorded activity. Any consequential decision should document the data source, retrieval time, covered accounts, and known gaps.

Risks and Limitations

  • Excessive permission: A provider may request broader data, a longer duration, or more accounts than the service requires.
  • Provider and impersonation risk: A fraudulent site can imitate a consent flow or falsely claim authorization.
  • Data breach risk: Every connected provider and processor expands the systems through which financial data may pass.
  • Stale or incomplete data: Aggregated balances may update at different times, and a connection failure can create gaps.
  • Payment fraud: Payment initiation can speed up a valid instruction and a fraudulent one; independent beneficiary verification still matters.
  • Operational dependence: API outages, token expiration, institution changes, and provider failure can interrupt a connected service.
  • Unclear responsibility: Complaint, error-resolution, and liability rules can differ across the bank, third party, payment rail, and jurisdiction.

Disconnecting an account may stop future access, but it may not automatically delete data already lawfully collected. Review the provider’s retention and deletion terms separately.

How to Evaluate an Open Banking Service

Before relying on a connection, verify:

  1. Provider identity and status: Confirm the legal entity and any required authorization in the relevant jurisdiction.
  2. Permission scope: Separate read access, payment initiation, recurring access, and access to additional accounts.
  3. Purpose and duration: Determine why each data field is needed and when access expires.
  4. Authentication path: Confirm that the bank controls the credential-entry or approved authentication step.
  5. Revocation and deletion: Identify how to stop access and how previously collected data is handled.
  6. Payment evidence: For initiated payments, retain the instruction reference and distinguish submission, acceptance, settlement, and recipient credit.
  7. Fallback process: Know how the service behaves if an API, institution, or data connection is unavailable.

Common Misconceptions

“Open banking means a third party can see everything.” Access should be limited by the customer’s authorization, available API scope, and local rules.

“An account aggregator is a payment network.” An aggregator may collect and display information. Payment initiation and settlement are separate functions.

“API access guarantees real-time data.” An API can provide timely data, but refresh schedules, pending entries, outages, and institution-specific behavior can still affect the result.

“Revoking access reverses a completed payment.” Revocation generally concerns future access. A payment already executed follows the rules of the payment service and rail.

Regulatory Context

Open banking models range from regulatory mandates to market-led standards. The European Union’s payment-services framework, the United Kingdom’s implementation, and U.S. consumer financial data initiatives do not use identical terminology or impose identical duties. Because these frameworks continue to develop, use the current regulator or official program page for the jurisdiction rather than assuming that a rule from another market applies.

Official Resources

  • API: A structured interface used to exchange authorized data and instructions.
  • Aggregator: A service that combines information from multiple sources.
  • Fintech: The broader use of technology to deliver or support financial services.
  • PSD2: European payment-services legislation associated with regulated data access and payment initiation.

FAQs

Does open banking let an application take money from an account?

Not from data access alone. Moving money requires a separate payment instruction and the authentication, authorization, and execution steps required by the bank, provider, payment rail, and applicable rules.

Is open banking the same as screen scraping?

No. Open banking commonly uses structured APIs and approved authentication flows. Screen scraping generally relies on a service reading information from an online-banking interface, often using a different technical and risk model.

Is an open banking provider automatically safe?

No system is risk-free. Confirm the provider’s identity and status, limit permissions to the intended purpose, use the bank’s approved authentication flow, and review how access can be revoked. This page is educational and is not individualized financial, legal, or data-protection advice.
Browse Financial Technology