Suppose you open a security-master table and see:
SecurityIdISINIssuerIdProductTypeCurrencyMaturityDateStatus
It is tempting to think that the modelling problem is already visible.
There is a security, it has an issuer, a product type, a currency, a maturity date and a status. Perhaps we just need to turn the table into classes and properties.
But before we model anything, there is a more basic question:
What are we actually modelling?
Are we modelling the record, the financial thing, the identifier, or the business claim that the data is trying to express?
These are easy to blur together because financial systems routinely place them side by side. Ontology modelling starts by separating them.
That sounds obvious, but in practice it is one of the most important habits a modeller can develop.
1. The Bond Is Not the Bond Record
Imagine FatCat Bank has issued a bond.
That bond may appear in a security master, trading platform, risk system, settlement platform, market-data database and external vendor feed. Each system may contain a record representing the bond.
Those records may differ.
One may use an internal security identifier, another an ISIN. One may store the direct legal issuer, while another stores a parent entity used for risk aggregation. One may contain only current information, while another preserves historical versions.
Yet we may still be talking about the same financial instrument.
Conceptually:
Bond
│
┌────────┼────────┐
▼ ▼ ▼
Record A Record B Record C
The records matter, but they are not automatically the thing itself.
This becomes clearer when the records disagree.
Suppose one system says the maturity date is 2032 and another says 2033. That does not automatically mean there are two bonds. More likely, we have two representations making conflicting claims about what may still be one financial instrument.
That distinction matters because otherwise data inconsistency can accidentally become ontology.
A duplicated record can become a duplicated financial thing. A corrected value can appear to create a new entity. A system migration can look like a change in business reality.
So the first distinction is:
financial thing ≠ record representing the thing
There is a deeper ontological idea behind this distinction.
One influential tradition, associated with Barry Smith and realist ontology, argues that ontology should begin with the entities and relationships that exist in the domain rather than taking the concepts or information structures used to describe them as its starting point.[1]
For financial modelling, this does not mean that records, messages and documents are unimportant or somehow unreal.
A security-master record is a perfectly real information artifact.
The point is that it is a different kind of thing from the financial instrument it describes.
We therefore need to keep two questions separate:
What exists or happens in the financial domain? ≠How is information about it represented?
A bond record can change without the bond changing. A record can be duplicated while there is still only one bond. A record can contain an error without the bond itself somehow becoming erroneous.
This is why the distinction between the thing and its representation is not merely a database-design concern. It is an ontological distinction.
For now, I am using the word thing loosely. Later we will distinguish more carefully between financial entities, relationships, events, roles, states, observations and other kinds of meaning.
The important point here is simpler:
A database schema tells us how information has been represented. It does not, by itself, tell us what exists in the financial world.
2. Identifiers and Fields Are Representations Too
The same problem appears with identifiers.
Suppose a record contains:
ISIN = GB00FATCAT01
That value is not the bond.
It is an identifier used to identify something according to an identification scheme.
The distinction becomes obvious when the same security has an ISIN, a CUSIP, a SEDOL, an internal security ID and several vendor identifiers.
thing │ ├── identified by → Identifier A ├── identified by → Identifier B └── identified by → Identifier C
Identifiers are essential for linking systems, but identity and identification are different modelling questions.
An identifier tells us how something is referred to under a particular scheme.
Identity asks what makes several records, identifiers and representations refer to the same financial thing.
We will return to identity properly later in the series. For now, the important habit is simply not to collapse the thing into the code used to refer to it.
Even the apparently simple relationship:
Thing ── identified by ──> Identifier
may later need richer modelling.
If assignment, identification scheme, assigning authority, validity period or provenance matter, the identifier assignment itself may deserve to be represented.
But that is a modelling decision for later.
The first step is recognising that:
identity ≠identifier
Fields create a similar trap.
Suppose we see:
IssuerId = 48291
A data modeller may reasonably want to know which table 48291 joins to.
But before deciding how to represent that field in an ontology, we need to understand what Issuer means in this particular data source.
Perhaps 48291 identifies the legal entity directly associated with the issuance. Perhaps it identifies an ultimate parent. Perhaps it identifies an entity used by a risk process for aggregation. Perhaps it reflects a local convention that everybody understands but nobody has formally documented.
The field therefore gives us evidence about some business meaning. It does not automatically tell us what that meaning is.
A useful way to think about the modelling process is:
field ↓business interpretation ↓semantic claim ↓ontology representation
Notice what has happened.
We did not simply translate IssuerId into an ontology property.
We first asked what business relationship or claim the field was intended to express.
Perhaps the underlying meaning is that a legal entity participated as issuer in an issuance that produced the security.
A simplified first view might be:
Legal Entity ── participates as issuer in ──> Issuance │ ▼ Security
A richer ontology may later model the issuance, the issuer role and the participation explicitly.
The important point here is not the final pattern.
It is that the data gives us clues, but it does not give us the ontology for free.
3. A Financial Thing Is Not a Statement About It
Now consider another familiar record:
Bond A has a price of
101.25.
At first sight, that looks like a straightforward property of the bond.
But the meaning changes once we ask where the value came from.
Was 101.25 reported by a particular market-data source?
At what time?
Was it bid, ask, mid or close?
Was it observed in a market or produced by a valuation process?
A more accurate business statement might be:
Market Data Vendor A reported a price of 101.25 for Bond A at 16:30.
Now the meaning looks different.
The number is not simply an eternal characteristic of the bond. It forms part of a statement or observation about the bond.
thing ≠statement about the thing
This matters far beyond market data.
Suppose Agency A says that Bond A is rated BBB.
That does not necessarily mean BBB should simply become an intrinsic type or permanent characteristic of Bond A.
It may matter that a particular agency made a particular assessment at a particular time.
The same issue appears with valuations, classifications, risk measures, analyst opinions and many other forms of financial knowledge.
They may tell us something about a financial thing without being the financial thing itself.
Ontology modelling needs to recognise both.
4. Reality, Knowledge and Representation Need to Be Distinguished
We can now put these distinctions together.
It is tempting to describe reality, knowledge and representation as three layers:
FINANCIAL WORLDthingsrelationshipseventsconditions ↓KNOWLEDGE ABOUT THE WORLDstatementsobservationsclassificationscalculations ↓REPRESENTATIONSrecordsfieldsmessagesdocumentsidentifiers
This is useful as a first mental model, but we should be careful about what the diagram means.
These are not three separate universes.
A rating assessment is itself something that happens.
A valuation is performed by some process.
A security-master record exists in an information system.
A document is also a real artifact.
The distinction we need is therefore not simply between things that are real and things that are not. It is between different kinds of things and the different semantic jobs they perform.
A more useful way to frame the questions is:
WHAT EXISTS OR HAPPENS?Bond AFatCat BankIssuanceTradePayment ↓WHAT IS CLAIMED, OBSERVED OR DERIVED ABOUT IT?Bond A is rated BBBBond A was observed at 101.25Bond A was valued at 100.87 ↓HOW IS THAT INFORMATION CARRIED OR ENCODED?database recordmarket-data messagerating reportAPI responsespreadsheet
This brings us to another useful idea from realist ontology: aboutness.
Barry Smith and Werner Ceusters use aboutness to describe the relationship between information content and what that information is about.[2]
That maps naturally into finance.
A security-master record may be about Bond A.
A rating report may be about Bond A.
A valuation result may be about Bond A.
But none of those things is therefore Bond A.
Security Master Record │ │ about ▼ Bond ARating Report │ │ about ▼ Bond A
This gives us a more precise way to think about representation.
Suppose Agency A assigns Bond A a BBB rating.
Several things may now matter:
Bond ARating assessmentBBB rating assertionRating reportDatabase field containing "BBB"
They are related, but they are not interchangeable.
The rating assessment may be an activity carried out by the agency.
The resulting rating may express an assessment concerning Bond A.
A report may carry that information.
A database field may encode it for use by a particular system.
Flatten them all into:
Bond.rating = "BBB"
and some important meaning may disappear.
The same issue occurs with market prices.
When Market Data Vendor A reports a price of 101.25 for Bond A at 16:30, the number is not simply an eternal characteristic attached to the bond.
It belongs to a richer observation involving the thing observed, the value reported, the source, the time and potentially the type of price.
So instead of asking only:
What properties does Bond A have?
we may also need to ask:
What thing are we talking about?What happened?What is being claimed or observed about it?What information artifact carries that claim?What is that information about?
Potentially, all of these may matter to an ontology.
We may need to model the bond. We may need to model the rating assessment or price observation. We may need to represent the resulting assertion.
And where provenance matters, we may also need to know which source, document or system carried that information.
The important point is not that everything should become a separate ontology object. The important point is to recognise the distinctions before deciding which distinctions matter for the problem we are solving.
This becomes increasingly important later when we discuss observations, assertions, evidence and provenance.
The mistake is not modelling records, documents or statements. The mistake is modelling them without noticing what they are — and what they are about.
That is how representation quietly becomes reality.
5. Start from Meaning, Not from the Data Structure
Most financial modelling work begins with existing data, and that is entirely reasonable.
Given a table such as:
SECURITY---------------SecurityIdIssuerIdCurrencyCodeProductTypeStatus
we naturally ask about primary keys, data types, nullability, joins and mappings. Those questions matter, but they concern how information has been represented.
Ontology modelling needs an earlier step.
A representation question might ask:
Which field contains the issuer identifier?
The corresponding semantic question is:
What relationship or role is the word
Issuerintended to express?
A representation question might ask:
What is the data type of
Status?
The semantic question is:
What does that status say about the financial thing, and can the status change while the thing itself remains the same?
The same modeller may need to answer both kinds of questions. This is not a competition between data modelling and ontology modelling. It is a matter of sequence.
Before deciding how financial meaning should be encoded, mapped or stored, we first need to understand the meaning itself.
That is why ontology modelling should be meaning-first.
The available representation is an input to the investigation, not the thing that determines the answer.
Tables make this particularly easy to forget because they flatten very different kinds of meaning into the same rectangular structure.
Consider:
TRADE------------TradeIdProductTypeBuyerSellerTradeDateStatusPriceCurrency
At the schema level, these are simply fields. Semantically, they may be doing very different jobs.
Buyer and Seller may express roles played by parties in a transaction.
TradeDate locates something in time.
Status may describe a changing condition.
Price may represent an agreed economic term.
ProductType may classify what was traded.
Currency may identify something used to denominate an amount or economic term.
The difficulty is not merely that the fields have different data types.
They express different kinds of meaning.
The table places them side by side because that is useful for storage.
That does not mean they should all be represented in the ontology in the same way.
A mechanical transformation such as:
table → classcolumn → property
may produce a graph.
It does not necessarily produce a good ontology.
The missing step is semantic judgement.
6. Existing Models Are Inputs, Not Answers
The same principle applies to sophisticated industry and canonical models.
FINOS CDM, FpML, ISO 20022, FIX and internal canonical models can contain enormous amounts of valuable business knowledge, and they should absolutely inform ontology modelling.
But their structures exist for particular purposes.
A canonical model may be designed for interoperability.
A message standard may be designed for exchange.
A processing model may be designed around lifecycle execution.
A database schema may be designed for storage and performance.
Those purposes influence not only their structures, but also their abstractions and granularity.
So:
CDM Type ≠ automaticallyOntology Class
and:
CDM Attribute ≠ automaticallyOntology Property
Likewise, a message element is not automatically a financial entity. A canonical object is not automatically something that exists independently in the financial world.
This does not make those models wrong. It means they answer different modelling questions.
Suppose an industry model contains an object called Issuer.
The ontology modeller should not immediately ask how to reproduce Issuer as an OWL class.
The better question is:
What business meaning is this structure expressing?
Perhaps it represents a party participating in an issuance. Perhaps it is a convenient processing structure. Perhaps several different business meanings have been grouped under one canonical object.
Only after understanding that can we decide what belongs in the ontology.
Existing models are evidence — sometimes exceptionally good evidence — but the semantic judgement still has to be made.
We will later place ontology, canonical models and physical representations into a larger semantic stack.
For now, the important boundary is simple:
A representation of meaning is not automatically the definition of that meaning.
7. Ontology Modelling Requires Business Understanding
This is why ontology modelling is not primarily a syntax skill.
OWL can tell us how to express classes, properties, restrictions, equivalence and disjointness.
It cannot tell us what the financial world should look like.
It cannot decide whether Issuer is a fundamental type of party, something derived from a relationship, or something requiring richer contextual modelling.
It cannot decide whether two security records represent the same financial instrument.
It cannot decide whether a market price should be treated as a persistent characteristic or an observation made at a particular time.
Those are business-semantic judgements.
The sequence is:
business meaning ↓semantic judgement ↓formal representation
If the first two steps are wrong, the third step can make the error extremely precise.
A modeller who understands OWL perfectly but misunderstands the financial domain can therefore encode the wrong model with impressive precision.
Conversely, a financial expert may understand the distinction clearly but need help expressing it formally.
Good ontology modelling needs both:
business understanding +formal clarity
But the order matters.
Formal languages are good at expressing decisions.
They are not substitutes for making them.
AI increasingly helps with syntax, transformation and suggesting possible models. It can generate OWL. It can propose mappings. It can identify candidate classes and relationships.
But it should not be assumed to understand automatically what a local field, convention or business practice means inside a particular financial institution.
A field called Issuer, Exposure or Position may carry institution-specific meaning that cannot be recovered reliably from the label alone.
That makes semantic judgement more important, not less.
Someone still needs to decide whether the proposed meaning actually makes sense.
8. Look Through the Data
When beginning an ontology, we will often start with existing artefacts such as databases, spreadsheets, APIs, canonical models, messages, documents and terminology lists.
That is normal.
The trick is to look through them.
A schema is not something to ignore. It is evidence of how somebody has already understood and represented the business.
But we should question what it is telling us.
Instead of asking only what columns exist, ask what financial world the database is trying to describe.
Instead of asking only what identifier is stored, ask what thing is being identified.
Instead of asking only what value is recorded, ask what business claim, observation or term the value is expressing.
And instead of asking first how a structure should be encoded in OWL, ask what business meaning deserves to survive the translation.
The movement is something like:
representation ↓business interpretation ↓semantic meaning ↓ontology
Three questions are especially useful at the beginning:
What thing are we talking about?
What are we claiming, observing or saying about it?
How is that meaning represented, and where did it come from?
Those questions do not give us the ontology. They give us a much better place to start.
The shift is simple:
Start with:data structure ↓"How should I represent this?"becomesbusiness meaning ↓"What are we actually talking about?"
References
[1] Barry Smith, “Beyond Concepts: Ontology as Reality Representation,” in Formal Ontology in Information Systems: Proceedings of FOIS 2004, IOS Press, 2004, pp. 73–84.
[2] Barry Smith and Werner Ceusters, “Aboutness: Towards Foundations for the Information Artifact Ontology,” CEUR Workshop Proceedings, Vol. 1515, 2015.
Data Ninjago (Financial Data Architecture) 