Operations11 min read

Sidecar Cores and Strangler Fig Patterns: Progressive Banking Modernization

The sidecar core pattern does not eliminate migration risk. It defers a one-time cutover and replaces it with a continuous reconciliation requirement that persists for the duration of the parallel run, which in most bank modernization programs is two to five years. Banks that treat the sidecar as a contained pilot, adding reconciliation as a later phase, consistently discover the problem in the wrong order: reconciliation gaps surface after data has been in flight across two systems for months.

40% of banks are pursuing sidecar core strategies as of 2026, projected to reach 70-80% by 2028. 85% of financial institutions report plans for heavy core transformation investment (KPMG European Banking Outlook 2026). The industry has accepted that big-bang replacement is too risky. Whether to run a sidecar is no longer the open decision. What matters is whether the sidecar architecture includes the reconciliation infrastructure necessary to operate two financial cores in parallel without accumulating irreconcilable state.

Why Big-Bang Replacement Failed

The TSB migration of 2018 is the canonical reference. TSB attempted to move 5.2 million customers from the Lloyds Banking Group platform to its new Proteo4UK core in a single weekend cutover. The migration produced an 18-day outage affecting 1.9 million customers, locked customers out of their own accounts, exposed some customers to other customers' transaction data, and ultimately cost TSB over GBP 330 million in remediation, compensation, and regulatory penalties. The UK FCA and PRA imposed additional fines totalling GBP 48.65 million in 2023.

The structural cause was not a single bug. It was the impossibility of validating, in a test environment, the complete behavioral equivalence of two systems against five years of production data, customer state, and edge-case transaction history. TSB tested the migration extensively. The production environment revealed interactions that no test matrix had anticipated.

Every large-scale core banking replacement that has attempted a single-weekend cutover has faced the same category of problem. The legacy system's behavior is not fully documented. The new system's behavior under production load is different from its behavior under test load. Customer state at the moment of cutover includes edge cases that pre-migration testing did not cover.

Sidecar architecture avoids the single-weekend cutover. It introduces a different class of problem.

The Split-Brain Problem

When two cores operate simultaneously against overlapping customer data, they become potential sources of conflicting truth. Customer Alice has an account in both the legacy core (where her direct debit mandates, standing orders, and historical transaction data live) and the modern sidecar (where her new accounts and new products live). When Alice's payroll is deposited, it goes to the legacy account. When she pays a subscription using the new product, it goes to the sidecar account. Her total available balance is the sum of both, but neither core knows the full picture.

The split-brain problem has three dimensions.

Balance visibility. The customer sees a balance that depends on which system's account they are querying. Customer service agents must query both systems to answer "what is my total balance?" Every customer-facing balance inquiry that touches both systems requires a join operation across two cores that may not have synchronized their state at the moment of the query.

Transaction history. A customer disputing a charge must have their complete transaction history reconstructable, regardless of which core processed it. An audit trail that says "your transactions from before [date] are in the legacy system; your transactions from after [date] are in the new system" is not a complete audit trail. It is a partition of two incomplete records.

Compliance state. CDD records, AML flags, PEP designations, and sanctions screening results must be consistent across both cores. If a customer is flagged in the legacy system but the sidecar has not received that flag, the sidecar may process transactions that the legacy system would have blocked. AMLD5 Article 14 requires that CDD results are applied consistently across all product lines, a requirement that is structurally violated if the two cores do not share compliance state in real time.

Reconciliation as a First-Class Architectural Component

The correct approach is to treat reconciliation as a structural component of the sidecar architecture, not as an operational process added after deployment.

Event-sourced synchronization. Every state change in either core is published as an event to a shared event log. The event log is the authoritative record of what happened, in what order. The legacy core and the modern sidecar both consume this event log. Their states are derived from the same sequence of events. Reconciliation is not comparing two independent states. It is verifying that both cores have correctly applied the same event sequence.

This requires that both cores support event-sourced state derivation, which legacy cores generally do not. The practical approach for legacy systems is to capture changes through database change data capture (CDC): monitoring the legacy core's database transaction log and converting state changes into events. CDC introduces latency (seconds to minutes) and requires careful handling of legacy data model quirks: undocumented fields, implicit state machines encoded in status columns, and business rules that live in stored procedures rather than application code.

Immutable audit trail across both cores. Every transaction processed by either core must be recorded in a shared immutable audit log with a common correlation ID scheme. When a customer asks "what happened to payment X?", the answer must be retrievable from the shared log regardless of which core processed it. The shared log is not a reporting database that aggregates both cores periodically. It is a write-ahead journal that both cores write to before executing state changes.

Rollback capability at product-segment granularity. The strangler fig pattern migrates customers or product segments from the legacy core to the modern sidecar incrementally. If a product segment migration reveals a behavioral difference, where the modern core handles a specific edge case differently from the legacy core, the architecture must support rolling back that segment to the legacy core without data loss.

Rollback requires that the modern core's state is a superset of what the legacy core would have had for the same transactions. If the modern core has processed transactions that the legacy core cannot represent (because the legacy core's data model does not support the new account type, or the legacy core's workflow engine cannot replay the event sequence), rollback is not possible. This must be verified before migrating each segment, not discovered during the rollback attempt.

