If you work in treasury and your company is not a Fortune 500, you probably know the feeling: you need better tools, but every solution on the market seems built for someone else.
Enterprise Treasury Management Systems cost too much for your company to afford it. Implementation takes 6 to 12 months. And you have to buy more than you actually need or use. So you stay in Excel. You copy data from banking portals. You build workarounds that technically work but feel fragile. And every few months, someone asks why treasury still runs on spreadsheets while every other function has moved to modern software.
Treasury software is built to sell licenses, not to solve daily treasury work.
How we got here
Treasury technology evolved inside large enterprises. The buyers were procurement teams with long evaluation cycles. The sellers optimized for big contracts, not fast adoption. The result: systems designed to do everything, configured over months, maintained by dedicated IT teams.
This made sense when only large corporations had complex treasury needs. It no longer makes sense today.
Mid-sized companies now operate across multiple currencies. They have bank accounts in several countries. They need forecasting, FX exposure tracking, payment workflows. The complexity is real, but the budget and team size are not enterprise-level.
The gap between what these companies need and what the market offers is enormous.
What changed everywhere else
Look at how other parts of fintech evolved over the last decade.
Payments went from monolithic processors to modular APIs. Stripe lets you use only what you need. Plaid connects to banks without forcing you into a full platform. Modern accounting tools integrate with dozens of services instead of trying to be everything.
The pattern is the same: break the monolith into components. Let users assemble what they need. Make each piece work independently.
Treasury is one of the last areas where this shift has not happened. Most vendors still sell all-or-nothing systems. The few that offer modular options often require expensive implementation projects anyway.
What modular treasury actually looks like
The alternative is not “simpler” software with fewer features. It is software where features are independent modules you can combine based on your actual needs.
Need cash positioning across entities? Use that module. Need FX exposure tracking? Add it. Do not need hedge accounting? Do not pay for it, do not configure it, do not see it in your interface.
This is what a modular approach looks like in practice. Instead of a fixed system where you navigate through features you will never use, you select the components relevant to your operations and ignore the rest.
The output is a focused workspace that does exactly what you need.
A cash position dashboard does not need to be part of a 200-feature TMS. It can be a standalone module that connects to your data sources and gives you what you actually look at every morning.
The integration question
The immediate objection to modular systems is integration. If everything is separate, how does it connect?
This is where modern architecture matters. Modular does not mean isolated. It means components that connect through standard interfaces rather than proprietary lock-in.
A proper modular system connects to your ERP, your banks, your existing tools. It exports to Google Sheets if that is where your team works. It sends alerts to Slack if that is where you communicate. It does not force you to change how you operate just to use one feature.
Who this is for (and who it is not for)
If your company has a dedicated treasury technology team, a seven-figure budget, and 18 months for implementation, enterprise TMS solutions work fine. They are built for you.
If you are a treasury team of one to five people, managing real complexity without enterprise resources, the monolithic approach does not serve you. You need tools that match your actual situation: real functionality without the overhead.
Treasury will not be transformed by bigger systems. It will be transformed by smaller, composable tools that actually fit how treasury teams work. The only open question is how long teams will keep paying for software they barely use.
The market is slowly moving in this direction. The question is whether you wait for the big vendors to catch up or start building your treasury stack from components that exist today.
