In the previous article, I introduced the high-level overview of the Finsight Semantic Foundation. The foundation consists of two main parts: the Semantic Model and the Semantic Repositories.

This article focuses on the first component: the Finsight Semantic Model. The model is organised into four connected layers: the Business Layer, the Canonical Layer, the Physical Layer, and the Mapping Layers connecting them.

The purpose of this structure is to keep business meaning, standardised representation and institutional implementation separate, while still connecting them into one traceable model.

This separation matters because the same financial concept may appear differently in business language, industry standards, trading systems, data platforms, reports and regulatory processes. Those representations are related, but they are not the same artefact.

Why a layered model is needed

Consider the fixed contractual rate of an interest-rate swap.

It may appear in three different forms:

1) Business concept 
   Fixed Contractual Rate
2) Canonical representation
   InterestRatePayout → Rate Specification → Fixed Rate
3) Physical implementation
   MUREX_IRS_TRADE.FIXED_RATE

At first glance, these may look like three names for the same value. They are not.

• The first describes what the value means in the business.
• The second defines how that meaning is represented in a common, machine-readable structure.
• The third identifies where one institution stores the value.

They differ in purpose, ownership, lifecycle and level of abstraction. The Finsight Semantic Model preserves those differences and connects them explicitly. The Mapping Layer records the governed relationships between them.

What goes wrong without this separation

When business, canonical and physical artefacts are collapsed into one model, business meaning quickly becomes tied to the systems that happen to store the data. A trade or payout is then understood through the structure of one application rather than through its underlying economic meaning. Replacing that application can appear to change the business concept itself, even when nothing has changed economically.

The problem becomes more visible when several systems represent the same concept differently. They may use different names, structures, units or levels of granularity. Without a separate business meaning and a common canonical representation, it becomes difficult to determine whether those fields are genuinely equivalent or merely look similar.

Technical lineage can also be mistaken for semantics. A lineage path may show that a value moved from a source field through a pipeline into a target table, but it does not explain what the value means, why it is required or whether the transformation preserves its business meaning.

Over time, the canonical model itself can become unstable. Instead of acting as a durable semantic contract, it gradually reflects the structures of whichever source systems are currently most influential. When those systems change, the canonical model changes with them.

This is also a problem for AI. Schema names and documentation fragments may help an AI system locate data, but they do not provide enough governed context to distinguish business meaning from canonical structure and physical implementation. The AI may recognise labels without understanding the relationships behind them.

The layered model avoids this collapse by making each concern explicit while preserving the governed connections between them.

1. The Business Layer

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

It models the things that exist in the business world, how they relate and which rules govern their behaviour.

Typical Business Layer concepts include:

• Trade;
• Product;
• Party;
• Role;
• Contract;
• Economic Terms;
• Payout;
• Obligation;
• Cashflow;
• Lifecycle Event;
• Trade State;
• Position;
• Valuation;
• Market Observation.

The Business Layer answers questions such as:

• What is a trade?
• What economic terms define a product?
• Which party performs which role?
• What obligations arise from a contract?
• How does a trade change through lifecycle events?
• Which cashflows are expected?
• What information is required for valuation?

The goal is not to reproduce the terminology of one system. It is to create a stable model of the underlying business meaning.

Example: an interest-rate swap

A simplified business view of an interest-rate swap might be expressed as:

This describes the contractual structure of the product. It does not yet say how the swap is represented in a canonical schema or stored in Murex, Calypso, a data warehouse or a regulatory report.

2. The Canonical Layer

The Canonical Layer provides a structured, machine-readable representation of the business domain.

It acts as a semantic contract between business meaning and institutional implementation.

One of the most important design principles is that canonical concepts should have a clear origin in recognised industry standards wherever suitable standards exist. The canonical model should not invent a parallel financial language without good reason.

For FICC trades, products, economic terms and lifecycle events, the FINOS Common Domain Model (CDM) is the primary reference. Other domains may rely on different financial, regulatory or technical standards.

Finsight does not assume that one standard can cover the entire financial domain. An institution may need multiple standards, controlled profiles and Finsight extensions. What matters is that the origin and status of every canonical concept are explicit.

The model therefore records whether a Finsight canonical artefact:

• directly adopts a standard concept;
• profiles or constrains a standard concept;
• extends a standard concept;
• aligns with an equivalent concept where the structures differ;
• has no suitable external standard and is defined as a governed Finsight concept.

This relationship is part of the model, not merely a statement in documentation. It provides traceability from the Finsight artefact to its standard origin and makes any profiling or extension visible.

This standards-backed approach improves consistency and interoperability while still allowing controlled adaptation to institutional requirements.

Typical Canonical Layer artefacts may include:

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

The Canonical Layer answers questions such as:

• How is a business concept represented consistently?
• Which canonical object contains a particular attribute?
• Which industry standard is the concept based on?
• Has the standard concept been adopted, profiled, extended or aligned?
• How are complex products decomposed into reusable structures?
• Which structure should downstream applications consume?
• How can different source systems map into one common representation?

Business meaning versus canonical representation

Consider the fixed contractual rate again.

In the Business Layer:

Fixed Contractual Rate

In a simplified canonical view:

InterestRatePayout
        contains
Rate Specification
        contains
Fixed Rate

The Business Layer explains what the rate means. The Canonical Layer explains how that meaning is represented within a structured model.

This distinction matters because a canonical representation may change through standards evolution, schema versioning, profiling, implementation constraints or controlled extension. The underlying business meaning may remain stable while its canonical representation evolves.

Canonical structures are semantic contracts

A canonical model should do more than standardise field names.

For an interest-rate swap, a simplified canonical structure may be:

