Can zDIH Become the Behavioural Memory Layer for Transactional AI?

Can zDIH Become the Behavioural Memory Layer for Transactional AI?

As organizations accelerate their adoption of AI, much of the conversation continues to focus on models, latency, coverage, and sovereignty. Discussions around AI on IBM Z frequently centre on technologies such as Telum, Spyre, and increasingly the role of large language models. These capabilities are important, but they can also create the impression that AI is primarily an inference problem.

Across multiple fraud, payments, and financial crime engagements, I have repeatedly encountered a different reality. Organizations are often able to identify the decision they want AI to improve, but the effectiveness of that decision depends heavily on access to behavioural information that exists outside the transaction itself. Whether the objective is detecting fraud, identifying suspicious account activity, evaluating payment risk, or identifying emerging financial crime patterns, the quality of the decision depends on understanding how the current event compares to everything that has happened before.

This distinction is important because it shifts the focus away from models and towards context. A model may ultimately produce a score, recommendation, or prediction, but that output is heavily influenced by the information available at the moment the decision is made. In many Transactional AI workloads, behavioural information accumulated over weeks, months, or even years provides the foundation upon which meaningful decisions are made.

The Importance of Behavioural Context

Consider a payment transaction being evaluated for fraud. A model may be asked whether a payment should be approved, declined, challenged, or referred for investigation. At first glance, this appears to be a straightforward inference problem. A transaction arrives, a model evaluates the available information, and a decision is returned.

In practice, however, many fraud decisions depend on information that is not contained within the transaction itself. Determining whether a payment is unusual requires an understanding of normal customer behaviour. Identifying a sudden increase in transaction velocity requires knowledge of historical activity. Detecting suspicious beneficiary relationships requires visibility into interactions that may have occurred days, weeks, or months earlier. Understanding whether an account is exhibiting mule-like behaviour requires an understanding of how money has been flowing through that account over time.

The information required to make these decisions often exists as accumulated behavioural history rather than transactional data. Historical transaction counts, rolling averages, behavioural baselines, beneficiary relationships, account relationships, device histories, and countless other indicators provide the context required to distinguish normal activity from suspicious activity. Without that context, even the most sophisticated model is operating with an incomplete view of reality.

This is precisely why adaptive behavioural models and daily behavioural models have proven so effective over many years. These approaches recognise that behaviour is often more informative than individual events. A transaction that appears entirely normal when viewed in isolation may become highly suspicious when viewed in the context of recent activity. Conversely, a transaction that initially appears unusual may prove entirely legitimate when considered against a customer’s established behavioural patterns.

The effectiveness of these approaches depends on the ability to continuously maintain and update behavioural state. Profiles must evolve as new transactions occur. Velocity counters must be updated. Rolling windows must be recalculated. Historical relationships must be maintained. Behavioural baselines must adapt as customer behaviour changes over time. This creates an architectural requirement that receives considerably less attention than model training or inference. Before AI can make better decisions, something must remember what happened before.

The Behavioural Memory Layer

Over time, I have come to think of this capability as a behavioural memory layer.

The behavioural memory layer sits between the systems that process transactions and the AI models responsible for making decisions. Its purpose is to maintain the behavioural state required to transform a transaction into meaningful context. It maintains profiles, velocity counters, rolling windows, aggregations, entity relationships, behavioural baselines, and other forms of historical state that help explain what is happening within a transaction.

When a transaction arrives, the behavioural memory layer provides the information required to enrich that transaction with context. Features can then be derived from this behavioural state and supplied to the model. Once the decision has been made, the behavioural state itself must be updated to reflect the latest activity. Viewed through this lens, Transactional AI is not simply an inference problem. It is a combination of behavioural memory, feature engineering, model execution, and decisioning.

This observation may help explain why many AI initiatives struggle to move beyond experimentation. Organizations often invest significant effort into model selection, training pipelines, deployment architectures, and inference runtimes while paying considerably less attention to the behavioural state required to support effective decisions. Yet in many real-world deployments, the quality of the behavioural context is every bit as important as the sophistication of the model itself.

