Generative AI has collapsed the cost of the ‘easy part’ of software development, turning a vision into a prototype almost instantly. But for regulated firms, the hard parts, involving architecture stewardship, security and regulatory evolution, remain untouched. In this environment, the strategic question for the C-suite is no longer whether a capability can be built in-house, but whether owning the maintenance of that infrastructure capability is the best use of a firm’s resources. Neil Wands, Chief Operating Officer of FinregE, reports.
For decades, the “build vs buy” debate in financial services followed a predictable logic. Firms built for control and customisation, while they bought for speed and lower upfront expenditure. Generative AI has rendered this framework incomplete.
The cost of the initial creation phase has fallen precipitously. With tools such as GitHub Copilot and Claude Code now ubiquitous across the Fortune 100 [1], McKinsey reports that developers can complete certain tasks up to twice as fast using generative AI [2], the “prototype in a weekend” is no longer a hyperbole.
If a firm possesses a talented engineering team, it likely can build a regulatory intelligence tool in-house. It can connect a large language model to internal documents, construct a conversational interface and produce a demonstration that appears seamless.
However, for a highly regulated firm, the demonstration is not the proof. The critical question is not whether a capability can be built, but whether it can be run for a decade and at what ultimate cost.
The mirage of the fast build
There is arguably a fundamental asymmetry between a prototype and an enterprise-grade regulatory capability. A prototype manages the “happy path,” but a production system must manage the “regulatory path.”
To move from a weekend project to a resilient system, a firm must solve for authoritative content, source provenance, structured taxonomies and a forensic audit trail that can withstand supervisory scrutiny.
The perceived speed of AI adoption is often an illusion. While basic coding has accelerated, a 2025 METR study found that on complex and unfamiliar tasks, the AI productivity gain shrinks to under 10 per cent, with some developers actually working slower as complexity increased [3].
In the lifecycle of design, build, run and evolve, the risk and cost migrate rightward. While the build is accelerated, the “run” and “evolve” phases are where regulated workloads either succeed or fail.
The Total Cost of Ownership (TCO) iceberg and positive risk loss
When institutions decide to build, they typically budget for developer hours and cloud infrastructure. This is merely the tip of the iceberg. Industry benchmarks from Forrester suggest that roughly 80 per cent of software costs occur after launch, with annual maintenance alone often accounting for 15 to 20 per cent of the initial build cost [4].
When coupled with McKinsey’s finding that large IT projects frequently run 45 per cent over budget [5], the “cheap build” often transforms into an expensive legacy programme.
Beyond the balance sheet, there is a more damaging hidden cost: positive risk loss. This is the opportunity cost of pulling top engineering talent and product owners away from the core business. Every hour spent maintaining a compliance utility is an hour not spent on proprietary pricing models, unique customer experiences or the trading algorithms that provide a genuine market edge.
It’s important to note that this struggle for talent is not theoretical. In our recent experience with a major European financial services firm, a significant pain point was simply identifying and appointing a dedicated team and ‘Product Owner’ to manage a third-party solution. And this is a challenge that would be exponentially compounded if they had been required to build and maintain the entire infrastructure in-house.
The question for the board is not simply what the tool costs to build, but what is lost by diverting the firm’s best minds to maintain a utility.
The network effect of shared intelligence
There is also a common misconception that owning the code equates to owning the control. In reality, owning the code often means owning the isolation.
An internal build only ever evolves within its own narrow context. Conversely, a specialist platform evolves through shared learning.
When a vendor serves hundreds of clients, the product gains pattern recognition across thousands of different regulatory contexts. Innovation in a shared product moves faster because the learning is amortised across the entire market. The buyer is not merely purchasing software, but the aggregated experience of every other firm using that platform.
The RegTech escalation
If the total cost of ownership is a financial risk, regulatory velocity is an operational one. Financial services are entering an era of unprecedented fragmentation. From the EU AI Act and MiCA to DORA and evolving AML guidance, the volume of change is staggering.
The well-followed Thomson Reuters Cost of Compliance surveys indicate that the industry must track upwards of 200 regulatory changes per day [6].
An internal team may keep pace with one or two jurisdictions for a time, but they cannot realistically maintain a real-time, multi-jurisdictional mapping of obligations without becoming a regulatory research house. A shared platform amortises the cost of this escalation.
When a rule is updated in the EU, the platform updates it once and every client benefits instantly. In an internal build, that update is a manual ticket in a backlog that may remain uncleared for months.
A framework for strategic sustainability
Notably, the UK Government’s Financial Services AI Adoption Plan calls for the sector to scale AI responsibly and at pace. However, scale will not come from treating every use case as a bespoke engineering project.
The most effective decision framework is simple: does this capability provide a unique competitive advantage? This is the central tenet of McKinsey’s make-or-buy matrix [7], which reduces the complex procurement process to a single strategic question: does this specific capability provide the firm with a unique competitive advantage?
This follows Geoffrey Moore’s widely adopted principle to “build your core, buy your context” [8]. Firms should build their “Core.” If a capability defines their edge, such as a proprietary risk model or a unique customer journey, they should own and defend it. Conversely, they should buy their “Context.” If a capability is essential but not unique, such as regulatory horizon scanning and obligation management, it should be treated as infrastructure.
This strategic alignment is further supported by Gartner’s Pace-Layered Application Strategy [9], which categorises software into three layers: Systems of Record, Systems of Differentiation and Systems of Innovation. For the C-suite, the regulatory layer is a “System of Record,” the stable and governed foundation that must be defended at all costs but does not require internal ownership to be effective.
By buying the infrastructure, the firm preserves its internal talent for systems of innovation. As noted in a recent Forbes analysis [10], buying is the smarter choice when the capability is essential but not strategically differentiating and when a vendor’s shared innovation outpaces what can be sustained in-house.
The strongest institutions will not be those that build the most technology internally, but those that understand the difference between proprietary advantage and essential infrastructure. They will build what differentiates them and buy the specialist infrastructure that keeps them governed, traceable and aligned with a world that refuses to stop changing.
How FinregE supports a hybrid AI strategy
FinregE enables financial institutions to focus internal development on the capabilities that differentiate them, while utilising a specialist Regulatory Operating System (FinregE ROS) for the intelligence layer.
By connecting global horizon scanning, digital rulebooks and AI-supported analysis into a single, governed environment that connects to your Policies and controls, FinregE removes the maintenance burden from internal teams. Our AI Regulatory Insights Generator (AI RIG) is designed specifically for the regulated use case, providing the transparency and provenance that a “weekend build” cannot provide.
Turn regulatory intelligence into infrastructure.
Footnotes
- [1] GitHub, “Research: quantifying GitHub Copilot’s impact on developer productivity and happiness.”
- [2] McKinsey & Company, “Unleash developer productivity with generative AI.”
- [3] METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.”
- [4] Forrester Research, Software Maintenance and TCO Benchmarks.
- [5] McKinsey & Company, Research on IT Project Value and Budgeting.
- [6] Thomson Reuters, Cost of Compliance Survey (Various Years).
- [7] McKinsey: Make-or-Buy Matrix
- [8] Dealing with Darwin, by Geoffrey Moore.
- [9] Gartner: Pace-Layered Application Strategy
- [10] Forbes: Build Vs. Buy In The Age Of AI
