By Robert Cooke, CEO of 3forge
Financial services firms operate highly specialized technology estates under demanding operational and regulatory conditions. Modernization therefore has to preserve the systems that still serve the business while introducing new capabilities around them. When a workflow spans several systems, that can mean another set of integrations, controls, and application infrastructure to develop and maintain.
AI is increasing the pressure on that model. AI-assisted development can accelerate the creation of applications and services, while agents and automated workflows add new consumers of enterprise data and new participants in operational processes. If each new application independently determines how to access data, store information, authenticate users, or implement common functionality, faster development can reproduce architectural fragmentation more quickly.
The resulting complexity exposes four connected challenges: combining real-time and historical data through a consistent operating model; moving AI-enabled applications from prototype into production; extending governance across data access, users, applications, agents, and the runtime in which generated software executes.
Treating these challenges each as separate initiatives can recreate fragmentation at the points where the solutions meet. That pressure is already visible in AI adoption: the 2026 Cambridge Global AI in Financial Services Report found that 40% of surveyed industry respondents cited data availability and quality as a leading barrier to AI adoption, rising to 49% among traditional financial institutions.
Taken together, they raise a broader infrastructure question rather than four isolated technology questions: which data, application, and control capabilities are genuinely specific to an individual workflow, and which are common enough to become reusable across the estate? Making common capabilities reusable can reduce the number of recurring architectural decisions engineers – and increasingly AI coding tools – must remake for every application, leaving more effort for the business logic and workflows that differentiate the firm.
Different Operating Cadences, the Same Infrastructure Question
Trading and private equity illustrate how the same architectural problem appears at very different operating speeds. The common requirement is not that every dataset become real-time, but that distributed data, business logic, and controls remain coherent at the cadence each workflow requires.
The same architectural pattern has emerged across distinct areas of financial services. Trading provides the faster-moving example: Order information may arrive across venues, desks, asset classes, and systems, while downstream workflows still need a coherent view of current activity. A consolidated order book illustrates one response: order flow is brought into a common real-time view rather than independently reconstructed by each downstream application.
Private equity presents the same coordination problem at a different cadence. Investment, fund, performance, carry, and capital-event information may be distributed across spreadsheets and specialist systems, while consequential business logic can become buried inside formulas, scripts, and individual applications. A shared operational view can bring together performance and NAV, investor and investment detail, and fee, carry, and capital-event information while making the underlying calculations easier to govern and audit.
But a common operational view solves only the problem. The next question is whether governed data and reusable business logic can flow into calculations, approvals, reporting, and operational actions without requiring another application-specific stack.
Trading firms need to process changes as orders arrive, execute, or are canceled. Private equity firms need shared data and business logic to drive calculations, approvals, reporting, and other fund workflows. In both cases, the objective is to reduce unnecessary handoffs between governed data, business logic, and execution. This points to two complementary opportunities for reuse: how distributed operational data is accessed and contextualized, and how that governed information is turned into working applications and workflows.
Connecting Data, Logic, and Execution
Trading and private equity both show why access alone is insufficient. Once information is available, firms still need consistent ways to apply business logic, move workflows into production, and govern the resulting activity. One way to organize those reusable capabilities is around two complementary functions:
- Reusable data access and context. A data fabric is one way to connect distributed sources through a common operating model, allowing workflows to combine real-time, historical, and legacy data without requiring those sources to operate at the same speed or be consolidated into one system. Source systems can remain authoritative while common controls govern how users, applications, and agents query, subscribe to, and act on that information.
- Reusable application runtime. Once data is available, teams still need the production capabilities required to turn it into calculations, workflows, interfaces, reports, and actions. An application engine can provide recurring capabilities such as state management, event processing, concurrency, permissions, visualization, reporting, testing, deployment, and monitoring, so those foundations do not have to be rebuilt for every application.
These are functional distinctions rather than necessarily separate physical layers. Depending on the workflow, business logic may execute close to the data in a headless process or extend into an interactive application. The architecture can follow the workload rather than forcing every use case into the same topology.
Across both, governance and operational control need to remain consistent. Identity, entitlements, permitted operations, audit, runtime resources, deployment state, utilization, and application versions can be governed and observed consistently across the environment rather than reconstructed inside each application.
Where this pattern fits, shared data and application capabilities can reduce the number of separate integration, runtime, and governance models that firms have to maintain. Governance can become part of the operating environment rather than something reconstructed differently for every application. That includes controlling who or what may access data, which functions an agent may invoke, recording the information and tools it accessed, and maintaining an attributable audit trail of the actions that followed.
AI-assisted development makes the runtime boundary increasingly important. If generated code can independently introduce libraries, open connectivity, bypass established application services, or consume resources without constraint, governance at the data-access layer is insufficient. A governed application runtime can instead constrain generated software to approved capabilities and interfaces, allowing AI to generate the business-specific portion of an application without giving it responsibility for recreating the surrounding infrastructure.
Modernize the Foundation, Not Everything Around It
Modernization does not necessarily require replacing specialist systems that continue to serve the business. One alternative is to establish reusable capabilities around those systems so workflows can share governed data access, logic, and operational controls without requiring prior consolidation.
A practical starting point is a bounded workflow where repeated integration, inconsistent logic, or fragmented controls create a measurable problem. The connections, data models, transformations, entitlements, and runtime services established there can then become candidates for reuse when subsequent workflows need them.
As AI accelerates software creation, the cost of rebuilding common infrastructure and controls application by application becomes more visible. The opportunity is not to standardize every application or move every workflow onto one platform. It is to make common capabilities reusable so that each new application inherits more of the governed foundation and has less infrastructure to recreate. Over time, modernization becomes a consequence of delivery rather than a prerequisite for it.
About the Author:
Robert Cooke is the CEO and Founder of 3forge, bringing over two decades of experience in designing mission-critical systems for global financial institutions. Early in his career, he optimized middle-office workflows at JPMorgan and managed regulatory compliance and high frequency electronic trading teams at Bear Stearns. He later modernized post-trade processing and transaction cost analysis at Liquidnet, establishing himself at the forefront of real-time data streaming, market infrastructure, and complex event processing. At 3forge, Cooke has spearheaded the company into a global powerhouse in high-impact application development, enabling global firms like Morgan Stanley, Bank of America, Barclays, and Wafra to accelerate trading, risk management, and operations.
