In the previous blog post, we introduced the four semantic layers of the Finsight Semantic Foundation: the Business, Canonical, Physical and Mapping Layers. Together, these layers organise financial meaning across business concepts, industry-aligned models, real-world systems and the mappings that connect them.

But defining the layers is only the beginning. We also need a consistent modelling structure for describing the artefacts within them.

Ontology provides that structure.

In financial services, this requires more than defining terms such as Trade, Party, Position, Payout or Cashflow. It requires a consistent way to describe what these things are, what characteristics they have, how they are connected, what conditions govern them and what can be done with them.

A practical financial ontology can therefore be organised around five foundational elements:

• Objects
• Attributes
• Relationships
• Rules
• Actions

These elements are established practices in ontology, domain modelling and operational semantic platforms. They are not unique to Finsight.

Within the Finsight Semantic Foundation, they are applied consistently across financial business concepts, canonical representations, physical data, mappings, controls and executable workflows.

Together, they provide the grammar through which financial meaning can be defined, connected, governed and used.

Objects: what exists

Objects represent the things that matter within a financial domain. They may describe business entities, contractual structures, events, observations, data artefacts or operational processes.

Typical business objects include Trade, Tradable Product, Party, Position, Payout, Cashflow, Lifecycle Event, Market Observation and Valuation.

Other semantic layers contain different kinds of objects. A canonical object may represent an InterestRatePayout or TradeState. A physical object may represent a table, file, message, API or stream. A mapping object may describe how a source field is transformed into a canonical attribute.

The important point is that an object is defined by what it represents, not merely by where it is stored. For example, Trade is a business object, while MUREX_IRS_TRADE is a physical data object. They are connected, but they are not the same thing.

The Trade represents something recognised by the business. MUREX_IRS_TRADE represents how a particular application stores information about it.

Keeping these objects separate allows business meaning to remain stable when systems, schemas or implementation technologies change. A source platform may be replaced. A physical table may be redesigned. The meaning of a Trade should not change with it.

Attributes: what describes an object

Attributes describe the characteristics of an object.

A Trade may have a trade identifier, execution timestamp, trade date, contractual state and clearing status. A Fixed Rate Payout may have a fixed contractual rate, notional amount, payment currency, payment frequency and day-count convention. A physical data object may contain fields such as TRADE_ID, FIXED_RATE, NOTIONAL and CURRENCY.

However, an attribute should not be understood as an isolated field name. A field called RATE, for example, could represent a fixed contractual rate, floating-rate spread, coupon, strike, discount rate or observed market rate.

Its meaning depends on the object that owns it and the context in which it is used. The semantic statement, “A Fixed Rate Payout has a Fixed Contractual Rate”, is therefore more precise than defining a generic attribute called Rate.

The same meaning can then be traced through the architecture.

This diagram describes model-level relationships.

The physical field is mapped to the canonical attribute. The canonical artefact is not a physical object, and the mapping does not imply that the two artefacts are the same.

At runtime, the value held in the physical field may be transformed and used to populate an instance of the canonical attribute.

For example:

Physical value 2.50 → percentage-to-decimal transformation → canonical value 0.025.

Separating artefact mapping from runtime data flow avoids an important source of confusion.

Relationships: how meaning is connected

Financial meaning rarely exists within one isolated object. A trade has a product. A product contains economic terms. Economic terms contain payouts. Parties perform roles within those payouts. Lifecycle events change the state of the trade. These connections are represented through relationships.

Relationships allow concepts to remain separate while still forming a connected model. This is particularly important in finance because an object often acquires meaning through the role it performs.

A Party may be a buyer in one trade, a seller in another, a payer in one payout, a receiver in another or a calculation agent under an agreement. The Party object alone does not express these differences. The relationship provides the context.

Relationships also connect semantic artefacts across layers. A business concept may be represented by a canonical artefact. A physical field may map to a canonical attribute. A transformation may be executed by a pipeline. A validation rule may protect a business expectation. A workflow may depend on the resulting data.

These connections make it possible to answer practical questions:

• Which canonical artefact represents this business concept?
• Which industry standard is the canonical artefact based on?
• Which physical field maps to the canonical attribute?
• Which transformation is applied?
• Which rule validates the result?
• Which pipeline executes the mapping?
• Which workflow depends on it?
• Who owns and approved the artefact?

Without these relationships, the ontology would remain a collection of separate definitions. With them, it becomes an operational semantic model.

Rules: what must be true

Rules describe the conditions that govern objects, attributes, relationships and actions. They may express business constraints, structural requirements, lifecycle conditions, classification logic, data quality expectations or execution policies.

In financial services, related rules may exist at several levels.

• A business rule may state: A fixed-rate payout must contain a fixed contractual rate.
• A canonical validation rule may state: InterestRatePayout.rateSpecification.fixedRate must be present when the payout is fixed.
• A physical data quality rule may state: MUREX_IRS_TRADE.FIXED_RATE must not be null for a fixed-leg interest rate swap.

