Where does money leave the mainframe, and what is running on those systems?
The ledger sits behind the mainframe. Money leaves through Linux: the systems that instruct payments, settle them, and sign them. That is where Churchill stands.
Nobody changes the gateway without two of your people signing.
It does not read or approve payments, and it never sees transaction data. It stops unapproved change to the system that sends them, and stops that system sending anywhere you never approved.
Four systems can move the bank's money.
The wires, the switches, the settlement engines, and the keys that sign it all. Churchill protects all four.
The messaging stack that creates, routes, and releases payment instructions, and the gateway credentials that make them authentic. The system attackers target to inject fraudulent payments.
SWIFT CSP · annual independent assessment
Fedwire, CHIPS, TARGET2, FedNow, RTP. Irreversible money movement with hard deadlines, and for instant rails, no batch window in which to catch fraud. Pre-execution control is the only control.
DORA · NYDFS Part 500
The hosts that hold the sessions, PINs, and logic deciding what the HSM signs. Tampering here means the HSM signs the attacker's transaction with the bank's own key.
Smallest footprint · highest authority
The translation layer where every message is touched, the card switch deciding approve or decline, and the file tier where recent breach headlines live. A modified batch file is thousands of altered transactions at once.
PCI DSS 4.0 · Req. 6 and 11
The HSM signs whatever the application asks. Churchill guarantees the asker. Churchill protects any zero-tolerance Linux workload; we started where tolerance is lowest, on the path money travels. The core ledger, CICS, and z/OS stay the mainframe's job. Each layer does what it does at its layer.
Nine situations you have already lived through.
Every one of these is inside the published threat boundary. Open the ones that matter to you. Each shows the change that actor needs to make, and what happens instead. To do damage, every one of them has to change the protected application. That is the only thing Churchill checks, which is why the actor never has to be identified first.
Config drift
Someone changed a gateway parameter during an incident months ago and never changed it back. The scan that would catch it runs quarterly.
A configuration file the gateway reads while it runs.
The unapproved change never takes effect. It is refused before it applies, and the record names the file, the account, and the second it happened.
Insider change
An administrator with legitimate root access edits a binary on the settlement connector outside the change process.
A binary that is part of the approved application.
Root is not enough. The modified binary does not execute, and no single person can authorize the change: two of your approvers have to sign it.
Ransomware
Malware lands on the host and starts encrypting or replacing the files the application needs.
Its own code, running. Or the files the application depends on, rewritten.
Unapproved code does not run. The application keeps running on the version your approvers sealed, and every attempt is recorded.
Malware
Something lands on the host and runs. It is not encrypting anything, it is establishing a foothold and waiting.
Its own executable, running on a protected host.
It does not run. Only what your approvers sealed executes, so there is no foothold to establish and the attempt is recorded.
Stolen credentials
Valid credentials, valid session. Nothing about the login looks wrong, because nothing about it is wrong.
What the application runs, or where it is allowed to send data.
The credential gets the attacker onto the host and no further. Changing what the application runs still requires two signatures they do not have.
Supply-chain compromise
A vendor update carries something you did not expect, through a channel you already trust.
A package or library the approved snapshot does not cover.
The update runs only if your approvers sealed that exact package. Anything the snapshot does not cover is refused, whatever channel delivered it.
Living off the land
An attacker uses tools already on the host, so nothing new ever appears on disk to detect.
The destination list, so data can leave for somewhere you never approved.
There is no new file to catch, and there does not need to be: the operation is still outside what was approved, and data cannot leave for a destination you never approved.
An AI agent goes rogue
An autonomous agent with production credentials starts acting outside what it was approved to do, faster than any review cycle can respond.
Something outside the approved snapshot, executed or modified.
It is refused at machine speed, with no analyst in the loop, and it cannot approve its own change: that still takes two of your people. The record shows every attempt it made outside what it was approved to do.
Month-end release
A release goes out on a deadline. The audit trail afterward is a ticket comment and somebody’s memory of who said yes.
The running application, which is exactly what governance exists to record.
The release goes out the way it does today. What changes is that approval is a cryptographically signed receipt naming who signed, and the record is the same one your examiner reads.
None of these depend on recognizing the attacker or the technique. They depend on the change being unapproved, which is the one thing every case above has in common.
The zone got bigger this year, and your evidence for the new part is the thinnest you have.
Under CSCF v2026, Control 2.4 moved from advisory to mandatory. That pulls back-office data flows, bridging servers, middleware, and customer connectors formally into scope for the first time, and it requires independent assessment. The stated reason is the pivot pattern you already know: the attackers who took $81 million out of Bangladesh Bank did not stop at the messaging terminal. They moved into the surrounding environment, changed what the payment application ran, and suppressed the confirmations that would have shown it.
Control 2.4, Back Office Data Flow Security, moved from advisory to mandatory this cycle.
Bridging servers, middleware, and customer connectors, formally, for the first time.
Independent assessment, not self-attestation, inside a window that closes 31 December.
Your attestation status is visible to the counterparties who check it.
Control 2.4 is a data-flow control. What it changed for you is scope:
those bridging servers, connectors and middleware are now in-scope Linux
hosts. Churchill protects the integrity of those hosts and produces a
dated record of what ran and every attempt to change it, which evidences
the change-control and integrity families rather than 2.4 itself. Do not
let anyone write 2.4 next to it in a remediation plan. That is the record
Churchill writes as it happens, rather than one your team reconstructs
from ticket exports in the autumn. Churchill supports specific technical
provisions within CSCF. It does not itself confer attestation, and it
does not cover the controls your program owns. Provision mappings are
WestGate Data Science analysis.
The full provision-level mapping →
Start where your annual attestation is hardest. Extend along the path money travels.
You think in zones, and so does Churchill. The first deployment is the smallest critical zone you have; each expansion follows the authority, on a deployment pattern your operations team has already seen hold.
Churchill supports control families in SWIFT CSP, DORA, NYDFS Part 500, and PCI DSS 4.0; it does not itself confer any attestation or compliance. Platform fit for a specific workload is confirmed during technical qualification.
Every feed you buy describes someone else's breach. This one describes yours.
The gate sees every attempt on a protected payment host, so the record it writes is intelligence about your own rails, from your own attackers, on the day it happens. It arrives without a production incident attached to it.
Attempts sorted by host and hour show whether the pressure is on the wire connector, the settlement broker, or the signing host. You staff and harden where it actually is.
The same kinds of attempts at the same times across separate payment hosts is one campaign, and you have the records to show it.
A hash-chained record of an attempt that never reached production, held in dual custody, with the session replayable. Evidence without an incident.
Refused hotfixes on one gateway are not an attacker. They are a change process that needs fixing, with accounts and timestamps attached.
What a record contains, and what it is worth across a fleet →
Setup follows your governance. Then Churchill refuses, autonomously.
Controlled deployment
Churchill installs on the protected hosts through a controlled download, in minutes. No pipeline changes, no modifications to your build infrastructure.
Your governance, encoded
Designate the approver pool from your Change Advisory Board: as many members as you choose, minimum two to approve, any single member can veto. The keys stay with your people.
The quorum seals the application
The approved version is captured as a cryptographically signed snapshot: executables, configurations, libraries, scripts, secrets. From that moment, only the sealed state runs; everything else is refused at the kernel in under 2 ms and preserved as forensic evidence.
Between releases there is nothing to manage: no ticket queue, no daily review burden, no added FTEs. At release time, a minimum of two members of the quorum you designed sign the change, in seconds, at 2 a.m. or 5 p.m., and a single veto denies. Nothing else about your release process changes.
Prove it on the zone your board already fears by name.
30 days free in non-production. Installs in minutes, removes cleanly. Production follows a joint engineering session, our team and yours.