In the previous article, we used Say It → Model It → Challenge It to develop a financial model we could explain, test and refine.

We distinguished financial things from the roles they play, and examined why a model needs to express which entity issued which security.

What happens when we want to use that model in an actual application?

We will follow one financial question through domain modelling, source interpretation, data mapping, an AI tool and validation. Along the way, we will see where an ontology contributes, what other work is required, and how the result can be implemented using different technologies.

1. Start with a Question Someone Needs Answered

Imagine a portfolio analyst asking an AI assistant:

Which bonds in Portfolio P were legally issued by FatCat Bank? Separately, which have payment obligations guaranteed by FatCat Bank? Use the portfolio as at 30 September 2026.

This is an illustrative design, using fictional entities and records.

Suppose the relevant facts have been established as follows:

The task requires us to distinguish issuance from guaranteeing. FatCat Bank participates in both, in relation to different bonds.

It also requires us to identify the particular legal entity meant by “FatCat Bank”, establish the relevant portfolio holdings, and interpret the date.

These decisions determine what a correct answer looks like.

2. Model the Meaning the Question Requires

For this series, our working definition is:

A domain ontology is an explicit model of the kinds of things in a domain, their properties and relationships, and the distinctions and conditions that apply to them.

Its subject here is the financial situation. We need to describe bonds, legal entities, issuance, guarantees and portfolio positions.

Our model needs to express that:

• A bond is a kind of security.
• A legal issuer relationship identifies the legal entity that issued a particular security.
• A guarantee identifies a guarantor and the obligations covered.
• A portfolio position connects a portfolio to a security, with the temporal information needed for the question.

We also need to keep the legal issuer distinct from a parent company or another entity used for group reporting.

The two business relationships in our question may deserve different structures. For this example, we can query issuance through a direct legalIssuer relationship. A guarantee may require additional information about the obligations covered and its scope. A relationship such as guarantorForBond would need a documented interpretation derived from that information.

The modelling purpose determines how much detail we retain. The analyst needs enough information to distinguish the two lists and understand the guarantee coverage.

These descriptions apply beyond FatCat Bank and the three example bonds. They express reusable domain meaning.

At this stage, we have established what the application needs to mean. We still need to determine how its source systems represent the relevant information.

3. Establish What the Source Records Mean

Suppose the application draws on three sources:

This requires source documentation, business definitions, relevant data and input from people who understand the systems.

For example, a column named IssuerId may identify the direct legal issuer. Another system may use a similar label for a parent entity used in reporting. The label alone cannot establish the correspondence.

Suppose our investigation confirms that, in one particular source:

• RoleCode = I identifies the direct legal issuer.
• RoleCode = G identifies a guarantor, with coverage specified in associated guarantee records.
• PartyId can be resolved to an identified legal entity using the reference records.

We can then specify mappings from those records to the domain relationships.

The position mappings also need to preserve the requested date. The guarantee mappings need to preserve the coverage relevant to the question.

The domain ontology supplies the definitions and distinctions. Source analysis establishes what the records mean. The mappings specify their correspondence.

These activities can inform one another. A guarantee record may reveal a qualification our model needs to express. A modelling question may expose an ambiguity in a source definition.

4. Build a Tool the AI Can Use

An engineer can now implement services whose behaviour follows those agreed meanings.

For example, the application could expose two query tools:

find_bonds_by_legal_issuer(portfolio_id, legal_entity_id, as_of_date)
find_bonds_by_guarantor(portfolio_id, legal_entity_id, as_of_date)

These are illustrative interfaces. Their descriptions must specify what each relationship means, which date is being applied, and how guarantee coverage is handled.

Behind the interfaces, the implementation resolves the entity identifier, retrieves the relevant positions, applies the appropriate relationship and date conditions, and returns the matching bonds.

Useful results would include:

• The bond and legal entity identifiers.
• The relationship that caused the match.
• Relevant guarantee coverage, where applicable.
• The source and effective date of the supporting information.
• Any known limitations in the available data.

The AI assistant receives these tool definitions and can call each tool to produce the requested lists. Its answer can explain why Bond A appears in the issuer list and Bond B in the guarantor list, using the returned evidence.

If the user’s entity reference or intended date is ambiguous, the application needs a way to obtain clarification.

The domain model has now influenced the tool names, input definitions, query logic and returned evidence. Turning those definitions into working services is engineering work, supported by explicit mappings and checks.

5. Challenge the Whole Connection

We can now extend Challenge It from the domain model to the application.

The example records give us initial acceptance cases:

1. Issuance: Bond A appears in the issuer list.
2. Guarantee: Bond B appears in the guarantor list and does not enter the issuer list merely because FatCat Bank guarantees its obligations.
3. Multiple roles: FatCat Bank can issue one bond and guarantee another; the model and queries must support both situations.
4. Entity identity: A bond issued by another group member does not enter the issuer list solely because that entity belongs to the same group.
5. Time: A position outside the requested portfolio snapshot does not enter the result.
6. Missing information: A missing guarantee record is treated according to the source’s coverage. Incomplete coverage should produce “unknown”, rather than an unsupported claim that no guarantee exists.

We should check the queries and the assistant’s final answers. Correct tool results can still be misrepresented in a generated explanation.

Different checks answer different questions. Domain examples test whether our model captures the required distinctions. Mapping checks examine whether source records are connected appropriately. Service checks examine the implemented query. Application checks examine the answer presented to the user.

