A bank trying to cut its SaaS bill faces a complication an ordinary company does not. When a marketing agency cancels a duplicate design tool, the worst case is someone grumbles.
When a bank cancels a tool, there is a real chance it was quietly load-bearing for a regulated process - an input to a control, a system in scope for DORA or NIS2, a place where personal data flows. Cutting it to save a licence fee can cost far more than it saves.
So for a bank, reducing SaaS spend is not purely a finance exercise. Every cut is also a risk decision, and the two cannot be made separately. The good news is that the same discipline that surfaces wasted spend also surfaces the compliance exposure, which means a bank that approaches this properly gets two returns from one piece of work.
Why generic cost-cutting is dangerous in a bank
The standard SaaS cost-reduction playbook is well known and genuinely effective: find the shelfware, reclaim unused seats, consolidate the tools that overlap, catch the renewal before it auto-renews at a bad price. For most of what a bank runs, that playbook applies unchanged, and it is worth running.
The danger is applying it blind. In a bank, a tool's cost and its regulatory role are not correlated - a cheap, low-profile application can sit inside a critical function, and an expensive one can be governing nothing that matters.
Cut purely by cost or usage signal and you will eventually cancel something that looked like shelfware from finance's side and was, from compliance's side, a documented part of a control. The generic playbook optimises for one variable; a bank has two, and they do not move together.
This is why "reduce SaaS spend" is a harder instruction in a regulated institution than it sounds. The savings are real, but they cannot be taken on the cost signal alone.
The hidden cost that is also a hidden risk
There is a category of SaaS spend in a bank that the generic playbook misses, and it is the one where cost and compliance are the same problem: the ungoverned tool.
Every application that entered the bank without going through procurement - the departmental sign-up, the free tier that grew, the AI feature switched on inside an existing platform - is two things at once. It is spend nobody is tracking, and it is an obligation nobody has assessed.
A duplicate analytics tool is wasted money; if it also processes customer data through an AI feature, it is a GDPR and potentially an EU AI Act exposure as well. The same object sits on both ledgers.
This is where a bank's cost problem and its compliance problem turn out to be the same object viewed from two desks: finance sees an untracked subscription, compliance sees an unregistered processing activity, and they are looking at one tool.
The reason this matters for spend reduction is that it changes the return on the work. Finding and rationalising ungoverned tools does not just recover licence fees; it shrinks the compliance surface the bank has to govern and evidence.
Do the cost and risk pass together, not in sequence
The practical consequence is a change in how a bank should run the exercise. The instinct is to run cost reduction as a finance project and compliance as a separate governance project. For AI-era SaaS in a bank, that separation is what creates the risk - because the finance project, acting on cost alone, makes decisions with compliance consequences it cannot see.
The better pattern is a single pass over a complete inventory that scores each tool on both axes at once: what it costs and whether it is used, and what function it supports and what obligations it carries.
A tool that is low-cost but high-criticality is kept and governed, not cut. A tool that is high-cost and governing nothing is an easy saving. A tool that is both wasteful and ungoverned, the duplicate AI-enabled app nobody recorded - is the best find of all, because removing it saves money and removes an obligation in one move.
None of this works without the inventory underneath it, which is the point the whole discipline keeps returning to. You cannot weigh the cost and risk of a tool you have not found, and in a bank the tools you have not found are precisely the ones most likely to be both wasteful and exposed.
What this means in practice
For a bank, the move is not to cut harder or to govern more; it is to stop treating the two as separate exercises. Run one discovery pass that produces a complete inventory. Score each tool on cost-and-usage and on function-and-obligation together. Then make rationalisation decisions that weigh both - keeping the cheap-but-critical, cutting the costly-but-idle, and prioritising the tools that are wasteful and ungoverned at once.
The bank that does this spends less and governs less surface, from a single piece of work. The bank that runs cost reduction on its own, on the cost signal alone, saves some money and occasionally cancels something it needed, and never sees the ungoverned tools that were costing it on both ledgers the whole time.
Frequently asked questions
How can a bank reduce SaaS spend safely?
Montro's position is that a bank should reduce SaaS spend through a single exercise that weighs cost and regulatory risk together, not a finance-only cost-cutting project. The standard tactics - reclaiming unused seats, consolidating overlapping tools, managing renewals - still apply, but in a bank each cut has to be checked against whether the tool supports a regulated function or processes personal data.
Cutting on the cost signal alone risks cancelling something load-bearing for compliance.
Why is cutting SaaS costs riskier for banks than other companies?
Because in a bank a tool's cost and its regulatory role are not correlated. A cheap, low-profile application can sit inside a critical function or process customer data, while an expensive one may govern nothing that matters. A generic cost-cutting playbook optimises for cost and usage alone, so applied blind it can cancel a tool that looked like shelfware to finance but was a documented part of a control to compliance. The savings are real, but they cannot be taken on cost alone.
What is the biggest hidden SaaS cost in a bank?
The ungoverned tool - an application that entered without procurement, including AI features switched on inside existing platforms. It is untracked spend and, at the same time, an unassessed compliance obligation.
This is the most valuable thing to find, because rationalising it recovers licence fees and removes a regulatory exposure in a single move the one place a bank's cost problem and compliance problem are literally the same object.
Should finance and compliance run SaaS reduction separately?
No, for AI-era SaaS in a bank, that separation is the risk. A finance-only project acts on cost alone and makes cuts with compliance consequences it cannot see. The effective pattern is a single pass over a complete inventory, scoring each tool on cost-and-usage and on function-and-obligation at once, so rationalisation decisions weigh both. This is also more efficient: one exercise, two returns - lower spend and a smaller compliance surface.
