Headless Banking and Monolith Decomposition: How Are Regulations Changing Banking Architecture?

Over the past decade, European banks have invested heavily in digital channels. Mobile banking apps and online platforms have become increasingly sophisticated, while many sales and customer service processes have been automated. Yet in many banks, the technology behind these digital experiences has struggled to keep pace.

While customer-facing applications have evolved, the underlying core banking systems have often remained largely unchanged for 15, 20 or even 30 years. Today, modern digital channels connected through APIs operate alongside monolithic backends that are increasingly difficult to develop and test. With so many interconnected components, isolating failures and preventing them from affecting other parts of the system has also become a challenge.

For years, this approach worked well enough. Now, however, many banks are reaching a point where the complexity of maintaining their existing architecture is becoming more costly than the stability it provides.

Regulation is adding to the pressure. PSD3/PSR, FiDA and DORA leave banks free to choose their architectural approach, but they also introduce more demanding operational requirements and broader responsibilities. Banks therefore need to consider how their existing systems will accommodate future regulatory requirements and changing market conditions.

Key Takeaways: 

• Headless Banking separates the customer experience layer from business logic and data, allowing individual channels to evolve more independently.
• DORA, PSD3/PSR and FiDA place greater emphasis on operational resilience, API quality, consent management, access control and data traceability.
• As monolithic systems become more complex, even relatively small changes can affect multiple interconnected processes.
• Successful modernisation starts with clearly defined business domains and their responsibilities. Microservices are one way to implement these boundaries.
• The Strangler Fig approach allows banks to decompose monolithic systems gradually, moving functionality away from legacy infrastructure in manageable stages.

Banking Is Moving from Applications to Platforms

Traditional banking architecture followed a relatively simple model:

Channel > Banking Application >> Core Banking System

With only a limited number of channels to support, this centralised approach made sense. A single system served as the Single Source of Truth, while individual applications acted as relatively thin clients, primarily displaying information and passing user requests to the core banking system.

Today’s banking environment is considerably more complex.

Customers use mobile apps and online banking, contact their bank through call centres or branches, and increasingly access financial services through third-party platforms. Banks also need to support B2B integrations with corporate customers’ ERP systems, alongside emerging interfaces such as IoT devices, chatbots and voice assistants.

Embedded finance is expanding the range of possibilities even further. Financial services can now be integrated directly into experiences offered by other businesses, allowing customers to access banking products while shopping online, using a telecommunications provider’s app or interacting with an e-commerce platform.

In this environment, banks increasingly operate as service platforms, making their capabilities available across multiple channels and systems. Headless Banking provides an architectural approach that supports this model.

What Is Headless Banking?

Headless Banking brings the headless architectural approach, already widely used in e-commerce, into the banking sector. Its central principle is the separation of the presentation layer, or frontend, from the business logic and data managed by the backend.

The frontend includes mobile and web applications, chatbots, voice interfaces, partner portals and embedded finance channels. The backend contains the business domains responsible for customer management, payments, lending, deposits, KYC/AML, risk management and fraud prevention.

Communication between these layers takes place through APIs and business events.

With this separation in place, customer-facing channels can evolve independently of the underlying business logic. Banks can introduce new services across different channels and partner platforms without having to rebuild their core systems whenever they change an interface or introduce a new way for customers to interact with their services.

Why Are Monolithic Banking Systems Becoming a Problem Now?

For many years, monolithic architecture provided the stability and consistency that banking systems required. As banks expand and the pace of change increases, however, the limitations of this approach are becoming more apparent to business teams and IT departments alike.

A typical monolithic banking system can contain millions of lines of code and support hundreds of business processes. It may also rely on a shared data model, a common deployment cycle and a complex network of dependencies that no single team fully understands.

In such an environment, even a relatively small change to a payment process or complaints-handling workflow can affect dozens of other areas.

At the same time, regulators are raising requirements in precisely the areas where tightly coupled architectures present some of the greatest challenges:

• Operational resilience and fault isolation.
• Cybersecurity and access control.
• Data traceability and auditability.
• API standardisation and quality.
• Consent management and data sharing.

DORA, PSD3/PSR and FiDA are increasing expectations in these areas, making the limitations of existing monolithic systems harder to ignore.

DORA: Making Operational Resilience an Architectural Requirement

The Digital Operational Resilience Act (DORA) introduces requirements for managing ICT risk and reporting incidents. It also covers resilience testing and oversight of technology providers.

From an architectural perspective, these requirements directly influence how banking systems are designed, operated and maintained.

Meeting DORA’s requirements involves developing capabilities in several areas.

1) Fault isolation  

A failure in a single component should not bring down an entire banking platform.

