SWIFT Turns Container Security Alert Fatigue Into a Data-Flow Problem

Swift, the cooperative that carries payment instructions between more than 11,500 financial institutions in over 200 countries, does not move money. It moves messages: the instructions that tell one bank to pay another. Keeping that messaging layer secure means running a container platform at a scale most enterprises never approach, millions of container images spread across multiple data centers and hundreds of Kubernetes clusters. At Red Hat Summit 2026, two Swift engineers and a Red Hat solutions architect described, in a Red Hat blog post recapping the session, how they redesigned that platform’s security architecture to solve two problems at once: network congestion from constant polling, and the alert fatigue that was burying developers under false positives.

What Swift Actually Carries

Swift (originally an acronym for the Society for Worldwide Interbank Financial Telecommunication) is a messaging network, not a bank and not a payment processor. It does not hold funds, manage accounts, or clear transactions. What it does is carry the “messages containing the payment instructions between financial institutions involved in a transaction,” while the actual movement of funds happens afterward through separate settlement systems. That distinction matters here because it explains the stakes: if Swift’s own infrastructure is compromised, the exposure isn’t a single bank’s ledger, it’s the instruction layer that thousands of banks rely on to trust each other’s payment requests.

Otmane Benali, Swift’s Container Platform Product Owner, framed the scale bluntly in the Red Hat writeup: “Every 3 days, the equivalent of the world’s GDP passes through the Swift network. That indicates the scale of the economies and supply chains that count on this transaction service, making availability and security our highest priorities.” He and Senior Platform Architect Praveen Siddu presented the work alongside Red Hat Senior Solutions Architect Ryan Riley.

The Problem: A Central Database That Couldn’t Keep Up

Before the redesign, Swift’s container vulnerability scanning followed the pattern most organizations start with: a central database that continuously polled every cluster, asking each one to report back on the state of its running images. According to the team’s own account, that pull-based model created excessive network congestion and operational complexity at Swift’s scale. Red Hat’s writeup doesn’t spell out exactly what made the resulting alerts fatiguing, but the fix it describes is telling: the rebuilt pipeline enriches every finding with ownership data pulled from Git, tying an alert to the specific repository responsible for it. That kind of context is exactly what a pure polling pipeline tends to lack, alerts with no clear owner and no clear priority are the classic recipe for alert fatigue, where real signals get lost in noise until people start ignoring the queue altogether.

The Fix: Reversing Who Talks to Whom

The team’s redesign is built around Red Hat Advanced Cluster Security for Kubernetes (RHACS), but the change that mattered wasn’t the tool, it was the direction data flows through it. Instead of a central system reaching out to ask every cluster for status, local agents inside each Red Hat OpenShift environment now gather their own container image data and push it to a central object store.

One Scanner, Enriched With Ownership Data

A single central RHACS instance matches the incoming image data against known vulnerabilities, then enriches each finding with ownership information pulled from Git. That last step is what turns a raw CVE list into something a developer can act on: instead of a generic alert, a team sees a finding tied to the specific repository and, implicitly, the specific people responsible for it.

Testing Policy Changes Before They Reach Production

New security policies don’t go straight to every cluster. They first run against sandboxed test workloads that are deliberately built to trigger specific violations, a form of regression testing for security rules. That catches policies that are too aggressive (or too loose) before they start generating bad alerts, or worse, blocking legitimate deployments, at production scale.

Zero-Touch Certificates

The last piece is certificate management, historically one of the more manual and error-prone parts of running security tooling across hundreds of clusters. Swift automated it with Argo CD handling GitOps-style deployment and HashiCorp Vault managing the certificates themselves, combined with daily automated image scans so nothing depends on someone remembering to rotate a credential or kick off a scan by hand.

Why the Direction of the Data Flow Matters

The architectural detail worth paying attention to here isn’t the specific vendor tooling, it’s the shape of the fix. A pull-based system ties the health of your security posture to the availability and responsiveness of every single cluster it has to reach; if a cluster goes away or a network path gets congested, the central system’s picture of the world degrades. A push-based system inverts that dependency: each cluster is responsible for reporting its own state, and the center’s job shrinks to collecting and correlating what arrives. Red Hat’s account of the redesign notes a direct consequence of that inversion: if a cluster is deleted, the central state simply rebuilds itself rather than leaving behind stale records that need manual cleanup. That’s a resilience property that falls out of the architecture, not something bolted on afterward.

Combined with Git-based ownership enrichment, the same architectural change addresses both of Swift’s original complaints. Less polling traffic solves the network congestion. Better-targeted, pre-tested alerts solve the fatigue. Neither fix required inventing new scanning technology, both came from rethinking who initiates the conversation.

What a Vendor Case Study Doesn’t Tell You

This account comes from a Red Hat Summit session and a Red Hat-published blog post, not an independently audited report, and it’s worth reading with that in mind. Swift and Red Hat describe the outcome in qualitative terms, reduced manual security tracking, reduced unnecessary alerts, faster developer velocity, but the public writeup doesn’t include hard before-and-after numbers: no specific percentage reduction in alert volume, no measured change in time-to-remediate, no count of false positives eliminated. For an organization that won’t disclose exactly how a payment-messaging network is defended in detail, that’s an understandable limit, but it also means the “solved alert fatigue” framing should be read as Swift’s own characterization rather than a verified benchmark.

What is independently verifiable is the shape of the architecture itself, and that’s the part that generalizes. Any team running container security scanning across more than a handful of clusters is likely to hit some version of the same problem: a central system that can’t scale its questions faster than the environment grows. Swapping who does the asking is a pattern worth knowing about long before you’re operating at Swift’s scale.