The Strangler Fig at Product Granularity

The strangler fig pattern, named for the fig tree that grows around a host tree and gradually replaces it, migrates functionality incrementally. In core banking, the most effective granularity for the strangler fig is the product segment: migrate one product type at a time, starting with new customer acquisition (new customers get the modern core; existing customers stay on the legacy core until explicitly migrated).

Product-segment migration at new customer acquisition has a specific advantage: new customers have no historical state in the legacy core. There is no customer data to migrate, no transaction history to reconcile, no direct debit mandates to transfer. The reconciliation burden for new-acquisition segments is limited to ensuring that the sidecar core correctly handles products that the legacy core has never processed.

The reconciliation burden increases as existing customer segments are migrated. Each existing customer brings historical state: transaction history, product configurations, direct debit mandates, standing orders, CDD records, AML flags, and any in-flight processes (pending payments, open disputes, scheduled transfers). Migrating existing customers requires:

Extracting the complete current state of each customer from the legacy core.
Validating that the modern core's data model can represent every element of that state without loss.
Transforming the legacy state into the modern core's format.
Loading the transformed state into the modern core.
Running both cores in parallel for a verification period, comparing outputs for the same inputs.
Cutting over customer-facing traffic to the modern core.
Retaining the legacy core in read-only mode for a defined period to handle disputes referencing historical data.

Step 5 is where most programs underestimate effort. The verification period requires generating identical transaction inputs against both cores and comparing outputs with sufficient coverage to be confident that behavioral equivalence holds across edge cases, not just for the happy path but for error conditions, R-transactions, concurrent updates, and regulatory-trigger events. This cannot be done by running a test suite. It requires replaying production traffic patterns against both systems simultaneously.

The 14% CAGR Context

Cloud deployment in European banking is growing at 14% CAGR (KPMG 2026). SaaS and hosted core banking models have reached 67.5% market share. The market is shifting from third-generation vendor-locked systems to fourth-generation composable cores with open APIs and cloud-native deployment models.

This shift means that most banks currently running sidecar programs are evaluating modern cores built specifically for cloud deployment, with event-sourced architectures, ISO 20022 native data models, and standard API contracts. The reconciliation challenge is lower when both cores speak the same data language: if the legacy core's transactions can be classified using ISO 20022 BankTransactionCodes and the modern core uses the same classification natively, the reconciliation matching is structural rather than heuristic.

The reconciliation gap is widest when the legacy core uses proprietary transaction codes, proprietary account identifiers, and proprietary API contracts, and the modern core uses ISO standards throughout. Every reconciliation match between these two systems requires a translation layer, and every translation layer is a maintenance burden and a potential mismatch source.

Trade-offs

Progressive modernization via sidecar introduces costs that big-bang replacement avoids, and avoids costs that big-bang replacement creates.

Ongoing operational overhead. Running two cores in production doubles the operational surface: monitoring, incident response, capacity planning, and security patching must cover both systems. For institutions that are understaffed for core banking operations already, doubling the operational surface without increasing headcount creates risk.

Consistency window. Event-sourced synchronization introduces a latency window between a state change in one core and its propagation to the other. During this window, the two cores may report different states for the same customer. For compliance purposes, the window must be bounded and documented: regulators expect institutions to know the maximum lag in their dual-core architecture and to have assessed its impact on compliance obligations.

Data model incompatibilities. Legacy cores were built with data models that predate ISO 20022, PSD2, and GDPR. Migrating customer data from a legacy model to a modern one requires dealing with missing fields (GDPR consent records that the legacy core does not track), structural mismatches (proprietary transaction code enumerations that do not map cleanly to ISO 20022 codes), and semantic ambiguities (status columns that encode business rules no longer documented anywhere).

Fernel Context

Fernel's architecture is designed for sidecar deployment from its initial layer decomposition. The three strictly isolated layers (the ledger engine, the orchestration engine, and the domain layer) operate independently. A bank running a sidecar can deploy Fernel's ledger engine for new product segments while retaining the legacy core for existing customers, connecting the two through an event-sourced synchronization layer that writes to both the legacy transaction log and Fernel's append-only journal. The reconciliation infrastructure is the event log, not a periodic batch job: every state change in either system is a journal entry with a correlation ID, queryable at any point in time.

Sources:

KPMG, European Banking Outlook 2026: 40% sidecar adoption by 2026, 70-80% projected by 2028; 85% planning heavy transformation; 14% CAGR cloud deployment; 67.5% SaaS/hosted market share
TSB Migration Failure, April 2018: GBP 330 million total cost, 1.9 million customers affected, 18-day outage. UK FCA/PRA enforcement action and GBP 48.65 million fine (2023)
ThoughtWorks, "Kill your core: The banking revolution you didn't see coming": coreless banking architectural principles
AMLD5, Directive 2018/843, Art. 14 (Timing and scope of CDD verification, consistency requirement)
Strangler Fig Pattern: Martin Fowler, "StranglerFigApplication" (2004), incremental migration via parallel system operation
ISO 20022 BankTransactionCode External Code Sets: the data language bridge for dual-core reconciliation