These rules describe related expectations, but they are not identical. The business rule defines what the financial concept requires. The canonical rule validates the standardised representation. The physical rule validates the source or target implementation.

Keeping these rules separate preserves the purpose of each layer. Connecting them provides traceability. A failed physical data rule can therefore be traced to the canonical attribute it affects and the business expectation that explains why the value is required.

This allows a platform to explain more than the fact that a check failed. It can explain why the check exists, which business concept is affected, which mapping supplied the value and which downstream workflows may be exposed.

Rules may also govern permitted lifecycle transitions, required party roles, product qualification, mapping approval, regulatory readiness, evidence sufficiency and AI execution.

For example:

A trade cannot be classified as cleared unless a recognised clearing venue is present.

Or:

A hypothesis cannot be promoted to a verified root cause without supporting evidence.

The first governs financial classification. The second governs AI behaviour.

Both can be represented as governed rules with ownership, versioning, approval, effective dates and execution scope.

Actions: what can be done

Objects, attributes, relationships and rules describe the structure and valid state of the domain. Actions describe behaviour and change.

In financial services, actions may include executing a trade, amending economic terms, cancelling a trade, novating a contract, calculating a cashflow, generating a payment schedule, publishing a lifecycle event, validating a mapping, onboarding a data feed or investigating an exception.

An action should not be treated as an isolated function name. It can be connected to the object on which it operates, the attributes it reads or changes, the rules that permit it, the evidence it requires, the workflow that performs it and the outputs it produces.

For example, an Amend Trade action operates on a Trade, checks whether the trade is in an amendable state, produces a Lifecycle Event and changes the Trade State.

This allows the ontology to describe not only what a Trade is, but also how it may change and under which conditions that change is permitted.

Actions are particularly important in an operational ontology because they connect semantic meaning to execution. A data-feed onboarding workflow may inspect a source schema, identify business concepts, select canonical targets, generate mappings, apply transformations, validate required attributes and publish an approved mapping.

Each step uses the ontology. The workflow reads physical objects and attributes, follows relationships to business and canonical concepts, evaluates rules and performs governed actions.

The semantic model therefore does not sit outside the workflow as documentation. It participates directly in how the workflow operates.

Applying the ontology elements across semantic layers

Within the Finsight Semantic Foundation, the five elements are used across the Business, Canonical, Physical and Mapping Layers. Each layer describes a different view of the financial domain, but the modelling grammar remains consistent.

At the Business Layer, an object may be a Fixed Rate Payout, with Fixed Contractual Rate as an attribute, a relationship to an Interest Rate Swap, a rule requiring the rate to be present and an action to calculate the fixed cashflow.

At the Canonical Layer, the corresponding object may be InterestRatePayout, with rateSpecification.fixedRate as an attribute, a relationship to EconomicTerms, a validation rule requiring fixedRate and an action to validate the canonical payout.

At the Physical Layer, the object may be MUREX_IRS_TRADE, with FIXED_RATE as an attribute, a mapping relationship to the canonical fixedRate, a rule requiring the field to be populated and an action that extracts and transforms the value.

At the Mapping Layer, the object may be a Fixed Rate Mapping, with source path, target path and transformation as attributes, relationships connecting the physical and canonical fields, an approval rule and an action that executes the mapping.

The layers remain separate because they serve different purposes. The ontology elements do not collapse them into one model. They provide a consistent way to describe the artefacts within each layer and the relationships between them.

This distinction is important. A canonical artefact may be modelled as an object in the general ontology sense, but it is a canonical object, not a physical object. A physical field maps to a canonical attribute at the model level. At runtime, the physical value may be transformed and used to populate a canonical data instance.

From ontology to executable financial semantics

The purpose of these five elements is not only to improve documentation. They allow the semantic foundation to be consumed by applications and AI.

• Objects can be resolved
• Attributes can be inspected.
• Relationships can be traversed.
• Rules can be evaluated.
• Actions can be executed.

Consider an AI workflow investigating a missing fixed cashflow.

The exception affects a Trade. The Trade contains a Fixed Rate Payout. The payout requires a Fixed Contractual Rate. That business attribute is represented by a canonical fixedRate, which is mapped from MUREX_IRS_TRADE.FIXED_RATE. A validation rule requires the value to be present, while a processing pipeline executes the mapping.

The AI workflow does not need to infer these connections from table names, source code or loosely written documentation.

The semantic path is already represented.

The workflow can retrieve evidence, evaluate the mapping execution, validate the source value, trace affected downstream processes and generate a supported hypothesis. This is how ontology moves from domain description into operational use.

Conclusion

Objects, attributes, relationships, rules and actions are established elements of ontology and operational semantic modelling. Their importance lies not in the terminology itself, but in how they are applied. Within financial services, they provide a consistent way to describe business meaning, canonical representation, physical data, mappings, controls and executable workflows.

• *AI-Native Financial Data Foundation