In the previous article, we started with a familiar security record and kept asking what the data was actually trying to describe.

That led to a simple but important principle:

Do not confuse the representation with the thing being represented.

A table, field, identifier or message is a representation. Before turning that representation into ontology structure, we need to understand the financial things, relationships and events that the data is trying to describe.

But discovering the meaning is only the first step.

Once we move from data structures to business meaning, we encounter another modelling trap:

Difference ≠ Type

Two things can differ without the difference necessarily telling us that they are fundamentally different kinds of things.

A GBP-denominated bond differs from a USD-denominated bond. An organisation acting as an issuer differs, in that situation, from one acting as an investor. A pending trade differs from a settled trade. A BBB rating differs from a BBB+ rating.

These are all meaningful distinctions. But they are not necessarily the same kind of distinction.

Some concern what something is. Others arise from relationships. Some describe changes through time. Others come from observations or assessments made under particular circumstances.

The central argument of this article is:

Finding a business difference tells us that there is something worth understanding. It does not, by itself, tell us that we have found a type distinction or what ontology construct should represent it.

Throughout this article, I use Difference ≠ Type as shorthand for that idea.

It does not mean that classes such as CallableBond, SettledTrade or InvestmentGradeBond are necessarily wrong. Such classes can be useful.

It means that discovering a business distinction is not enough to establish the ontological nature of that distinction.

Before asking:

What class should I create?

we first need to ask:

What kind of difference have I found?

And, where necessary:

What makes that difference meaningful?

1. A Difference Does Not Automatically Reveal a Type

Suppose we encounter the following statements:

Bond A is denominated in GBP.
Bond B is denominated in USD.
FatCat Bank is an issuer.
FatCat Bank is an investor.
Trade 123 is pending.
Trade 123 is settled.

Each expresses a meaningful distinction.

A natural modelling reaction might be to create:

Bond
 ├── GBP Bond
 └── USD Bond
Organisation
 ├── Issuer
 └── Investor
Trade
 ├── Pending Trade
 └── Settled Trade

Some of these classes may be useful. The problem is not the use of classes. The problem is the inference:

I found a business difference
        ↓  therefore
I found a different type of thing

That conclusion does not automatically follow. The same organisation may issue one bond and invest in another. The same trade may be pending at one time and settled later. The underlying thing can remain the same while something meaningful about it differs.

So the important lesson is:

A business distinction does not determine its own ontology structure.

Finding the difference is the beginning of the modelling problem, not the solution.

We still need to understand what produced that difference and what kind of semantic phenomenon it represents.

2. Grammar Hides Ontological Differences

Natural language makes this harder because very different claims often have exactly the same grammatical form.

Consider:

FatCat Bank is an organisation.
FatCat Bank is an issuer.
FatCat Bank is under investigation.

All three look like:

X is Y

But they do not appear to say the same kind of thing.

“Organisation” tells us something relatively fundamental about what FatCat Bank is.

“Issuer” appears to depend on FatCat Bank participating in an issuance or standing in a particular financial relationship.

“Under investigation” describes a condition that may begin and later end.

The grammar does not reveal those differences.

The same issue appears with a bond:

Bond A is a security.
Bond A is callable.
Bond A is investment grade.
Bond A is matured.

Again, the linguistic form is similar. But it does not follow that Security, Callable, InvestmentGrade and Matured have the same ontological status.

Barry Smith’s work on Basic Formal Ontology gives a useful theoretical basis for this distinction. BFO separates what a thing is from dependent features such as qualities, roles and dispositions.

That matters here because statements with the same grammatical form may describe very different kinds of reality.

Saying that FatCat Bank is an organisation is not the same kind of claim as saying that it is an issuer. The first concerns what kind of entity it is. The second depends on the role it plays in a particular financial relationship.

The broader lesson is simple:

Not everything we can say about a thing tells us what type of thing it is.

For financial ontology modelling, this means that we cannot simply extract nouns and adjectives from business language and turn them into classes.

Language gives us evidence about meaning.

It does not give us the ontology structure for free.

3. Data Structures Flatten Those Differences

Databases create the same problem from another direction.

Consider a familiar security record:

SECURITY
-----------
SecurityId
ProductType
Currency
Issuer
Status
Rating
Price

From the perspective of storage, these are simply fields on the same row.

Semantically, however, they may be doing very different jobs.

• “ProductType” may classify the security according to a product taxonomy.
• “Currency” may describe an economic characteristic.
• “Issuer” may express a relationship with another entity.
• “Status” may describe a condition that changes through time.
• “Rating” may record an assessment made by another organisation.
• “Price” may record an observation whose meaning depends on source and time.

The table deliberately flattens these distinctions because that is useful for storage and processing.

The ontology has a different responsibility. It needs to preserve semantic differences when those differences matter.

That is why this transformation is too simple:

database column
      ↓
ontology property

