When enterprise leaders talk about AI strategy, the conversation organises quickly around two familiar categories. Copilots: AI that assists knowledge workers by drafting, summarising, retrieving, and suggesting. Agents: AI that executes multi-step workflows autonomously, connecting systems and completing tasks without human intervention at each step. Both categories have genuine value. Both have attracted the majority of enterprise AI investment over the past three years.

Both operate above the transaction. Neither changes what happens inside it.

Transactional AI is different in kind, not in degree. It is intelligence whose inference result participates directly in the transaction decision path before the transaction completes. Copilots and agents may at times invoke or influence transactional processes, but they operate around the transaction. Transactional AI operates inside the decision path, at the point where the outcome is determined. It influences whether a transaction is approved or declined, priced or routed, flagged or cleared, in the milliseconds between initiation and resolution.

That distinction carries more strategic weight than it appears to on the surface.

What happens in the transaction decision path

A payment authorisation decision takes place in under 100 milliseconds in a modern payments network. Within that window, the network must determine whether the transaction is legitimate, whether the cardholder has the available funds or credit, whether the merchant is operating within acceptable parameters, and whether the combination of these factors meets the threshold for approval. Every one of those determinations is currently being made, to varying degrees of sophistication, by rules and models running inside the transaction processing environment.

Transactional AI improves the quality of those determinations. Not by adding a step after the transaction. Not by flagging it for human review. By making a better determination within the same window, at the same speed, with the same finality. The transaction is either approved or declined, and the AI has influenced which outcome occurs.

The business consequence of improving the quality of that determination, across the volume of transactions that a large payments network processes, is not an incremental productivity gain. It is a fundamental improvement in the financial performance of the core business operation. A one-percentage-point improvement in fraud detection accuracy across ten billion annual transactions is a different category of AI value from a ten-percent productivity improvement for a team of analysts using a copilot.

Defining the category

To use Transactional AI as a strategic concept rather than an impressionistic one, it requires a formal definition that distinguishes it from real-time inference in general and from the adjacent AI categories it is frequently conflated with.

Transactional AI has seven defining characteristics. Its inference result participates in the transaction decision path rather than informing a separate process alongside or after it. It operates before transaction completion, meaning the decision it produces is a determinant of the outcome rather than a commentary on it. It influences a transaction outcome directly, whether approval, decline, routing, pricing, or risk classification. It operates under deterministic latency constraints imposed by the transaction processing environment, not by a service level agreement that can be negotiated. It executes within the operational governance boundary of the transaction system, subject to the same integrity, auditability, and continuity requirements as the transaction itself. It affects financial or operational exposure in real time, with consequences that are immediate rather than deferred. And it operates continuously at transaction scale, not in response to a user request or a scheduled batch.

These characteristics collectively define a category that is architecturally, operationally, and economically distinct from copilots (human-facing, workflow-adjacent) and agents (task-orchestrating, workflow-automating). They also explain why the governance, continuity, and data fidelity requirements for Transactional AI are materially different from those that apply to other AI categories. The operating conditions are different. The failure modes are different. The value density is different.

Why IBM Z is a natural platform for Transactional AI

Many of the world’s highest-volume banking, payments, insurance, and trade settlement transaction systems run on IBM Z. The concentration reflects decades of deployment decisions made on the basis of reliability, security, and throughput, and it has not diminished as cloud alternatives have matured.

The significance of that concentration for Transactional AI is not primarily about platform preference. It is about where the transactions are. Transactional AI that runs on IBM Z runs where the transactions run. The AI and the decision it influences are co-located. The inference happens on the same platform as the authorisation, using data that has not been extracted, transmitted, or transformed to reach it. Every characteristic in the definition above is more naturally satisfied by an architecture where AI and transaction are co-located than by one where they are separated.

IBM Z’s Telum II processor provides on-chip AI inference that operates without a round trip to an external model server, within the latency envelope that payment authorisation requires, and at the throughput required to score every transaction rather than a sample. That capability is what makes the Transactional AI characteristics operationally achievable on IBM Z rather than aspirational. The question of whether equivalent capability can be assembled elsewhere is secondary to the question of whether it already exists where the transactions are.

Transactional AI on IBM Z does not require a single deployment pattern. Inference may execute through several architectural approaches depending on latency, governance, and operational requirements: co-located inference through Machine Learning for z/OS, Liberty-based decision services invoked through WOLA, REST-based invocation through z/OS Connect, or adjacent Linux on Z inference architectures. What defines the category is not a specific implementation mechanism. It is that the inference result participates directly in the transaction decision path before the transaction completes. The architectural pattern is a design choice. The operational role is the category definition.

The category that most AI strategies are missing

The reason Transactional AI has not been named as a distinct category in most enterprise AI strategies is that the people building those strategies are typically not the people who understand what runs on IBM Z. The AI strategy is built by the digital and data leadership. The transaction processing infrastructure is owned by the core banking or payments technology organisation. The conversation between those two functions, about what AI could do if its inference result participated directly in the transaction decision path rather than sitting alongside it, is not happening at the frequency or the level it needs to.

The organisations that close that conversation gap are the ones that will define the Transactional AI category before their competitors do. The platform is already there. The data is already there. The transaction volume is already there. The investment required to generate Transactional AI value at scale is not a greenfield build. It is an architectural decision about where intelligence should live relative to the decisions it is meant to improve.

Copilots and agents will continue to generate value in the workflows that surround core operations. Transactional AI will generate value inside those operations, at the point where the financial consequences of decisions are largest. The category is distinct. For many of the world’s largest financial transaction systems, the platform where that category is most naturally realised is IBM Z. The question is which organisations recognise the category and act on it before the window narrows.