In the previous article, we looked at a problem that sits underneath many disappointing enterprise AI applications. The organisation often already has much of the knowledge the AI needs, but that knowledge is scattered across people, systems, code, policies and operating practices.

For years, financial institutions have been able to live with this arrangement. Different teams could use slightly different meanings, different systems could represent the same concept in different ways, and experienced people could usually bridge the gaps. A front-office user knew what trade meant in one system. Operations knew what it meant in another. A data engineer knew which transformation connected the two.

AI changes that arrangement because AI is useful precisely when it crosses those boundaries. Once we expect it to combine information from different teams and systems, answer questions across business domains, or eventually take actions, local meanings can no longer remain safely local.

Shared meaning stops being somebody else’s modelling problem. It becomes an organisational problem.

Local meanings worked when systems stayed local

Financial institutions are full of local languages.

A front-office team may use trade to mean the transaction agreed with a counterparty. Operations may use the same word for the record that moves through confirmation, settlement and lifecycle processing. Risk may work with an economic representation of that trade, while regulatory reporting may use a transformed representation created for a particular reporting purpose.

None of these usages is necessarily wrong. Each has evolved to support a particular job, and experienced people usually understand the context in which the word is being used.

Traditional software can also tolerate this surprisingly well. An application normally operates within a relatively narrow boundary. Its developers know what Trade means inside that application, and the necessary assumptions are encoded in interfaces, mappings and business logic.

Problems arise at the boundaries, of course, but organisations have spent decades building integration layers to manage them. Humans provide another layer of integration almost without noticing it. They know that trade in System A is not quite the same as trade in System B, even when both systems use the same word.

As long as these meanings remain inside familiar organisational boundaries, the ambiguity can be manageable.

AI is much less respectful of those boundaries.

AI is valuable because it crosses the boundaries

Think about the kinds of questions we actually want an enterprise AI assistant to answer:

Why did this position change?

Which trades are exposed to this issuer?

What happened to this contract after the amendment?

Which clients are affected by this event?

Why does the risk system disagree with the front-office system?

None of these questions belongs neatly to one database or one application. A useful answer may require the AI to move from a security master to trade data, from trades to positions, from positions to legal entities, and from structured records to contracts, policies or operational documentation.

That is what makes AI interesting. It can potentially connect knowledge that previously sat behind organisational and technical boundaries.

But once the AI starts crossing those boundaries, differences in meaning that were previously tolerable become part of the reasoning problem.

Suppose one system uses issuer to mean the legal entity that directly issued a security, while another uses issuer for the parent company used in risk aggregation. Both systems may be working correctly for their intended purposes. If an AI combines the two without understanding the distinction, however, it can produce a conclusion that is perfectly plausible and completely wrong for the question being asked.

The problem is no longer whether each system works independently.

It is whether their meanings still work when AI brings them together.

Shared vocabulary is not shared meaning

This problem is easy to underestimate because financial institutions already appear to have a common vocabulary. Everyone talks about trades, customers, counterparties, products, securities, accounts, positions and prices.

The words look familiar, so we assume the meanings must also be shared.

Consider position.

A trader may think of a position as the economic exposure currently held in an instrument. An operations platform may calculate a settled position. A risk system may construct its own position after applying aggregation or netting rules. A regulatory process may use another definition determined by the reporting obligation.

All of them may legitimately use the word position. The important question is not which team owns the correct definition. The important question is what each position actually represents and how those representations relate to one another.

This leads to an important distinction:

Shared vocabulary is not the same as shared meaning.

Nor does shared meaning mean forcing the entire organisation to use one vocabulary.

Risk should be allowed to use concepts that matter to risk. Operations needs terminology suited to operational processes. Legal may distinguish things that a trading interface has no reason to expose. Attempting to force every team into a single universal business language would probably create as many problems as it solved.

What matters is that we know when two different names refer to the same concept, when the same name refers to different concepts, and when two representations are related but not identical.

That is semantic alignment.

Meaning can no longer be somebody else’s job

Traditionally, semantic questions tended to belong to specialist roles. Data architects worried about canonical models. Data modellers worried about definitions and structures. Reference-data teams worried about identifiers. Enterprise architects worried about integration. Ontology specialists, where they existed, worried about formal semantics.

Most other people could reasonably treat these concerns as part of the technical machinery.

AI makes that separation much harder to maintain.

Suppose a business user asks an AI assistant to find all trades affected by a particular event. Before the AI can answer, somebody has to determine what counts as an affected trade. That is not a question a technology team can answer by inspecting the database schema.

Or suppose one system identifies a legal entity as the contractual counterparty while another records the parent company used for credit-risk aggregation. Deciding which relationship matters to a particular question is not merely a technical mapping decision. It requires business meaning.

The business therefore cannot simply hand vague terminology to the technology team and expect semantics to emerge automatically from implementation.

But the reverse is also true.

Technologists can no longer assume that understanding field names and APIs is enough. If a developer connects an AI agent to a field called issuer_id, the fact that the field exists does not tell them what issuer means, whether the value identifies the direct issuer or a parent, how that relationship changes through time, or whether the field is authoritative for the question the agent is trying to answer.

