Across the previous 30+ articles in this series, I have focused on the theoretical foundations behind AI-native financial data platforms, covering financial business semantics, canonical data models, knowledge graphs, GraphRAG, semantic retrieval, tool contracts and related topics.

From this article onwards, I would like to shift the discussion towards the design and implementation of my own AI-native financial data foundation.

I have now formalised this work under two related Finsight products:

• Finsight AI-Foundry, a reusable framework and collection of implementation components for building AI-native financial data foundations and governed AI workflows;
• Finsight AI-Control, which focuses on AI governance, runtime controls, monitoring, evidence and operational assurance.

I will discuss the reasons for designing these two products, and how they relate to one another, in a separate article.

This group of articles begins with one of their core components: the Finsight Semantic Foundation. Its purpose is to provide the machine-readable meaning that allows AI systems to understand financial concepts, data and operational context more reliably.

The design of the Semantic Foundation has not been a smooth or linear process.

I have repeatedly reconsidered modelling boundaries, terminology and levels of abstraction. I have gone back and forth over the use of industry standards, the separation between business concepts and their data representations, and the balance between conceptual accuracy and practical implementation.

Many of these decisions involved trade-offs rather than obviously correct answers.

In the next few articles, I will try to explain not only the resulting design, but also the thinking behind it: the alternatives I considered, the distinctions I chose to preserve, and the compromises required to turn an abstract semantic model into an implementable foundation.

Before introducing that design, however, I want to begin with the nature of the domain being modelled.

In particular:

What characteristics of financial services, especially capital markets and FICC products, need to be reflected in an ontology?

The ontology modelling challenge

The challenge is not simply that financial institutions have many systems or large volumes of data.

It comes from the nature of the business itself.

Capital markets are built around contracts, economic terms, rights, obligations, roles, events, states, calculations and expectations. Many of these concepts are abstract. They evolve over time, appear differently across business functions and may be represented in several systems for different purposes.

As I worked through the design of the Finsight Semantic Foundation, I found that many modelling decisions could be traced back to a relatively small number of recurring domain characteristics.

Challenge 1 — We are modelling contracts, not physical objects

Many capital-markets concepts do not correspond to physical things.

A trade represents an agreement between parties. A derivative represents a set of contractual economic terms. A position represents an economic exposure. A valuation represents an assessment made using a model, market observations and assumptions.

Even a cashflow may refer to several related but distinct things:

• a contractual payment obligation;
• a projected payment;
• a settlement instruction;
• an actual cash movement;
• an accounting record.

These concepts are real within the business, but they are abstract.

A database row may record information about a trade, cashflow or valuation, but the record is not the business object itself. It is one representation of that object for a particular purpose.

This creates an important modelling requirement:

The ontology must distinguish the financial object from the records and representations used to describe it.

Challenge 2 — Products are compositions, not only classifications

Capital-markets products are often introduced through classifications such as bond, swap, option or repo.

These classifications are useful, but they do not fully describe the economic structure of a product.

An interest-rate swap, for example, may contain:

• fixed and floating payment legs;
• payer and receiver roles;
• rate specifications;
• notionals;
• calculation periods;
• payment schedules;
• day-count conventions;
• reset terms;
• settlement provisions.

Two trades may both be classified as interest-rate swaps while differing materially in their underlying economic terms.

A taxonomy tells us which category a product belongs to:

Derivative
    └── Interest Rate Derivative
            └── Interest Rate Swap

Composition tells us how the product is constructed:

Interest Rate Swap
    ├── Fixed Payout
    │     ├── Fixed Rate
    │     ├── Notional
    │     └── Payment Schedule
    └── Floating Payout
          ├── Floating Rate Index
          ├── Spread
          ├── Reset Schedule
          └── Payment Schedule

Both are useful, but they answer different questions.

Classification supports product grouping and navigation. Composition describes the economic structure required for valuation, lifecycle processing, cashflow generation and data validation.

This creates a second modelling requirement:

The ontology must represent reusable economic components and the relationships through which products are formed.

Challenge 3 — Identity is different from state, version and representation

A trade may have one business identity while appearing through several versions, states and system records.

Consider a trade that is executed and later amended.

It may have:

• one underlying transaction identity;
• multiple business versions;
• several lifecycle states;
• different identifiers across applications;
• separate representations in trading, clearing, risk and reporting systems.

A new record does not necessarily mean a new trade. It may represent a changed state, a new version or another system’s view of the same transaction.

A useful ontology must therefore keep several ideas separate.

• Identity answers which business object this is.
• Type describes what kind of object it is.
• State describes its condition at a point in time.
• Version represents a particular form of the object following change.
• Representation describes how the object appears in a system, message, report or analytical model.

These distinctions are easy to blur when modelling directly from existing data structures. A booking system may use a new row for each version, while another platform may update a record in place. Neither implementation should determine the underlying business ontology.

This creates another modelling requirement:

The ontology must preserve business identity across changing states, versions and institutional representations.

Challenge 4 — The business evolves through events

Financial objects do not remain static.

Trades may be:

• executed;
• confirmed;
• allocated;
• cleared;
• amended;
• novated;
• exercised;
• partially terminated;
• compressed;
• settled;
• cancelled.

An event may create an object, change its state, generate obligations or supersede an earlier version.

A static record such as:

trade_status = TERMINATED

describes a condition, but it does not explain what happened.

An event-oriented model can express:

Partial Termination Event
    acted on
Trade
Partial Termination Event
    produced
New Trade State
New Trade State
    superseded
Previous Trade State

This preserves the relationship between cause, change and resulting state.

It also helps answer operational questions:

