Should you build or buy a treasury management system?

For almost every corporate, buying beats building. A packaged TMS already embeds decades of bank connectivity, statement and payment formats, valuation logic and regulatory compliance — all of which you would otherwise have to build and then maintain forever. Building only makes sense in rare cases where treasury technology is a genuine competitive differentiator and you have a permanent software team to own it, which is almost never true for a corporate treasury.

Why is building a treasury system so expensive?

Because the cost isn't the first version — it's forever. Bank connectivity and message formats change, regulations evolve, banks are added and removed, and every one of those requires ongoing development and testing. A packaged vendor spreads that maintenance across hundreds of customers; if you build, you carry all of it alone, permanently, with a team you have to keep staffed and current. The build is cheap to start and expensive to never stop paying for.

Is configuring a packaged TMS the same as building one?

No, and the distinction matters. Packaged systems are meant to be configured — tailored to your entities, accounts and processes through settings, not code. Building means creating the core capability from scratch. The danger is buying a packaged system and then customizing it so heavily that it becomes a de facto bespoke build, inheriting the maintenance burden of build with none of the benefits — the worst of both worlds.

Build vs Buy a Treasury Management System

For almost every corporate, buying a treasury management system beats building one. A packaged TMS already embeds decades of bank connectivity, statement and payment formats, valuation logic and regulatory compliance — everything you would otherwise have to build from scratch and then maintain forever. Treasury technology is rarely a company's competitive differentiator, and the true cost of "build" isn't the first version — it's the permanent obligation to keep it current as banks, formats and regulations change underneath it. Build only in genuinely rare cases; for the rest, the honest answer is buy, and the real skill is buying well.

The question

"Build vs buy" sounds like a technology decision. It's really a focus decision: is running treasury software something your company should be in the business of doing? For a bank or a fintech, maybe. For a manufacturer, a retailer, a services firm — almost certainly not. The question isn't "can we build it?" (you probably can) but "should we own it forever?"

Why buy wins for almost everyone

A packaged TMS gives you, on day one, things that took the vendor years and hundreds of customers to build:

Bank connectivity — SWIFT, host-to-host, EBICS, API — already built, tested and maintained.
Formats — MT940, camt, pain.001 and their endless bank-specific variations, handled.
Domain logic — valuation, exposure, accounting, already encoded.
Compliance — regulatory changes delivered as updates, not projects.
Upgrades — someone else's job to keep it modern.

You're not buying software; you're buying not having to build and maintain all of that.

The real cost of build

The trap in build is that the first version looks affordable. The bill arrives afterwards, forever:

A bought TMS is cheap to change and expensive to buy. A built TMS is cheap to start and expensive to never stop paying for. The build cost you can't see is the one that matters.

Banks change formats. New banks get added. Regulations shift. Every one of those is development and testing you now own alone — where a vendor spreads it across its whole customer base. And it requires a permanent team: build a TMS, and you've committed to staffing treasury-software engineers indefinitely, or watching your system rot.

The spreadsheet is a third option — with a ceiling

Many treasuries "build" without noticing, in Excel. It's the cheapest possible start and genuinely fine at small scale. But it hits a hard ceiling: no controls, no audit trail, no segregation of duties, key-person risk, and errors that scale with the business. The spreadsheet isn't build vs buy — it's the thing you're deciding to replace.

Build vs buy vs configure

The most important nuance: packaged systems are configured, not built. A good TMS is designed to be tailored — to your entities, accounts, workflows — through configuration, not custom code. The failure mode is buying a package and then customizing it so heavily it becomes a bespoke build: you inherit build's maintenance burden and lose buy's upgradeability. This is exactly what fit-gap discipline protects against — close gaps by configuration or process change, and reserve true customization for the rare gap that warrants it.

How to decide

Three tests:

Differentiation. Is your treasury process a genuine competitive advantage, or just familiar? Build only for genuine, defensible differentiation.
Total cost of ownership. Compare buy's licence + implementation against build's lifetime — initial build plus permanent maintenance and staffing. Honest TCO almost always favours buy.
Risk and focus. Can you keep a treasury-software team current forever? Do you want that to be a thing your company does?

What usually goes wrong

Build hubris. "We can build something better/cheaper" — true for v1, false across the decade of maintenance nobody costed.
Underestimating maintenance. Budgeting the build, not the forever.
Buying then over-customizing. Turning a package into a de facto build and getting the worst of both.
Confusing configure with build. Treating necessary configuration as if it were bespoke development, or vice versa.

For the overwhelming majority of corporates, the answer is buy a packaged system and configure it well. Spend your energy not on building the software, but on selecting the right one and implementing it properly — that's where the value and the risk actually live.

Part of the Treasury Management Systems guide. See also when you need a TMS and the TMS business case. The newsletter sends one finance-systems pattern every two weeks.