Different source systems may store the swap differently, but they can map into the same governed structure.

3. The Physical Layer

The Physical Layer describes how the financial domain is implemented within an institution.

It covers both technology and operational implementation.

Typical Physical Layer artefacts include:

• applications and services;
• databases, schemas, tables and fields;
• files, messages, APIs and event topics;
• pipelines and calculations;
• controls and exception stores;
• reports and regulatory submissions.

The Physical Layer answers questions such as:

• Where is the data stored?
• Which application owns it?
• Which process produces it?
• Which pipeline transforms it?
• Which field contains the value?
• Which service consumes it?
• Which control validates it?
• Which downstream processes depend on it?

Example physical implementation

For the fixed contractual rate, the Physical Layer might include the Murex application, its reporting database, the MUREX_IRS_TRADE table, the FIXED_RATE column, the canonicalisation pipeline that reads and transforms the value, and the target platform where the canonical trade is stored.

Together, these artefacts describe how the institution stores, processes and moves information about the fixed rate. They do not redefine what the fixed contractual rate means in business terms.

A physical representation is not the business object

This distinction is central to the model.

Murex trade record      ≠     Business trade
Lifecycle message       ≠     Lifecycle event
Present-value field     ≠     Valuation
Cashflow table row      ≠     Payment obligation

A physical artefact may store, transport, transform, calculate or report information about a business object, but it is not the business object itself.

For example, MUREX_IRS_TRADE.FIXED_RATE may hold the value used to represent a fixed contractual rate in a particular Murex reporting structure. The column is a physical implementation artefact. The fixed contractual rate remains a business concept whose meaning exists independently of that table, database or application.

Keeping these concepts separate allows the same business meaning to be connected to different systems, schemas, messages and data platforms without making any one physical representation the definition of the business itself.

4. The Mapping Layer

The first three layers describe different views of the financial domain. The Mapping Layer connects them.

Without mappings, the layers would remain separate sets of definitions. With mappings, they become an operational semantic model.

The Mapping Layer answers questions such as:

• Which canonical artefact represents a business concept?
• Which standard is the canonical artefact based on?
• Which physical field populates a canonical attribute?
• Which transformation must be applied?
• Which rule validates the result?
• Which pipeline executes the mapping?
• Who owns and approved it?
• When is it effective?
• Which workflow depends on it?

A simple semantic trace

The fixed-rate example can be represented as:

Business Layer
Fixed Contractual Rate
        ↓ represented by
Canonical Layer
InterestRatePayout → Rate Specification → Fixed Rate
        ↑ populated from
Physical Layer
MUREX_IRS_TRADE.FIXED_RATE

Mapping types

The Mapping Layer can contain several types of relationship.

Standard-to-canonical mapping

Records the industry origin of a canonical artefact.

FINOS CDM InterestRatePayout
        adopted / profiled / extended / aligned by
Finsight Interest Rate Payout

Business-to-canonical mapping

Connects business meaning to a structured representation.

Fixed Contractual Rate
        represented by
Canonical Fixed Rate

Physical-to-canonical mapping

Connects institutional data to the canonical structure.

MUREX_IRS_TRADE.FIXED_RATE
        populates
Canonical Fixed Rate

Process mapping

Connects a mapping to the pipeline or service that performs it.

Murex Trade Canonicalisation Pipeline
        executes
Fixed-Rate Source Mapping

Rule mapping

Connects a semantic expectation to an implementation control.

Fixed-rate payout requires a fixed rate
        enforced by
FIXED_RATE_NOT_NULL Control

Action mapping

Connects semantic artefacts to the capabilities and workflows that use them.

Fixed Contractual Rate
        supports
Assess Valuation Readiness
Fixed-Rate Source Mapping
        supports
Trace Data Lineage
Validation Rule
        supports
Investigate Missing Cashflow

These mappings make the model usable by data platforms, governance capabilities and AI workflows. The model becomes executable context rather than static documentation.

All layers together

With all the four layers together, the semantic model can now answer different kinds of questions.

Business question

What fixed-rate information is required for an interest-rate swap?

The model resolves the relevant payout and business rule.

Standards question

Which industry standard is this canonical payout based on, and has the standard structure been extended?

The model traces the canonical artefact to its standard origin and identifies any profiling or extension.

Data question

Which physical field provides the fixed rate?

The model follows the business concept through the canonical representation to the source field.

Lineage question

Which pipeline transforms the fixed rate?

The model identifies the process attached to the governed mapping.

Data-quality question

Which control should detect a missing fixed rate?

The model connects the business expectation to the canonical constraint and physical control.

AI workflow question

Why was the trade not ready for valuation?

An AI workflow can retrieve the semantic path, combine it with operational evidence and determine whether the required rate was absent in the source, incorrectly mapped, rejected by validation or lost during processing.

Conclusion

The four layers serve different purposes.

The Business Layer defines what financial concepts mean. The Canonical Layer represents those concepts through consistent, standards-backed structures. The Physical Layer describes how an institution stores, processes and controls the data. The Mapping Layer records the governed relationships that connect the other three.

Keeping these concerns separate allows business meaning to remain stable when systems change, while canonical structures and physical implementations can evolve independently. Connecting them through governed mappings makes the complete model traceable and operational.

The result is more than a collection of definitions or a traditional source-to-target mapping catalogue. It provides the connected semantic context required for data discovery, lineage tracing, readiness assessment, mapping automation, exception investigation and governed AI workflows.

The next article will introduce the shared modelling language used across these layers: the five semantic dimensions through which concepts, relationships, rules, processes and actions are defined and connected.

• *AI-Native Financial Data Foundation