01
Cost & Usage Report ingestion
CUR files land directly in the bank's environment from each cloud account, on the provider's native cadence. No third-party data hop, no vendor sitting between the bank and its own billing data.
Banking · Baltics
A Baltic bank builds its own FinOps platform
instead of buying one
A bank-owned cloud-cost platform that runs on the bank's own infrastructure,
built in-house rather than subscribing to a commercial FinOps SaaS whose fee scales with the cloud bill.
0
recurring vendor fee
100%
cost data in-house
8–10
weeks to deploy
3+
clouds unified
Fee avoided
No recurring, percentage-of-cloud-spend SaaS fee ever enters the budget. Cost avoidance from day one.
Dashboards owned
The multi-cloud cost view engineering and finance need, running on data the bank owns end to end.
Platform owned
Multi-cloud ingestion, normalisation, and dashboards now run inside the bank, end-to-end.
The challenge
A cost tool that gets pricier as you grow.
The bank needed one cost view across more than one cloud. The commercial FinOps tools that could do it priced their fee as a percentage of the cloud bill, so the cost of watching the cloud spend would climb in lockstep with the cloud spend itself. Paying a growing, recurring fee for a capability the bank could own and run itself did not add up.
- Pricing tied to cloud spend, not value. A commercial SaaS fee would scale automatically as the cloud bill grew, year after year.
- A recurring fee for a stable capability. Ingest, normalise, visualise: the core FinOps job is well understood and does not need a vendor's ongoing roadmap to keep working.
- No single cloud's tools could cover it. Each provider's native tooling sees only its own platform. The bank runs on more than one, and unifying cost across providers was the capability it needed.
Why the cost model stopped making sense - illustrative
Schematic, not the bank's figures. The SaaS fee grows as a fraction of a rising cloud bill;
the owned platform's run cost grows only with the data it processes.
The solution
Rebuild the part the bank actually uses.
A custom platform that ingests Cost & Usage Reports from the bank's own cloud accounts, normalises across providers, and powers the dashboards the organisation depends on - on data the bank owns end-to-end.
02
Multi-cloud normalisation
A single internal cost model unifies AWS, Azure, and the bank's other providers into one coherent view - purpose-built for the bank's topology, not a generic vendor schema retrofitted to fit.
03
Dashboards on bank-owned data
Full drill-down to source records. No rate limits, no usage tier, no dashboard a vendor can decide to deprecate. The exact cost view engineering and finance need, running on data the bank owns.
Governance & compliance
Held to the bank's own bar.
Regulators don't mandate a commercial vendor - they mandate auditability, change management, and a defensible architecture. The platform was built to exactly the bar of any other internal application, not a lower one because it was small.
Runs entirely on the bank's infrastructure
No CUR data, no normalised cost data, no dashboard data, and no audit log leaves the bank's environment. It does the work of a commercial SaaS without becoming a dependency of its own.
Bank-grade corporate pipeline
Built and deployed through the same CI/CD path as the bank's own internal applications - mandated stages, security review, architecture review board, requirements traceability, change management.
Version-controlled architecture
Every architectural decision is recorded in a dated, reviewable artefact. A change that contradicts the document is a change to the document first.
Results
Owned end to end, at no recurring fee.
- No recurring vendor fee, ever. Instead of paying a percentage of its cloud bill every year, the bank pays only to run the platform on its own infrastructure: a cost that grows with data processed, not with the size of the cloud bill.
- Ingestion, normalisation, and dashboards run inside the bank. No external data hop, no third-party SaaS layer, no recurring licence.
- Same enterprise process as the bank's internal apps. Built and deployed through the bank's CI/CD pipeline, architecture document written, requirements verified, security review passed.
- Future capabilities plug into the same platform. AI-powered optimisation, drift monitoring, and internal cost-governance extend the live platform on the bank's timeline - no vendor release calendar, no renegotiation.
The takeaway
The criteria for building instead of buying: a recurring fee that scales with something other than value, a capability well understood enough to own, and a governance bar the build can meet. This is the governed foundation every AI capability on the platform builds on next.
Questions
Why not just use the cloud provider's native cost tools?
For a single cloud, native tools are often enough. For a multi-cloud bank, the gap is normalisation - translating each provider's Cost & Usage Reports into one coherent view. The in-house platform delivers that on the bank's own infrastructure, purpose-built for its topology.
What happens when cloud spend grows? Doesn't the platform need to scale with it?
The platform's run cost scales with the bank's own infrastructure cost - not with a vendor's percentage. As cloud spend grows, marginal cost grows linearly with data processed, not as a fraction of the cloud bill. The structural mismatch that would have made a SaaS expensive at scale never applies.
Do regulators accept a custom-built FinOps platform?
Regulators mandate auditability, change management, and a defensible architecture - not a specific vendor. Every architectural decision is recorded in a version-controlled document, every security exception is filed and time-bound, and CI/CD records every deployment. It meets the same bar as any other internal application.
How long does it take to deploy a self-built FinOps platform?
Eight to ten weeks for comparable scope: one bank, multi-cloud CUR ingestion, normalisation, and the dashboards the organisation depends on.
Why is the timeline so short compared to a commercial deployment?
We aren't rebuilding a decade of vendor feature accretion - only the part the bank actually uses, and nothing else.