In the previous article, we looked at a strange feature of modern financial AI. Large language models can know an extraordinary amount about finance. They can explain products, markets, settlement, corporate actions, valuation and risk in impressive detail. Yet once we ask them to solve a real problem inside a financial institution, that knowledge often stops being enough.

The reason is that real work depends on more than general financial knowledge. It depends on actionable knowledge: what things mean in this organisation, how they relate, which sources are trusted, which rules apply, and what should happen in a particular context.

That raises an obvious question: if the AI does not have this knowledge, where is it?

The uncomfortable answer is that much of it is already inside the organisation. It is just not where the AI can reliably use it.

The organisation already knows the answer

Take a simple question:

Who issued this bond?

Someone in the organisation probably knows. A reference-data specialist may know the legal issuer. A risk analyst may care about the parent company behind it. An operations user may know which value is trusted for a particular process.

What the organisation knows, however, is richer than the textbook definition of issuer. It knows what issuer means in this particular context, which relationship matters for this particular use case, and which source should be trusted when systems disagree.

An AI model does not automatically inherit any of that. It may understand perfectly well what an issuer is in finance, but it still has to work out how that general concept maps to this bond, this system and this business process.

That is the gap between knowing finance and knowing how finance works here.

Knowledge is scattered across the institution

The issuer example is not unusual. The same pattern appears across almost every important financial concept.

The meaning of a trade may be spread across a data model, lifecycle code, validation rules and operational procedures. The meaning of a position may depend on how several systems calculate, aggregate and date it. The meaning of a price may depend on its source, observation time, valuation policy and intended use.

Some of this knowledge is written down. Some is encoded in source code, transformation rules, schemas, mappings, system configurations and spreadsheets. A great deal still lives in the heads of experienced people.

No single artefact necessarily tells the whole story. Instead, people inside the organisation assemble that meaning from different places. They know that a field name is misleading, that two systems use the same word differently, that one source should be trusted for one purpose but not another, or that an old rule still appears in the data even though the business has moved on.

Humans who have worked with these systems for years often make these connections almost automatically. They know the context, the history and the exceptions. An AI system sees fragments.

It may have access to the same database, documentation and policies, but access is not the same as understanding how those pieces fit together. If the relationships between them have never been made explicit, the AI has to reconstruct the organisation’s meaning for itself.

And that is precisely where a plausible answer can become a misaligned one.

Sometimes the real knowledge base is a person

Almost every large organisation has a few people who are effectively part of the production architecture. You discover a strange value, an unexpected relationship or an old field nobody quite understands, and someone says:

“Ask Sarah.”

Sarah knows why the field behaves that way. She remembers a migration from seven years ago. She knows that the original design assumed one issuer per instrument but the current platform supports something more complicated. She knows which source feeds the value, which team overrides it, and why the documentation is technically correct but practically misleading.

Sarah is not merely holding data. She is holding meaning, context and history: why something works the way it does, which distinction matters, what changed over time, and which exceptions are important.

That kind of knowledge is enormously valuable because it connects facts that would otherwise look unrelated.

Unfortunately, “ask Sarah” does not scale particularly well as an AI architecture.

It does not scale particularly well as an organisational architecture either. The problem has always existed; AI simply makes it much harder to ignore.

We have encoded data more successfully than meaning

Financial institutions are generally very good at recording information. We have database schemas describing fields, APIs describing messages, catalogues describing datasets, lineage showing where values came from, canonical models describing shared structures, and policies describing what people are supposed to do.

All of these are useful. But they often describe different parts of the puzzle rather than the meaning of the whole thing.

A schema may tell us that issuerId is a string. A data catalogue may tell us that it contains an issuer identifier. A lineage tool may tell us that the value came from System A. An API specification may tell us how that value is transported. A transformation rule may tell us that it was copied from legalEntityId.

Yet none of these necessarily tells us what issuer actually means in that context.

Is it the legal entity that issued the security? Is it the parent company used for risk aggregation? Is it a role played by a legal entity? Is it a relationship between a security and an organisation? Is it simply an organisation-specific reporting classification that happens to be called issuer?

Those are semantic questions.

And semantic questions are exactly the ones most likely to have been answered implicitly rather than explicitly.

A familiar name can hide an unfamiliar meaning

This is one reason enterprise AI can be misled even when the underlying data looks well documented.

A field named issuer feels meaningful. A table called Security feels meaningful. An API object called Trade feels meaningful. Because the words are familiar, we tend to assume the concepts behind them are obvious.

They rarely are.

Two systems can both contain something called Trade while representing different things. One may represent an executed transaction. Another may represent the current operational record of that transaction. A third may represent a reporting view assembled from several lifecycle states.

The people working with those systems may understand the difference without even thinking about it. An AI sees three things called Trade and has to infer whether they are equivalent, related, or completely different representations.

The same problem appears with words such as Customer, Account, Instrument, Product, Position, Contract, Price and Status.

Naming something does not make its meaning explicit.

Code contains knowledge we do not usually call knowledge

Source code is another major reservoir of organisational knowledge.

Imagine a rule like this:

if legalEntity.type == "SPV" and parentEntity is not null:
    reportingIssuer = parentEntity
else:
    reportingIssuer = legalEntity

From a software perspective, this looks like implementation logic. From a knowledge perspective, it says something much more interesting.

It says that for a particular reporting process, the organisation does not always treat the direct legal issuer as the relevant issuer. Under certain conditions, it applies a different business interpretation.

That is domain knowledge.

