Financial institutions are being asked to share data and capabilities with customers, fintechs, aggregators, partners, and digital platforms at a pace their technology was rarely built for. Many still rely on fragmented interfaces, point-to-point integrations designed for a single partner, and data-sharing practices that vary from one system to the next.
Open finance and BaaS are two connected responses to that pressure. Open finance extends customer-permissioned data access, which open banking established for deposit accounts and payments, across a wider set of financial products such as lending, investments, and insurance. Banking as a Service (BaaS) exposes banking capabilities such as accounts, payments, card issuing, or compliance services through APIs and platforms, so other companies can consume them as infrastructure.
In the United States, Section 1033 of the Consumer Financial Protection Act is the central regulatory reference for consumer financial-data access and portability, and its implementation is still unsettled. That makes the underlying architecture choices more important, since institutions need systems that adapt to whatever final framework applies.
The two models answer different questions. Open finance settles who can access financial data, with whose permission, and how participants interoperate. BaaS comes down to how financial capabilities are packaged and handed to other organizations. Embedded finance and composable banking sit next to both: the first describes how those capabilities reach end customers, the second how institutions assemble them internally. This article looks at each model from a business, architecture, and regulatory point of view, for the leaders who have to plan the platform work behind them.
Why financial infrastructure is becoming more open
For decades, most banks ran vertically integrated technology stacks. Products, data, and channels lived inside one boundary, and anything external was handled through custom projects. That model is giving way to ecosystems where data, products, and capabilities are exposed through standardized interfaces.
Several forces drive the change. Customers expect to connect their accounts to budgeting tools, lenders, payroll providers, and business software without friction. APIs, now the normal way to connect systems, have lowered the cost of exposing a capability to a partner, and specialized fintech providers deliver narrow capabilities faster than a single institution can build them. Data portability rights and supervisory attention to third-party relationships shape how access is designed, financial services increasingly appear inside the apps customers already use, and business lines want to release products in weeks rather than quarters.
Each of these forces pushes toward the same technical requirement: stable, governed interfaces to the institution’s data and services. Institutions that treat this as part of a wider software development strategy for financial services companies, can connect these external demands to the platform decisions they already face, such as core modernization, integration standards, and security.
Banks as part of broader financial ecosystems
A traditional bank builds or buys a product, distributes it through its own channels, and keeps customer data inside its own systems. In an ecosystem model, the same bank is one participant among many, and others consume parts of its capabilities.
That shift reaches several parts of the technology stack. Internal capabilities such as account lookup, payment initiation, or limit management are exposed through APIs. Partner integration follows repeatable patterns, so adding the tenth partner takes much less effort than adding the first. Third-party channels sell or service the institution’s products, customer data moves to authorized parties when the customer requests it, services are modular enough to change one component without rebuilding the whole, and specialized providers handle functions such as identity verification, payments processing, or fraud screening.
The bank remains the regulated provider and system of record throughout. Institutions with reusable APIs, repeatable partner integration, and clear ownership of each capability can add new partners and channels without reworking the core every time.
Open finance in the U.S. financial ecosystem
Open finance is a model of permissioned financial-data access that reaches past traditional checking and savings data. The customer decides which third party can see which data, for what purpose, and for how long. The scope can include lending, investments, payments, insurance, and retirement or wealth data where applicable, along with broader financial-management use cases.
Coverage varies by category. Current U.S. regulation does not address every product type in the same way, and the exact scope of Section 1033 should be kept separate from the broader open finance concept. Some data sharing in the U.S. market runs through private agreements between institutions and aggregators, supported by industry standards, and extends to categories the regulation does not directly cover.
Open finance vs open banking
The difference comes down to scope. Open banking covers access to bank accounts, transaction data, and payment-related services. Open finance applies the same permission model to products held across banks, lenders, insurers, and investment providers. The consent models, API patterns, and security practices built for account data carry over, which is why institutions with mature open banking capabilities have a head start.
The wider scope also changes the design work for U.S. banks. API standards, identity services, consent management, and data governance have to accommodate more financial products, partners, and permission scopes.
Section 1033 and the move toward standardized data access
Section 1033 of the Consumer Financial Protection Act gives consumers a right to access their own financial data. The Consumer Financial Protection Bureau (CFPB) issued a rule in October 2024 to implement that right, covering access for consumers and for third parties authorized by consumers. The framework addresses the shift away from credential-based screen scraping toward more standardized access through APIs, with attention to data security, consent, authentication, governance, and the responsibilities of data providers.
For technology leaders, the Section 1033 open finance conversation matters because it points to a direction: standardized, authenticated, consent-based access with clear accountability on both sides. That direction is useful for planning even while the legal details change.
The legal status deserves particular care. The 2024 rule was challenged in court, and a federal court in Kentucky has enjoined its enforcement while the CFPB reconsiders it. After an advance notice in August 2025 that reopened questions such as who qualifies as an authorized representative and whether data providers may charge fees, the CFPB sent a reconsideration proposal to the Office of Information and Regulatory Affairs on August 6, 2026. Implementation dates, covered entities, fee provisions, and compliance obligations may therefore differ from the original rule. This article gives a technology-strategy view and is not legal guidance, so institutions should confirm the current status with their counsel and with CFPB and Federal Register sources before making commitments.
Architectural implications of consumer-authorized data access
Whatever form the final rules take, consumer-authorized access creates a consistent set of technical requirements:
- Standardized API access to the data categories in scope, with versioned and documented interfaces.
- Consent records that capture who authorized what, when, and for which purpose, with revocation that takes effect quickly and reaches every system holding the permission.
- Authentication of both the customer and the requesting third party, with token-based access in place of shared passwords.
- Data minimization, so each request returns only the data the authorization covers.
- Access logging that can reconstruct who accessed which data and when.
- Rate and usage controls, plus monitoring of availability, latency, error rates, and unusual access patterns, to protect core systems from abusive or runaway traffic.
Banking as a Service in the same ecosystem
Banking as a Service allows banks or licensed infrastructure providers to expose financial capabilities through APIs and platforms, so other organizations can integrate them into their own products or customer experiences. The partner builds the customer relationship and user experience, and the provider supplies the regulated banking capability underneath.
Those capabilities can include account infrastructure, payments and money movement, card issuing, ledger functionality, compliance services, and onboarding components. Providers differ in what they offer: some specialize in card programs, others in account structures or payment rails, so each partnership starts with a map of which capabilities are available and who carries which regulatory responsibility.
That last question matters more than it first appears. The bank that supplies the regulated capability stays responsible for the activities its partner performs on its behalf, including compliance obligations such as anti-money laundering. The partner owns the customer experience and needs to understand the bank’s obligations before designing the product. The federal banking agencies’ June 2023 interagency guidance on third-party risk management addresses fintech arrangements directly, and the governance section below returns to what it asks of banks.
How open finance and BaaS reinforce each other
The two models play different roles, and they meet inside broader ecosystems. A company that uses a BaaS platform to offer accounts may also need customer-authorized data from other institutions to assess affordability, verify balances, or personalize its product. A bank that exposes BaaS services may be the data provider for those same customers. Both depend on APIs, identity, consent, and governance, which is why the two conversations increasingly happen together.
Consider a regional lender that opens deposit accounts for small businesses through a BaaS provider and, with each customer’s permission, reads balances and payment history held at other institutions to size a credit line. The BaaS provider supplies the account infrastructure, and open finance gives access to information held elsewhere. The lender has to coordinate both without losing track of customer permissions, data ownership, or the responsibilities of each provider. That combination opens the way to more connected financial products, and it raises the stakes on reliable integration between participants.
Composable banking
Composable banking is the architectural model that connects these trends. The institution assembles its capabilities from modular services, each with clear responsibilities, an API that other components consume, and its own release cycle. Providers sit behind stable interfaces, which speeds up product assembly and turns the replacement of a single component into a contained project.
Architecture for open financial ecosystems
Open finance and BaaS architectures typically combine several capabilities that work together to expose financial data and services securely. Their arrangement depends on the institution’s technology landscape, integration patterns, and operational requirements.
The main components are API management, which exposes documented interfaces and applies traffic, access, and usage controls; identity and consent services, which authenticate participants and enforce permissions; and integration and orchestration, which coordinate interactions across banking systems, external providers, and business processes. Core banking and BaaS services execute financial operations and maintain the systems of record. Data platforms provide governed access to financial information, with transformation and quality controls. Partner connectivity manages integration with authorized third parties and external services, and monitoring and security support visibility, incident response, and protection across all of it.
These capabilities do not always follow a single execution sequence. A data-access request may follow a different path from a payment instruction or an account-opening workflow. The architecture should preserve clear responsibilities while allowing each process to use the services it requires.
Behind each API sits a control layer that determines whether a request is authorized, how it is processed, and what happens when a dependency fails. A customer-authorized data request, for example, may need consent validation, partner authentication, policy enforcement, data normalization, and access logging before the response goes out. If one of those systems becomes unavailable, the integration has to fail without exposing unauthorized information or leaving an inconsistent result. Centralizing the appropriate controls lets the institution apply consistent policies across partners and products and see the complete request.
Identity and consent as infrastructure
In an open financial ecosystem, customer authorization must remain consistent across channels, products, and third-party connections. A permission granted through one interface may need to be recognized by several systems, while changes or revocations must be reflected wherever that permission is enforced.
When identity and consent are managed independently by each application, institutions face inconsistent access decisions, fragmented records, and greater difficulty demonstrating compliance. Shared identity and consent services give authorization decisions and audit evidence a consistent source of information.
Consent across the customer lifecycle
Consent changes over time, and the architecture has to follow it through each stage:
- Creation: capturing the customer’s choice with its scope and purpose.
- Verification: confirming the customer and the requesting party at the moment of authorization.
- Scope changes: handling requests to add or reduce permissions.
- Expiration: ending permissions automatically where the rules or the customer’s choice call for it.
- Revocation: stopping access promptly and notifying every system affected.
- Access history: keeping a record of what was accessed under each consent.
- Policy enforcement: checking consent state at the time of every request.
Data architecture for open finance
Open finance depends on data management as much as on connectivity. An API can deliver data quickly, and the value of that data still depends on its accuracy, consistency, and provenance.
Each data domain needs a named owner with authority to set definitions and quality standards. A canonical model gives customers, accounts, and transactions a shared representation that partner formats map to, and normalization converts data from different sources into consistent structures and codes. Lineage traces each data point to its source and each transformation applied, synchronization rules set how quickly changes in one system appear in others, and automated checks test completeness, validity, and timeliness. Access control follows the consent model and the institution’s internal policies, metadata makes data discoverable for the teams and partners who use it, and consistent customer identifiers link records for the same customer across systems.
These disciplines reinforce one another: ownership sets definitions, models and normalization apply them, lineage and quality checks verify them, and access control limits exposure.
Fragmented data and ecosystem value
Poorly governed data creates visible operational problems. Duplicated customer records lead to double outreach, mismatched consent, and confusion over who the customer is. Conflicting balances between systems cause failed payments and support calls, stale data leads to wrong decisions in lending, risk, and personalization, and inconsistent transaction categorization makes financial insights unreliable. Missing provenance makes disputes about where a figure came from impossible to resolve, and incompatible partner schemas force custom mapping work for every new integration. These problems grow with every participant added, and they are usually cheaper to fix at the source than downstream.
Where embedded finance fits
Embedded finance is the use of financial capabilities inside another company’s customer experience, and BaaS is the infrastructure layer that makes it possible. Embedded finance creates distribution opportunities for banks and infrastructure providers by bringing financial services into platforms customers already use.
An insurer, for instance, can pay claims into a virtual account or onto a virtual card from inside its own claims app. The policyholder deals with the insurer’s app, and the regulated activity runs on banking systems and external providers behind it.
For the financial institution, this model changes how service reliability and customer support must be managed. An issue involving account balances, payment status, or onboarding can affect the partner’s customer experience even when the bank’s own digital channels work normally.
Infrastructure behind embedded financial experiences
Teams need to settle how transactions are reconciled, how incidents are escalated, which service levels apply, and how customer information is protected across organizational boundaries. Each new distribution channel adds to that workload.
Business opportunities for U.S. financial institutions
The architecture work supports several opportunities: new distribution channels and partner ecosystems that extend the institution’s reach, fee-based API or platform models, faster fintech partnerships through standardized onboarding, richer financial insights drawn from permissioned data, more personalized products, infrastructure services for non-bank platforms, and customer portability, which can be a service feature as well as an obligation.
None of these generates revenue automatically. Each depends on a clear value proposition, a willing partner market, and operating costs that the pricing model can cover. Fee-based access in particular should wait for the outcome of the Section 1033 reconsideration, which reopened whether data providers may charge for access. Institutions get the best results when they select opportunities against their strengths and test them with a limited set of partners before scaling.
Mid-market banks and selective platform strategies
For mid-market banks, the strategic question is which capabilities to offer and which to source. Several approaches fit this position: competing through specialization in a vertical, a segment, or a particular product; exposing selected capabilities through partners instead of building a full platform; using specialized third-party infrastructure for functions that are expensive to build and maintain; accelerating selected product launches with existing components; and taking part in embedded-finance ecosystems as a regulated provider.
Vendor, compliance, security, and operational controls scale with the number of partners, so a mid-market institution is usually better served by a few well-governed relationships than by many lightly managed ones.
Risks and partner governance
Open ecosystems bring risks that closed stacks avoided by default. Third-party risk and dependency on external providers for critical functions grow with every partner, and vendor concentration appears when too many functions rest on one provider. API abuse, including scraping and credential stuffing, and data leakage through over-broad scopes or poorly secured partners add exposure at the interface. Consent failures such as access continuing after revocation, fraud that moves quickly across connected systems, outages that spread from one participant to others, and unclear responsibility when something goes wrong complete the picture. Regulatory exposure stays with the institution even when a partner performs the function.
The June 2023 interagency guidance is explicit that using a third party does not remove a bank’s own responsibilities, and it organizes oversight into five stages: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination. The two sections below follow that lifecycle.
Third-party access and accountability
Governance covers the full life of the relationship. Onboarding starts with due diligence on the partner’s security, financial condition, and compliance posture, followed by access scopes limited to the data and functions the partner needs. SLAs carry measurable commitments that are reviewed regularly, incident responsibilities state who detects, communicates, and resolves each type of event, and security reviews repeat on a recurring schedule. Data-use policies limit what partners can do with the data they receive. At the end of the relationship, offboarding confirms data deletion and closed connections, and access revocation has to work quickly for a single partner or a single customer.
Enforcing these controls through configuration and monitoring as well as contracts makes them hold up under pressure. A consistent governance model also shortens onboarding, since each new partner follows a known path.
Designing for vendor flexibility
Architecture can reduce dependence on any one provider. An abstraction layer puts the institution’s own interface between its applications and each provider. Standardized contracts define the request and response formats expected from any provider of a given function, and provider adapters translate between that contract and each provider’s specific API. Data stays in formats and locations the institution controls, ownership boundaries define which system holds each piece of business logic, and a composable architecture turns the replacement of one component into a bounded project.
Using APIs everywhere does not guarantee portability. Proprietary schemas, business logic spread across several systems, and point-to-point integrations each create dependency.
Implementation roadmap for financial institutions
Modernization for open ecosystems works best as a series of increments that each deliver value, without a full-stack replacement. A practical sequence looks like this:
- Map current data and API capabilities. Document what exists, who uses it, and how well it performs.
- Identify systems of record. Establish which system is authoritative for each data domain.
- Define Section 1033-related responsibilities. Work with legal and compliance to translate the current regulatory position into technical requirements, and revisit it as the rules develop.
- Assess consent and identity architecture. Find where that logic is duplicated or missing.
- Prioritize use cases and define API standards. Choose the first use cases by demand and feasibility, and set conventions for naming, versioning, security, and documentation.
- Introduce partner governance. Put onboarding, SLAs, and offboarding processes in place before partner volume grows.
- Modernize integration incrementally. Replace the most painful point-to-point connections first, and make end-to-end tracing, alerting, and reporting available across APIs and partners.
- Expand into BaaS or embedded-finance use cases where the strategic case is clear.
The steps overlap in practice, and each one produces something usable on its own, so the institution gains value before the sequence is complete. Regular reviews, especially of the regulatory responsibilities in step 3, keep the roadmap aligned with the rules and with the institution’s strategy.
Sequencing should weigh regulatory necessity first, then customer impact, integration pain (manual work, errors, or delays that are costly), data readiness, API maturity, and strategic value, including capabilities whose payoff comes later. Replacing the core may be justified at some institutions, and it should follow from this analysis.
Measuring progress
Useful metrics tie technical performance to business outcomes: API availability and latency, partner onboarding time, consent success rate, data-access error rates, support incidents linked to integrations or data issues, time to launch a new integration, the share of reusable APIs, customer adoption of connected services, reconciliation exceptions, and partner SLA performance. Raw API call volume says little without context. The set should show whether the platform is reliable, whether new partners and products reach production faster, and whether operating costs and risk are under control.
