Read about the KG capabilities used by Ontotext for trade surveillance to prevent manipulation from professional traders and how they can help in the situation…
In the past year, knowledge graphs topped the curve of the Gartner Hype Cycle for Artificial Intelligence, and graph database vendors raised more than half a billion dollars in venture capital funding. It’s safe to say knowledge graphs have entered the spotlight. But amidst all the hype and hubbub, what is the real value of a knowledge graph? In this blog series, we will explore specific industries to highlight the impact of knowledge graphs on critical use cases.
This article will examine the world of financial services and look at how knowledge graphs enable organizations to derive more value from the data they already possess. Before we dig into the details, however, we need to establish what a knowledge graph is. You may be familiar with the basics of knowledge graphs, but others may be encountering the term for the first time. For the purposes of this article, you just need to know the following:
A graph is a method of storing and modeling data that uniquely captures the relationships between data. A knowledge graph uses this format to integrate data from different sources while enriching it with metadata that documents collective knowledge about the data. This creates a contextual layer that allows companies to rapidly retrieve and interpret the data stored in the graph whether structured or unstructured. What this looks like in practice will become clearer as we delve into some examples.
Thanks to efforts to become more data-centric, financial firms have a lot of data. The ability of an organization to survive, much less thrive, in the industry depends on its ability to retrieve, make sense of, and act on that data in a timely fashion. Knowledge graphs help these firms identify relevant data, whatever its source or format, and understand in real terms what that data represents.
The value of this approach becomes clear when we examine a use case such as company intelligence in an emerging market. Investment firms, including one of Ontotext’s clients, spend enormous sums every year buying data from brokers, while also producing original analyses and relying on coverage from news media, especially in regions where raw numbers are harder to find.
Most of the time this information is scattered across the organization and stored in a number of different silos. Structured data sets purchased from a data vendor sit in a data warehouse or other repositories while analyses are kept in a shared file system and news articles are consulted on an as-needed basis. Using a knowledge graph-based solution, Ontotext was able to bring all of this information together in a queryable way for their customer.
In practice, say an analyst wants to see all the information their firm has on a prospect called New Delhi Ventures. In a knowledge graph, New Delhi Ventures exists as a single node with relationships to other nodes representing the firm’s knowledge of the company. These nodes include metrics and attributes extracted from structured data sources as well as qualitative data stored in unstructured documents. (See figure 1.)
Figure 1. Mock Knowledge Graph for New Delhi Ventures
Instead of having to track down each element individually, the analyst could simply run a query against the graph and retrieve any of that information. It’s not that the analyst couldn’t eventually find most of the same information in a siloed data landscape, but they’d need to know where to look first, and it would ultimately take much longer to answer a specific question. Delays in answering questions can lead to delays in decision making that can ultimately result in lost opportunities. If you already have the data, why not store it in a way that facilitates its use? Additionally, the graph captures certain relationships that might not exist in any one siloed data source.
We all know what a hassle regulatory reporting can be. There are dozens of different entities with dozens of different forms all of which need similar information, but which define terms slightly differently. In most organizations, filling out these reports correctly becomes an extremely tedious, highly manual task. A human person must determine what information the regulatory agency actually needs and then how that data is recorded within the company. Next, they must locate it, make any necessary calculations, and add it to the form. With its ability to capture relationships, a knowledge graph helps automate this process.
Knowledge graphs are particularly suited to solving these types of problems because they allow organizations to map the way regulatory definitions relate to one another and company data. Say that at a company level, an organization uses sub-state-level regions, but, when it reports, one agency needs data by country, another by state, and a third has its own regional definitions. The simple graph below can make querying the right data for each agency much more efficient.
Figure 2. Knowledge Graph of Regional Designations
Because the knowledge reflects how each entity—region, state, agency region, and country—relates to the others we can infer additional information. For instance, I know Region C is in the United States because it is in South Carolina, which is in Agency A’s Southeast Region which is in the United States. Now, without ever having explicitly stated that Region C was in the US, when I query all US data from the graph, it will return data from Region C.
This is an obviously trivial example, but knowledge graphs can model far more complex relationships. Instead of relying on human intelligence to bridge the gaps between the way a company records data and the way regulatory agencies think about it, the company can actually store that knowledge in the graph itself. After modeling the relationships once, matching data to forms ceases to be a manual task
Now you may be thinking “that’s all well and good but creating a realistic map of all of these relationships sounds like a herculean task to begin with.” You wouldn’t be wrong, except that you don’t have to build out a knowledge graph from scratch.
Although knowledge graphs have only recently entered the zeitgeist, the technology and standards have been around for decades. As a result, numerous public resources exist to give organizations a jump start on building their enterprise knowledge graphs. Within the financial sector, FIBO (The Financial Industry Business Ontology) is an ontology created by a consortium of organizations and maintained by The Enterprise Data Management Council for organizing knowledge graphs.
What is an ontology? It’s the framework that defines the types of entities (company, person, article, etc.) that can exist in a graph and the types of relationships that can connect them. In short, FIBO provides the conceptual structure over which financial companies can place their data. Not only does this mean much of the heavy lifting needed to build a new graph is already complete, but it also enables greater interoperability between financial sector knowledge graphs.
Two or more partner companies can easily link their graphs as long as they share a standard ontology, so as organizations share data with one another, FIBO makes it easy to scale up knowledge graphs. Furthermore, using existing standards allows companies to add the thousands of publicly available linked data sets to their knowledge graph to increase its size and scope with little extra labor.
At the end of the day, the financial sector competes on data. Unless companies can quickly find the information they need to make decisions, they jeopardize their future. Knowledge graphs help companies extract more value from their data by making it easier to retrieve and analyze. They mimic the way humans actually think, linking concepts via relationships. This model results in a store of information that is both machine and human readable. It layers context and meaning on top of the data itself. With a knowledge graph in its back pocket, a financial services company can see into its data more effectively and use it more efficiently.