In a monolithic system, tightly coupled components increase the risk of cascading failures. A domain-based architecture makes it easier to establish clear boundaries between services, helping prevent problems in one area from spreading across the system.

2) Observability  

Effective monitoring requires more than collecting system logs.

Banks need metrics, distributed tracing, and technical and business monitoring capabilities that allow them to understand how an incident affects specific processes, customers and services.

With this level of visibility, teams can identify the source of a problem, assess its impact and respond more effectively.

3) Recoverability  

Restoring services after a disruption requires recovery plans tailored to individual business domains and effective disaster recovery (DR) strategies.

In monolithic environments, recovery often involves restoring large parts of the system together. A modular architecture allows banks to develop more targeted recovery strategies for individual services and business domains.

4) Operational testing  

Modular systems make it easier to test individual domains independently and assess how they behave under different failure scenarios.

Banks can conduct resilience tests, simulate incidents, and use chaos engineering techniques to evaluate their systems under controlled conditions. They can also introduce mechanisms such as circuit breakers, bulkheads and event replay to help contain failures and support service recovery.

In practice, many DORA implementation programs also create opportunities to decompose existing banking architecture, even when architectural modernization is not their primary objective.

PSD3/PSR: Treating API Endpoints as Products

PSD2 laid the foundations for Open Banking, but its implementation also exposed several challenges. These included inconsistent API quality, differing interpretations of standards, security concerns and friction in the user experience.

PSD3 and the Payment Services Regulation (PSR) are intended to address these issues and further develop the existing framework.

For banking IT teams, this places greater emphasis on three areas.

API-First Architecture 

An API-first approach starts with designing a service that can be used across different channels, including web applications, mobile apps and partner platforms. The way that functionality is presented within a particular interface is defined afterwards.

This allows banks to develop reusable services that support multiple customer journeys without having to recreate the same business logic for each channel.

Applying Product Thinking to APIs

The way banks manage APIs is also evolving. Rather than treating them primarily as technical integration points, banks are increasingly building portfolios of APIs that provide specific business capabilities.

Examples include:

• Payments API.
• Customer/Identity API.
• Consent API.
• Credit Decision API.

These APIs have their own product owners, development roadmaps, quality metrics and service-level agreements (SLAs), much like other digital products.

Developer Experience  

APIs used across a broader ecosystem need to be accessible and straightforward for developers to work with.

This requires developer portals, OpenAPI specifications, sandbox environments, versioning, monitoring and technical support.

By providing these capabilities, banks make their services easier to integrate with external platforms and can increasingly operate as platform providers.

FiDA: Expanding Financial Data Access Beyond Open Banking

While PSD2 opened access to payment account data, the proposed Financial Data Access (FiDA) framework aims to extend controlled, consent-based access to a much broader range of financial information.

This includes savings and investment products, insurance data, and other aspects of a customer’s financial relationship.

The implications for banking architecture extend well beyond traditional Open Banking. FiDA creates a need for capabilities that have often been fragmented across banking systems or treated as secondary concerns.

These include:

• Consent management: centralised, transparent management of customer permissions.
• Data lineage: the ability to trace where data originates and how it is transformed.
• Data governance: clear responsibility for data ownership and quality within individual business domains.
• Fine-grained access control: precise permissions based on individual attributes, data scope and the purpose of access.
• API monetisation: the ability to develop revenue models around data and services.

FiDA has implications beyond system integration. Banks need to develop the capabilities to manage financial data as a business asset that can be accessed and shared securely within a wider ecosystem.

Why Business Domains Matter More Than the Choice of Microservices

A common mistake in banking transformation programs is to equate modernization with a migration to microservices.

Microservices are one way to implement a modular architecture. What matters more is defining clear boundaries between business domains and establishing ownership of their respective functions and data.

Modern banking transformation draws on several architectural approaches.

Domain-Driven Design (DDD)

Domain-Driven Design structures software architecture around the actual business areas of an organization.

In banking, this means identifying domains such as Payments, Cards, Customer, Loans, Fraud and Treasury, then assigning each domain clearly defined functions and responsibilities.

The resulting architecture reflects how the bank operates and helps teams understand which parts of the system are responsible for specific business capabilities.

Bounded Context

A bounded context establishes a clearly defined boundary within which a particular domain model applies.

Each domain has its own data model and responsibilities, reducing dependencies between different parts of the system and limiting conflicts when changes are introduced.

Event-Driven Architecture

Event-driven architecture enables systems to communicate through business events.

For example, a “Customer Updated” event can be consumed by CRM, AML, fraud prevention and marketing systems, allowing each to respond according to its own business requirements.

This approach can reduce the need for direct point-to-point integrations, limit dependencies between systems and make it easier to develop additional functionality.

What Does the Target Architecture of a Banking Platform Look Like?

