The Platform Business Case Banks Can Prove

Juliano Marcos Martins makes a point in his recent platformengineering.org piece that every engineering leader should take into their next budget meeting. A platform decision isn't a technical decision. It's a capital allocation decision, and you're already making it by default.

You already have a platform. It's the Terraform project somebody copied from another team, the Slack channel where people ask for environments, the security checklist in a spreadsheet, and the approval process that lives in one person's head. As Martins puts it, it has costs, owners, downtime and debt. "What it doesn't have is a budget line."

He then splits the return into two buckets for the CFO. Direct infrastructure savings are smaller but easy to defend with outside data. Recovered engineering capacity is bigger but softer, and best argued from your own tickets and hours.

That's the right structure. In financial services it's missing a third bucket, and it's the one we'd put first.

Every regulated engineering org carries audit overhead: the hours spent proving that changes were controlled. Change records assembled by hand. Approval screenshots pasted into audit packets. Access reviews reconciled in spreadsheets. Sample requests from internal audit that pull a senior engineer off real work for two days. None of it ships software, and all of it is mandatory. Unlike recovered capacity, it's work your second line and internal audit already know about, because they're the ones asking for it.

Recovered capacity is the line a CFO discounts

Here's how the capacity argument usually goes. Engineering says the platform frees up 15% of developer time. Finance asks whether that means fewer engineers. Engineering says no, it means more features. Finance nods and mentally moves the number from "savings" to "aspiration."

That isn't cynicism. Capacity you redeploy doesn't show up anywhere a CFO can check it. The work changes, the payroll doesn't, and nobody can point to a line that went down.

Audit overhead behaves differently, for three reasons.

It's fixed by obligation. You can't decide to do less change management evidence next quarter. SOX change controls, PCI requirements and your own policies set the floor, and the work comes back every audit cycle.

It has owners outside engineering. Your second line knows which controls generate findings. Internal audit knows how many sample requests it sent and how long they took to close. You're not asking finance to trust an engineering estimate; you're quoting the people whose job is to be skeptical.

It goes away cleanly. When a pipeline records the approval, the test results, the deployed artifact and the rollback path as a byproduct of shipping, nobody has to rebuild that record later. The hours stop, and so do the findings that come from records that were incomplete in the first place.

The new-hire test, run in a bank

Martins offers a good warning-sign test: measure how long it takes a newly hired developer to push a trivial change to production, securely and auditably. If the answer is weeks, or nobody knows, you have a hidden cost.

Run that test inside a bank and look at where the time goes. It's rarely the tooling. It's the access request that waits on a manager, then an application owner, then an entitlement review. It's the change record that needs a CAB slot. The developer spends an afternoon on the change and two weeks waiting for permission to make it.

So add a second test next to his. Pick a production change from 90 days ago. Ask your team to show who approved it, what tested it, exactly what was deployed and how they'd roll it back. Time how long that takes. If the answer involves three people, a ticketing system, a shared drive and somebody's memory, you've just measured audit overhead on one change. Multiply by your change volume.

Agents multiply audit overhead

Martins' sharpest point is that the committee that fast-tracked GenAI and deferred the platform made one mistake, not two good decisions. It treated them as independent. He cites Puppet's 2026 platform engineering research: 79% of organizations with mature platforms report mature governance, against 14% of those without.

In a regulated shop, that gap shows up as arithmetic. Every action an agent takes against a real system is a change. It needs the same record a human change needs: who authorized it, what it was allowed to touch, what checked it, and how to undo it. Your change management policy doesn't have an exception for software acting on someone's behalf.

So if evidence is produced by hand, agent throughput doesn't reduce audit overhead. It multiplies it. You end up in one of two places. Either every agent run stops at a person who assembles the paperwork, and your cadence drops back to the speed of your slowest approval loop, or the paperwork quietly stops getting assembled. The second one has a name. We call it the unowned change: an agent made a change and nobody can say which agent, on whose authority, with what permissions, or how to reverse it.

The platform is what breaks that trade-off. When identity, policy and evidence live in the path to production, an agent's change carries its own record the same way a developer's does. That's the difference between an agent pilot your second line can approve and one it shuts down after the first audit sample.

You can buy the governance layer, but not the control mapping

On build versus buy, Martins proposes a third option: buy the governance layer, keep your existing repos, pipelines, Terraform and observability. For a lot of organizations that's sensible, and we'd rather see a team buy governance than spend two years hand-building a portal.

In financial services, add one caveat. A governance product gives you the place to enforce policy. It doesn't give you the policy. Which approvals satisfy your SOX change controls, which environments are in PCI scope, what your second line accepts as segregation of duties: that mapping is specific to your institution, and it has to be written with the people who'll defend it to an examiner. Budget for that work explicitly. It's usually where audit overhead actually comes down.

Build the case in confidence order

Martins is right that the case should rest on your own data rather than a vendor benchmark. Here's how we'd assemble it for a bank or a fintech with real regulatory exposure.

1. Count one quarter of audit overhead. Sit down with your second line and internal audit. Total the hours spent on change records, CAB preparation, audit sample requests, access reviews and finding remediation. Note which controls produced findings, because those are where the platform pays back first.
2. Run the 90-day change test on ten random production changes. Record how long each takes to reconstruct and how many people it needs. That turns audit overhead from a complaint into a number.
3. Run the new-hire test and split the result. Separate time spent on tooling from time spent waiting on access and approvals. In most banks the second number is the bigger one, and it's the one a platform with pre-approved paths removes.
4. Present the three returns in order of how hard they are to argue with. Audit overhead first, because it's internal, recurring and owned by skeptics. Infrastructure savings second, because external data backs them (see our take on how a platform cuts cloud waste). Recovered capacity last, framed as shorter lead time for changes rather than a headcount number nobody will believe.
5. Pilot where the evidence is worst. Pick the service whose changes generate the most audit pain and build one golden path for it with policy as code and evidence captured in the pipeline. Then measure the same service through one audit cycle.

That last step is what makes the case self-proving. You aren't asking for a multi-year platform budget on faith. You're asking for one path, measured against a baseline your auditors helped set. We've seen that pattern work at a bank that moved to pre-approved infrastructure templates and shared golden paths: standardized modules codified the security and operational standards once, so developers picked a size, supplied their workload inputs, and stayed on a compliant path without rebuilding it per database.

Where this argument doesn't hold

If you're a fintech with light regulatory exposure and no internal audit function yet, audit overhead is small and this post's ordering doesn't apply. Lead with Martins' two buckets. The same goes for a platform team whose changes are mostly in non-production tooling: there's no examiner on the other end, so there's nothing to prove.

And don't count evidence hours you'd still spend. A platform removes the work of reconstructing records. It doesn't remove your second line's review of them, and a business case that claims it does will lose credibility with exactly the people you need on your side.

Start with one number

Before the next budget conversation, get the hours your team spent last quarter proving changes were controlled. If nobody can produce that figure, that's your first finding. If you want to see where your platform stands before you build the case, the Platform Engineering Maturity Assessment will show you. Or talk to us about piloting one golden path against your worst audit pain.