Because it is encoded as application logic, however, it may never be recognised or governed as knowledge in its own right. The same thing happens with validation rules, transformation code, workflow conditions and query logic. Large systems contain thousands of tiny statements about how the organisation understands its financial world.

Later, when we build an AI assistant, we may give it documentation and data but not realise that some of the most important business knowledge is hidden inside the code that transforms and interprets them.

Then we wonder why the AI reaches the wrong conclusion.

Transformations can make the data cleaner while making the meaning weaker

Transformation layers create another subtle problem.

Suppose one system represents a legal entity, another represents an issuer, and a canonical model maps both into something called Party. From an integration perspective, that may be entirely sensible. It gives downstream systems a common structure and reduces the number of representations they need to understand.

But from a semantic perspective, something important may have disappeared.

One source may have represented the identity of an organisation. The other may have represented a role that organisation was playing in relation to a security. By mapping both into the same structural concept, we may have made the data easier to move while making the original distinction harder to recover.

The transformation succeeds. The interface works. The data flows. The AI can retrieve the result.

But the meaning may already have been flattened before the AI sees it.

This is why connecting AI to existing enterprise data does not automatically give it access to organisational knowledge. Sometimes the knowledge was never represented explicitly in the data in the first place.

Policies know one thing, systems know another

Organisational knowledge is also distributed across different forms of authority.

A valuation policy may state that an approved source must be used. A system configuration may contain the current list of approved sources. A business procedure may define exceptions. An operations team may know that one normally approved source is temporarily unreliable. Historical data may still contain values produced under an older policy.

Now ask the AI:

Which price should we use?

It may need all of those pieces of information. More importantly, it needs to understand what kind of information each piece represents and how they should be combined.

Which statement is a policy? Which is a configuration? Which is an exception? Which is an observation? Which was valid last year but is no longer valid today?

Retrieving all five pieces is not enough. The AI needs to understand their roles, their authority and their temporal context.

Organisations run on tacit semantics

A useful way to describe all of this is that many organisations operate with tacit semantics.

The meaning is real. People depend on it. Systems indirectly encode it. Business processes assume it. Yet it has never been made fully explicit in one shared form.

This can work surprisingly well while experienced humans remain in the loop. A person recognises context, remembers an exception, asks a colleague, or notices that an answer is technically correct but does not make business sense.

If we want AI to become part of core financial processes, however, relying on accidental inference becomes increasingly uncomfortable. The more important the decision, the less we should want the AI to reconstruct organisational meaning from scattered clues.

The problem is not simply whether the AI has access to enough information. It is whether the organisation has expressed the meaning behind that information clearly enough for the AI to use.

Retrieval can find information without resolving meaning

This is why retrieval-augmented generation is valuable but not sufficient.

Retrieval can help an AI find internal documents, policies, technical specifications and data definitions. That is a major improvement over asking the model to rely entirely on its general knowledge.

But retrieval mainly helps answer:

Where is the relevant information?

It does not automatically answer:

How should these pieces of information be interpreted together?

If two documents disagree, retrieval can return both. If two systems use the same term differently, retrieval can expose both definitions. If one policy replaced another, retrieval may find both versions. If a company is referred to by several identifiers, retrieval can bring back all of them.

The AI still has to determine which things are the same, which are different, what relationships connect them, which source is authoritative, and when a particular statement was valid.

Those are not search problems.

They are problems of meaning.

Much of the knowledge is in the relationships

There is another important point. Organisational knowledge does not live only in individual facts. Much of it lives in the relationships between those facts.

Knowing that ABC Finance plc exists is one piece of information. Knowing that a particular bond exists is another. Knowing that ABC Finance plc issued that bond is a different kind of knowledge.

Knowing that ABC Holdings is the parent of ABC Finance plc may matter for risk aggregation but not for identifying the legal issuer. Knowing that a vendor asserted one issuer relationship while an internal legal review asserted another adds another layer of meaning.

The important knowledge is increasingly in the structure connecting the pieces: identity, role, relationship, context, time, evidence and authority.

This is why simply placing more text into an AI context window cannot be the whole solution. The organisation needs to express not only its facts, but also the meaning that connects those facts.

Making organisational knowledge explicit

Once we recognise this, the enterprise AI problem begins to look rather different.

The goal is not to replace people’s knowledge with an ontology. Nor is it to turn every document, rule and database row into a giant knowledge graph.

The first goal is much simpler:

Make the important organisational meaning explicit

What is this thing? Which identifiers refer to it? What role is it playing? How is it related to other things? Which event changed its state? Which observation produced this value? Which source made this claim? When was it true? Which rule determines what should happen next?

These questions reveal semantic structure that is already present in the organisation, whether or not anyone has formally modelled it.

Ontology modelling gives us a disciplined way to capture that structure.

The AI knowledge problem is also an organisational knowledge problem

It is tempting to describe enterprise AI failures as deficiencies in the model. Sometimes they are.

But sometimes AI is exposing something uncomfortable about our own organisations.

For decades, we have relied on people to reconcile inconsistent terminology, infer relationships, remember exceptions and understand which representation means what. Those people made fragmented organisational knowledge usable.

Now we want AI to do some of the same work, and we are discovering that much of the knowledge it needs was never expressed in a clear, shared form.

The organisation knows more than its AI does.

The challenge is that its knowledge is fragmented across people, systems, code, documents, policies and history. If we want that knowledge to become actionable for AI, we need to make the underlying meaning more explicit.

That takes us to the next problem.

Once AI begins working across teams, systems and business domains, shared meaning is no longer just the concern of data modellers, architects or ontology specialists.

It becomes everyone’s problem.

• *Financial Ontology Modelling