The banks we work with have a metric called collection efficiency. Every one of them computes it differently.
Differently in ways that matter: whether part-payments count, which Days Past Due bucket resets the denominator, what happens to accounts that were written off and then recovered. Ask the collections head, the risk head, and the MIS team to write down the formula independently. You will get three documents. They will not agree on the same number for the same portfolio in the same month.
This has been true for years. Each team ran their own reports, attended their own reviews, and made their own arguments with their own numbers. The disagreement was distributed across the organization and therefore invisible. Day-to-day operations never required a single simultaneous answer from all three teams. So the question of what collection efficiency actually means, at this institution, is never formally put.
This is where Knowledge Graphs come in aid of risk analytics. The architecture has one non-negotiable requirement: every metric must be defined with enough precision for a machine to compute it without asking for clarification. Not approximately but exactly. Which means before a single query can run, someone must write down that one formula that every team will use.
If your institution is like most we have encountered, the architecture will keep stopping you. Not because the concepts are hard. It will stop because your teams have likely been running on several slightly different definitions of the same term for years, and the machine will not proceed on a consensus that has never been made explicit. It demands the explicit.
A Knowledge Graph is how you give it that precision. Think of it as three layers sitting between your data and your people. The first layer is where your metrics live — NPA rate, collection efficiency, provision coverage — each with one exact, approved formula. The second layer maps abstract business concepts like Days Past Due to wherever they actually sit across your tables and systems, because the same concept rarely lives in one place. The third layer is your physical database. The graph connects all three so that when anyone asks a question, the answer follows your rules — not a guess. Every query, from every user, computes the same number.
That is what makes it different from every analytics tool that came before it. Those tools connect to your database and approximate. The Knowledge Graph does not approximate. It enforces.
It is not a data problem. Data quality is a different failure, with a different fix. This is a belief problem. The Knowledge Graph is the first system to put everyone in the same room and ask the question simultaneously.
In making the question unavoidable, it makes it answerable. The act of encoding produces the definition. An institution knows what it believes about collection efficiency only after it is forced to say it precisely enough for a machine.
This matters for how you think about AI. The question before any deployment is not which model to use, or which vendor has the best interface. It is whether your institution has encoded what it knows. An AI layer sitting on top of tacit, unresolved institutional knowledge will not surface that knowledge. It will approximate it, quickly and confidently, with enough plausibility that the approximation will not be questioned until it causes a problem in a credit committee, in an RBI examination, or in an ECL computation that two teams cannot reconcile.
Before you approve the next AI initiative, ask one question in your next review: can your team produce, in writing, the exact formula for your five most critical risk metrics, with sign-off from every function that uses them? If they cannot, you do not yet have an AI problem. You have an encoding problem. The AI project is premature.
The institutions that build this layer now will not just move faster. They will, for the first time, know what they know.