A field tells us that somebody decided to record a piece of information. It does not tell us what kind of information it is.

This connects directly to the previous article. The data structure belongs to the representation. The ontology is trying to understand what that representation is about.

Moving from one to the other therefore requires more than schema translation.

It requires semantic judgement.

4. Some Differences Come From Relationships

Consider again:

FatCat Bank is an issuer.

At first sight, Issuer looks like a category of organisation.

But suppose FatCat Bank:

issues Bond A
invests in Bond B
guarantees Loan C

The same organisation participates in all three situations. What changes is how it relates to other financial things.

This suggests an important question:

Does the distinction tell us what the thing is, or does it arise because of how the thing relates to something else?

Finance contains many descriptions of this form:

issuer
investor
borrower
lender
guarantor
custodian
counterparty
calculation agent

Many only make sense relative to another entity, agreement, transaction or process.

FatCat Bank does not stop being an organisation when an issuance terminates. Nor must it become a fundamentally different kind of organisation every time it enters another financial relationship.

BFO’s notion of a role gives us one useful way of thinking about this. A role depends on circumstances involving its bearer rather than simply describing what fundamental kind of thing the bearer is.

That does not mean that every financial concept such as Issuer must mechanically be implemented as a BFO Role.

The business meaning still needs to be examined.

The important lesson is:

A relationship-dependent distinction should not automatically be treated as a type distinction merely because business language gives it a noun.

5. Some Differences Come From Change

Now consider:

Trade 123 is pending.

Later:

Trade 123 is settled.

Suppose both statements refer to the same trade.

Something has changed. But the trade itself has not necessarily become a fundamentally different kind of financial thing. Its condition within a lifecycle has changed.

The same pattern appears in:

Account A is open.
Account A is closed.
Instruction A is pending.
Instruction A is completed.
Bond A is active.
Bond A is matured.

This gives us another useful question:

Can this distinction change while the underlying thing remains the same?

If the answer is yes, we should at least hesitate before treating the distinction as though it describes what kind of thing the entity fundamentally is.

This matters especially in finance because so much business meaning is temporal.

Trades progress through lifecycle events. Instructions change processing status. Contracts become effective and later terminate. Positions change as transactions occur. Assessments are revised.

A static classification can easily hide that temporal structure.

Again, this does not mean that a class such as SettledTrade is wrong.

There is an important difference between:

It is useful to retrieve all trades that are currently settled.

and:

Being settled tells us what kind of thing a trade fundamentally is.

Those are different modelling claims.

6. Some Differences Come From Observation and Assessment

Consider:

Bond A is BBB.

That looks straightforward.

But suppose:

Agency A rates Bond A BBB.
Agency B rates Bond A BBB+.

Or:

January:
Agency A rates Bond A BBB.
June:
Agency A rates Bond A BBB+.

Now:

Bond A is BBB

looks incomplete.

Important information has disappeared:

Who assigned the rating?
When?
Under which methodology?

The same issue appears with price.

Suppose we say:

Bond A hasPrice 101.25

while the market data says:

Source A   10:01   101.25
Source B   10:01   101.30
Source A   15:30   101.45

There is no necessary contradiction. All three prices may be legitimate. The apparent inconsistency appears only because the circumstances surrounding the observations have been removed.

Some information therefore does not simply describe an enduring characteristic of a financial thing. It records an observation, assessment or claim about that thing.

Finance contains many examples:

price
rating
valuation
risk measure
benchmark fixing
credit assessment
exposure calculation

For these, the right question may not be:

What value does this thing have?

It may instead be:

Who observed or assessed what, when, and under which conditions?

That is a different modelling problem.

7. Context Can Explain an Apparent Difference

Context becomes particularly important when two systems appear to disagree.

Suppose:

System A
Issuer = FatCat Bank Ltd

while:

System B
Issuer = FatCat Holdings plc

At first sight, this looks like a data-quality problem.

Which system is correct?

But suppose System A is a security-master system and records the legal entity directly associated with the issuance.

System B supports group-level risk aggregation and records the parent entity used for exposure aggregation.

The apparent contradiction now looks different.

The systems may not be answering the same question.

So rather than asking only:

Which issuer value is correct?

we need to ask:

Correct for what meaning?

Financial professionals often say:

It depends.

Sometimes that is exactly right.

But “it depends” should never be the end of the semantic analysis.

It should trigger another question:

Depends on what?

Compare:

Issuer has different meanings in different contexts.

with:

In the security-master process, Issuer means the legal entity directly associated with the issuance. In the group-risk process, Issuer refers to the parent entity used for exposure aggregation.

The first tells us that ambiguity exists. The second explains the ambiguity.

And because it is explicit, it can be challenged.

Does the security-master always use the legal issuer? How are special-purpose vehicles treated? Does the risk process use the immediate parent or ultimate parent? Can that corporate relationship change through time?

Those are useful modelling questions.

