TMS Cloud Security and Data Residency

A cloud treasury management system holds your bank account details, your payment capability and your financial data — which makes it a high-value target — and it runs in someone else's infrastructure, which makes its security a shared-responsibility question, not a box the vendor ticks on your behalf. When you buy a TMS today it is almost certainly SaaS: the vendor hosts and operates it, and the natural follow-on question is how that data is secured and where it lives. This guide is the set of questions I'd want answered before signing — general guidance, not advice for any specific organisation.

Why treasury raises the stakes

Most software holds data. A TMS holds the two things an attacker actually wants: information and the ability to move money. It aggregates bank balances, stores account and counterparty details, and — the part people underweight — it can originate and approve payments. A compromise isn't an embarrassing data leak; it's a route to fraudulent payments and a map of how your cash moves. That's why it belongs on your requirements checklist as a scored, evidenced criterion, not a reassuring line in the sales deck.

And because the system runs in the vendor's cloud, "is it secure?" is the wrong question. The honest framing is the shared-responsibility model: the vendor secures the infrastructure, platform and application they host; you remain responsible for who has access, how duties are segregated, how payments are approved, and whether your configuration is sound. A great deal of real-world SaaS harm is customer-side misconfiguration, not a vendor breach — both halves have to be solid, and each side should be able to show its work.

Certifications and assurance: what to actually ask for

Vendors will list certifications. Your job is to read them, not collect logos:

• SOC 2 (ideally Type II). An independent auditor's report on the controls around security, availability and confidentiality. Type I says the controls were designed adequately at a point in time; Type II says they operated effectively over a period — usually six to twelve months. Type II tells you the controls are lived, not laminated.
• ISO 27001. Certification that the vendor runs a recognised information-security management system — an audited framework for managing risk, not a single technical control.
• Independent penetration testing. Evidence that a third party regularly tries to break in, and — more telling — that findings get remediated.

The critical move is to ask to see the reports, typically under NDA, then read three things: the date (is it current?), the scope (does it cover the service you're actually buying, or a sibling product?), and the exceptions the auditor noted. A vendor that shares a current, in-scope report without friction is telling you something reassuring. One that offers only a webpage badge is telling you something too.

"

A certification logo is a marketing claim. The audit report behind it is the evidence. In selection, insist on the second — before you sign, not after an incident makes you wish you had.

Data residency and sovereignty

Data residency is where your data physically lives and is processed. For a lot of software that's a footnote; for treasury it can be a binding constraint, for three overlapping reasons:

• Privacy law. Regimes such as GDPR govern where personal data — including the people behind bank and counterparty records — may be stored and transferred.
• Banking secrecy and sector rules. Some jurisdictions require that financial data about their entities stay in-country, or restrict cross-border transfer.
• Government-access concerns. Where data is stored can determine which government can compel access to it, which is a real consideration for some groups and regulators — the "data sovereignty" question sitting underneath residency.

So the question to a vendor is concrete: in which region(s) will our instance be hosted and processed, will you commit to that in the contract, and where do backups, support access and any sub-processors sit? Multi-tenant SaaS often runs in a fixed set of regions; if you need a specific one, confirm it's actually offered rather than assumed — residency is the constraint most likely to override the SaaS default.

Access and identity

The controls you own start here, and they're where customer-side incidents concentrate. What good looks like:

• SSO, so TMS access is governed by your corporate identity provider and a leaver loses access everywhere at once.
• MFA, enforced — non-negotiable for a system that can move money.
• Role-based access, granular enough to give people only what their job needs.
• Segregation of duties inside the tool, so whoever creates a payment can't also approve and release it — the control that most directly blocks internal fraud.
• Audit trails that record who did what and when, and that you can actually export and review.

What varies is how well the tool enforces these versus how well it demos them — exactly the thing to probe during a structured selection process rather than take on faith.

Encryption, resilience and the payment path

Encryption is table stakes but worth confirming: data encrypted in transit (nothing moves in the clear) and at rest (a stolen disk or backup is useless). Then resilience, because a TMS you can't reach on a payment-run morning is its own kind of failure — ask for backup and disaster recovery with stated RPO/RTO targets and evidence they're tested, and business continuity for the service as a whole.

Give the payment path its own scrutiny, because it's where security and fraud meet. How are payment instructions protected end to end? Are approval limits and segregation of duties enforced by the system rather than by convention? How are the connections to your banks secured and monitored? It's the flow most worth an attacker's effort.

Treat security as an evidenced selection criterion

The through-line: make security a criterion you score with evidence, the way you'd score functionality. Ask for the SOC 2 and ISO reports, get the residency commitment in writing, walk the access controls and payment path with someone technical, and — because moving vendors later is hard — ask how you'd get your data out when you leave. A vendor that answers fluently and hands over documents is a different proposition from one that reassures you warmly.

Docs-vs-reality

Here's the pattern I've watched play out. Security gets a slide and a confident nod in selection while attention stays on features and price. It gets real scrutiny exactly once — after an incident, or after an auditor asks a question no one can answer — and by then you're negotiating from weakness, mid-contract, with the leverage gone. That leverage exists in precisely one window: before you sign, when the vendor wants your business and will hand over the SOC 2 report, commit to a region, and walk you through the payment controls. After signing, the same requests become favours. Security and residency are cheapest to secure as questions in a selection, and most expensive to discover as gaps in production — and if you're still framing the wider decision, what a TMS is and does sets the context these questions sit inside.

Part of the Treasury Management Systems guide. The newsletter sends one practical finance-systems pattern every two weeks — real SAP, treasury and delivery notes from 18 years inside enterprise finance.