IBM has spent years developing the ability to execute artificial intelligence inside one of the world’s most important transaction-processing environments. Telum introduced on-chip AI acceleration to IBM Z. Telum II extends that capability, while Spyre expands the range and scale of models the platform can support. Machine Learning for IBM z/OS and the surrounding software stack provide the means to deploy and govern models close to the applications and data on which consequential financial decisions depend. This is a substantial engineering achievement, but it is not yet the full commercial opportunity.

The greater opportunity is to build the leading on-platform fraud solution around that runtime. IBM has created the machinery required to execute models within the transaction path. The next source of value will come from assembling the models, behavioral features, decision logic, integrations and operational workflows that allow financial institutions to prevent more fraud rather than merely run more inference.

The platform advantage already exists

IBM Z occupies a position that most AI vendors would find extraordinarily difficult to reproduce. IBM reports that 45 of the world’s 50 largest banks use the platform and that approximately 70 percent of global transactions by value pass through IBM Z. These figures do not mean every fraud decision occurs on the mainframe, but they establish something strategically important. A significant share of the world’s highest-value financial activity already touches a platform capable of executing AI inside the transaction flow.

Most technology companies trying to enter fraud detection must first win access to the data, integrate with the transaction system and prove that their technology can operate reliably at financial-services scale. IBM begins with the transaction platform, established client relationships and an integrated inference capability. Those are not peripheral advantages. They remove several of the hardest barriers to entering the market.

Yet platform presence does not automatically create a fraud business. A runtime can evaluate a model, but it does not determine which fraud problems matter, create the behavioral context required to recognize them or provide the operating processes through which suspicious decisions are investigated and improved. The runtime makes the opportunity possible. It does not capture it.

Fraud should not be treated as another workload

Infrastructure businesses naturally describe opportunities as workloads. Fraud detection then becomes one of several examples used to demonstrate low latency, transaction throughput or the value of keeping data in place. This framing is technically valid and commercially limiting.

A bank does not invest in fraud detection because it wants to execute an inference request in a few milliseconds. It invests because fraud losses are unacceptable, false positives are damaging customer relationships, manual reviews are expensive and existing controls fail to recognize enough suspicious behavior before money leaves the institution. Runtime performance matters only when it improves one or more of those outcomes.

Treating fraud as a workload places responsibility for almost everything valuable back on the client. The institution must identify the fraud vectors, reconstruct the relevant data, engineer the features, source or train the model, integrate it into the transaction path, build the investigation workflow and establish how value will be measured. The vendor supplies an execution environment while the client carries most of the distance between technical capability and business value. That approach may sell infrastructure to institutions already committed to building the solution themselves, but it is unlikely to create a repeatable market at scale.

The unclaimed solution layer

An on-platform fraud solution is not simply a fraud model hosted on IBM Z. Nor is it an existing fraud platform described as on-platform because it is installed somewhere inside the same institution. The category only has meaning if fraud intelligence is brought into the IBM Z transaction environment and participates directly in the decision being made there.

That requires an operational fraud product rather than an inference demonstration. It must understand behavior over time, evaluate transactions in context, combine model outputs with policy, explain why a decision was reached and connect that decision to the institution’s response. It must improve fraud outcomes without imposing unacceptable latency, operational complexity or customer friction.

The commercial opening exists because IBM’s runtime supplies only one part of that proposition. The remaining value sits in the fraud-specific product layer. That is where domain intelligence, behavioral modeling, decision management and operational experience are converted into something a financial institution can buy and use.

On-platform cannot mean platform-isolated

The case for an on-platform solution becomes weak if it is reduced to a claim that all relevant fraud intelligence already resides on IBM Z. It does not. Device intelligence, digital-session behavior, consortium signals, merchant data, sanctions information and cross-channel relationships may originate elsewhere. Some fraud controls require graph analysis or historical processing that is better performed outside the immediate transaction path.

The winning architecture must therefore be platform-native without being platform-isolated. It should make the consequential decision where the transaction is processed while consuming intelligence from across the enterprise. It should support a division of labor in which retrospective analysis, model training and graph computation can occur on the most appropriate platforms, with operational features and scores made available at the moment of decision.

This distinction matters. Data gravity and latency can justify on-platform inference, but architectural purity cannot. The objective is not to keep every component on IBM Z. The objective is to improve the decision occurring there.

The runtime owner does not automatically win

IBM has a natural claim to this opportunity, but it has no entitlement to it. Established fraud vendors possess mature models, investigation workflows, institutional knowledge and accumulated experience across large customer populations. Banks also have internal data-science teams and existing fraud platforms that cannot be displaced by a processor feature or a latency benchmark alone.

The winner will be the organization that closes the gap between IBM Z’s technical capabilities and a bank’s operational fraud outcomes. That could be IBM. It could be an established fraud vendor that embraces the platform. It could also be a specialist that builds the on-platform product and works through IBM’s installed base and field organization.

The defensible position will not come from placing an isolated model on the mainframe. It will come from combining a proven fraud product with the ability to participate directly in IBM Z transaction processing. That is a product and market commitment, not merely another supported deployment target.

An opportunity worth investing in

IBM has likely invested hundreds of millions of dollars across the processor, accelerator, systems and software capabilities that make AI on IBM Z possible. IBM does not publicly disclose a program-level figure, so false precision would be irresponsible. The strategic point does not depend on knowing the exact number. The platform engineering investment is substantial, while the additional investment required to create a reusable fraud proposition would be modest by comparison.

That asymmetry should command attention. Custom silicon and enterprise runtimes are expensive to create. Building, acquiring or partnering for the fraud solution layer also requires serious commitment, but not investment on the same scale. Failing to address that layer leaves the largest engineering investment dependent on clients or other vendors creating its most valuable applications.

The business case should not be based on capturing a fictional share of a trillion-dollar fraud-software market. The global fraud-detection market is measured in tens of billions of dollars, while the wider economic exposure includes hundreds of billions in annual fraud losses and trillions in illicit financial flows. The relevant opportunity is narrower and more credible. It is the market for improving fraud decisions associated with the high-value banking, payment and claims transactions processed on or adjacent to IBM Z.

Even a small improvement in those decisions can create value far exceeding the cost of the inference infrastructure. That makes fraud more than a demonstration workload. It makes it one of the clearest economic reasons to invest in AI on the platform.

The next layer will determine who captures the value

IBM developed the AI on IBM Z runtime. That achievement created an opening, not a completed proposition. The greater opportunity is to build the leading on-platform fraud solution around it. Doing so requires moving beyond the language of model support, inference throughput and deployment options. It requires choosing fraud as a market to win and measuring success through prevented losses, reduced friction and better decisions.

The infrastructure has already been built. The transactions are already there. The clients already bear the economic cost of fraud. What remains missing is the solution that connects them. Whoever builds that layer will capture more than runtime consumption. It will capture the higher-value relationship with the business problem that made the runtime worth building in the first place.

Sources

  • IBM, “Announcing IBM z16: Real-time AI for Transaction Processing at Scale and Industry’s First Quantum-Safe System,” April 5, 2022.
  • IBM Research, “How the IBM z17 was prepared for tomorrow’s workloads,” April 7, 2025.
  • IBM, “New Telum II Processor and IBM Spyre Accelerator,” August 2024.
  • IBM Institute for Business Value, “How mainframes are rewriting the AI playbook,” 2024.
  • Nasdaq Verafin, 2024 Global Financial Crime Report.
  • Featurespace, “The Featurespace Platform,” accessed September 2026.
  • Visa, “Visa Completes Acquisition of Featurespace,” December 19, 2024.