Blog

The Hidden Cost of Building Treasury Infrastructure In-House

Written by Jason Mountford

May 8th, 2026

The pressure on commercial banks to modernize their digital treasury experience has never been higher. Corporate clients no longer benchmark their bank's portal against other banks, they benchmark it against the consumer-grade SaaS tools they use everywhere else in their finance stack. They expect real-time multibank visibility, intelligent forecasting, embedded workflows, and AI-driven insights, and they're increasingly willing to consolidate share of wallet with whichever institution can deliver them.

That pressure is showing up in budgets. Digital transformation spending in banking is projected to grow at over 14% to 2034, to almost $300 billion. The instinct to channel some of that budget into building proprietary commercial banking experiences in-house is understandable. Differentiation is important, the data is sensitive, and outsourcing the client-facing layer to a third party can feel like ceding control. 

But the build calculus is changing in ways that aren't always obvious from the outside. Rather than a single application, modern treasury infrastructure is a stack of interlocking systems that have to work together at high reliability, under regulatory scrutiny, with engineering and ongoing maintenance costs that compound year after year. 

Most banks that set out to build this stack underestimate what it actually entails, and the gap between intent and delivery shows up in transformation programs that miss their goals. Just 18% of banks have been highly successful in achieving their transformation objectives, according to a recent KPMG survey of 228 banking leaders globally. 

This article examines what banks actually take on when they choose to build treasury infrastructure in-house, and where partnership models offer a faster path to delivering modern capabilities to commercial clients.


Treasury Infrastructure Defined

Before assessing build cost, it's worth separating treasury infrastructure into its component layers. A bank that wants to deliver a modern commercial digital experience comparable to what fintech competitors offer needs to deliver, at minimum:

  1. A bank connectivity layer that ingests balances, transactions, and rich metadata from the bank's own core systems, and from the client's other banking relationships if multibank visibility is part of the value proposition. 

  2. A data normalization layer that reconciles inconsistent formats, transaction codes, and timing conventions across institutions. 

  3. A storage and processing layer built for the volume and query patterns of treasury workloads, which look very different from retail banking workloads. 

  4. An analytics and forecasting layer that produces meaningful projections from historical and projected activity. 

  5. An AI layer for natural language search, anomaly detection, and predictive insight, including the data pipelines and model infrastructure that make those features possible. 

  6. And the embedded experience layer that surfaces all of the above inside the bank's existing portal in a way that feels native.

Each of these is a discipline in its own right, with its own engineering team, its own vendor ecosystem, and its own ongoing maintenance burden. The banks that have built complete in-house stacks tend to be the largest tier-one institutions with multi-thousand-person technology organizations and decade-long roadmaps. 

Even there, the results are uneven. Tier-one commercial portals deliver strong core functionality, but treasury practitioners increasingly benchmark them against fintech-grade UX and AI capabilities they encounter elsewhere in their finance stack, a comparison the incumbent portals weren't designed to win.

For mid-market and regional banks, the question is even more important. The build cost is rarely the sticker shock, it’s the ongoing cost of operating a system that has to keep pace with a rapidly evolving expectations landscape is what tends to surprise.


Where Build Costs Hide

Several categories of cost tend to be underestimated in build-vs-partner analyses.


Bank API Connectivity Isn’t Simple

Aggregating data across the client's other banking relationships requires either bilateral API agreements with each institution or a network already in place. APIs aren't standardized across banks, as each has its own authentication model, its own data schema, its own quirks around posting times and reversals. 

Even within the bank's own walls, surfacing real-time balance and transaction data often means traversing multiple legacy systems with their own brittle integration paths. Building and maintaining this connectivity is a permanent engineering commitment, not a one-time integration project, and the failure modes are visible to clients the moment a feed breaks.


Treasury Data is Unforgiving

Unlike many SaaS workloads, treasury data has to be exactly right. A misclassified transaction or a stale balance is more than just a UX issue and can have serious ramifications. Building reconciliation, self-healing, and audit-ready data quality into a treasury platform requires both engineering investment and deep domain expertise that's rarely sitting on a bank's existing technology team.


AI Infrastructure Compounds Build Complexity

The current generation of generative AI features that commercial clients increasingly expect (i.e., natural language search across cash positions, predictive forecasting, and anomaly detection, etc.) sit on top of substantial data infrastructure. Models need clean, normalized, context-rich data flowing in continuously. Without that foundation, AI features either don't work or produce confidently wrong outputs, which is worse. Banks pursuing in-house AI without first solving the data layer often spend significantly more than projected and ship significantly less than planned.


