In the previous articles, I spent a lot of time discussing the static structure of financial products. We looked at product nature, economic terms, payouts, price, quantity, schedules, settlement terms, and product qualification. The main question explored was: what is this financial product, structurally and economically?

That was a necessary foundation. If an AI-native financial data foundation cannot understand what a product or trade contract is, it has no chance of understanding anything more complicated. It needs to understand that an interest rate swap is not just a label. It needs to see the fixed and floating payouts. It needs to understand notional, rate, index, calculation periods, payment dates, settlement terms, payer and receiver. It needs to understand why a product is what its structure says it is.

But real financial trades do not stay still. A trade is executed. It may be confirmed. It may be allocated. It may be cleared. It may be amended. A notional may be reduced. A counterparty may change. A floating rate may be reset. A cashflow may be paid. An option may be exercised. A repo may be rolled. A credit event may trigger settlement. A trade may be partially terminated, fully terminated, compressed, matured, cancelled, or novated.

So far, much of the discussion has been about the question: What is the trade defined? But there is another equally important question:

How does the trade change over time?

This is where the CDM Event Model becomes important. The CDM Product Model helps describe the static economic structure of a financial transaction. The CDM Event Model helps describe the dynamic lifecycle of that transaction. For an AI-native financial data foundation, both are necessary.

Product modelling gives us static financial semantics.
Event modelling gives us dynamic lifecycle semantics.

Without the first, an AI system cannot understand what the trade means. Without the second, it cannot understand why the trade is now in its current state.

The Snapshot Approach Has Worked — But It Is Not Enough for AI-Native Use

In many financial data platforms, a trade is represented primarily as a current snapshot. That snapshot may contain the current notional, current counterparty, current maturity date, current product type, current trade status, current settlement information, and perhaps the latest valuation attributes.

This is not a bad design. In fact, it has been the standard practice in many financial systems for many years. There is a good reason for that. Most users need to know the current state of the trade. A trader may want to see the live position. A risk manager may want current exposure. A finance team may need current valuation inputs. An operations team may need current settlement status. A reporting process may need the latest eligible trade population. A dashboard may need to show today’s outstanding notional, maturity profile, counterparty exposure, or cashflow projection.

For these use cases, a snapshot view is not only useful; it is often exactly what the user needs. A well-designed current-state trade table can support many practical requirements. It can simplify reporting. It can make queries faster. It can hide unnecessary lifecycle complexity from users who only need the latest view. It can support reconciliation, risk aggregation, regulatory extracts, and operational dashboards. In many environments, the current snapshot is the most consumed representation of trade data.

So the point is not that the snapshot approach is wrong. The point is that the snapshot approach is not enough for an AI-native financial data foundation.

The reason is that AI-native use cases are different. An AI agent is not only retrieving the current value of a field. It may need to explain why that value is there. It may need to trace how the trade reached its current state. It may need to distinguish between original economic terms, later amendments, observed values, settlement events, workflow steps, and operational corrections.

Suppose an AI agent looks at a trade and sees that the notional is now USD 80 million. That may be factually correct. But it immediately raises deeper questions. Was the trade originally booked as USD 80 million? Was it originally USD 100 million and later partially terminated? Was it allocated from a block trade? Was part of it novated to another party? Was it compressed with another position? Was there an operational correction? Did the lifecycle event change the actual economics of the trade, or did it only change the booking representation?

A current snapshot alone cannot answer these questions reliably. It can tell us what the trade looks like now, but not how it became that way.

This distinction is critical. Current-state consumption and lifecycle reasoning ask different kinds of questions.

These are different questions. They require different data semantics. The event model does not replace the current snapshot. The snapshot remains valuable and will continue to be used. But for AI-native financial data, the snapshot needs lifecycle semantics behind it. The current state is the result. The event model explains the process that produced the result.

Lifecycle Events Are Not Just Event Names

A common way to model trade lifecycle is to create a list of event types, such as execution, confirmation, allocation, clearing, amendment, reset, settlement, exercise, termination, novation, compression, and cancellation. At first glance, this looks reasonable. Human beings use these words every day. Traders, operations teams, product controllers, risk managers, and technologists all understand these event names in normal business conversation.

But for a canonical data model, especially one intended to support AI reasoning, event names are not enough. The problem is that an event name often hides the actual state change.