A logically consistent ontology would address only part of this work.

6. Choose How the Domain Model Participates

The same modelling decisions can support several implementations.

A SQL and API implementation

The agreed domain definitions can guide SQL views, application services, interface descriptions and acceptance cases.

The application may never load an ontology file at runtime. The model contributes through the design decisions implemented in its code and queries.

Where an existing model already expresses the necessary meaning clearly, the team can reuse it. A separate ontology document needs a purpose, such as providing a common reference across applications or supporting formal checks.

An ontology-based data access implementation

In ontology-based data access, mappings connect source data to a domain vocabulary that applications can query.

Ontop provides a virtual knowledge graph implementation: data remains in relational sources, while SPARQL queries are translated into SQL. It supports mappings and lightweight ontologies, including RDFS and OWL 2 QL. [1]

For our example, the application could query portfolio positions, issuers and guarantees through the mapped graph. The ontology can contribute supported class and property semantics, while the mappings determine how source records supply the relevant facts.

The source interpretation, identity resolution and temporal conditions still need to be established.

A Palantir implementation

Palantir’s product named Ontology combines objects, properties and links with functions, actions and security capabilities. Its scope includes the operational connection between a business model and an application. [2]

For this example, a team could configure the relevant objects and relationships, bind the verified source data, and implement functions for the two queries. Palantir’s AI tools support object queries, relationship traversal and function calls; configured actions can support workflows that change information. [3]

This is a practical way to combine several responsibilities within a platform. Its functions and operational rules should be understood according to their documented behaviour; the product name alone does not establish OWL-style entailment semantics.

Across these implementations, the domain decisions remain visible: which entity is meant, what each relationship expresses, which date applies, and what evidence supports the result.

7. More Uses in Practice

Our portfolio assistant illustrates one application. Published projects and studies show several others, with different levels of implementation evidence.

Trade surveillance. In Ontotext’s account of an unnamed global bank, ambiguous business definitions, inconsistent identifiers and missing organisational context made alerts difficult to interpret. The reported solution combined FIBO, identity reconciliation and a knowledge graph, allowing reviewers to examine activity against the organisational structure at the time of an event. Here, definitions, identity and time contributed together to an investigation workflow. [4]

Investment research and company profiles. Another Ontotext case describes an unnamed investment bank combining proprietary information, vendor data and facts extracted from news. The information was reconciled to an industry-specific ontology and assembled into connected company profiles. Queries and graph analysis then supported tasks such as finding indirect company associations and exploring alternative investment targets. The ontology worked alongside entity matching, text analysis and data-quality processes. [5]

Insurance portfolio underwriting. In March 2026, AIG reported that it had analysed McGill and Partners’ specialty portfolio, developed underwriting criteria and worked with Palantir to build a portfolio ontology. The announcement described planned use of exposure, deployed limits, modelled risk and loss information to support ongoing capacity management and agentic AI. This connects a business model to an underwriting workflow; the announcement also contains forward-looking plans. [6]

Financial concept classification. A 2021 FinSim-2 research system mapped financial terms to FIBO and searched its graph for suitable broader categories. Word representations and a machine-learning classifier supplemented the ontology-based method. This illustrates how an ontology can provide an explicit category structure within an AI task. The evidence is a shared-task research evaluation, rather than a reported banking deployment. [7]

Access to complex source data. Outside finance, a 2015 Statoil study used an ontology and mappings to connect geologists’ information needs to relational exploration data. Queries about wells and geological formations could be translated into database queries while the data stayed in its existing stores. The authors reported an industrial deployment and evaluation. It provides a concrete example of the OBDA connection introduced above. [8]

8. Is OWL Really Needed?

We have seen how domain-modelling decisions can become useful through mappings, query tools and application services.

This leaves us with a question:

If we can put a domain model to work in these ways, do we still need to learn OWL?

We will explore that question in the next article: Do We Still Need to Learn OWL?

Model the meaning before you model the data.

References

[1] Ontop, “Introduction,” Ontop Documentation, accessed 25 October 2026.

[2] Palantir Technologies, “Ontology Building,” Palantir Foundry Documentation, accessed 25 October 2026.

[3] Palantir Technologies, “Tools,” AIP Chatbot Studio Documentation, accessed 25 October 2026.

[4] Ontotext, “A Global Bank Improved Its Trade Surveillance System by Using Ontotext GraphDB to Tackle Market Manipulation,” Ontotext Case Studies, accessed 25 October 2026.

[5] Ontotext, “A Top-tier Investment Bank Gained Deeper Insights and Created Better Investment Opportunities for Their Clients,” Ontotext Case Studies, accessed 25 October 2026.

[6] American International Group, Inc., “McGill and Partners and AIG Launch Long-Term Strategic Collaboration in a Major Development for the Subscription Market,” AIG Press Release, 16 March 2026.

[7] Timen Stepišnik Perdih, Senja Pollak and Blaž Škrlj, “JSI at the FinSim-2 Task: Ontology-Augmented Financial Concept Classification,” arXiv preprint arXiv:2106.09230, 2021.

[8] Evgeny Kharlamov et al., “Ontology Based Access to Exploration Data at Statoil,” in The Semantic Web – ISWC 2015, Lecture Notes in Computer Science, Vol. 9367, Springer, 2015, pp. 93–112.

• *Financial Ontology Modelling