Looking for a Home for Behavioural Memory

Once the need for behavioural memory becomes apparent, an obvious architectural question emerges. Where should that behavioural state be maintained?

The challenge is not simply one of storage. Behavioural memory must be continuously updated, enriched, queried, and consumed by multiple communities. Application developers need access to it. Data engineers need access to it. Data scientists need access to it. AI models need access to it. The most successful solutions are often those that reduce friction between these groups while maintaining proximity to the systems that generate the data.

As I explored this requirement, I found myself repeatedly coming back to IBM Z Digital Integration Hub.

Could Transactional AI Be the Use Case zDIH Has Been Waiting For?

IBM positions zDIH as a platform for creating and sharing real-time information while protecting systems of record from inquiry traffic. Historically, the conversation has centred around information rather than AI. The platform is designed to transform raw operational data into consumable information that can be shared across applications, services, and environments.

The more I examined zDIH, however, the more difficult it became to ignore the similarities between its architecture and the requirements of a behavioural memory layer. Behavioural memory requires the ability to maintain real-time state, process continuous updates, create derived information, expose that information through standard interfaces, and make it available at low latency to consuming applications. These are precisely the capabilities zDIH was designed to provide.

For years, zDIH has been positioned as a mechanism for transforming raw data into consumable information. Transactional AI requires exactly the same transformation. Models do not consume transactions. Models consume features. Those features are derived from behavioural state, historical activity, aggregations, relationships, and context. Behavioural profiles, adaptive behavioural models, velocity counters, rolling windows, and derived features are all examples of consumable information created specifically to improve decisions.

Viewed through this lens, the connection between Transactional AI and zDIH becomes difficult to ignore.

What makes this particularly interesting is that zDIH appears capable of bridging the gap between the transaction processing world and the data and AI world. Behavioural profiles become accessible through interfaces and patterns that are familiar to application developers, data engineers, data scientists, and machine learning practitioners alike. Rather than forcing AI teams to work directly against systems of record, behavioural information can be maintained, enriched, and exposed in a form specifically designed for consumption.

In many ways, Transactional AI may represent the use case that zDIH has been waiting for. Organizations have often struggled to articulate the value of maintaining consumable information separate from their systems of record because the business outcome was not always obvious. Transactional AI changes that conversation. The objective is no longer simply to share information. The objective is to improve decisions. Behavioural memory provides the context required for those decisions, while zDIH appears uniquely positioned to create, maintain, and serve that context in real time.

A Different Way of Thinking About Transactional AI

Perhaps the most important observation is that this discussion shifts the focus away from models and towards context.

The AI industry often behaves as though better decisions are primarily the result of better models. In practice, many successful Transactional AI deployments achieve their results because they provide models with richer behavioural context. A relatively simple model supplied with high-quality behavioural information will often outperform a more sophisticated model operating with limited context.

As organizations move AI closer to live transactions and real-time decisions, the question may become less about how quickly a model can execute and more about how effectively the surrounding architecture can provide the behavioural information required to make informed decisions. Transactional AI may ultimately be remembered not for the models it deploys, but for the way it combines behavioural memory, feature engineering, and decisioning into a single operational capability.

Conclusion

As Transactional AI moves from experimentation into production, organizations may discover that model inference is only one part of the challenge. Equally important is the ability to maintain the behavioural state required to make high-quality decisions. Fraud detection, financial crime prevention, payment risk management, claims analysis, and many other Transactional AI use cases depend on understanding behaviour over time. They require a mechanism for remembering what happened before, maintaining context, and transforming historical activity into information that can be consumed by AI models.

Perhaps the most interesting aspect of this discussion is that it provides a new lens through which to view zDIH itself. Rather than thinking about the platform solely as a mechanism for sharing information, it may be useful to think about it as a platform for maintaining the behavioural memory required by Transactional AI. If that observation proves correct, then Transactional AI may have finally provided the business context that reveals the strategic role zDIH was designed to play.