In the previous article, I discussed several characteristics of financial services that need to be reflected in ontology modelling, particularly in capital markets and FICC.

Financial products are contractual and compositional. Trades evolve through lifecycle events and changing states. Meaning depends on roles, context, provenance and time. The same business object may also appear in multiple operational, analytical and regulatory representations.

This article presents the high-level architecture of the Finsight Semantic Foundation, my approach to modelling financial-domain meaning, particularly for capital markets.

The overall architecture

At its core, the Finsight Semantic Foundation consists of two closely connected parts:

• the Semantic Model;
• the Semantic Repositories.

The Semantic Model describes the financial domain and connects business meaning, canonical representation and institutional implementation.

The Semantic Repositories hold the governed source definitions through which that model is expressed, maintained and versioned.

The Finsight Semantic Foundation contains no running components.

It defines and governs financial meaning through a logical model and repository-based semantic artefacts. The repository loader, compiler, compiled snapshot and operational capabilities belong to the Finsight Semantic Runtime.

This article focuses on the two components inside the Foundation. The Semantic Runtime is introduced only to explain how the governed semantic definitions become operational.

Modelling the capital-markets business world

The architecture begins with the capital-markets business world being modelled.

That world contains observable entities and activities, such as trades, payments, market observations, lifecycle events and operational processes.

It also contains more abstract concepts that are essential to understanding them. These include contractual rights and obligations, economic terms, party roles, product structures, trade states, classifications, valuation concepts and business rules.

Some concepts can be observed through transactions, messages and system events. Others exist primarily as business meaning.

A payer role, contractual obligation, fixed-rate payout or trade state cannot be reduced to a single row, field or message. These concepts may be represented in data, but their meaning exists independently of any individual representation.

Similarly, a trade may appear in a trading platform, message, database table, regulatory report or canonical model. These are different representations of the trade rather than the business trade itself.

Systems and data structures provide views of the business world. They do not define the business world.

The purpose of the Semantic Foundation is to model that underlying meaning and connect it explicitly to the ways in which it is standardised and implemented.

The distinction between the main architectural elements can therefore be summarised as follows:

• The Semantic Model describes the domain logically.
• The Semantic Repositories hold and govern its formal definitions.
• The Semantic Compilation loads, validates, resolves and compiles those definitions.
• The Compiled Semantic Snapshot is the runtime-ready representation.
• Runtime capabilities make the compiled model available to applications and AI workflows.

1. The Semantic Model

The Semantic Model is the logical, ontology-based representation of the capital-markets domain.

Its central design principle is to keep business meaning, canonical representation and institutional implementation separate while connecting them explicitly.

The model contains four related layers:

• Business Layer;
• Canonical Layer;
• Physical Layer;
• Mapping Layer.

These are not four independent models. They are connected views of the same business world, with each layer serving a different purpose.

Business Layer

The Business Layer describes the capital-markets domain independently of any particular application, database schema or message format.

It includes concepts such as:

• trades and products;
• parties and roles;
• economic terms and payouts;
• rights, obligations and cashflows;
• lifecycle events and trade states;
• positions, valuations and market observations.

It defines what these concepts mean, how they relate and which rules govern their behaviour.

For example:

Trade
    has
Tradable Product
Tradable Product
    contains
Economic Terms
Economic Terms
    contain
Payouts
Party
    performs
Payer or Receiver Role
    within
Payout

The important point is that the Business Layer models the domain itself rather than the way a particular system stores or transmits information about it.

• A trade record in Murex is not the business trade. It is one system representation of that trade.
• A lifecycle message is not the lifecycle event itself. It is a message describing or communicating that event.
• A database field containing present value is not the valuation itself. It is a stored representation of a valuation result produced under a particular methodology, market context and calculation time.

Keeping these distinctions explicit provides a stable business reference point for the other layers.

Business meaning can remain stable even when applications are replaced, schemas are redesigned or data-processing technologies change.

Canonical Layer

The Canonical Layer provides structured, machine-readable representations of business meaning.

