Build vs. Buy for Treasury Systems
The build-vs-buy decision in treasury is usually framed as a budget question. It is really a choice about who controls the logic. Here is how to think about buying a TMS, building on raw AI, and the third path most teams overlook.
Every treasury team I talk to eventually hits the same decision, and almost all of them frame it the same way: do we buy a treasury management system, or build something ourselves? Posed as a budget-and-headcount question (how much can we spend, how many engineers can we spare), it has no good answer. Both roads are expensive, and both take longer than anyone plans for.
The framing is the problem. Build vs. buy in treasury was never really about budget. It is about who owns the logic. The real question is whether your cash forecasting, approval rules, and reconciliation logic are dictated by a vendor's roadmap, or written by your team on top of technology that arrives knowing nothing about treasury. Once you see it that way, the two options everyone argues about start to look like two versions of the same compromise, and a third option comes into view.
What buying a TMS actually costs you
Buying means adopting a treasury management system (TMS): Kyriba, GTreasury, Clearwater, and their peers. Each ships a prescribed set of workflows: cash positioning, payments, forecasting, risk, and reporting, built the way the vendor decided to build them. That is the appeal. You get decades of treasury domain knowledge, encoded and waiting on day one.
It is also the ceiling. Your process has to bend to fit the tool, not the other way around. When the workflow you need is not the one the vendor shipped, your choices are to wait on their roadmap, stretch an already long implementation, or quietly rebuild the gap in spreadsheets. You are not just licensing software; you are adopting someone else's opinion about how treasury should work, and inheriting their release calendar for every change you want after that.
For plenty of teams that is still the right trade. A mature TMS hands you a model of treasury you would not want to rebuild from scratch. Just be honest that what you are buying is that model, rigid edges and all. We wrote more about the trade-off between automation and flexibility in finance software here.
What building on raw AI actually costs you
Building used to mean writing a treasury system from scratch. Today it usually means building on raw AI: pointing a general-purpose model like ChatGPT, Claude, Gemini, or Copilot at your treasury problem and having your own engineers wire it into your banks and systems.
The appeal is the mirror image of a TMS: total control, no vendor dictating how treasury should run. The catch is that a general model shows up with zero treasury domain knowledge. It does not know your account structures, your approval thresholds, your bank formats, or what "reconciled" means at your company. Before it does anything useful, your team has to build all of it (account hierarchies, approval rules, bank integrations, reconciliation logic) and then keep maintaining it as banks, entities, and policies change.
That is not a one-time project; it is a standing commitment. Most finance teams do not have engineers to spare for it, and the few that do rarely want their best people owning bank connectivity forever. Building buys you a system that fits your process exactly, and hands you the bill for every piece of domain logic a TMS would have given you for free.
The trade-off, side by side
Line the two conventional options up and the pattern is hard to miss: each is strong exactly where the other is weak. One gives you domain logic and takes your flexibility; the other gives you flexibility and takes your time.
| Buy a TMS | Build on raw AI | |
|---|---|---|
| Treasury logic | Prebuilt by the vendor | Built and maintained by you |
| Flexibility | Limited to the vendor roadmap | Unlimited, but all on you |
| Time to value | Long implementation cycles | Long build before anything works |
| New functionality | On the vendor's release calendar | On your engineering backlog |
| Engineering burden | Low | High and ongoing |
If the best you can do is choose which compromise hurts less, the question itself is set up wrong. When both answers to a question are bad, it is usually worth checking whether you are asking the right question.
Build vs. buy is only one axis
Here is what the standard debate misses. Buy-versus-build is a horizontal axis: off-the-shelf on one end, do-it-yourself on the other. But there is a second axis running vertically, and it matters more: whether a tool is horizontal (general-purpose, with no idea what treasury is) or vertical (built around treasury workflows from the ground up). Plot the market on both axes and it sorts itself into corners.
Buy vs. build is only one axis. The other is whether a tool knows treasury at all.
Treasury management systems sit top-left: deeply vertical, but locked to buy. Legacy ERPs like Oracle and SAP sit bottom-left: bought, and horizontal. The general models everyone is now experimenting with sit bottom-right: endlessly buildable, but horizontal. They are powerful engines with no treasury knowledge of their own. Three corners fill up fast.
The top-right corner, configurable and built for treasury, stays empty in the conventional framing. For most of software history it had to. Vertical depth meant buying a rigid product; flexibility meant starting from a blank model. What changed is that AI finally makes it possible to ship treasury logic and keep it configurable at the same time. That corner is the third path.
The third path: a configurable platform with treasury logic built in
The third option is a configurable agent platform that ships with treasury logic already embedded, then lets you shape it to how your team actually works. It does not make you choose between domain knowledge and control. It gives you both.
This is the category Concourse is built for. Core treasury workflows (cash forecasting, reconciliation, and bank account management) are already built in, so you are not writing domain logic from scratch. Each customer is paired with a team of ex-CFOs and forward deployed engineers who handle integration, so the burden of wiring it into your stack does not land on your engineers.
Crucially, it reads your existing systems rather than replacing them. Concourse reads Kyriba, GTreasury, and Clearwater at the line level and connects to the banks underneath them, so your team works from one source of truth instead of reconciling across portals. Agents run each workflow from source data to a finished deliverable or action, with a human in the loop to approve.
The result looks like buying, since treasury logic is there on day one, but it behaves like building, because the workflows bend to how your team actually operates. Here is a deeper look at how those agents work across treasury.
How to make the build vs. buy decision
The right choice depends less on budget than on how much of your process is genuinely unique and how much control you need over it. A handful of questions cut through most of the debate:
- How standard is your process? If your workflows are conventional and unlikely to change, a TMS's fixed feature set is a fair trade. If your process is unusual or still evolving, being locked to a vendor roadmap will hurt.
- Do you have engineers to spare permanently? Building on raw AI is not a one-time project. Someone has to own bank integrations and reconciliation logic as banks, entities, and policies change.
- How fast do you need to see value? Both buying and building carry long lead times before anything works end to end. A platform with logic already embedded compresses that.
- Where does the domain knowledge live? If it lives with your vendor, you inherit their assumptions. If it lives with your engineers, you own the maintenance. A configurable platform lets it live with treasury while staying adaptable.
- Do you need to replace your systems or read them? Ripping out a TMS is expensive and risky. Reading it at the line level preserves your investment while giving agents one source of truth.
Answer those honestly and the question shifts from "build or buy" to "how much treasury logic do I want handed to me, and how much control do I want to keep." Almost everyone wants both, which is precisely the gap the third path fills.
Where treasury is heading
Build vs. buy was always a false binary: a choice between two compromises that only looked like opposites. The treasury teams I watch pulling ahead are the ones who stopped picking a side and started asking a sharper question: how do we get treasury domain knowledge on day one and keep control of how our process runs?
For the first time, that question has a real answer. The tooling has caught up to the ambition, and the vertical-and-configurable corner that used to be theoretical is where the most interesting treasury work is now happening. Over the next few years I expect it to stop being a third path at all and simply become the default.
If you are weighing treasury tools right now, pressure-test your process against raw model capability before you commit to either end of the spectrum. And if you want to see what the third path looks like against your own workflows, talk to our team. Several of us ran treasury and finance functions before we built this.
