Finance has a reputation for being difficult, and for good reason.

Even apparently simple concepts become complicated once we look closely at the real financial world. A bond involves an issuer, a security, identifiers, contractual obligations, payments, prices and lifecycle events. A derivative can bring in multiple parties, economic terms, rights, obligations, amendments, novations and settlement.

Much of that complexity is real. We cannot make it disappear simply by choosing a nicer data model.

Ontology has a reputation for being difficult too. Mention ontology modelling and many technologists immediately think of classes, individuals, properties, axioms, formal logic, RDF and OWL. Put finance and ontology together, and financial ontology modelling can sound as though we have deliberately combined two difficult subjects to create a third one.

But there is an important difference.

Finance is difficult because the financial world itself can be complicated.

Ontology does not need to be difficult simply because of the way we choose to approach it.

A large part of the problem is that ontology is often introduced backwards.

1. Ontology Often Arrives Backwards

Ontology is often introduced through the machinery used to represent it.

We learn about classes and individuals, object properties and data properties, domains and ranges, restrictions and cardinalities. Before long, we may be looking at RDF triples or OWL expressions.

All of those concepts have their place.

But they answer the wrong first question.

Imagine that we want to model a simple financial situation. FatCat Bank enters into an interest-rate swap with another bank. The agreement creates payment obligations. Rates are determined periodically. Payments become due. The trade may later be amended, novated or terminated.

If we start with ontology syntax, we might immediately ask:

Which things should be classes? Which relationships should be object properties? Do we need a restriction here? Should this relationship have cardinality one?

Those are legitimate questions.

But we have skipped something more important.

We have not yet decided what the financial situation means.

Before worrying about OWL, we need to understand what is actually there. Is the execution the same thing as the trade? Are the contractual terms the same thing as the agreement? Is a payment obligation the same thing as the payment that eventually fulfils it? Does an amendment change the existing trade, or create something new?

Those are the modelling questions.

Only after answering them does it become useful to ask how the resulting meaning should be expressed formally.

The more natural direction is therefore:

Financial situation
        ↓
Business meaning
        ↓
Modelling decisions
        ↓
Ontology
        ↓
Formal representation

This may sound obvious, but it changes the experience of ontology modelling considerably.

Instead of learning a vocabulary of ontology constructs and then looking for somewhere to use them, we allow the financial problem to tell us which distinctions we need.

Sometimes the problem will lead us to identity.

Sometimes to roles.

Sometimes to states, events, composition or time.

And sometimes the right answer will be that we do not need a sophisticated ontology construct at all.

Start with the financial world. Understand the meaning. Then build the model.

The formal terminology can come when it helps us express that understanding more precisely.

2. The Difficult Part Is Not the Syntax

This is the point that is easiest to miss.

Suppose we have decided that issuer is a role rather than the fundamental identity of a legal entity.

Writing an OWL class or relationship to express that decision is not necessarily the hardest part.

The harder questions came before it.

What exactly is the entity? What makes it the same entity over time? What makes the issuer role true? What is it an issuer of? Does that role arise from an issuance, a security, a contractual relationship, or some combination of them?

Those are questions about financial meaning.

OWL cannot answer them for us.

It can help us state our answer precisely once we have made the modelling decision. It can help expose inconsistencies. A reasoner may derive consequences from the commitments we have made.

But valid syntax does not guarantee valid meaning.

We can write a perfectly valid ontology that models the financial world badly.

The same problem appears everywhere.

Is SETTLED a type of trade, or a condition that a trade can enter and leave?

Is a callable bond a fundamentally different kind of thing from every non-callable bond, or is callability one dimension of its economic structure?

Is VaR a property sitting inside a portfolio, or the result of assessing that portfolio under a particular method and set of assumptions?

None of these questions is primarily about OWL syntax.

They are modelling judgements.

That is why becoming an expert in ontology syntax is not the same thing as becoming good at ontology modelling.

The difficult part is learning to recognise when different kinds of financial meaning have been collapsed together.

3. Look Through the Representation

Financial technologists spend much of their working lives looking at representations.

A database table might contain fields such as security_id, issuer_id, status, position and market_value.

It is tempting to treat those fields as though they have already told us what the ontology should contain.

But they have not.

security_id might identify a security. It is not necessarily the security itself.

issuer_id may point to a legal entity playing an issuer role.

status may represent one particular state dimension among several.

position may be an aggregation calculated for a particular account, portfolio or reporting basis.

market_value may be the result of a valuation performed at a particular time and under a particular method rather than an intrinsic property of the portfolio.

The database schema tells us something extremely useful: how one system represents information.

The ontology asks a different question:

What does that information mean in the financial world?

Sometimes the schema is an excellent guide. Sometimes it reflects implementation compromises, historical naming, reporting requirements or the needs of one particular application.

