Banking supervision is a pillar of economic stability, and rule-based AI systems promise to enhance its efectiveness through scalability and explainability. In this paper, we present a concrete case study from the Central Bank of Italy, where we developed and deployed KG4VIG, a rule-based framework built on the Datalog± family of languages and Knowledge Graphs. Focusing on the task of computing shareholding relationships in a financial network, we show how our declarative reasoning approach overcomes the limitations of matrix-based methods and provides an explainable and scalable solution.
Banking supervision is one of the most critical aspects for ensuring the continued functioning of our economic systems and society as a whole—as demonstrated by the devastating efects of some of the largest bank failures in history. The promises of information technology in general, and symbolic, rule-based AI systems in particular, to address these challenges are high. The main question we are going to answer in this paper is “is this all a fantasy?” and which points translate into reality, shown through a concrete approach in real-world use in the central bank space.
In an influential paper, Ehrlinger and Wöß [
Still, how should we model ontologies? A prominent approach comes from the logic, database, and
Knowledge Representation and Reasoning (KRR) communities, which have devoted increasing efort to
express ontologies as rules in the Datalog± family [
Vadalog [
From the academic point of view, here we wonder: is this Datalog- rule-based ecosystem, stemming from decades of database and AI research, really actionable for real-world problems? Contribution. In this paper, we demonstrate through an industrial case in the financial domain that rule-based reasoning with Vadalog and KGs can efectively address real-world challenges, ofering scalable and explainable solutions. We present a perspective on Kg4Vig, a framework we developed and now in production at the Central Bank of Italy to support banking supervision.
Kg4Vig is a banking supervision platform with numerous features. In this paper, we focus on one specific task: providing analysts with the Integrated Ownership (IO) of a bank within a financial KG, where nodes represent financial entities (be they banks, companies, intermediaries, or people), and edges are shareholding relationships between them. The IO of an entity over is defined as the total ownership—both direct and indirect—that holds on , and serves as a measure of the influence of an entity over another, by quantifying the cumulative ownership involvement between them. While a matrix-based formulation of this problem exists, it sufers from computational limitations. We propose a declarative rule-based solution, formalized in Vadalog and implemented within Kg4Vig. We argue for the scalability and explainability of our technique for IO, and underscore the key role of tailor-made UI/UX components for successful rule-based applications.
Overview. In Section 2 we present the reasoning setting. In Section 3, we focus on the implementation and UI aspects. Section 4 concludes the paper.
Let = (, , ) be a graph that models the property relationships between financial entities—or
companies hereinafter—where is the set of nodes representing companies, ⊂ × is the set of
directed edges for ownership relationships, and : → [
In Kg4Vig, we solve the IO problem with a graph factorization approach: first, we compute the IO between all pairs of nodes within the same strongly connected component (SCC) with Eq. (1). Then, with the following Vadalog rules, we merge the SCC-local IOs and compute the IO between nodes in diferent SCCs.
Edge(, , _, _, _, _ ), = ,
→ Own(, , _, _, _, _ )
Edge(, , _, _, _, _ ), _ ̸= _, = (_ /(1.0 − _ )) → Own(, , _, _, , _ ) Edge(, , _, _, _, _), Edge(, , _, _, _, _ ), _ = _, _ ̸= _, _ ̸= _, = (_ * _ /(1.0 − _ )) → Own(, , _, _, , _ ) Own(, , _, _, _, _), Edge(, , _, _, _, _ ), _ ̸= _, _ ̸= _, _ = _, = (_ * _ ) → OwnD(, , _, _, , _ ) OwnD(, , _, _, _, _), Edge(, , _, _, _, _ ), _ ̸= _ ̸= _ = (_ * _ /(1.0 − _ )) → Own(, , _, _, , _ ) Own(, , _, _, _, _), Edge(, , _, _, _, _ ), _ ̸= _ ̸= _, = (_ * _ /(1.0 − _ )) → Own(, , _, _, , _ ) (2) (3) (4) (5) (6) (7) The Edge predicate captures the identities of and , the SCC they belong to (_ and _ ), the weight _ , and the (SCC-locally computed) integrated ownership of over itself _ = ℐ. If and belong to the same SCC, then _ is set equal to ℐ, as by Eq. (1); if they belong to diferent SCCs, then _ = (, ), i.e., the ownership shares of in , if there are any. This is equivalent to adding edges between any pair of nodes (, ) belonging to the same SCC with weight ℐ (see Figure 1, black and purple edges and weights). The contributions are later summed to get the integrated ownerships between every two companies.
When and belong to the same SCC (Rule 2 - base case) the resulting ’s simply equals _ itself. When and belong to diferent SCCs and are connected by an edge ( Rule 3 - base case), the resulting of Own is computed by the sum of all _ normalized by (1 − _ ). This normalization factor takes into account the sum of the weights of all walks from to itself in the graph, which in matrix terms is equal to ∑︀+=∞0 = ( − )−1; these walks are the ones that, concatenated with the edge (, ), form the Baldone walks from to . Indeed, by massaging Eq.(1), it can be shown that 1/(1 − _ ) = 1/(1 − ℐ ) = ( − )−1. In Figure 1 this is the case for = and = , which produces the contribution = 0.1/(1 − 0.4) = 0.1¯6 to the computation of ℐ.
The last four rules are recursive cases of the first two. Rule 4 states that if and belong to the same SCC (and hence there is an edge between the two of weight _ = ℐ) and there is an edge from to where belongs to a diferent SCC then the term for Own between and is the sum of _ * _ normalized by (1 − _ ). In Figure 1 this is the case for = , = and = , producing the contribution = (0.7 × 0.5)/(1 − 0.4) = 0.5¯8 to the computation of ℐ. Summing up the two contributions coming from Rule 3 and Rule 4 (as together they consider all the Baldone walks from to in the graph), we get that ℐ = 0.1¯6 + 0.58¯ = 0.75.
In Rule 5, a new predicate appears, OwnD, which is in turn used in Rule 6. Rule 5 tackles the case where an ownership path is computed between and belonging to diferent SCCs, and then is connected to in the same SCC; the term for OwnD between and is the sum of _ * _ ; this time it is not normalized, as by definition _ is already equal to ℐ. In Figure 1 this is the case for = , = and = , producing ℐ = ℐ × 1 = 1 × 1 = 1. Since in our setting every pair of nodes is connected in a SCC, with Rule 5 we already cover all the nodes belonging to the same SCC of .
Therefore, the next step of the recursion must necessarily leave such SCC as otherwise it would re-visit nodes; this is the role of Rule 6. In it, all three nodes , , must belong to diferent SCCs, with OwnD between and computed by Rule 5 and an edge from to ; then the term for Own between and is the sum of _ * _ normalized by (1 − _ ). In Figure 1, this is the case for = , = and = , which produces = ℐ × 0.1/(1 − 0.4) = 1 × 0.1/0.6 = 0.16¯ to the computation of ℐ.
Finally, Rule 7 is as Rule 6 but with the predicate Own in input, covering the last case where all the three nodes , , belong to diferent SCCs. In Figure 1 this is the case for = , = and = , producing the contribution = ℐ × 0.5/(1 − 0.4) = 1 × 0.5/0.6 = 0.8¯3 to the computation of ℐ, that together with what computed by Rule 6 is equal to ℐ = 0.16¯ + 0.83¯ = 1. Notice that ℐ = 0.3/(1 − 0.7) = 1 is computed by Rule 3 in the base case.
Correctness and scalability. Our observation is that the IO between two nodes that belong to the same SCC involves only walks in , i.e., the application of Eq. (1) can be restricted to the adjacency matrix of . For example, in Figure 1, we have three SCCs: {}, {, } and {, , }; the application of Eq. (1) to = {, } produces ℐ = 0.7, ℐ = 1, ℐ = 0.7 and ℐ = 0.7 using = [0, 1; 0.7, 0].
Our KG comprises ∼ 64k SCCs, whose largest component has ∼ 1k nodes, while all the others are under 50 nodes, making Eq.(1) eficiently computable in each SCC. Moreover, such computations are parallelizable among the SCCs as the calculations are independent of each other. The whole IO computation can be parallelized among weakly connected components of the graph, as they do not share any Baldone walk.
While this paper only focuses on a specific application perspective, we remark that the Kg4Vig system is fully engineered and currently adopted in production in the Central Bank of Italy. Implementation. An IO-centered view on its architecture is shown in Figure 2. A data wrangling component builds the KG from the enterprise data stores and materializes it into a Neo4J cluster.
In particular, they perform specific step in the data transformation pipeline that goes from improving the data quality and consistency (data cleaning) and harmonizing heterogenous data schemas into a unified global one ( schema integration), up to the construction of a unified graph view on domain entities and their relationships by integrating data from diferent data sources ( entity resolution and data fusion). The database is deployed across three geographically distributed nodes to ensure load balancing, end-users’ query performances, and fault tolerance.
Vadalog is used for data wrangling as well as the execution of business rules, like those of IO (Section 2). The rules are compiled into an abstract higher-level algebraic representation, namely, an execution plan, which is finally translated into a set of Spark Jobs. An underlying Apache Spark Cluster (16 cores, 32 threads, 256 GB of RAM each) executes these jobs, and the results are stored back into the KG. A dedicated web app provides access to the users. The data wrangling phase, as well as performance-critical tasks like IO, require the native use of PySpark and dedicated graph libraries such as GraphFrames, which provide primitives for distributed data processing within a Spark ecosystem.
To compute IO, all the SCCs are preliminarily identified using built-in methods from GraphFrames and then, they are transformed into a matrix representation, where Eq.(1) is solved in Numpy. The illustrated Vadalog program is then applied on the results from this phase. The reasoning engine retrieves and parses the ontology (i.e., set of rules) from its internal repository, applies a series of logic optimizations, and construct an access plan that maps each rule to a corresponding data transformation operation. This access plan is eventually compiled into a query plan tailored for the target execution environment. Within our framework, the reference execution environment is represented by the Apache Spark cluster; hence, the compiled query plan leverages Spark primitives to distribute the data processing workload across it. Finally, the computed IO from both stages are persisted back into the Neo4J graph database, thereby augmenting the KG with new inferred knowledge. These results are accessible to end-users through a tailored web application that facilitates the user interaction with the KG.
Notably, all the reasoning and Python computations are executed in parallel across SCCs, maximizing
the use of cluster resources. The overall computational time for the IO is ∼ 3 hours; notice that the use
of Eq.(1) for the whole graph would make the machine to run out of memory space before termination.
Visualization. As rule-based developers and adopters, a tempting perspective lies in ofering
generalpurpose solutions, with generic graphical metaphors for nodes and edges cooperating with rule-based
reasoning widgets [
Scalable logic fragments like Warded Datalog± , supported by eficient execution engines, ofer an extremely promising avenue. Thanks to the combination of KGs and rule-based reasoning, high interpretability of results can also be achieved. UIs can be hinged on the visual metaphor of extensional vs intensional components: the former shows the business data in the form of a property graph, carefully rendered with graph visualization libraries, the latter highlights the knowledge derived from the reasoning process. For example (Figure 2), the derived edges denoting IO and other business-relevant amounts, are shown in dashed line, while the extensional edges for the same measures (i.e., in the figure, the control edges, denoted in orange in both cases) are shown in solid line. The informative use of line styles, added to an accessible color palette to denote the diferent measures, as well as the careful use of shapes and symbols, facilitate the readability of the information shown by the application.
User interaction is also crucial: our approach consists in an incremental expansion of the currently visualized graph, which follows and mimics the rule application. The involving feeling of driving the analysis comes as a consequence. In the IO case, explainability is supported by interactive node exploration. The analyst may request a visualization of entities that directly or indirectly own the subject, with each step of the calculation made explicit as computed by Vadalog, trace ownership chains, and find the ultimately controlling bank. Side-tabs provide legends on colors and symbols, as well as information on the datasets of provenance and computed IO, reminding the user the computational principles underneath.
We presented a real-world application for the Central Bank of Italy, demonstrating the practical use of
rule-based technology built on a state-of-the-art Datalog-based language and system. The successful
deployment of such tools proves that their use is not a fantasy. While the gap between theory and
practice, especially in the realm of logic programming, often seems wide, we showed that careful
design choices and concrete experience in industrial contexts can bridge it efectively. The step-by-step
inference mechanism of Datalog is already inherently explainable, but tight integrations with LLMs are
starting to show the possibility to develop GraphRAG [
This work was partially supported by the Vienna Science and Technology Fund (WWTF) [10.47379/VRG18013, 10.47379/NXT22018, 10.47379/ICT2201] and the Austrian Science Fund [10.55776/COE12].
The authors have not employed any Generative AI tools.