AI brings business and technology closer together around the question of meaning.

Business experts need to explain the distinctions that matter. Technologists need enough domain understanding to preserve those distinctions when they build systems around them.

AI teams are already making semantic decisions

There is another reason shared meaning cannot remain the responsibility of a small modelling team.

AI developers are already making semantic decisions, whether or not they describe them that way.

Imagine a prompt that says:

Treat the issuer as the legal entity directly responsible for issuing the security, not its ultimate parent.

That is a semantic decision.

A retrieval rule that treats one system as authoritative for legal-entity identity and another as authoritative for market prices contains semantic decisions.

A tool definition that distinguishes a trade from a position contains semantic decisions.

An agent workflow that interprets an amendment as an event affecting an existing contract rather than an unrelated record also contains a semantic decision.

None of these necessarily looks like ontology modelling. They look like prompts, tool definitions, configuration or application logic.

But underneath, the same questions are being answered: What is this thing? How is it related to that thing? Which distinction matters? Under which context does this statement apply?

If every AI team answers those questions independently inside prompts and code, the organisation risks recreating its existing semantic fragmentation in a new technology stack.

One team may teach its assistant that Product means a financial instrument. Another may use the same word for a commercial offering. A third may treat product as the template from which a trade is constructed. Each assistant may work well in isolation.

The problem arrives when somebody asks them to work together.

We have recreated the old integration problem, except now every system can produce an eloquent explanation of why its interpretation makes sense.

Shared meaning must preserve context

There is an important trap here. Semantic alignment does not mean pretending there is only one correct view of the financial world.

Financial institutions often contain genuinely different perspectives.

Legal may care about the contractual counterparty to a trade. Credit risk may care about the parent group to which that counterparty belongs. Operations may care about the entity responsible for settlement. Regulatory reporting may classify the relationship differently again.

Those are not necessarily inconsistencies that need to be removed. They may be different legitimate views created by different business purposes.

The modelling mistake would be to flatten all of them into a vague statement such as:

ABC Holdings is the counterparty.

A better representation may preserve the contexts:

ABC Finance plc is the contractual counterparty to this trade.

ABC Holdings is the parent entity used for this credit-risk aggregation.

Now the two statements can coexist without contradiction.

This is an important point for enterprise AI. A shared semantic foundation should not remove business context in pursuit of simplicity. It should make that context visible enough that an AI can understand why two apparently different answers may both be correct.

Shared meaning does not mean one version of reality. It means being clear about which version we are talking about and why.

The organisation needs a semantic meeting point

This suggests a different way of thinking about enterprise architecture.

Different applications can keep their own physical models. Business teams can retain terminology suited to their work. Industry models can provide standard structures. AI systems can use the technical representations that best suit their tasks.

But somewhere between the business meaning and those implementations, the organisation needs a place where important concepts and relationships can meet.

A semantic meeting point.

At that level, we should be able to say clearly that this is a legal entity, this is a security, this identifier identifies that security, this organisation issued it, another organisation guarantees it, and a third may be its parent.

We should be able to distinguish a price from an observation of that price, a trade from a position created from trading activity, and a lifecycle event from the state produced by that event.

The implementation can vary. The meaning should not have to be reinvented every time a new application is built.

This is one of the roles a domain ontology can play.

Not as a replacement for databases, canonical models, APIs or industry standards, but as a layer where important business meanings and relationships are made explicit before they are encoded into those different forms.

Shared meaning becomes infrastructure

This is also why ontology becomes relevant to far more people than ontology specialists.

Most business users do not need to learn RDF or OWL. Most developers do not need to become formal ontologists. What they do need is the habit of asking better semantic questions.

When someone says two records represent the same thing, what exactly is the thing that is the same?

When a system calls an organisation an issuer, is issuer describing the organisation itself or the role it plays in relation to a security?

When two sources disagree about a price, are they contradicting each other, or are they observations from different times, sources or contexts?

These questions are not academic. They determine whether the AI is connecting information correctly.

For years, organisations could leave many of these distinctions implicit because experienced people compensated for them. As AI begins to reason across more systems and eventually act on what it finds, that approach becomes increasingly fragile.

The first generation of enterprise AI has naturally focused on models, prompts, retrieval and agents. Those technologies matter, but they all depend on something underneath them: a sufficiently clear understanding of what the organisation means.

Business experts contribute that meaning. Data professionals help structure it. Architects connect it across systems. Developers preserve it in applications. AI engineers teach systems how to use it. Ontology modelling provides a discipline for keeping the distinctions clear.

That is why shared meaning is becoming organisational infrastructure.

An organisation that makes its financial meaning explicit can reuse that meaning across data, APIs, analytics, knowledge systems and AI. An organisation that does not will keep asking each new system to reconstruct the meaning from fragments.

And AI is exceptionally good at reconstructing a plausible meaning.

The challenge is making sure it reconstructs ours.

• *Financial Ontology Modelling