Ontologies in Finance: Uses and Costs Seen Through FIBO, BCBS 239 and AML

Why financial data is hard, and why the financial sector is drawn to ontologies

This article is Part 3, the finance installment, of the series 'Ontologies: Hype and Reality.' Part 2 explained that the Palantir ontology is an operational layer that adds actions to objects, properties and links and writes decisions back to source systems. This installment looks at what uses the same idea delivers, and what costs it demands, in the tightly regulated world of finance.

There are three main reasons financial data is hard. First, each system calls the same thing by a different name. An introductory article from the EDM Council, which manages FIBO source, gives the example that even within a single financial firm, 'counterparty,' 'client' and 'customer' can mean different things in different systems. Second, legal entities are tangled together through ownership structures. In its FIBO proof of concept, State Street separately sourced data on legal entities and their hierarchies (parent-subsidiary relationships) from external providers source. HSBC has also said it uses external data such as corporate ownership information to find connections between counterparties source. Third, contract terms are scattered. In a press release on the open-sourcing of Goldman Sachs Legend source, FINOS explained that the components of a complex product such as an FX option can be stored across dozens, or even hundreds, of systems in an investment bank's front, middle and back offices.

The answer an ontology (a formal knowledge model that defines which concepts exist and how they relate to one another) offers is simple. Instead of fixing the data in each system, it connects (maps) each system to a single set of common concepts. Then questions such as 'Do this customer and that counterparty belong to the same corporate group?' can be asked across systems. This is also exactly where the cost arises. Building the mappings, agreeing on definitions and maintaining them whenever things change must be done by people. This entire article follows that trade-off.

Components: what FIBO defines, and what the proof of concept revealed

FIBO (Financial Industry Business Ontology) is a financial standard ontology developed and maintained by the EDM Council together with industry practitioners. According to the council's description source, FIBO divides the financial domain into modular domains and defines, for each domain, concepts (e.g., a bond), relationships (e.g., 'is issued by') and attributes (e.g., maturity date). Its format is RDF/OWL, so it can be converted into other formats and used in various analytics and data management tools. It is published as open source and reviewed and updated quarterly by a team of ontology experts and financial practitioners. According to a 2016 report source, FIBO has been developed since 2011 in cooperation with the standards body OMG. FIBO's job is not to hold data. It provides a 'common dictionary and grammar' to attach to data.

A 2016 WatersTechnology report source covers State Street's FIBO proof of concept in detail. State Street deliberately narrowed the scope to interest rate swaps, which make up a large share of the trades it processes. It used the published FIBO as-is without modification, and used only data extracts without connecting to operational systems. There were four steps: loading the FIBO model into a semantic tool, mapping the extracted data to FIBO, graphing the trades, and building analytics on top. As a result, State Street said, it could produce reports without building a separate data warehouse and could see where collateral was concentrated in particular legal entities or regions.

The same article also describes the mapping burden. When one data item would not map, the team at first suspected FIBO was incomplete. Only after asking Wells Fargo, which had already done a proof of concept, did they learn they had been looking in the wrong place within FIBO. State Street's chief scientist said FIBO is largely intuitive but becomes more complex as it grows, so training would be needed. This case shows that 'the standard is right' and 'fitting our data to the standard is easy' are separate questions. It should also be kept in mind that this was a proof of concept not connected to operational systems.

Demand created by regulation: BCBS 239, common terminology and data lineage

Regulation plays a large role in why the financial sector is considering ontologies. On November 28, 2023, the Basel Committee on Banking Supervision published a report assessing how well banks had implemented BCBS 239 (the Principles for effective risk data aggregation and risk reporting) source. It covered 31 global systemically important banks (G-SIBs) designated between 2011 and 2021. The committee stated that nearly 10 years after the principles were first issued and 7 years after the compliance deadline, banks' levels of implementation varied and most still had significant work to do.

A press release issued the same day source set out specific recommendations. Boards should take full responsibility for overseeing the development, implementation and maintenance of robust data governance frameworks. Banks should foster a culture of ownership and accountability for data quality across the organization and ensure sound data quality as the foundation for digitalization projects. Supervisors were advised to use stronger measures against long-standing deficiencies. At the same time, as the Basel Committee itself notes, its decisions have no legal force and take effect only when member jurisdictions' authorities implement them source.

