A custom treasury management system costs roughly $40,000 to $450,000 depending on scope. Here are the modules, bank connectivity options and a realistic timeline.
A custom treasury management system (TMS) costs roughly $40,000 to $80,000 for a cash visibility module and $200,000 to $450,000 or more for a full multi-entity platform with payments, forecasting and FX risk. Most companies reach for a build when spreadsheets stop scaling, bank portals fragment across too many banks, or they need to automate payments across currencies with real audit controls. Here is what the scope involves in 2026.
A TMS pulls balances and transactions from every bank a company uses into one place, then layers payments, forecasting and risk management on top. The core job is cash visibility: knowing your actual position across entities, currencies and banks today rather than last week. Around that sit four or five modules.
| Module | What it covers | Typical build effort |
|---|---|---|
| Cash management | Consolidated balances, cash positioning, forecasting | 1.5–3 months |
| Payments / payment factory | Multi-bank payment files, four-eyes approval, reconciliation | 2–4 months |
| Bank connectivity | SWIFT, EBICS, host-to-host or API feeds per bank | 1–3 months, grows with bank count |
| FX and interest rate risk | Exposure tracking, hedging, mark-to-market | 2–4 months |
| Investments and debt | Portfolio tracking, loans, interest schedules | 1–2 months |
Cash management is almost always the first module you build, because payments and forecasting both depend on accurate balances.
Cost scales with the number of banks, entities and currencies, and with whether you buy bank connectivity or build it yourself.
| Scope | Planning range | Timeline |
|---|---|---|
| Cash visibility module (statements, positioning, basic forecasting) | $40,000 – $80,000 | 2–3 months |
| Cash plus payments (payment factory, multi-bank files, approvals) | $100,000 – $200,000 | 4–6 months |
| Full multi-entity TMS (cash, payments, FX, forecasting, in-house banking) | $200,000 – $450,000+ | 6–12 months |
These are planning ranges, not quotes. Three things move the number most: how many banks you connect, whether those connections are file-based or API-based, and how much FX and risk functionality you need. Bank connectivity is the hidden cost. A single host-to-host or SWIFT connection can take a month of engineering and testing, and every additional bank adds more.
For comparison, buying a commercial TMS costs less up front but keeps charging. A mid-size company pays up to $40,000 a year for an off-the-shelf product, and complex multi-entity deployments run $100,000 a year or more, with first-year implementation often adding about 15% on top. That recurring spend is why companies with unusual workflows or many bank relationships consider building instead.
Start with cash visibility, then payments. Leave FX risk, investments and in-house banking for later.
Cash visibility means pulling end-of-day and intraday statements from every bank into one dashboard, with per-entity and consolidated views. Payments comes second because that is where control and fraud risk live. A payment factory normalises files across banks, enforces four-eyes approval and keeps an audit trail. Segregation of duties is non-negotiable here: whoever creates a payment should not be the one approving it. If you already move money across borders, this module overlaps with what we cover in our cross-border payment platform guide.
In-house banking, which nets and pools intercompany balances, saves real money for groups with heavy intercompany flows, but it is a later phase. Most teams do not need it in the first release.
Bank connectivity is the part people underestimate. In 2026 the main options are SWIFT (through a service bureau or SWIFT for Corporates), EBICS in Europe, host-to-host connections with individual banks, and open banking APIs where the bank offers them.
The format underneath is changing. SWIFT retired the old MT payment messages for interbank payments in November 2025, moving to ISO 20022 XML (pacs.008 and pacs.009). Fedwire cut over to ISO 20022 in July 2025, and the UK's CHAPS did in 2023. Corporate bank statements in MT940 still work, but they migrate to ISO 20022 (camt.053) bank by bank, on each bank's schedule. A TMS built now should read both MT940 and camt.053 so it keeps working when a bank flips.
The practical fix is a pluggable bank layer. Treat each bank as an adapter rather than a hardcoded integration, so adding a bank never means rewriting the core.
We treat treasury work as a financial systems project, not a generic web app. That means a finance-literate business analyst on the team, segregation-of-duties controls baked into the payment workflow, and an audit trail on every action. The stack is Java with Spring Boot on the backend, React or Vue on the frontend, and PostgreSQL or MySQL for ledger-adjacent data, with bank feeds isolated as adapters.
We have already delivered financial management systems with AP/AR, tax computation and real-time statements, so the domain is familiar. A build usually opens with a two-to-three week discovery phase to map every bank, currency and approval rule before we commit to a number. If you run several currencies, our multi-currency accounting guide covers the FX side in more detail.
A cash visibility module runs $40,000 to $80,000, cash plus payments $100,000 to $200,000, and a full multi-entity TMS $200,000 to $450,000 or more. Bank count and FX scope move the number most.
A focused cash visibility module takes two to three months. A full platform with payments, forecasting and FX takes six to twelve months. Buying a legacy commercial TMS is not faster: SAP and ION implementations commonly run 12 to 24 months.
Buy when your treasury process is standard and a vendor's modules fit most of it. Build when your workflows are unusual, you run many banks and currencies, or licence fees scale badly. A hybrid is common: buy a small platform and build custom bank adapters around it.
Most systems connect through SWIFT, EBICS, host-to-host or open banking APIs. Support both MT940 and ISO 20022 camt.053 statements so the system keeps working as banks migrate.
The system itself is not usually regulated, but the payments it sends are. If it touches card data it must meet PCI DSS. Payment approvals and audit trails also support financial controls and audit requirements such as SOX.
Usually not. In-house banking saves money for groups with heavy intercompany flows, but it is a later phase. Start with cash visibility and payments.
A custom TMS is a multi-month financial systems build, not a weekend project. If you are comparing build against buy, or have a treasury workflow you want automated, we can scope it with you.
GlobeSoft builds custom software, AI applications, SaaS, FinTech and enterprise systems for clients worldwide. Message us on WhatsApp for the fastest answer, or email us — we typically reply within 24 hours.
Keep reading
What the discovery phase of a software project covers, what it produces, what it costs, and how to tell a real one from a formality before you commit.
9 min readA guide for non-technical founders who need software built: how to validate the idea, scope an MVP, pick a build path, and hire a team you can actually trust.
12 min readFounders confuse proofs of concept, prototypes, and MVPs, and the confusion costs real money. Here is what each one actually tests and when to build it.
13 min readA practical guide to custom internal tools: what they cost, when building beats buying or low-code, and how to scope one without overbuilding.
11 min readHow to recover a failed software project: the salvage-or-rebuild decision, a clean code handover, what a rescue actually costs, and how to choose the team that takes it over.
10 min readA practical guide to custom software for small and medium businesses: when off-the-shelf stops working, what to build first, what it costs, and how to pick a vendor.