Regulatory and Security Overhead Never Stops

Every new feature surfaces a new regulatory review, a new third-party risk assessment, a new penetration test cycle. The Digital Operational Resilience Act (DORA) framework in the EU, which became mandatory in January 2025, requires banks to conduct rigorous digital operational resilience testing, third-party risk assessments, and incident reporting within strict timeframes. 

In-house builds often increase this overhead, because the bank owns more of the surface area. Cybersecurity costs alone are non-trivial, with cybersecurity spending by banks worldwide increasing substantially year on year.


Talent Is The Binding Constraint

The engineers who can build modern, cloud-native, AI-ready treasury infrastructure are the same engineers who command premium compensation at fintechs and hyperscalers. Banks that successfully recruit them then face the harder challenge of retaining them, and of keeping the program staffed through the multi-year delivery window required to ship anything meaningful.


The ‘AI Changes Everything’ Assumption

The rapid maturation of AI coding tools means in-house builds are now faster and cheaper than conventional wisdom suggests. Code generation, automated testing, and AI-assisted debugging can meaningfully compress development timelines for well-scoped features.

But treasury infrastructure is rarely a well-scoped feature problem. The hard parts, the parts that determine whether the platform succeeds with commercial clients, aren't code. They're the bank API negotiations and ongoing relationship management, the data normalization rules that take years of treasury domain expertise to encode correctly, the regulatory review cycles that don't move faster because a developer is more productive, and the institutional knowledge of why a particular SWIFT message type behaves a certain way at quarter-end. AI tools accelerate the parts of the build that were already the easy parts.

The risk is that AI productivity gains create a misleading impression of build feasibility, leading to programs that ship a working prototype quickly but stall when they hit the real complexity. The banks that have pursued this path tend to find themselves with partial solutions that need ongoing investment to stay relevant, rather than finished platforms.


What A Partnership Model Changes

The alternative is to build the experience layer on top of infrastructure that already exists. Embedded treasury platforms now offer banks a way to deliver modern multibank visibility, forecasting, and AI capabilities inside their own digital portals, without taking on the full infrastructure stack. The bank retains the client relationship, the data governance, and the brand experience, while the fintech partner provides the connectivity, normalization, and feature velocity that would otherwise require a multi-year internal program.

For most regional, super-regional, and even tier-one banks outside the very largest, the build-it-all model is becoming harder to justify against an alternative that ships in months rather than years and stays current automatically as the underlying platform evolves.


Getting The Decision Right

The build-vs-partner decision deserves a more rigorous framework than it usually gets. Bank product and digital leaders evaluating the question should pressure-test their build case against several criteria:

  • Total cost of ownership over a five-year horizon (not just initial development).

  • Opportunity cost of engineering capacity that could otherwise go toward differentiated features.

  • Time-to-market gap and what that gap costs in client retention and primary bank designation.

  • Talent risk inherent in any program that depends on a hard-to-recruit specialist team.

  • Realistic pace at which commercial client expectations will continue to escalate.

The honest answer for many banks is that some elements should remain in-house, the parts that genuinely differentiate the institution and reflect its specific commercial banking strategy, while the underlying treasury infrastructure is better consumed as a service. Building the connectivity layer, the data lake, the AI infrastructure, and the multibank network from scratch is increasingly an exercise in reinventing capabilities that already exist at higher quality elsewhere.

Trovata's Bank Pro is built around this idea. It gives banks an embedded cash and liquidity platform that delivers multibank visibility, AI-powered insights, and a freemium-to-premium engagement model directly inside the bank's existing digital portal, on infrastructure already trusted by mid-market and enterprise treasury teams. 

For banks weighing the real cost of building treasury infrastructure in-house, it offers a faster path to the modern commercial banking experience clients are now demanding, without the long-term operational burden. To explore what an embedded model could look like for your institution, book a partnership call.

Jason Mountford

Jason Mountford

A finance professional with over 15 years in wealth management, Jason started Hedge, a content agency, to bridge the gap between great writers and great finance businesses. He is a fully qualified Financial Advisor in both the UK and Australia, and also works with many clients in the United States and the Gulf Cooperation Council. He’s worked with companies of all sizes, from the Fortune 500 to small boutique firms. As a financial commentator, Jason has appeared in FT Adviser, Bloomberg, Investors Chronicle, the Daily Mail, the Daily Express, Money Marketing and more. Outside of work, Jason enjoys spending time with his wife and 2 kids, and keeping active. He’s a keen (though slow) endurance athlete, enjoying running, cycling and triathlon.

Subscribe to Newsletter