There are two links connecting these demands to ontologies. One is common terminology. To aggregate risk data from multiple systems, the same concept must be used with the same meaning. The EDM Council directly cites consistency in regulatory reporting such as BCBS 239, and KYC/AML risk analysis, as uses of FIBO source. However, this is the description from the side that runs the standard. The other is data lineage (a record of where data came from and how it was transformed). FINOS explained that common regulatory frameworks such as MiFID II created the need for sophisticated data lineage tools source. In short, what regulation directly demands is 'data that can be aggregated and reported, and accountability for it.' An ontology is one of the means of meeting that demand.

US and European cases: uses seen through official announcements and reports

The table below lists what companies and institutions officially announced first, with media reports added as supplements. All entries are 'what was announced or reported,' and performance figures are the claims of the announcing party.

| Institution (country) | Area | Approach | Source | |---|---|---|---| | State Street (US) | Industry-standard proof of concept | Mapped FIBO to interest rate swap data extracts and analyzed as a graph; not connected to operational systems | 2016 report source | | HSBC (UK) | Trade finance AML | 'Contextual monitoring' built with Quantexa; builds networks of counterparties and transactions | Quantexa press release, 2019 source | | Goldman Sachs (US) | Open-sourcing data modeling and governance | Released five modules of its internal platform Legend as open source to FINOS | Linux Foundation press release, 2020 source | | Societe Generale (France) | Financial crime (money laundering, fraud) | Deployed a Palantir Foundry-based financial crime solution in its international retail business | Palantir press release, 2025 source | | AIG (US) | Insurance underwriting | Built a Lloyd's syndicate portfolio with its own ontology and Palantir Foundry | 2025 report citing AIG announcement source | | Swiss Re (Switzerland) | Reinsurance data and AI platform | Placed a Palantir-based platform combining ontology, automation and governance at the center of its strategy | 2025 report, based on company management briefing source |

A few details follow. HSBC said it runs this system in the UK and Hong Kong, automatically checking trade finance transactions against more than 50 scenarios that capture money laundering indicators. It also said it screens more than 5.8 million trade transactions a year source. Quantexa described the solution as an Entity Resolution and network analytics framework that references more than 40 billion financial transactions source. Before its release, Goldman Sachs Legend was piloted for six months by Deutsche Bank, Morgan Stanley, RBC Capital Markets and others. An FX option extension modeled jointly by this pilot group was adopted into ISDA's Common Domain Model (CDM) source. AIG said its in-house ontology gives its models access to more than 4 million industry data points. Syndicate 2479, which operates on this structure, was reported to begin underwriting $300 million in premiums from January 1, 2026 source. Swiss Re also stressed the need for cross-functional governance to manage model risk source.

As a Korean case, it was reported in August 2025 that DB Insurance signed a memorandum of understanding with T3Q to jointly pursue a proof of concept automating long-term insurance claims processing with ontology-based AI source. It should be kept in mind that this is still at the agreement stage.

Comparing three approaches: Palantir-style, standards/open, and network analysis

Grouping the cases by approach gives three types. The Palantir-style approach places an ontology on top of an operational platform. Societe Generale, AIG and Swiss Re fall into this group. Its strength is that it does not stop at analysis but handles workflows such as underwriting and monitoring on a single platform. The price is accepting the switching costs and lock-in discussed in Part 2, because ontology definitions accumulate inside a specific platform.

The standards/open approach uses a published common language. Open ontologies such as FIBO source and open data modeling platforms such as Goldman Sachs Legend source belong here. Its strengths are interoperability between companies and vendor neutrality. State Street said FIBO can be used in other products too and that it does not recommend any particular vendor source. On the other hand, the standard itself does not run any business processes. So each company must handle the training needed for mapping and interpretation, and connecting it to actual operational systems is separate work.

The network-analysis approach, like Quantexa's, monitors through Entity Resolution and networks source. It merges people and legal entities scattered across multiple data sources into single entities and looks at the connections and transaction patterns between them. It is well suited to problems like AML, where the key question is 'who is moving money with whom.' But since building an enterprise-wide concept system is not its goal, it does not solve terminology unification across regulatory reporting as a whole.

In practice, one can consider a setup that layers all three. Terms and concepts are aligned with a standard such as FIBO, network analysis is used in areas that need monitoring, and an operational platform is used only where decisions must be written back into workflows. Definitions aligned with a standard become an asset that remains no matter which platform you move to. In this sense, they also act as a buffer that reduces lock-in risk.

