MACH Architecture in Financial Services: Why Composability Stops at the Data Layer

The Question

Financial institutions have spent the past several years adopting MACH principles, Microservices, API-first, Cloud-native, Headless, expecting the same composability and delivery speed MACH produced in retail and ecommerce. Banks and insurers now run more services, more APIs, and more cloud infrastructure than before, yet architecture reviews keep surfacing the same dependency: a new product still cannot ship without a change request against the core system, and AI initiatives stall waiting for a clean, owned data source. This raises a direct question: why do MACH implementations in financial services routinely fail to deliver the composability they promise, and where does the gap between architectural intent and operating reality open?

The evidence points to a structural answer, not an execution failure specific to any one programme. Financial services organizations decompose the application and delivery layer through APIs and microservices while the data layer, anchored to a legacy core banking or policy administration system, remains a single authoritative source built around a data model no MACH initiative has touched. The result is an architecture that is MACH-compliant in form but not in function, a pattern recurring closely enough across institutions to be a property of the sector's starting conditions rather than of any single vendor choice or delivery team.

Context and Definitions

MACH describes four architectural principles: Microservices (independently deployable services scoped to a single business capability), API-first (every capability exposed through a documented interface before any user interface is built on top of it), Cloud-native (elastic, cloud-managed infrastructure rather than fixed on-premises capacity), and Headless (the front-end presentation layer decoupled from back-end business logic). The MACH Alliance, the industry consortium that coined and stewards the term, frames these as principles for building a composable technology stack rather than a specific product category or vendor label (MACH Alliance, 2025).

Financial services is a distinct implementation context for two reasons. First, core banking and policy administration systems typically carry decades of accumulated business logic and remain the authoritative record for customer, account, policy, and transaction data, unlike the product catalog a retailer replatforms during a MACH migration. Second, financial services entered the API era earlier than most sectors, not by strategic choice but by regulatory mandate: the European Union's Payment Services Directive 2 required banks to expose secure, standardized account and payment interfaces to licensed third parties years before MACH adoption became a strategic conversation (European Banking Authority, 2017). This note treats "MACH implementation" as the pursuit of architectural composability, a distinct effort from the compliance-driven API exposure many institutions had already built, and it examines banking and insurance specifically rather than fintech and insurtech challengers built MACH-native from inception, which do not carry the legacy-core dependency examined here.

What the Evidence Shows

Composability pays off where it is genuinely achieved, and financial services has not shown it is achieving it at the same rate as other sectors. The MACH Alliance's 2025 Global Annual Research Report, based on a survey of 561 senior IT decision-makers at large enterprises across the United States, United Kingdom, Germany, France, Canada, and Australia, found that nine in ten organizations that have implemented MACH technology report meeting or exceeding ROI expectations, citing improved customer experience (55%), better systems integration (54%), and organizational agility (50%) as the leading benefits (MACH Alliance, 2025). This shows composability, once achieved, produces measurable value rather than remaining a marketing claim. It does not show financial services institutions reach that state at the same rate as the retail and consumer brands that dominate MACH case studies; the survey does not break out sector-specific completion rates, and that gap is where the financial services pattern diverges.

The core banking legacy is the specific obstacle, and it is expensive enough to shape what gets funded. McKinsey's analysis of core technology modernization in banking found that institutions running outdated core systems carry operating costs roughly ten times higher than banks on modernized cores, with maintenance alone consuming up to 70 percent of IT budgets at the most legacy-burdened institutions (McKinsey & Company, 2021). A MACH initiative competes for funding against the daily cost of keeping the existing core running, and resulting programmes tend to get scoped as an API layer on top of the core rather than a redesign of its data model, which is materially more expensive and riskier to deliver.

Migration practice confirms the pattern directly: interfaces get replaced before data does. Oliver Wyman's 2025 guidance on core banking modernization describes abstraction layers as the standard technical bridge institutions use to connect legacy cores to new architecture during a phased migration, adopted explicitly to avoid the higher-risk "big bang" replacement that has drawn regulatory pushback for its unpredictability (Smith et al., 2025). The same analysis identifies talent gaps and reliance on non-permanent staff, not technology limitations, as a leading cause of stalled programmes. Read together, these findings describe an industry that has standardized on wrapping the legacy core rather than replacing it, a sequencing choice made for sound risk-management reasons that nonetheless leaves the original data model in place at the center of the new architecture.

Standards exist for exactly this problem, and their existence is itself evidence of how common the gap is. The Banking Industry Architecture Network, a nonprofit consortium of banks, technology providers, and consultancies, maintains a semantic API standard covering more than 5,000 defined service domains, built so services can be composed around shared data contracts rather than each institution inventing its own (BIAN, n.d.). An industry does not fund a shared standard unless the underlying integration problem is common and unresolved institution by institution.