One of its most important design principles is that canonical concepts should be grounded, wherever possible, in recognised industry standards rather than invented independently for each implementation.

For FICC trades, products, economic terms and lifecycle events, the FINOS Common Domain Model, originally developed by ISDA, is the primary reference model.

Other areas may rely on different financial, regulatory or technical standards. Finsight does not assume that one standard can cover the entire financial domain.

Different domains may require different standards, controlled profiles or Finsight extensions. What matters is that the origin and intended meaning of each canonical concept are explicit.

The Semantic Model therefore records clear relationships between a Finsight canonical artefact and the standard on which it is based.

A canonical artefact may:

• directly adopt a standard concept;
• profile or constrain a standard concept;
• extend a standard concept;
• align with an equivalent concept where the structures differ.

For example:

Interest Rate Payout (Finsight canonical concept)
        based on or aligned with
InterestRatePayout (FINOS CDM concept)

This standards-backed approach provides a stronger semantic basis than creating an institution-specific canonical model from scratch.

It improves consistency, interoperability and traceability while still allowing controlled extensions where an industry standard does not fully cover the required business or implementation context.

Typical Canonical Layer artefacts may include:

• Observation;
• TradeState;
• TradableProduct;
• EconomicTerms;
• InterestRatePayout;
• PartyRole;
• PriceQuantity;
• Transfer.

The Canonical Layer is not intended to replace the Business Layer.

The Business Layer defines what a concept means in the domain. The Canonical Layer defines how that meaning is represented in a structured, standard-aligned and machine-readable form.

Physical Layer

The Physical Layer describes how the business world is implemented within a particular institution.

It includes:

• business and operational processes;
• applications and services;
• platforms and databases;
• schemas, tables and fields;
• files, messages and APIs;
• pipelines and processing jobs;
• calculations and controls;
• reports and regulatory submissions.

For example:

Application:
Murex
Physical object:
MUREX_IRS_TRADE
Physical field:
FIXED_RATE
Pipeline:
Murex Trade Canonicalisation

The Physical Layer makes the institutional implementation explicit without treating that implementation as the business definition.

A physical artefact may store, transport, transform, calculate or report information about the underlying business world.

The same business concept may appear in many physical forms.

A fixed contractual rate may be represented in a trading-system column, a message attribute, a canonical field, a valuation input and a regulatory-reporting field. These physical representations may use different names, structures, types and units.

The Physical Layer records those implementation-specific artefacts while preserving their distinction from the business concepts they represent.

This allows the model to describe the real institutional data estate without allowing the current data estate to define the meaning of the domain.

Mapping Layer

The Mapping Layer connects the Business, Canonical and Physical Layers.

It explains:

• how business meaning is represented canonically;
• how physical data populates canonical structures;
• how values are transformed or derived;
• which processes produce or consume the data;
• which rules validate a mapping;
• which actions an implementation supports.

A simplified trace may look like:

It may also include:

• transformation logic;
• data types and units;
• applicability conditions;
• effective dates;
• provenance;
• ownership;
• validation rules;
• approval status;
• implementation evidence.

The layers remain separate because they evolve for different reasons.

Business meaning may remain stable while an industry standard changes. A canonical representation may be upgraded while the source system remains unchanged. A source system may be replaced without changing either the business concept or its canonical representation.

The Mapping Layer preserves these distinctions while making the layers usable together.

Without this separation, business meaning, canonical structure and physical implementation tend to collapse into a single model. When that happens, a change in one area can incorrectly appear to be a change in the others.

For example, replacing a source table should not redefine the business meaning of a trade. Updating a CDM version should not automatically redefine how a client system currently stores its data. A local implementation constraint should not silently become part of the enterprise business definition.

The Mapping Layer allows these concerns to evolve independently while maintaining explicit traceability between them.

A shared modelling language

Across the four layers, Finsight uses a common set of modelling dimensions:

• Objects;
• Attributes;
• Relationships;
• Rules;
• Actions.

An object represents something the model needs to understand.