Ontology modelling therefore requires us to look through the representation rather than simply reproduce it.

This is why ordinary questions can be so powerful.

When somebody gives us an identifier, we can ask whether it is the thing or something that identifies the thing.

When somebody describes an organisation as an issuer, manager, custodian or buyer, we can ask whether that describes what the organisation is or a role it is playing.

When we see SETTLED, we can ask whether it describes a type of trade or a state of a trade.

When we see a portfolio with a value of £100 million, we can ask whether that value is part of the portfolio itself or the result of valuing it in some context.

These questions are simple.

The modelling consequences are not always simple.

That is precisely why they are useful.

4. Model Enough Meaning

Once people become comfortable with ontology modelling, another danger appears.

We can start enjoying the model too much.

Every relationship can become an entity. Every value can acquire its own context object. Every possible distinction can become another class. Every concept can be split into three more precise concepts.

The result may be ontologically sophisticated and practically unbearable.

Financial reality is already complicated. Our job is not to recreate every possible detail simply because we can.

The useful question is:

Which distinctions matter for the problems this model needs to solve?

If an identifier’s authority, validity period and assignment history matter, the identifier relationship may deserve richer treatment.

If they do not, a simpler model may be enough.

If a relationship carries important facts of its own, such as time, status or contractual context, we may need to represent that relationship explicitly.

If it does not, a direct typed relationship may be clearer.

If a position needs to be treated as something with continuing identity, that identity matters. If the business only requires an as-of aggregation under a defined basis, creating an elaborate enduring Position entity may add more confusion than meaning.

The goal is not maximum semantic detail.

It is sufficient semantic clarity.

Model enough meaning to remove the ambiguity that matters.

This is one of the most important practical principles in ontology modelling.

Too little modelling and important distinctions disappear.

Too much modelling and those distinctions disappear beneath machinery.

5. Ontology Is Not Another Data Model

This also explains why ontology modelling should not become a more elaborate form of database modelling.

A database model has an important job. It decides how information should be structured, stored, indexed and constrained for particular applications.

A canonical model has another important job. It can provide common representations through which systems exchange information.

An industry model can provide shared structures for a particular ecosystem.

An ontology asks a different question:

What are we claiming about the domain itself?

That does not make ontology superior to those other models.

It means they serve different purposes.

A financial institution will still need databases, APIs, messages, canonical models and industry standards. The ontology does not replace them.

Its job is to make important domain meaning explicit enough that we can recognise what those different representations are actually representing.

This becomes especially useful when two perfectly reasonable systems model the same financial situation differently.

Instead of asking which schema is the “real” one, we can ask which financial things and relationships each schema is trying to represent.

That is often a much more productive question.

Formal representation still matters.

Natural language is wonderfully flexible, but that flexibility can also hide ambiguity. We might say:

“An issuer is a party associated with a security.”

That sounds reasonable until we ask what kind of association we mean, whether every issuer must be a party, what makes the issuer relationship true, and whether the same party can play other roles.

Formal representation forces us to become more precise about those commitments.

OWL gives us a standard way to express many of them. It can describe classes, relationships, restrictions, equivalences, disjointness and other semantic structures in machine-readable form.

But there is an order to the work.

If we formalise before we understand, we merely encode our confusion more precisely.

A beautifully written ontology can still contain the wrong categories. A reasoner can faithfully reason over assumptions that should never have been made.

So the principle is not to avoid formalism.

It is to earn the formalism by understanding the meaning first.

6. Finance Can Stay Hard

None of this means financial ontology modelling makes finance simple.

It will not.

A five-year interest-rate swap still has contractual terms, payment periods, rate determinations, obligations, lifecycle events and potentially amendments or novations.

A portfolio can still contain positions whose meaning depends on trading activity, accounts, strategies, quantities, valuation conventions and aggregation basis.

Settlement is still settlement. Risk is still risk.

The financial world does not become less complicated because we have an ontology.

What can become simpler is how we think about that complexity.

Instead of beginning with a long list of ontology terms, we can begin with the financial situation.

What are the things?

How are they related?

What is a role rather than a type?

What happened?

What condition is something in?

What remained the same?

What economic consequences resulted?

Which distinctions actually matter?

Then, when the meaning is sufficiently clear, we can give it structure and eventually formalise it.

This is the sense in which financial ontology modelling can be painless.

Not because finance suddenly becomes easy.

Not because ontology has no theory behind it.

And not because formal modelling disappears.

It becomes easier because we put those things in the right order.

Start with the financial world. Understand the meaning. Build the model. Use formalism when it helps make the commitments precise.

And throughout the process, remember:

Good ontology modelling is not about modelling more. It is about confusing less.

Finance can stay hard.

Ontology does not have to make it harder.

• *Financial Ontology Modelling