Traditional banking systems can make it difficult to introduce new capabilities without changes to existing infrastructure. Composable banking offers an alternative approach, but the flexibility it promises depends on how individual components are designed and integrated.
This article examines how composable banking works, the hidden costs and challenges involved, and the evaluation of vendors’ claims.
Key takeaways:
- Composable banking organizes banking technology into independent capabilities, such as payments and lending, connected through APIs.
- Existing core systems can remain in place while surrounding banking capabilities are modernized.
- Integration requires clear ownership of orchestration, data consistency and reconciliation across systems.
- Multiple providers increase management complexity, while EU institutions subject to DORA must also address ICT third-party risks.
- Vendor claims require verification through component replaceability, data portability and clear exit arrangements.
What is composable banking?
Composable banking is a way of building a bank’s technology from separate capabilities, such as onboarding, payments, lending and the ledger. Each component has one job and connects to the others only through documented interfaces, usually APIs, so a bank can replace its onboarding provider without rebuilding payments or the ledger. The trade-off is that the bank becomes responsible for how the parts work together.
A typical composable banking stack includes:
| Component | Typical responsibilities | Key implementation challenges |
|---|---|---|
| Identity and KYC | Customer onboarding, identity verification, fraud screening and sanctions checks | Maintaining a consistent customer record and audit trail across verification services |
| Payments and money movement | Payment processing, settlement and reconciliation | Reconciling payment status with ledger postings when cross-service processes partially fail |
| Lending and origination | Credit assessment, loan decisioning, origination workflows and loan servicing | Synchronizing lending data with the ledger and maintaining a consolidated view of customer exposure |
| Accounts and ledger (system of record) | Account balances, transaction postings, statements and account servicing | Preserving authoritative balances and postings while managing dependencies across connected capabilities |
| Data and analytics | Data aggregation, customer insights, reporting and analytics | Maintaining consistent data definitions, completeness and timely updates across data sources |
| Customer channels | Mobile and online banking interfaces and relationship-manager tools | Maintaining consistent customer information and journeys across channels and underlying services |
These components are logical building blocks that can be delivered through different products or services. A bank may combine internally developed services, third-party providers and an existing core ledger. The ledger can remain the authoritative system for balances and postings while surrounding capabilities are modernized.
Composability can also extend beyond core banking products to shared reference data, customer engagement, daily operations, accounting and regulatory reporting. The exact scope is determined by the institution’s architecture, operating model, and business priorities.
How composable banking architecture works
A composable banking architecture has four layers. Channels, such as the mobile app, web and staff tools, call an integration layer, which routes requests to the capability components behind it. A data layer collects what those components produce.
These mechanisms make the layers work together:
- APIs: The contracts between layers. Each capability exposes what it does, such as “open an account”, and hides how it does it.
- Orchestration: Coordinates journeys that cross capabilities. Opening an account may involve identity checks, account creation and card issue, so one service or team must own the sequence, retries and failure handling.
- Events: Announce that something has happened, such as “payment settled”, to any component that subscribes. New capabilities can react without changing the sender. Events can arrive late, twice or out of order, so consumers must be built to cope.
- Data ownership: Each component owns its data and shares it through APIs or events, not through a shared database. A customer view is assembled from those feeds.
Composable banking vs. traditional banking architecture
Composable architecture doesn’t remove complexity; it moves it from inside one platform to the connections between capabilities.
Where do functions live?
Traditional: Banking functions operate within a single, tightly integrated application or platform
Composable: They are split into separate capabilities, each with its own responsibilities and interfaces.
What happens when one part changes?
Traditional: Changes may rely on shared code and coordinated releases.
Composable: An individual service may change separately if its contracts remain stable.
Who coordinates customer journeys?
Traditional: Coordination often happens within the central platform.
Composable: Cross-capability workflows require orchestration and clearly assigned end-to-end ownership.
How do integrations work?
Traditional: Internal dependencies may be proprietary or hard to separate.
Composable: APIs and events expose explicit contracts that require governance.
Where does failure handling sit?
Traditional: The platform may manage some transactions centrally.
Composable: Teams must design retries, idempotency and reconciliation across boundaries.
Can you modernize without replacing the core?
Traditional: Usually difficult; a core migration is a major programme.
Composable: Often yes; the core can remain the system of record.
What composable banking is not
Several related banking concepts are frequently used interchangeably, despite important differences in their architecture and purpose. Understanding the differences is important when evaluating banking technology solutions.
| Often confused with | How it differs | Why the confusion causes wrong decisions |
|---|---|---|
| Modular banking | Modules often operate within one vendor’s platform. Composable components can be combined across providers and managed independently. | You may buy a modular suite believing it offers the freedom to swap parts. |
| Microservices | An engineering technique. Composable banking is a business architecture where boundaries follow banking capabilities, and microservices can be one way to build it. | A system split into services along old code lines can still be rigid. |
| Open banking | Standardized, often regulated access to data and payments for third parties. | It governs outside access, not how your own systems are built. |
| Cloud banking | Where the system runs. Composable describes how it is structured. | A monolith can run in the cloud, and a composable system can operate on premises. |
| Coreless banking | Pushes further by dispersing the core’s functions. Usage varies by vendor. | A composable design may keep a core as one component, so check what is meant. |
| Banking-as-a-service | A business model in which a licensed bank offers its services to others through APIs. | It is a way of selling banking, not a way of building your own stack. |
| BIAN (The Banking Industry Architecture Network) | An industry framework that describes banking functions and services. | BIAN alignment may be mistaken for proof that components can be integrated or replaced without affecting the rest of the stack. |
When composable banking delivers value
The benefits depend on specific technical and operational conditions. The table below outlines these requirements and the factors that can limit the expected outcomes.
| Benefit | Conditions for success | Potential challenges |
|---|---|---|
| Faster product launches | The new product touches few components, contracts between them are stable, and test environments exist. | A launch waits on the slowest vendor or on the one team that understands the integrations. |
| Replace a weak component without a full migration | Clean contracts, data you can export, no hidden coupling. | Data or logic is tied to the incumbent platform, so ‘replacing’ means rebuilding. |
| Best-of-breed capability | You have the capacity to integrate and govern several suppliers. | Component sprawl: various tools, poorly connected, an inconsistent customer view. |
| Lower risk through gradual change | Legacy and new components run in parallel with clear ownership. | The parallel period drags on and you pay for both. |
| Cost efficiency | Integration and maintenance costs stay manageable. | Licensing fees and overlapping systems increase overall costs. |
Treat any vendor’s speed claim without conditions, such as ‘launch in weeks’, as marketing until you see what it assumes.
Hidden costs and risks of composable banking
Implementing a composable architecture involves several challenges, each requiring specific measures to manage the associated risks and costs:
- Integration complexity across vendors. Each component adds API contracts, versioning schedules and failure modes. Critical cross-component operations also require idempotent processing, controlled event handling and reconciliation. Reduce it with: Documented contracts, contract tests, tested failure recovery and a named owner for each integration.
- Unclear orchestration ownership. Processes such as onboarding span identity verification, account opening and card issuance. If nobody owns the end-to-end flow, integration becomes everyone’s part-time job. Reduce it with: One named team accountable for each cross-component journey.
- Vendor management overhead. Multiple suppliers introduce additional contracts, roadmaps and support relationships. Reduce it with: A vendor-management function sized for the number of suppliers, and a realistic count of suppliers before you start.
- Talent gaps in distributed systems. Engineers experienced in monolithic systems may lack the expertise required to trace failures across multiple services. Reduce it with: Observability across components and hiring or training for distributed systems.
- Inconsistent governance. Compliance and audit controls previously managed centrally must be applied consistently across relevant components and providers. Reduce it with: Shared standards for logging, access and audit, written into every contract.
EU regulatory considerations: DORA and third-party risk
Working with multiple technology providers brings additional regulatory requirements. The EU’s Digital Operational Resilience Act (DORA), which has applied since 17 January 2025, sets rules for managing ICT third-party risk. Under Article 28(3), financial institutions covered by DORA must keep a register of their contractual arrangements with ICT service providers.
For banks adopting composable architecture, working with more providers increases the effort required to assess suppliers, monitor risks and plan exit strategies. Replacing individual components may be easier when contracts and technical dependencies are clearly defined.
Requirements for outsourcing and third-party risk vary across jurisdictions, so check which regulations apply to your institution.
Is composable banking right for your institution?
Before adopting this approach, assess whether your institution has the technical capabilities and resources to manage a distributed banking architecture.
Three questions are particularly important:
- Do you have in-house API and integration expertise? Without it, composable architecture shifts fragmentation to a different team rather than solving it.
- Can you name the single source of truth for the customer state today? If the honest answer is ‘it depends which system you ask’, fix that first.
- How long can you run legacy and new systems side by side? Progressive modernization may require parallel operations, with additional infrastructure and maintenance costs.
Institutions with limited integration capacity may find pre-integrated platforms more practical. The appropriate approach is shaped by your existing architecture, available resources, and modernization priorities.
Where to start
A practical approach is to begin with capabilities that have clear boundaries and require frequent changes, such as onboarding or customer-facing channels. The right starting point comes down to how tightly your existing systems are connected.
Step 1: Assess your existing architecture. Identify system dependencies, integration requirements and areas where changes are difficult to implement.
Step 2: Select a capability for modernization. Prioritize a function with clearly defined responsibilities and limited downstream impact. Consider leaving the core ledger for a later stage, based on the state of your architecture.
Step 3: Test and evaluate. Start with a limited use case to assess integration effort, operational requirements and potential benefits before extending the approach to other banking functions.
Vendor evaluation: A seven-question test
As interest in composable banking grows, vendors use the term to describe different architectural approaches. However, the level of modularity and interoperability these solutions offer varies. Evaluating vendor claims therefore requires looking beyond marketing descriptions.
Put these questions to every supplier:
- Can I replace one component without changing the others? A good answer: A documented example, ideally a reference customer who has done it.
- Can the component run on its own, or does it need the vendor’s whole platform? A good answer: It is deployable and licensable separately. If not, you are probably buying a modular suite.
- Who owns the data model, and can I export all my data in a usable form? A good answer: Your data, in documented formats, with no extra fees to extract it.
- How are API contracts versioned, and how much notice do I get before breaking changes? A good answer: A published policy with defined notice periods.
- What does exit look like? A good answer: Stated cost, timeline, data format and contractual support for the transition.
- Who is accountable when a failure crosses components? A good answer: A named party and a defined process, not ‘it depends where the fault is’.
- Is there a reference customer with a stack and scale like mine? A good answer: One you can speak to. Proof at a small institution says little about a large one.
Composable banking pays off only when integrations are owned, contracts are clear and vendors can be replaced in practice.
Final thoughts
Composable banking offers greater flexibility, but independent capabilities also introduce integration challenges, operational costs and vendor dependencies. The key is to look beyond the promise of modularity and evaluate what each solution can deliver in practice.
Evaluate your banking modernization options
Assess your existing systems, integration challenges and technology priorities with our banking experts.
