So far, we have argued that financial ontology modelling should begin with the financial world rather than with ontology syntax.

That leaves a natural question:

What exactly are we going to model?

The answer is broader than securities, trades or legal entities.

A financial institution does not deal only with static things. Things enter relationships, agreements create obligations, trades happen, positions arise, cashflows become due, values change, risks are measured, exceptions occur, and people decide what to do next.

But before we model any of that, there is one more step.

We have to learn to look at the financial world differently.

A useful way to see the journey is:

Learn to see the financial world ontologically
          ↓
Model the things
          ↓
Model the changes
          ↓
Model the economic consequences
          ↓
Make organisational know-how explicit
          ↓
Put the meaning to work

This is not a checklist of everything that belongs in one ontology.

It is the path we will follow as the modelling questions become richer.

1. Learn to See the Financial World Ontologically

Financial technologists are used to working with representations.

We see tables, fields, messages, APIs, object models and reports. We learn where data is stored, how it is transported and what values particular systems expect.

That is necessary work.

But ontology modelling asks us to look through those representations.

If we see a security_id, we ask what thing it identifies.

If we see ISSUER, we ask whether it describes what an organisation fundamentally is or a role it plays.

If we see SETTLED, we ask whether it describes a kind of trade or a state the trade is currently in.

If two systems contain different records, we ask whether they represent different things or merely different representations of the same thing.

This is the first mental shift.

We stop treating the structure of the data as though it were automatically the structure of the financial world.

Instead, we start asking questions about meaning.

• What is the thing?
• What makes it the same thing over time?
• Is this difference really a different type?
• Is this a role, a state or a characteristic?
• Does this relationship carry meaning of its own?
• Which distinctions actually matter?

Before we can model finance ontologically, we have to learn to see finance ontologically. That does not mean learning a large vocabulary of ontology terminology first. It means developing the habit of questioning what the business concepts actually mean before deciding how to represent them.

2. Start with the Things

Suppose “FatCat Bank enters into an interest-rate swap with another bank”.

That one sentence already contains quite a lot of meaning.

There are two organisations. They participate in the transaction in particular capacities. There is a financial product. There is a trade. There are contractual terms defining what the parties have agreed. Those terms may establish rights and obligations, including obligations to make future payments.

Before we worry about what happens next, we already need to distinguish legal entities, roles, products, trades, agreements, terms, rights and obligations.

Those distinctions matter because these things are not interchangeable.

A legal entity is not the role it happens to play. A trade is not the financial product being traded. Contractual terms are not the same thing as the document in which they happen to be recorded. An obligation is not the payment that may later fulfil it.

This is one of the first challenges of financial ontology modelling: deciding what kinds of things exist in the domain, what makes them different, and which relationships between them carry business meaning.

Many modelling problems begin because these distinctions have been collapsed.

A database might identify an organisation as an ISSUER, store a security and its ISIN in the same record, or attach a position directly to an instrument. Those representations may be perfectly useful for the systems that created them, but they do not automatically tell us what the underlying financial things are.

Ontology modelling asks us to look beneath the representation.

Until the things and their relationships are reasonably clear, everything built on top of them inherits the ambiguity.

3. Then Something Happens

The financial world does not remain still.

Our swap may be quoted, executed and confirmed. Rates may be determined. Payment obligations become due. Payments occur. The trade might be amended. One party might novate its contractual position to another party. Eventually, the transaction reaches maturity.

Now a different kind of meaning appears.

Knowing that a trade exists is no longer enough. We also need to understand what happened to it.

An execution is an event. A payment is an event. An amendment is an event. A novation is an event.

But events are not the only way we describe change.

A trade may also be confirmed, matched, cleared, pending settlement or settled. Those words usually describe conditions of the trade, not different kinds of trade. Several of them may even apply at the same time because they describe different state dimensions.

Time becomes important too.

When did an event occur? When did its consequences become effective? During which period was a relationship valid? Was something true at trade date, settlement date or valuation date?

Then identity starts to become difficult.

If an order is amended, is it still the same order? If it is cancelled and replaced, has a new one been created? If a contractual relationship is novated, does the same relationship continue with a different party, or does one relationship terminate and another begin?

These are not merely questions about keeping history.

They are questions about what change means.

So the next area of modelling asks what happens to financial things, when those changes matter, and what remains the same through them.

That brings events, states, time, lifecycle and identity through change into the picture.

4. Then Ask What It Means Economically

Things exist. Things change.

But financial institutions ultimately care about the economic consequences of those things and changes.

Suppose our swap contributes to a portfolio. The portfolio contains or gives rise to positions. Those positions involve quantities or notionals. The swap produces future cashflows. Those cashflows depend on contractual terms such as rates, calculation periods and day-count conventions.

The portfolio is valued. Its value changes. P&L is calculated. Risk is measured.

Now consider a few apparently simple statements:

The portfolio has a position of £50 million.
The swap has a cashflow of £1.2 million.
The portfolio is worth £100 million.
Today’s P&L is £2 million.
The portfolio has £4 million of risk.

Each sounds straightforward.

Each can hide several different meanings.

What exactly does the £50 million describe? Is it quantity, notional, market value or exposure?

What does the £1.2 million cashflow represent? Is it a projected amount, a calculated amount, a payment obligation, or a payment that has actually happened?

What does the £100 million portfolio value mean? At what time was the portfolio valued? Under which methodology? Using which market inputs?

And what exactly is “£4 million of risk”? VaR? Expected loss? Stress loss? Counterparty exposure?

A financial number does not explain its own meaning.

This is why positions, quantities, cashflows, valuation, P&L and risk deserve modelling attention of their own.

A portfolio is not its valuation. A position is not its instrument. P&L is not simply a permanent property attached to a portfolio. A risk measure is not the same thing as the portfolio being measured.

The economic result has its own meaning, context and relationship to the financial things from which it was derived.

So another major modelling question is:

What economic consequences arise from the financial things and events we have modelled?

5. Then Ask How the Organisation Knows What to Do

Financial institutions do not merely describe the world.

They act in it.

Suppose a settlement fails. A system may tell us that the settlement status is FAILED. That is useful, but it does not tell an experienced operations analyst what to do next.

The analyst may know to inspect the settlement instruction, compare the account being used with the standing settlement instruction that was effective for the relevant counterparty and security on the settlement date, and determine whether the failure can be repaired.

They may know that one mismatch can be corrected routinely, another requires confirmation, and a third must be escalated. They may know who is authorised to approve a repair and which control prevents a settlement from being released until a particular condition is satisfied.

That knowledge is not simply another attribute of the failed settlement.

It is organisational know-how.

It may include decision criteria, procedures, exceptions, heuristics, responsibilities, authority and controls. Much of it may currently live in people, operating manuals, spreadsheets, system logic, policies and local practice.

Not all of that knowledge should become ontology. Not all of it should be automated either.

But if people, systems and AI are expected to work with the same financial meaning, important organisational know-how may need to become more explicit and structured.

That gives us another question:

How does the organisation interpret a financial situation and know what should happen next?

This is different from describing the trade itself. It is also different from recording what happened. It is knowledge about how the organisation responds to what happened.

6. Finally, the Meaning Has to Become Usable

At this point, we may have modelled a surprisingly rich financial world.

We have financial things and their relationships. We understand important changes. We can describe positions, cashflows, valuations and risk. We may also have explicit organisational knowledge about decisions, procedures and controls.

But none of this becomes useful merely because an ontology file exists somewhere.

The meaning has to connect to the rest of the institution.

Existing systems still have databases. Applications still expose APIs. Industry standards still matter. Messages still need to be exchanged. Canonical models still have a role. Analytics still run in their own technologies. AI systems still consume data and documents.

Ontology should not try to replace all of those representations.

Its role is different.

It provides an explicit model of important domain meaning that other representations can align to.

Conceptually:

Domain ontology
      ↓
Semantic foundation
      ↓
Data / Models / Services
      ↓
Applications / Analytics / AI

The wider semantic foundation may contain more than ontology. It might also contain mappings, institution-specific semantics, provenance, governance, procedures or other forms of operational knowledge.

That is an important boundary.

Ontology models domain meaning. The wider semantic foundation makes that meaning usable.

This prevents us from trying to force every semantic concern into the ontology itself.

It also allows existing standards, canonical models and physical systems to continue doing the jobs they are good at.

The objective is not one giant model replacing everything.

It is clearer meaning across different representations.

7. One Financial World, One Modelling Journey

We can now return to our interest-rate swap.

Before modelling anything, we first had to learn to see the financial world differently: not simply as records, fields and messages, but as things with identity, roles, relationships and meaning.

Then we began identifying the things themselves: organisations, products, trades, terms, rights and obligations.

Once those things started changing, events, states, time and identity became important.

Their economic consequences led us to positions, cashflows, valuation, P&L and risk.

And once something goes wrong, another kind of meaning appears again: the decisions, procedures, exceptions, authority and controls through which an organisation knows how to respond.

Eventually, all of that meaning has to connect to real data, systems and AI.

These are not unrelated subjects. They are one modelling journey.

First:

How should we look at the financial world?

Then:

What is there?

Then:

What happened?

Then:

What does it mean economically?

Then:

What does the organisation know how to do about it?

And eventually:

How can people, systems and AI use that meaning consistently?

That is the territory ahead.

We do not need to model all of it at once. We do not even need every ontology to cover all of it.

The important thing is to recognise the different kinds of meaning before we accidentally collapse them into one model.

And that brings us to the next question.

If ontology is going to help us preserve these distinctions, what exactly gives it that ability?

• *Financial Ontology Modelling