A modern banking platform increasingly follows a layered architectural model. Each layer has clearly defined responsibilities, with customer-facing channels separated from business domains and the underlying integration infrastructure.

A typical architecture consists of six layers.

1. Channel Layer

This layer covers the different ways customers and partners interact with the bank, including mobile applications, web platforms, branches, contact centers, and embedded finance channels.

2. Experience Layer

The Experience Layer supports the delivery of digital customer experiences through components such as Backend for Frontend (BFF), Experience APIs and Journey Orchestration.

These components help coordinate interactions between customer-facing interfaces and the services required to complete specific customer journeys.

3. Platform Layer

The Platform Layer provides shared capabilities used across the architecture, including Identity and Access Management (IAM), observability, security, API Management and Consent Management.

4. Domain Layer

The Domain Layer contains the bank’s core business domains, such as Payments, Lending, Customer and Deposits.

It also includes capabilities that support regulatory compliance, such as Anti-Money Laundering (AML).

5. Data Layer

The Data Layer provides the infrastructure needed to store, process, and manage data across the banking platform.

It can include components such as an Operational Data Store (ODS), a Lakehouse and an Event Store.

6. Integration Layer

The Integration Layer enables communication between business domains and connected systems through APIs, Event Mesh and event-streaming platforms such as Kafka.

This model brings banking architecture closer to the platform-based approaches commonly used by large technology companies.

Banks can move towards this architecture incrementally, continuing to use their existing core banking systems while gradually transferring selected functions and business domains away from legacy infrastructure.

How Can Banks Decompose a Monolith Incrementally? The Strangler Fig Approach

Replacing an entire monolithic banking system in a single project carries considerable risk. Core banking processes must continue operating throughout a modernization program that may take several years.

The Strangler Fig approach provides a practical way to modernize these systems incrementally.

It involves gradually introducing new components around the existing monolith and transferring functionality to them in stages.

The process typically follows five steps.

1. Introduce an API Gateway. Placing an API Gateway in front of the monolith provides a controlled access point and helps standardise security policies and monitoring.
2. Separate the channel layer. Decoupling customer-facing interfaces from core banking logic allows banks to develop and modify the user experience more independently.
3. Develop new functionality outside the monolith. New capabilities are built as separate components, particularly in areas where the business needs to introduce changes more quickly.
4. Migrate business domains incrementally. Existing functionality is gradually transferred to the new architecture, with clearly defined boundaries between business domains.
5. Gradually retire legacy components. As new services take over their responsibilities, the corresponding legacy components can be phased out.

This approach allows banks to modernize their architecture while maintaining continuity for customers. It also spreads the cost and risk of transformation over time, rather than concentrating them in a single large-scale migration.

The Biggest Change Is in the Business Model, Not the Technology

Headless Banking has implications beyond system architecture. It changes how banks can deliver financial services, making them available outside their own applications through partner platforms, purchasing journeys and the systems used by corporate customers.

DORA, PSD3/PSR and FiDA further increase the importance of modular, API-based architectures built around clearly defined business domains and event-driven communication. They also place greater demands on how banks manage, protect and share data.

As a result, banking modernisation is increasingly connected to a broader business question: How can banks build an operating model that remains adaptable over the coming years, despite growing regulatory requirements and rapid market changes?

Monolith decomposition is becoming part of this wider transformation. By modernizing their architecture incrementally, banks can maintain their existing operations while developing the capabilities needed to introduce new services, support additional channels and respond to future regulatory requirements.

If your bank is planning a similar transformation, talk to Univio’s experts about an approach tailored to your existing architecture and business objectives.

Below, we answer some of the most frequently asked questions about Headless Banking.

FAQ

What Is Headless Banking?

Headless Banking is an architectural approach that separates the presentation layer from business logic and data. Customer-facing channels, such as mobile apps, web platforms and partner applications, communicate with backend services through APIs and business events. This separation allows individual channels to evolve more independently of the underlying core banking systems.

Why Are Banks Decomposing Monolithic Systems?

As dependencies within a monolithic system increase, even relatively small changes can affect multiple business processes. Decomposition allows banks to separate business domains and reduce the dependencies between them. It also makes it easier to contain failures and develop individual parts of the system at different speeds.

How Does DORA Affect Banking Architecture?

DORA places greater emphasis on operational resilience, system monitoring, service recovery and resilience testing. A modular architecture can help banks establish clear failure boundaries and test individual business domains independently. It also supports more targeted recovery strategies when incidents occur.

How Does the Strangler Fig Approach Work in Banking Modernisation?

The Strangler Fig approach involves gradually building new components around an existing monolithic system. Banks migrate individual functions and business domains to the new architecture in stages, allowing legacy components to be retired as their responsibilities are transferred to the new services.