How banks protect core banking data on IBM Z with tokenization, pervasive encryption, and agentless deployment, without modifying COBOL.
Mainframe security for banking protects the data flowing through IBM Z systems, which nearly all of the world's top 100 banks depend on for core operations.
Mainframes support the vast majority of global card‑transaction volume, including a still large portion of credit‑card transactions.
The most critical threats, however, aren’t external breaches, but actually cleartext data exposure in DB2 databases and TN3270 terminal sessions, privileged access abuse through over-entitled Resource Access Control Facility (RACF) accounts, and invisible Customer Information Control System (CICS) transaction blind spots that enterprise monitoring platforms cannot detect.
Banks that lead in mainframe security combine pervasive encryption and agentless tokenization to protect data at every point it is stored, accessed, and replicated, all without modifying legacy code or consuming additional mainframe processing capacity.
Mainframe security for banking is not a subset of general enterprise security. It is a distinct discipline built on a fundamentally different platform, threat model, and regulatory landscape than anything in the distributed or cloud world.
IBM Z and z/OS are purpose-built for high-volume, low-latency transactional workloads.
As a result, security controls must integrate with platform-native constructs – i.e., RACF, Access Control Facility 2 (ACF2), Top Secret (TSS), the System Authorization Facility (SAF), and System Management Facilities (SMF) records – without destabilizing the COBOL, PL/I, and Java applications that power daily banking operations.
The critical distinction: banking mainframes process regulated financial data – i.e., Primary Account Numbers (PANs), account balances, personally identifiable information (PII) – under multiple overlapping compliance regimes simultaneously.
Likewise, Payment Card Industry Data Security Standard (PCI DSS), Sarbanes-Oxley Act (SOX), Federal Financial Institutions Examination Council (FFIEC) guidance, and General Data Protection Regulation (GDPR) all impose requirements on the same data flowing via the same systems.
This is why mainframe security for banking demands a hierarchy:
Access controls protect the perimeter. Tokenization and encryption protect the data itself, so that even when perimeter controls fail, the exposed information is useless to attackers.
(See our guide for a deeper look at how mainframe security software works across enterprise environments.)
Banks are not holding onto mainframes due to inertia; rather, they are investing in IBM Z because no alternative platform matches the combination of transaction throughput, reliability, and hardware-rooted security that core banking demands.
Many large enterprises still operate mainframes, with financial services representing the largest concentration.
IBM reports that mainframes process over 30 billion transactions per day, with approximately 70% of all financial transactions touching IBM Z infrastructure at some point in the processing chain (IBM/theCUBE).
75% or more of the more than 2,500 global IT executives surveyed by the IBM Institute for Business Value rate mainframes as equal to or better than cloud computing in total cost of ownership. More than 70% of banking corporate data still resides on the mainframe.
The question for banking CISOs is not whether to keep the mainframe. It is about securing the data on it while connecting it to everything else.
Banking mainframes face a distinct threat landscape compared to distributed environments.
The high value of the data they process – e.g., account balances, PANs, transaction histories – combined with the unique characteristics of the IBM Z platform, creates attack surfaces that general-purpose security tools do not address.
The average cost of a data breach now stands at $4.88 million, according to IBM's 2024 Cost of a Data Breach Report. Financial services firms face costs above this average.
RACF administrators and system programmers hold root-level access to mainframe datasets, transaction definitions, and security configurations.
A rogue or compromised admin can modify transaction records, disable audit logging, or access customer financial data across every application on the system.
Operational reality: most mainframe audit findings are less about sophisticated external attacks and more about over-entitlement, shared service accounts, and "temporary" elevated access that becomes permanent.
CICS processes millions of real-time banking transactions – e.g., fund transfers, balance inquiries, card authorizations – but requires mainframe-specific collectors/parsers and normalization (often via SMF pipelines).
Fraudulent card authorizations and unauthorized fund transfers can pass through CICS without triggering a single alert in your enterprise security operations center.
This is the leading threat to mainframe security. Sensitive information – e.g., PANs, Social Security numbers, account balances – is frequently stored in cleartext in DB2 tables, Virtual Storage Access Method (VSAM) files, batch job outputs, and TN3270 terminal sessions.
TN3270 streams data directly to user screens using a protocol designed decades before modern data loss prevention existed. DB2 databases often store customer records without field-level encryption or tokenization.
When this data replicates to downstream systems for analytics or fraud detection, it crosses trust boundaries in cleartext.
A financial services organization addressed this by deploying agentless dynamic masking on TN3270 sessions and tokenization on DB2 replication flows, eliminating cleartext exposure without modifying a single line of legacy code.
Attackers are collecting encrypted banking data today and storing it for future decryption when quantum computers can break current cryptographic algorithms. Credit card data has a 3–5 year value window. Mortgage data has a lifespan of 15–30 years.
Production data cloned to User Acceptance Testing (UAT), quality assurance (QA), and training environments represents a major unaddressed banking threat.
These environments carry broader access permissions, fewer patches, and less monitoring, but they contain the same real customer data as production.
Banks run continuous release cycles for mobile banking, core system upgrades, and regulatory reporting changes. Every UAT environment is a copy of production with real PANs and PII.
A global financial services organization with banking operations across 11 countries discovered that its previous test data management solution routinely broke downstream systems when it randomized data without preserving format dependencies.
Effective mainframe security for banking is not a single product. It is a layered architecture where each control addresses a specific threat, and the most important layer is the one closest to the data.
Note the table order. Data-centric protection sits at the top because it is the last line of defence. If access controls fail, if encryption keys are compromised, but if a malicious insider bypasses monitoring, tokenized data remains useless to the attacker.
For a detailed comparison of mainframe security tools, see our companion guide.
Banking compliance is not a single mandate; rather, it is a stack of overlapping requirements that all converge on the same mainframe data.
Your CISO must demonstrate that the same DB2 table meets PCI DSS, SOX, FFIEC, GDPR, and potentially the Digital Operational Resilience Act (DORA) simultaneously.
SOX compliance expenses range from $181,300 for smaller institutions to over $2 million for large banks (Protiviti). These costs are driven largely by the manual effort required to produce audit evidence from mainframe environments.
Operational reality: a simple auditor request can trigger weeks of mainframe team effort when data is spread across DB2 tables, VSAM files, batch outputs, and non-production copies.
Automated data discovery and classification tools that maintain a continuous inventory of sensitive data convert this from a fire drill into a standing report.
The central tension in banking mainframe modernization is that the systems you most need to secure are the ones you least afford to disrupt. Ripping out and replacing infrastructure that processes trillions in daily transactions is not viable.
Banks are refactoring COBOL alongside Java rather than replacing it.
Atruvia AG, which supports over 800 cooperative banks in Germany with nearly 100 billion annual transactions running on IBM Z, modernized 85% of core banking transactions by writing RESTful services in Java alongside existing COBOL, improving workload performance 3X without a platform migration.
The 2025 BMC Mainframe Survey found that among financial services organizations prioritizing cloud technologies, nearly half (47%) are connecting the mainframe to cloud-based workloads.
Banks are not choosing between mainframes and the cloud; instead, they are connecting both through API gateways and modern integration patterns.
The security challenge: every connection point between mainframe and cloud is a trust boundary crossing. Data protected within the z/OS perimeter must remain protected as it flows to analytics platforms, SaaS applications, and mobile banking APIs.
See our guide on mainframe-to-cloud data pipeline security for additional guidance on migrating or connecting mainframe data to other environments.
This is where the conventional approach breaks down – and where banks most need a different model. Most mainframe security tools require installing software agents directly on z/OS.
For a production banking mainframe carrying $10.4 trillion in annual card transactions, this introduces three unacceptable risks:
A financial services organization solved this by implementing DataStealth's agentless platform to secure IBM DB2 databases and TN3270 terminal sessions without installing a single agent on the mainframe. The results:
This works because protection occurs in network traffic, not on the mainframe itself.
The mainframe continues processing transactions exactly as before. The platform operates inline, communicating with the mainframe using its native protocols, i.e., no agents, no code changes, no performance impact.
Treat every mainframe session as untrusted.
Apply least-privilege access through RACF or your External Security Manager (ESM), require multi-factor authentication (MFA) for all privileged accounts, and continuously verify every access request.
Zero trust on the mainframe means microsegmenting Logical Partition (LPAR) workloads and eliminating shared service accounts that bypass individual accountability.
Stop treating the mainframe as a security island.
Feed SMF records, RACF events, CICS transaction logs, and DB2 access logs into your enterprise SIEM. Your security operations center needs visibility into the same platform that processes your most valuable data.
Products like Precisely Ironstream and BMC AMI Security provide the mainframe-to-SIEM connectors.
Do not rely on encryption alone. Encryption is reversible; if keys are compromised, data is exposed.
Tokenization replaces PANs, account numbers, and PII with irreversible tokens that have no mathematical relationship to the original values. Even if your cloud analytics environment is breached, tokenized data is useless to attackers.
Format-preserving tokens pass legacy business logic rules (Luhn checks, field-length validation), ensuring existing COBOL workflows continue without modification.
Mainframe systems that store only tokens can significantly reduce PCI scope, dramatically reducing your audit surface.
Manual audit preparation consumes weeks of mainframe team effort every cycle.
Deploy automated data discovery and data classification tools that maintain a continuous inventory of sensitive data across DB2 tables, VSAM files, and batch outputs.
This converts SOX, PCI DSS, and FFIEC audit evidence from a periodic fire drill into a continuous compliance posture.
Your UAT and QA environments contain the same customer data as production, but with broader access, fewer patches, and less monitoring. This is a recognized breach vector that most banking mainframe security programs underaddress.
A global financial services organization replaced a legacy test data management solution that routinely broke downstream systems by randomizing data without accounting for format dependencies.
DataStealth's platform preserved referential integrity, geographic accuracy, and downstream functional behaviour while removing real PII from every non-production environment.
The solution automatically adapted to production schema changes without manual intervention, eliminating the fragile per-team workarounds that had consumed engineering resources.
Each banking operation has different data sensitivity, regulatory exposure, and access patterns. A comprehensive approach applies the right protection based on context, not a one-size-fits-all policy.
Banking mainframes are under simultaneous pressure from regulatory changes, evolving threats, and modernization demands.
Data-centric protection – i.e., tokenization and dynamic masking deployed without agents – addresses all three at once. It neutralizes cleartext exposure, reduces PCI and SOX audit scope, and enables secure hybrid cloud integration without touching legacy code.
See how a financial services organization secured its legacy mainframe data without agents or code changes. Or see how a global insurer protects non-production environments across 11 countries without breaking downstream systems.
Schedule a demo to see how DataStealth protects mainframe data across banking environments.
Lindsay Kleuskens is a data security specialist helping enterprises reduce risk and simplify compliance. At DataStealth, she supports large organizations in protecting sensitive data by default, without interrupting user workflows. Her work focuses on PCI DSS scope reduction, preventing client-side attacks, and enabling secure third-party integrations without the security risk. Lindsay regularly shares practical insights on modern data protection challenges and helps organizations navigate evolving compliance standards with confidence.