Insurance shows the same shape, on a different core system. Composable architecture in insurance applies the same logic to policy administration rather than core banking: encapsulated Packaged Business Capabilities exposed through APIs, intended to let insurers update pricing, underwriting rules, or distribution channels without rewriting the underlying platform (Viswanath & Metzler, 2022). The framing matches the banking case; only the object being wrapped, a policy administration system instead of a core banking ledger, differs, consistent with this being a property of legacy-core architecture in regulated financial services generally rather than a banking-specific artifact.

What Deeper Analysis Reveals

The pattern this evidence describes is not a technology failure. It is a single strategy, minimum viable exposure, applied for two different reasons with the same architectural consequence both times.

Financial institutions had already learned, through PSD2 compliance, that regulators, auditors, and boards accept an API placed in front of a legacy core as evidence of modernization, provided the API meets the specified interface contract. That precedent normalized a specific move: expose a stable, well-defined surface over the core; leave the core's internal data model, and its status as the single source of truth, untouched. This is a rational response to a compliance deadline, where the requirement is a defined interface rather than a defined internal architecture. When the same institutions later adopted MACH principles for competitive rather than regulatory reasons, they reached for the pattern they already knew satisfied external scrutiny: expose the required interface, leave the core alone. The evidence above supports this reading. Abstraction layers as the standard migration bridge, "systems integration" rather than "data architecture" as the leading cited MACH benefit, and BIAN's decision to standardize at the API and service-domain level rather than mandate a specific data-ownership model all describe an industry optimizing for the same move, in banking and in insurance alike.

The distinction "MACH in form, not in function" does not by itself explain when this pattern is adequate and when it fails, and that boundary is the more useful diagnostic for leaders. The pattern is adequate wherever the exposed capability is genuinely bounded and rarely recomposed: a payment initiation endpoint or a policy-status lookup is exactly this shape, which is why PSD2-style compliance APIs work well within their own scope. It fails wherever the point of the new architecture is recomposition itself, assembling existing capabilities into product configurations the core was never asked to support, or serving several downstream consumers, a mobile app, a distribution partner, an AI underwriting or servicing model, with the same entity under different freshness and shape requirements. A composable architecture's core promise, independent evolution of its parts, requires that no consumer be silently coupled to a producer's internal schema. An API surface alone does not guarantee that; only an explicit data-ownership and event-contract layer does, and that layer is precisely what neither PSD2 compliance nor most cited MACH benefits required institutions to build.

This yields a practical diagnostic the architecture diagram alone will not reveal: ask whether adding a new consumer of an existing core entity, a new channel, a new AI model, a new distribution partner, requires a change request against the core system's own team and roadmap. If it does, that entity is still centrally owned in practice regardless of how many APIs sit in front of it. Under the D3 (Digital Business Platforms) lens, this reframes the failure diagnosis: a stalled MACH programme in financial services is rarely a technology-selection problem and is almost always a platform-design problem, an unresolved question of who owns which data entity and under what contract other services may depend on it.

Implications for Leaders

Audit composability at the data layer, not the API layer. An inventory of APIs and microservices will show progress even when the architecture has not become composable. Require architecture reviews to answer a narrower question for each core data entity: which team owns it, what is the contract for consuming it, and can that contract change independently of the system of record.

Treat the PSD2-era wrapping pattern as a starting hypothesis, not a template. The abstraction-layer approach that satisfied a compliance deadline is a reasonable first migration step, but institutions should name explicitly when a programme has stopped there rather than treating the compliance-era pattern as the finished state of a competitive architecture effort.

Fund data-domain ownership as a deliverable in its own right. Where several product or AI initiatives depend on the same core entity, treat resolving its ownership and contract as a funded platform product, not as scope absorbed inside each dependent project's budget.

Apply existing operational-resilience discipline to this question. UK financial institutions already map important business services to the underlying systems, including legacy technology and third parties, that support them, under the Prudential Regulation Authority's operational resilience framework (Prudential Regulation Authority, 2021). The same mapping discipline, extended to data ownership rather than only availability, gives leaders a governance mechanism they do not need to invent from scratch.

Sequence AI ambitions to the data layer's actual state. An AI roadmap that assumes API-exposed data is also owned, current, and independently consumable will meet the same core-team bottleneck described above. Scope AI initiatives against the data-domain ownership map, not the API catalog.

Conclusion

MACH implementations in financial services routinely fail to deliver the composability they promise because programmes decompose the application and delivery layer while the data layer, anchored to a legacy core banking or policy administration system, stays under unchanged, centralized ownership. The pattern is structural: it follows from a wrapping strategy institutions already knew satisfied external scrutiny under earlier API mandates, applied again for competitive rather than compliance reasons, in both banking and insurance.

The main limitation is that no cited source measures financial-services-specific MACH completion rates directly; the argument connects sector-level cost and migration-practice evidence to an architectural mechanism rather than a single study that isolates the effect. The next question is empirical: whether institutions that fund data-domain ownership as a distinct deliverable show measurably faster time to compose new products than those that do not. Until that evidence exists, leaders should audit composability where it actually lives, at the data layer, not where it is easiest to measure.