Context should explain a semantic difference, not hide it.

Context also does not automatically imply that different things exist.

Two systems may describe the same financial entity differently because they are making different claims about it.

Context helps us interpret those claims.

It does not solve every identity problem for us.

8. The Same Word Does Not Guarantee the Same Meaning

Large financial organisations create another difficulty: the same word is often reused for different things.

Consider:

Account

Depending on the application, this might mean:

bank account
custody account
securities account
trading account
general-ledger account
internal reporting bucket

The word is the same.

The meaning may not be.

same word
    ≠
necessarily same meaning

The reverse problem also occurs.

One system may use:

IssuingEntity

another:

LegalIssuer

and another:

SecurityIssuer

The labels differ.

But they may be expressing the same underlying business relationship.

different words
       ≠
necessarily different meaning

Terminology therefore provides evidence, not proof.

Definitions, relationships, behaviour and business use usually tell us much more.

The goal of ontology modelling is not simply to standardise vocabulary.

It is to make explicit what those terms refer to and how the things they refer to relate to one another.

9. The Risk Is a Semantic Category Mistake

We can now see why Difference ≠ Type matters.

Suppose we treat “Issuer” as a permanent kind of organisation.

What happens when the same organisation issues one instrument, invests in another and guarantees a third?

Suppose we treat “SettledTrade" as though settled trades are fundamentally different financial things.

What happens to Trade 123 while it moves from pending to settled?

Suppose we treat BBB as an intrinsic and permanent characteristic of Bond A.

What happens when another agency says BBB+, or when the rating changes?

Suppose we model:

Bond A hasPrice 101.25

without saying where or when that price was observed.

What happens when another legitimate price appears?

These problems may look like data inconsistencies.

Sometimes they are.

But sometimes the deeper problem is semantic.

A valid business distinction has been represented as the wrong kind of semantic phenomenon.

That is what I mean here by a semantic category mistake.

For example, we may treat something relationship-dependent as though it were intrinsic, something temporary as though it were permanent, or an observation as though it were a timeless fact about the thing itself.

These mistakes are dangerous because ordinary technical checks may not detect them.

The OWL can be syntactically valid. The graph can be internally consistent. The class hierarchy can look elegant. The queries can execute perfectly. And yet the model may still describe the financial world incorrectly.

A technically correct model can encode a semantic mistake with great precision.

The solution is not more syntax. It is better semantic judgement before the syntax is chosen.

10. Ask What Makes the Difference Meaningful

It is tempting now to replace one mechanical modelling method with another.

Instead of turning every noun into a class, we might build a checklist:

Type?
Role?
Relationship?
State?
Quality?
Classification?
Observation?

Those categories are useful.

But ontology modelling is not mainly an exercise in memorising which bucket every financial term belongs in.

The more important skill is learning to investigate why a distinction exists.

Consider:

FatCat Bank is an organisation.
FatCat Bank is an issuer.
Trade 123 is settled.
Bond A is investment grade.
Bond A is denominated in GBP.
Bond A has a price of 101.25.

Before choosing an ontology construct, ask what each statement is actually claiming.

Does the distinction describe what kind of thing something is?

Does it arise because of a relationship?

Can it change while the underlying thing persists?

Is somebody making an assessment?

Is it an observation associated with source and time?

Does its meaning depend on purpose, methodology, jurisdiction, aggregation basis or some other context?

These questions do not automatically produce the final ontology design.

They do something more important first.

They tell us:

What modelling problem are we actually dealing with?

Only then should we decide how to represent it.

The modelling sequence therefore changes from:

"What class should I create?"

to:

"What distinction have I found?"
          ↓
"What kind of difference is it?"
          ↓
"What makes the difference meaningful?"
          ↓
"Does its meaning depend on context?"
          ↓
"How should I represent it?"

This is the next step in the progression that began in the previous article.

Previous article
Representation ≠ Reality
Data representation
       ↓
What is this data actually about?
       ↓
Business meaning
This article
Difference ≠ Type
Business meaning
       ↓
What kind of distinction have I found?
       ↓
Semantic structure

The first problem is representation:

Do not mistake the structure of the data for the structure of the financial world.

The second problem is categorisation:

Do not mistake every meaningful business difference for a difference in fundamental type.

But once we become better at discovering meaningful distinctions, another problem appears.

There are almost always more distinctions we could model.

A security has an issuer, identifier, currency and maturity.

Then we discover issuance structures, corporate-group relationships, ratings, market observations, settlement processes, legal agreements, accounting treatments, collateral relationships, lifecycle events and risk views.

Follow those relationships far enough and almost everything connects to everything else.

So the next question is not:

Does more meaning exist?

It almost always does.

The next question is:

How much of that meaning should we model?

That is the subject of the next article.

First understand what the data is about. Then understand what kind of difference you have found. Only then decide how to model it.

• *Financial Ontology Modelling