Take partial termination as an example. The name tells us that part of the trade has been terminated. But what exactly changed? The notional may have decreased. The remaining trade may still be active. There may be a fee or settlement payment. The closed portion may need to be represented. The current trade state must be linked back to the previous trade state.

Now take novation. Again, the word is familiar, but the actual data change may be more complex. A party changes. A new trade relationship may be formed. The original trade may be closed, partially closed, or split. Legal agreement information may change. New identifiers may be created. The lifecycle history must remain traceable.

The event name tells us what people call the event. It does not fully tell us what happened to the trade state. This is the central reason why the CDM Event Model is designed around state transition rather than merely around event labels. In a state transition view, a lifecycle event is not simply a row in an event type table. It is a structured transformation:

Before TradeState + lifecycle instruction = After TradeState

That is a very different level of semantic precision. It allows the model to ask what the trade state was before the event, what changed, what the trade state became after the event, whether the result can be validated, and whether the lifecycle can be reconstructed.

For AI-native financial data, this matters because the system needs to reason about the change, not only repeat the name of the event.

The CDM Event Model as a Lifecycle Grammar

The most interesting thing about the CDM Event Model is that it does not try to manage lifecycle complexity by creating a long list of product-specific event types. Instead, it treats lifecycle events as state transitions composed from a smaller set of primitive changes.

This is why I think of the CDM Event Model as a kind of lifecycle grammar. If we only define event names, lifecycle modelling quickly becomes a growing dictionary: IRS partial termination, CDS partial termination, repo rerate, FX forward settlement, swaption exercise, bond redemption, equity swap reset, commodity delivery, cleared novation, allocation split, compression termination, and many more.

The list grows quickly because every asset class and product type starts to create its own event vocabulary. The model becomes harder to maintain and harder for AI to reason about.

The CDM approach is different. It asks what smaller state changes sit behind these lifecycle events. A quantity can change. Terms can change. A party can change. A trade can be split. A reset can be recorded. A transfer can happen. An option can be exercised. A contract can be formed. A trade can be executed.

These smaller operations are more reusable than product-specific event names. They are not perfect abstractions for everything, but they create a disciplined way to describe complex lifecycle events.

Partial novation, for example, is not just a magic event label. It can be understood as a composition of simpler changes: split, quantity change, and party change. That is much more meaningful than simply writing eventType = PartialNovation.

For an AI-native data foundation, this is extremely valuable. An AI agent does not only see the lifecycle event name. It can inspect the structure of the transition, understand what changed, and trace how the resulting trade states are linked to the original state. This is what makes lifecycle data explainable.

Why This Matters for AI-Native Financial Data

In traditional data platforms, lifecycle history is often treated as operational history. It is valuable for audit, reconciliation, reporting, and support, but it is not always treated as a first-class semantic layer.

For AI-native financial data, that is not enough.

AI agents need lifecycle semantics because they need to answer explanatory questions, not only retrieval questions.

These questions cannot be answered reliably from a flat trade table alone. They require a lifecycle model with state transitions, lineage, and workflow context.

This is why AI-native financial data foundation is not just about adding embeddings or putting a chatbot on top of existing databases. The foundation itself has to be more semantic. It has to tell the AI system what the data means, how it changes, where it came from, and what stage of the lifecycle it represents. Otherwise, AI will only produce confident summaries of poorly structured data.

From Product Qualification to Event Qualification

The previous article discussed product qualification. The idea was simple but important: a product is not what its label says it is. A product is what its structure says it is.

The same logic applies to lifecycle events. An event is not merely what its name says it is. An event is what its state transition says it is.

This creates a consistent modelling philosophy:

Structure determines product meaning.
State transition determines event meaning.

State transition determines event meaning. That consistency matters for AI-native systems because it allows the system to reason from structure rather than merely repeat labels.

Conclusion

The CDM Event Model matters because it moves lifecycle modelling away from loose event labels and towards structured state transitions. This is not just a technical modelling choice. It is a semantic shift.

A product model explains what a trade is. An event model explains what happened to it. Lineage and workflow explain how the current state came to exist and how the change was processed.

Together, these layers allow financial data to become not only machine-readable, but machine-understandable. This is the next layer of the AI-native financial data foundation: moving from static product semantics to dynamic lifecycle semantics.

• *AI-Native Financial Data Foundation