Executive Summary
Financial services organizations that have delivered multiple platform investments: modernized core banking, cloud data platforms, digital lending engines, API gateways: are discovering a consistent pattern: the estate does not cohere into a working system. The EU's Digital Operational Resilience Act entered full enforcement in January 2025. Eighteen months in, institutions are discovering that DORA's mandatory technology dependency mapping requirement reveals what platform architects have long known: the dependencies between platforms were assumed, not designed. Integration relationships that were invisible on individual project trackers are now documented compliance exposures on DORA readiness assessments. McKinsey research consistently finds that approximately 70% of digital transformation programs fail to meet their original objectives, with integration complexity as one of the most frequent causes of overrun. The composable banking market is projected to reach USD 36 billion by 2033 (from USD 4.8 billion in 2024), but market size alone does not resolve the architectural failure pattern that prevents most institutions from realizing it.
Every Platform Works; The Estate Does Not
Financial services organizations that have delivered multiple platform investments: modernized core banking, cloud data platforms, digital lending engines, API gateways: are discovering a consistent pattern: the estate does not cohere into a working system. The EU's Digital Operational Resilience Act entered full enforcement in January 2025. Eighteen months in, institutions are discovering that DORA's mandatory technology dependency mapping requirement reveals what platform architects have long known: the dependencies between platforms were assumed, not designed.
Integration relationships that were invisible on individual project trackers are now documented compliance exposures on DORA readiness assessments. McKinsey research consistently finds that approximately 70% of digital transformation programs fail to meet their original objectives, with integration complexity as one of the most frequent causes of overrun. The composable banking market is projected to reach USD 36 billion by 2033 (from USD 4.8 billion in 2024), but market size alone does not resolve the architectural failure pattern that prevents most institutions from realizing it.
The Orchestration Tier Is The One That Goes Unbuilt
D3: Digital Business Platforms: applied to financial services requires three tiers to work together: a systemic orchestration layer (cross-platform governance standards, data contracts, API protocols, and accountability structures); a Platform of Solutions layer (domain-specific platforms: core banking, customer data, risk management, digital lending); and a Solutions of Applications layer (individual components and microservices). Most financial services organizations have built the bottom two tiers.
The top tier: the governance logic that makes them behave as a coherent system: is the one that consistently goes unbuilt. BIAN provides a taxonomy of banking service domains but does not define how those domains interact. TOGAF provides a governance process but does not provide an active operational model for how independently built platforms manage their relationships. SAFe coordinates delivery but does not address the meta-architecture above the delivery teams. The D3 framework's Platform of Platforms model addresses the gap: it specifies what the systemic orchestration layer must contain and who must own it.
Someone Must Own The Space Between Platforms
Transformation leaders in financial services have three decisions to make if their platform estate is already partially built. First: define the systemic orchestration layer explicitly: not as a technology project but as a governance document specifying how platforms expose capabilities to each other, what data contracts apply, and who is responsible for cross-platform standards.
Second: use DORA's dependency mapping requirement productively: the dependency map DORA requires is structurally similar to what a well-designed systemic orchestration layer produces as a natural output; run the compliance exercise and the architectural design together. Third: assign clear accountability for the space between platforms: most transformation organizations have accountability for individual platform delivery and no accountability for the relationships between platforms; this gap defaults to the integration function, which solves point-to-point rather than systemically.
Sector Context: Banking Has Become a Multi-Platform Enterprise
Modern banking estates are no longer organized around one core system. They combine core banking, payments, customer data, identity, risk, lending, fraud, integration, cloud, analytics, and channel platforms, often built or modernized at different times by different teams. Composability promises faster change because capabilities can be replaced or recombined without rebuilding the entire bank.
The promise breaks when composability is interpreted only at the component level. A collection of modular platforms is not automatically a composable enterprise. The bank also needs rules governing how those platforms expose capabilities, exchange data, manage identity, handle failure, and evolve without breaking one another.
Four Forces Exposing the Missing Orchestration Layer
Regulatory dependency mapping is making hidden architecture visible. DORA turns cross-platform dependencies from an architecture concern into an operational-resilience concern. Relationships that were previously managed informally must now be understood and governed.
Platform modernization is happening asynchronously. Core, data, payments, lending, and channels rarely modernize together. Without shared contracts, every modernization creates new translation layers and temporary integrations that become permanent.
APIs do not create governance by themselves. API gateways make connectivity easier, but they do not determine service ownership, semantic consistency, versioning policy, or accountability when a dependency fails.
Delivery frameworks optimize teams, not the estate. Domain teams can deliver quickly while the enterprise accumulates incompatible data models, duplicated services, and integration debt. Local autonomy therefore requires stronger systemic rules, not weaker governance.
The Structural Shift: From Platform Portfolio to Platform of Platforms
D3 distinguishes between domain platforms and the systemic layer that allows them to operate as one business architecture. The orchestration layer should define capability boundaries, data contracts, API and event standards, identity and access patterns, observability, resilience expectations, and decision rights for cross-platform change.
D4 supports this architecture by ensuring transformation increments strengthen the target system rather than merely complete projects. D2 becomes relevant as more decisions cross platform boundaries and the bank needs intelligence to move coherently through the estate. D6 can accelerate implementation through reusable integration patterns and architecture repositories.
Opportunities and Risks
A mature orchestration layer can lower the marginal cost of change, improve resilience, make regulatory dependency evidence easier to produce, and allow domain platforms to evolve independently without losing enterprise coherence. It is what converts modularity into strategic agility.
The risk is creating another centralized bottleneck. Systemic orchestration should define the minimum rules required for interoperability and accountability, not pull every design decision into a central architecture committee. Excessive centralization can destroy the autonomy composability is meant to create.
Five Executive Priorities
Name an owner for cross-platform coherence. Accountability must exist for relationships between platforms, not only for the platforms themselves.
Turn dependency mapping into architecture design. Use DORA work to identify fragile dependencies, undocumented data exchanges, concentration risk, and missing ownership.
Define enterprise contracts. Establish standards for data semantics, APIs/events, identity, versioning, resilience, and observability that every platform must honor.
Measure integration debt explicitly. Track duplicated services, point-to-point interfaces, unresolved ownership, and change lead time across platform boundaries.
Govern the minimum, federate the rest. Preserve domain-team autonomy while making systemic rules non-negotiable where enterprise resilience and reuse depend on them.
The Watch List
Two near-term signals will indicate whether institutions are building the orchestration layer or continuing to defer it.
- DORA compliance dependency mapping audits (ongoing): the quality and completeness of technology dependency maps that institutions produce for DORA will reveal the true state of cross-platform architecture governance across the financial services sector.
- BBVA platform API disclosure updates: BBVA's continued open banking platform reporting provides the clearest public reference for what mature systemic orchestration looks like at a retail banking scale.
- BIAN v12 adoption in European banking: whether BIAN's latest domain model supports more precise inter-domain interaction standards will determine whether the industry taxonomy closes the governance gap or leaves it to individual institutions.
Executive Decision Test
The practical test for leaders is whether the next investment strengthens an enduring sector capability or merely improves one local initiative. Before approval, executives should be able to identify the operating-model dependency being changed, the reusable capability being created, the owner of the cross-functional decision, the outcome metric that will demonstrate value, and the governance mechanism that will remain after the implementation team leaves. If those answers are missing, the organization is still funding activity rather than redesign.
The sequencing principle is equally important. Leaders do not need to replace the entire estate before value can emerge. They do need each increment to move toward a coherent target architecture. That means using current initiatives to establish shared data, interfaces, decision rights, measurement, and reusable controls that subsequent initiatives can consume. The result should be cumulative: every deployment should make the next deployment easier, faster, safer, or cheaper.
This is also the distinction between adoption and capability. Adoption measures whether a technology or service is being used. Capability measures whether the organization can repeatedly produce the intended outcome under changing conditions. Industry Brief decisions should therefore be evaluated against capability compounding, not launch completion.
Closing Perspective
The central issue is structural rather than technological. The organizations that create durable advantage will be those that turn the capability described in this brief into part of the operating model, with clear ownership, reusable architecture, measurable outcomes, and governance that persists beyond an individual project. The leadership question is therefore not whether to adopt another tool or launch another initiative. It is whether the sector's operating architecture is being redesigned so that each investment strengthens the next one.