• Why did the notional change?
• Which event created this payment?
• Which version was used for valuation?
• Was the latest event processed downstream?
• Which state was valid at reporting time?

This leads to the following requirement:

Events, states and state transitions must be modelled explicitly rather than hidden behind status fields.

Challenge 5 — Meaning depends on context and provenance

Many financial terms are ambiguous when considered in isolation.

The term rate may refer to:

• a contractual fixed rate;
• a floating-rate fixing;
• a discount rate;
• an FX rate;
• a recovery rate;
• a market quote.

The meaning depends on the object and relationship in which the value participates.

The same is true for parties.

An institution is not permanently a buyer, seller, payer or receiver. These are roles performed within a particular transaction, payout or process.

Party
    performs
Payer Role
    within
Fixed-Rate Payout

This is more precise than modelling Payer as a permanent type of legal entity.

Meaning may also depend on the origin and status of the information.

A fixed coupon is contractually agreed. An overnight fixing is observed from the market. A present value is calculated by a model. A regulatory field may be derived through a transformation. A suspected processing failure may be inferred from operational evidence.

Although all of these may appear as values in a data platform, they represent different kinds of knowledge.

To interpret them correctly, the model may need to capture:

• the business object and context;
• the role played by the value;
• its source;
• the time to which it applies;
• the method, rule or model used to produce it;
• whether it is asserted, observed, calculated, derived or inferred;
• the evidence supporting it.

Meaning can also depend on the business perspective. Trading, operations, risk, finance and regulatory reporting may maintain different but valid views of the same transaction.

This creates a broader modelling requirement:

Meaning must be established through context, relationships, roles and provenance rather than inferred from names and values alone.

Challenge 6 — Time has several meanings

Capital-markets data contains many dates and timestamps, but they do not all describe the same kind of time.

Examples include:

• execution time;
• trade date;
• effective date;
• fixing date;
• valuation time;
• payment date;
• settlement date;
• reporting date;
• processing time;
• ingestion time.

There may also be a difference between when something became true in the business and when a system recorded or observed it.

An amendment may become economically effective on Monday but reach a downstream system on Tuesday.

A market observation may describe the market at 4 p.m. but be ingested later.

This creates several temporal perspectives:

Business-effective time
Event time
Observation time
Processing time
System-recording time
Validity period

These distinctions affect more than historical reporting. They determine which trade version, market observation, calculation rule or mapping was valid for a particular business event.

This leads to another requirement:

Time must be modelled according to its business and operational meaning, rather than treated as a collection of generic timestamps.

Challenge 7 — Rules define expected behaviour

Capital-markets meaning cannot be described through objects and relationships alone.

Rules determine:

• which attributes are required;
• how cashflows are calculated;
• how lifecycle transitions occur;
• when obligations arise;
• how products are classified;
• whether transactions are reportable;
• which controls should be applied.

Examples include:

A fixed-rate payout requires a fixed rate.
An effective date must not follow the termination date.
A cashflow amount is derived from notional, rate and day-count fraction.
A termination event supersedes the previous active trade state.

These rules are not merely technical implementation details. They contribute to the definition and behaviour of the business concepts themselves.

Rules also establish expectations.

A product rule may define which economic terms must be present. A lifecycle rule may determine which trade state should be active. A calculation rule may determine which cashflows should be generated. A reporting rule may define which information must be available.

Institutions then compare these expected outcomes with what is observed operationally:

Rule or obligation
        ↓ defines
Expected state
        ↓ compared with
Observed state
        ↓ supported by
Evidence

A difference may become a control finding, data-quality issue, reconciliation break or operational exception.

These outcomes should not define the entire ontology, but they demonstrate why expectations, observations and evidence need to remain connected to the underlying business rules.

This creates the requirement:

Rules and expected outcomes should be represented as part of the semantic model, while remaining connected to the observations and evidence used to assess them.

Challenge 8 — The business has many institutional representations

The capital-markets business world is implemented through:

• operating processes;
• applications;
• services;
• messages;
• APIs;
• databases;
• tables;
• pipelines;
• calculations;
• controls;
• reports.

The same trade may be represented in a booking platform, risk engine, settlement system, reconciliation application and regulatory submission.

Each representation serves a purpose. None of them fully defines the underlying business object.

• A lifecycle event is not the same thing as a Kafka message.
• A payment obligation is not the same thing as a row in a cashflow table.
• A valuation is not the same thing as a field containing present value.
• A risk representation, regulatory representation and operational representation may all describe different aspects of the same transaction.

An ontology cannot therefore be derived from one application or one enterprise schema and assumed to represent the entire business.

At the same time, a business ontology that remains disconnected from real processes, systems and data has limited practical value.

This creates the final requirement:

Business meaning and institutional implementation must remain distinct while being connected explicitly.

What this means for ontology modelling

The characteristics described above create a broader modelling problem.

A capital-markets ontology must be able to represent:

• abstract and contractual objects;
• product composition;
• parties and contextual roles;
• identity, state, version and representation;
• events and temporal change;
• context-dependent meaning;
• provenance and different kinds of knowledge;
• multiple business perspectives;
• rules, calculations and expected outcomes;
• operational observations and evidence;
• institutional processes, systems and data representations.

The objective is not to simplify the domain by removing its distinctions.

It is to identify which distinctions matter, represent them explicitly and connect them in a form that can be understood consistently by people, software and AI.

Looking ahead

These modelling requirements shaped the design of the Finsight Semantic Foundation.

The next article will introduce its overall architecture, including the Business, Canonical, Physical and Mapping layers, the Semantic Repository, the compilation model, runtime services, and the way these components support AI-native financial data workflows.

• *AI-Native Financial Data Foundation