Constraints specific to finance, and common mistakes

The first constraint is explainability and audit trails. In finance, firms must be able to answer questions such as "Why was this transaction flagged as suspicious?" and "Which source data did this risk figure come from?" This is the same context in which BCBS 239 reviews keep stressing accountability and governance for data quality source, and in which FINOS explains that regulation creates the need for data lineage tools source. Because an ontology makes concepts and relationships explicit, it helps meet this requirement. But if mapping rules are not documented, it only adds one more black box.

The second is model risk management. AIG has described a long-term direction in which an LLM, working on top of an ontology, assesses whether a portfolio fits the company's risk appetite source. Swiss Re said that as AI moves into day-to-day work, cross-departmental governance is needed to manage model risk source. When an ontology definition changes, the inputs to the models and agents built on it change too. So definition changes should be reviewed the same way as model changes. Data regulations such as personal data protection and Korea's network separation rules (which require financial firms to keep certain internal systems separated from external networks) are not covered in detail by the sources used here. They are, however, items that must be checked separately before combining external data or adopting a cloud platform.

The third is final human accountability. In the HSBC case as well, the system finds suspicious connections, and financial crime investigators make the judgment after examining the network source. Decisions that directly affect customers, such as suspicious transaction reports, insurance underwriting rejections and risk limit decisions, should include human-in-the-loop (a step where a person reviews and approves). As the Basel Committee stresses, final responsibility for data governance also rests with the board source.

Common mistakes are worth listing too. First, reading a successful proof of concept as operational success. The State Street case was an experiment with a narrow scope that was not connected to production systems source. Second, assuming that adopting a standard as-is is the end of the job. Interpreting mappings takes experience and training source. Third, carrying performance figures from vendor announcements over as general expected benefits. All figures in the table above are claims made by the announcing parties. Fourth, not assigning owners to term definitions. If no one is responsible for revising definitions, the ontology quickly goes stale.

How Korean financial firms can start small

The sequence below is a recommended flow based on the cases above and the BCBS 239 recommendations. 1) Pick one business process and one regulatory report. Just as State Street started with interest rate swaps, a single product with a large share of trading source, a report with clear stakes and a limited number of data sources works well. 2) Extract the key terms in that report (customer, counterparty, legal entity group, exposure, etc.) and compare them with the concepts in a public standard such as FIBO source. Building your own scheme from scratch may mean having to realign it later.

3) Assign a definition owner to each term. This is the step that puts into practice the culture of data quality ownership the Basel Committee called for source. Document who has the authority and responsibility to change each definition. 4) Map the columns of source systems to the common concepts, and connect data lineage so that any single number in the report can be traced back to the value in the system it came from. 5) Actually produce the report and compare it with the results of the existing process. If items fail to map, first check whether the standard is lacking or the mapping was identified incorrectly source.

6) Only then connect agents. Let the LLM use the common concepts and lineage as tools, but route any action that affects customers through human approval. 7) When expanding to a second business process, check whether concepts already defined are being reused. If the reuse rate does not rise, it is a sign that you are building process-specific mapping tables rather than an ontology.

As a checklist, confirm the following. Does every key term have a definition owner? Are mapping rules documented, with a change history? Can lineage be traced from a report number back to its source? Has the proof of concept been revalidated on production data and production systems? Do external data combinations and platform adoption comply with Korean data regulations? Is there a human approval step for agent actions?

Further reading, and on to Part 4

As a first read, we recommend the EDM Council's introduction to FIBO source. Its structure of concepts, relationships and properties, along with its "counterparty/customer" example, shows the usefulness of an ontology most concisely. Next, the article on State Street's proof of concept source shows both the four mapping steps and the actual obstacles. On the regulatory side, see the Basel Committee's notice on its BCBS 239 progress report source and the press release summarizing its recommendations source.

Three official announcements are useful for comparing cases. For the network-analysis approach, the HSBC–Quantexa press release source; for the standards/open approach, the Goldman Sachs press release on open-sourcing Legend source; and for the Palantir-style approach, the Societe Generale press release source. On the insurance side, read the AIG source and Swiss Re source reports together, keeping in mind that they are articles relaying company announcements.

Part 4 will lay out how the three approaches covered here compete in the market. It will then turn to the series' conclusion, the hype and reality of ontologies: where actual benefits end and expectations begin.