Inside SWIFT's plan to modernize thousands of Ansible Playbooks — and govern automation at scale

At Red Hat Summit 2026, SWIFT shared the approach they’re rolling out — including the pilot results that informed it, and the scale they’re targeting next. Imagine running automation that touches roughly one third of global GDP every day. Tens of thousands of VMs, network devices in production, elevated privileges across production systems — and every playbook you run is, effectively, a software supply chain. That is the everyday reality at SWIFT, the secure financial messaging backbone connecting 11,000+ financial institutions across more than 200 countries.

At Red Hat Summit 2026, Suvasish Ghosh, Product Owner for CI/CD Engineering and DevOps Engineering Services at SWIFT, joined Gregor Berginc, CEO of XLAB Steampunk, on stage to talk about how SWIFT is using Steampunk Spotter to govern Ansible automation at this scale.

Why automation at SWIFT scale needs governance by design

For SWIFT, security, availability and auditability are not features added on top — they are baseline engineering requirements. Regulatory frameworks (including DORA) codify the expectations, but as Suvasish made clear on stage, governance is by design at SWIFT, not driven solely by regulation.

That stance reflects a simple truth that more and more platform teams are arriving at: automation is production infrastructure, and it must be governed as such. When you run an Ansible playbook, you are executing a software supply chain — collections, modules, roles, Python packages, system packages, the execution environment, the operating system underneath. The playbook itself is just the tip of the iceberg. Errors propagate fast. The blast radius is large.

And yet, until recently, most of the security and compliance attention in IT organizations went to the applications shipping to production. The automation that built and configured everything around them often slipped through.

Suvasish put it directly during the session:

“We spent a lot of time being compliant and secure in our application, but we often don’t pay too much attention to what’s coming into our development environment via Ansible collections and through badly written Ansible scripts. That’s where we started looking at Steampunk Spotter.” - Suvasish Ghosh, Product Owner for CI/CD Engineering and DevOps Engineering Services at SWIFT

Use case 1: A 2.9 → 2.16 modernization that doesn’t break the bank — or the calendar

The first proof point SWIFT shared is the kind of project every Ansible team eventually faces: a major version migration. The catch is scale.

SWIFT’s pilot benchmark put the cost of doing it manually in plain terms: 100 playbooks would take roughly 100 hours of engineering time to modernize from Ansible 2.9 to 2.16. Across their full estate of ~2,000 playbooks, the manual path was clearly not viable.

The expensive part, it turned out, was not the fix itself. The fix is usually the simplest step. The expensive parts were:

• Identifying which changes were actually needed
• Finding the correct solution from a sprawling and evolving knowledge base
• Validating that the fix was correct before anyone signed off on it

This is exactly what Spotter automates. Spotter identifies required changes automatically, looks up the right solution, validates the fix before flagging it, and auto-rewrites the playbook in the majority of cases. Engineers review and approve — they don’t rebuild from scratch.

Based on comparable project the projected outcomes are:

• ~2,000 playbooks targeted
• 75–85% auto-fix rate by Spotter
• ~6,500 engineering hours to be saved
• 3-month target for full migration

A controlled, auditable change at scale — without pulling every team in the company into a multi-quarter modernization project.

Use case 2 & 3: From one-off project to permanent guardrail

The migration win is one story. The more interesting part for any platform team is what happenes after.

Spotter is being embedded into two further parts of SWIFT’s automation lifecycle:

Assessing third-party Ansible collections before internal distribution. The goal here is to unlock safe use of community Ansible collections. Spotter generates risk-based reports on Galaxy content — collections like community.mongodb or containers.podman — so SWIFT can approve high-value collections with confidence, demonstrate compliance to internal auditors, and expand their automation footprint without growing the attack surface.

Standardizing and securing internal Ansible usage. Every developer playbook gets scanned by Spotter before it reaches production — continuously, across every repo. The aim is real-time, auditable oversight: vulnerabilities, misconfigurations and standards violations caught proactively, without relying on manual spot-checks. The same security checks, the same policy engine, the same SBOM and vulnerability analysis. Playbooks stay aligned with evolving best practices and Ansible releases.

Feedback loops close the system: blocks and findings flow into Jira and ServiceNow, security signals into SIEM tooling like Splunk or QRadar. Compliance reports map directly to FFIEC, PCI-DSS and SOC 2.

The four pillars of SWIFT’s governance approach

If you take one framework away from the session, take this one. SWIFT’s approach to automation governance rests on four pillars — and they are reusable far beyond financial services:

1. Visibility. Know what is actually executed, dependencies included. Remove the blind spots.
2. Consistency. Same rules for all teams. No special cases. No tribal knowledge.
3. Policy as code. Human memory does not scale. Expectations must be machine-readable, and policies have to evolve with the platform.
4. Feedback loops. Early, automated signals in developer context — before production, not after.

Governance, framed this way, is not the opposite of velocity. It is what makes velocity safe.

What this means for your automation

A few honest takeaways from the SWIFT story that apply whether you run 50 playbooks or 5,000:

• Automation is production infrastructure — govern it as such.
• Modernization at scale is a controlled, auditable change — not a heroic effort.
• Supply-chain assessment is non-negotiable for third-party Ansible content.
• Standardization and qualification enable safe reuse at scale.
• Spotter enables safe velocity by strengthening automation governance, not slowing it down.

If you are staring at your own version of “2,000 playbooks, three months from now” — or just noticing that the Ansible content in your development environment is getting less attention than the apps it deploys — there is a faster way to find out where you stand.

Get a free Spotter script assessment

Curious how Spotter would find in your Ansible or Terraform scripts? Book a free script assessment and our team will scan your playbooks for security risks, compliance gaps and modernization opportunities — and walk you through what we find.

👉 Reserve your free script assessment