By Macer Skeels, CTO and Co-Founder, FinanceKey

Most enterprise software today is multi-tenant. That means multiple organisations: you; your competitors; your peers; all run on the same underlying infrastructure. The same servers, the same databases, the same application layer. You each have your own login and your own data, but ultimately, you share the same system. 

Single-tenant architecture is different. Your environment is yours alone. Dedicated infrastructure, isolated data, no shared layer with anyone else. Think of it as the difference between a shared office floor and a private floor in the same building. The address looks similar from the outside. Operationally, it’s completely different. 

Neither model is inherently insecure. Multi-tenancy underpins a huge portion of modern software, and it works well in many contexts. But architecture shapes how risk moves – and that distinction matters enormously when the platform in question sits at the centre of your treasury operations. 

The risk framing treasury teams aren’t applying 

Treasury teams are incredibly disciplined about financial risk: 

• Cash in not concentrated with a single counterparty without limits  
• Entities, accounts, and exposures are ring-fenced 
• Decisions are always made in terms of containment.  

This is foundational thinking: if something goes wrong, how far does it spread?  

Yet, that same question is rarely applied when selecting the technology stack. Shared environments get accepted without the equivalent question being asked: if something breaks here, or is breached, is the impact isolated to us, or are we exposed too? 

Architecture defines how risk cascades. And in treasury, cascading risk is everything. 

In a multi-tenant environment, an incident affecting one customer – a data exposure, a performance failure, a misconfiguration – can affect others. Not always. Not inevitably. But the architecture allows for it. The blast radius is shared by design. 

In a single-tenant environment, what happens to one organisation stays contained to that organisation. The walls are structural, not just logical. 

This isn’t a theoretical concern. Widely discussed incidents across enterprise SaaS in recent weeks have demonstrated that shared infrastructure creates shared exposure. The question isn’t whether these events happen. It’s whether your platform’s architecture means they can affect you when they happen to someone else. 

Why we built FinanceKey to be single-tenant

When we were making foundational decisions about FinanceKey’s architecture, this wasn’t a close call. 

The companies that use FinanceKey are running live treasury operations. They’re processing bank transactions, managing cash positions across entities and currencies, and making decisions on real money in real time. The data flowing through the platform – account balances, payment flows, counterparty relationships, forecasting positions – is among the most sensitive in any organisation. 

We decided early on that the right architecture for that context was one where each customer’s environment is fully isolated. Dedicated infrastructure. Dedicated resources, no shared data layer, no dependency on what another customer is doing or what happens to their environment. 

There are trade-offs to this approach. Single-tenant deployments are more operationally intensive to run than a shared platform. They cost more per customer to maintain. Scaling requires more deliberate engineering. 

We made that choice anyway, because we think the people responsible for treasury operations deserve a platform where the risk containment model matches the standards they apply everywhere else in their work. 

Tenancy used to be a criterion in treasury platform selection, often framed as cloud versus on-prem. However, in the move to Saas, that thinking was largely forgotten. We think that this is now a gap. Not because one model should be dismissed outright, but because the question itself matters – and one whose answer should be part of how you assess operational and security risk in your stack. 

If you’re evaluating treasury platforms, it’s worth adding it to your list: what’s the tenancy model, and what does that mean for how risk moves if something goes wrong?