An attribute describes a characteristic of an object.

A relationship explains how semantic artefacts are connected.

A rule defines a constraint, derivation, classification, calculation or expected behaviour.

An action represents a meaningful operation that can be performed using the model.

These dimensions are applied across the layers, but their meaning depends on context.

A Business Layer object may represent a contractual obligation. A Canonical Layer object may represent a standard-aligned payout structure. A Physical Layer object may represent a database table or API payload.

The common modelling language allows these different artefacts to be described consistently without treating them as the same type of thing.

I plan to dedicate a later article to a more detailed discussion of these modelling dimensions.

2. The Semantic Repositories

The Semantic Model is a logical model. The Semantic Repositories are the governed source environments in which its formal definitions are stored, versioned and maintained.

Finsight separates these definitions into two connected repositories:

• the Finsight Semantic Repository;
• the Client Semantic Repository.

Finsight Semantic Repository

The Finsight Semantic Repository contains reusable semantic assets developed and maintained by Finsight Technologies Ltd.

These may include:

• shared capital-markets business concepts;
• reusable relationships and rules;
• standard-aligned canonical models;
• FINOS CDM alignments and controlled extensions;
• common modelling patterns;
• semantic action definitions;
• common operational concepts;
• schemas and validation contracts;
• governance and provenance metadata.

This repository provides a reusable starting point for implementations.

It avoids rebuilding common financial concepts, canonical structures and modelling patterns for every institution and use case.

However, it is not intended to describe a client’s complete business or data estate.

It provides reusable semantic foundations that can be adopted, profiled, extended or mapped to an institution-specific environment.

Client Semantic Repository

The Client Semantic Repository contains institution-specific definitions.

These may include:

• local business terminology;
• client-specific business extensions;
• proprietary products and classifications;
• internal rules and calculations;
• business and operational processes;
• applications and services;
• physical data objects and fields;
• source-to-canonical mappings;
• controls and data-quality rules;
• institution-specific semantic actions.

The Client Semantic Repository therefore does more than configure the Finsight model.

It formally represents the client’s own extensions, operational environment, physical data estate and implementation mappings.

A client may adopt a reusable Finsight business or canonical concept while defining its own physical representation and transformation logic.

For example, Finsight may provide a reusable definition for a fixed-rate interest-rate payout. The client repository may then define how that concept is represented in Murex, a data warehouse, an internal API and a regulatory-reporting pipeline.

The reusable meaning and the institution-specific implementation remain separate but explicitly connected.

How the repositories relate to the model

The repositories are not the Semantic Model itself.

A useful analogy comes from software engineering:

Software design
        ≠
Source-code repository
        ≠
Compiled executable
        ≠
Running application

Similarly:

Semantic Model
        ≠
Semantic Repositories
        ≠
Compiled Semantic Snapshot
        ≠
Semantic Runtime

The Semantic Model describes the financial domain logically.

The repositories hold the formal artefacts through which that model is defined, maintained and governed.

The Finsight Semantic Repository contributes reusable business semantics, canonical structures, rules and modelling patterns.

The Client Semantic Repository extends those definitions and adds institution-specific business concepts, physical assets, mappings and controls.

Together, the repositories provide the governed source material from which the Semantic Runtime constructs a client-specific compiled representation.

The repositories remain declarative. They contain definitions rather than running services.

This distinction is important because the same semantic repositories should be usable across different runtime technologies and deployment environments.

The underlying model should not depend on whether the runtime uses NetworkX, Neo4j, another graph engine, a relational representation or a combination of technologies.

I plan to write a dedicated article examining the structure of the Finsight Semantic Repository and how clients can construct and govern their own Client Semantic Repository.

Conclusion

The Finsight Semantic Foundation provides a governed way to describe the capital-markets business world and connect that meaning to standards and institutional implementations.

Later articles will examine the individual modelling layers, shared modelling dimensions, repository structure, compilation process and Semantic Runtime capabilities in more detail.

• *AI-Native Financial Data Foundation