> This can not be borne in a mainframe environment.
I mean, maybe not in an old-school 1970s batch-SIMD mainframe environment with limited storage memory.
But in a modern mainframe environment, where
1. every tenant being processed is hitting their own virtualized environment locked into their own legacy versions of everything (think: separately-SCMed "Enterprise" deployments of SaaS software — just all living together on one machine cluster rather than on-prem per customer); and
2. you've got the spare storage capacity to do everything via async-queued CQRS/ES + writing secondary representations and cubes to a local data lake, rather than ever updating anything in place...
...then why not do "agile" blue-green deploys of your ACH reconciliation logic, starting with the smallest tenants first?
If you ever produce a bug in such an environment, you can always just: stop the job; emit tombstone records for all the CQRS Commands it produced so they'll be ignored on "outbox processing" rather than pushed to consumers; fix the bug; up the version number for OLAP report generation, invalidating + requiring recomputation for any reports produced from the data in the reporting period; and then start the job up again. No external system will ever have to know, because your own system should be set up such that no other external system is synchronously dependent on its outputs. (This is half the reason things like ACH are designed with the async "flex" they have.)
And, in fact, assuming you've got the spare CPU power (which you do), you can even run entire reporting / integration cycles twice — once under the old logic, once under the new logic — and examine the resulting queued commands + reports to see that they all come out the same, before allowing anything to go through. You can do this not just in production, but experimentally, against a corpus of all old input data for each tenant (which you've almost certainly kept around.) And, as such, you don't even have to stick with those virtualized legacy environments that mainframe architectures like z/OS were designed to enable — you can actively migrate clients away from them (even automatically, with CI/CD-triggered graduated rollouts et al) as soon as you can prove that their workloads (both present and historical!) won't be affected by the change. Each tenant can be re-pinned over time to the newest release that can be proven to be equivalent to the original release provided to them on all known data.
One of the key insights about mainframe programming, is that the software architectures of the kinds of systems deployed on mainframes, are designed to be resilient against individual bugs; or, one might say, against individual programmers who don't know what they're doing. Systems engineering in e.g. finance, is to bad individual-component / individual-release logic, as NASA's Mars-rover systems engineering is to bad hardware: designed under the assumption of the potential for failure, and designed with built-in remediation strategies for that failure.