Unravelling financial scenarios characterized by the interplay of many entities with complex interconnections is at the core of banking supervision. In particular, it involves applying technical regulations to large graphs of banks, financial intermediaries, and companies, to derive the knowledge needed for compliance checks. In such settings, modern notions of logic-based Knowledge Graphs (KGs) come to help. A KG is composed of an extensional component, the enterprise data, and an intensional component, a set of rules capturing the regulations, which are applied to infer a derived extensional component, thus enriching the original graph. State-of-the-art logical languages of the Datalog+/- family strike a good balance between expressive power and computational complexity, allowing for efective encoding of real-world scenarios.
In the financial space, the application of regulatory prescriptions and compliance checks in the presence of large networks of entities with a complex interplay is particularly challenging. Specifically, banking supervision, i.e., the oversight ensuring that the banks follow the regulation, often entails unravelling such networks so as to compute the knowledge nee1d].edTh[ e typical supervision action follows a threestep process: (i) the financial authority is tasked with some regulation-related questions concerning a supervised entity, a bank or a financial intermediary; (ii) the regulation-related questions are translated into one or more data-related query to be answered thanks to an intelligent use of the enterprise data assets of the financial authority; (iii) the data-related queries are executed, integrated, and contribute to the construction of the business answer.
In these settings, logic-based notionKsnoofwledge Graph[s2] (KGs) are helpful. They consist of an extensional compone,natdatabase of facts integrating the enterprise data storeisn,taenndsiaonal componen,ta set of logic-based rules capturing the regulation. The extensional component is modelled as a graph. The intensional component is expressed wKitnhowaledge Representation and Reasoning (KRR) formalism. Languages of the Data±lofagmily [3] such asVadalog [4], achieve a good balance Joint Proceedings of the Workshops and Doctoral Consortium of the 41st International Conference on Logic Programming, September (D. Magnanimi)
luigi.bellomarini@bancadital(iLa..iBtellomarini)m;atteo.brandetti@bancadita(lMia..iBtrandetti);
CEUR Workshop
ISSN1613-0073 between expressive power and computational complexity, ofertirnagctable query answeriwnghile supportingfull recursioanndexistential quantificatio,fneatures that are essential for KG navigation and ontological reasoning, respectively. The application of the intensional component to the extensional component, through the so-calrleeadsoning proce,sgsives rise to thdeerived extensional compon.ent
In the Central Bank of Italy, we have extensive experience in tackling regulation-intensive tasks by adopting logical KGs and we have developed methodologies, tools, and best practices to design, construct, and roll out into production KG-based solutions. The extensional component of the KG integrates the information assets of the Central Bank into a supervision KG. To obtain a comprehensive, easy-tocommunicate, and sound extensional component, we introduschedemaa-design methodolog[5y], which fosters the idea of a high-level conceptual understanding of the domain, featuring a straightforward conversion to an executable form, fit for the target system. The design of the rules and constraints to encode the regulation is not new in the liter6,a7t,uer.ge.][. It is intellectually stimulating and involves delving into the computer-theoretical internals of the entailed problems and capturing them in a logic-based formalism. We have developed experience with many problems revolving around the corporate economic area and, in particular, related to understanding who retains control over th decisions of banks and intermediari8e]s. [
Architectural challenges arise in the so-rceaalsloending proce,swshere the regulationViandalog is applied to the extensional component, to implement steps (i)-(iii) of the supervision endeavour. A particularly relevant one is scalability, since many analyses often involve worldwide KGs, with hundreds of millions of nodes and even billions of edges. In this sense, we have recently developed systems for scalable reasoning Vinadalog, which exhibits very good performance in the settings at9h].and [ Concerted Control. In this paper, we want to walk the thin line between theory and practice and share our design-to-production experience and methodology. We will follow a by-example approach and showcase how the regulation-intensive problceomnocferted contr[1o0l] is faced by (i) designing the extensional component of the KG; (ii) encoding the regulatViaodnailnog in the intensional component of the KG; (iii) executing the regulation inVatdhaelog system in a distributed setting.
Example 1. Consider Figur1e. Two entities, and , hold a minority stake (respectively 20% and 40%) of a company . Individually, neither holding would be enough to co,natcrcoolrding to a majority threshold of 50%. In fa cth,olds a managerial role in. This suggests th atand have a potential strategic alignment. Therefore, seemingly independent ownerships can “act in concert” and exert influence or even control, summing their shares in it. Clearly, this definition recursively propagates through the graph: if a company has an managerial role in, coordinated interest can spread: in this case, the concert group would indirectly control the shares held directly by the controll ed, caonmdpcaonnycerting actors and , eventually gaining control of an interme diaasrwyell with 60% of the shares. ■ Contribution. Along the lines of concerted control, this paper provides a guided explanation of our methodology as well as pointers to more in-depth notions for the interested reader. • We introducKeG-Model, our schema-design methodologies for KGs and apply it to concerted control. • We analyse and formalize the problem of concerted control, providing its encoding Vinadalog. • We discuss how thVeadalog system addresses the mentioned scenario sincaalable setting. Overview. The remainder of the paper is organised as follows. In Se2c,twioenlay out the preliminary technical background of KGs aVnaddalog. In Section3, we design the schema to solve our problem. Section4 is dedicated to the concerted control problem. S5ecshtioowns theVadalog system in action in the setting at hand. Finally, in Sec6t,wioendraw our conclusions.
Let us now introduce the necessary preliminaries. First, we describe the technical background, then we introduce the company control problem, as an example.
Relational Foundations. A (relationa)lschema S is a finite set of relation symbols (porredicate)s with associated arity.teArmis either a constant or a variablea.tAomn overS is an expression of the form()̄ , where ∈ S is of arit y> 0 and ̄ is an -tuple of terms. Adatabase(instanc)eoverS associates to each symbolSina relation of the respective arity over the domain of constants and nulls. The extensional componenotfa KG is a database instance.
Vadalog. A Vadalog program consists of a set of facts aexnidstential rul,efusnction-free Horn clauses of the form∀∀̄((̄, ̄)→̄∃ (̄, ̄ ))̄ , where(, ̄)̄ (thebody) and (, ̄ )̄ (thehead) are conjunctions of atoms over the respective predicates and the arguments are vectors of variables and constants. It may also featureequality-generating dependenc(EieGsDs), first-order implications of the for∀m((̄)→̄ = ), where()̄ is a conjunction of atoms an d, ∈ .̄ Existential quantification in rule heads introduces new fresh symbols calleldabelled nul,lws hich are placeholders for unknown values. EGDs assign values to labelled nulls or enforce their equivalence. This mechanism is fundamental for a broad class of reasoning tasks, including graph traversal, clustering, entity resolution, and1d1]a.ta fusion [ Moreover, our applications call for multiple features that extend the declarative language. Among them, aggregate functio,nnsamelysum, prod, min, max andcoun,tas well as SQL-like grouping constructs, are particularly relevant. Important extensions alsostinrcaltuifieddeandground negatio,nnsegative constrain,tnsegations as failu,raendexpressionsin rule bodies, modelled wictohmparison(>, <, ≥, ≤, ≠) andalgebraic(+, −, ∗, /, etc.) operators. The intensional component of a KG consists of a set Σo.f rules Reasoning and Query Answering. Intuitively speaking, aonntological reasonitnagsk consists in answering aconjunctive quer(yCQ) over a databas e, augmented with a seΣtof logical rules. A conjunctive query (CQ ) over a schemaS is an implicatio n( x) ← (x, y), where (x, y) is a conjunction of atoms, a n(dx) is an n-ary predicate notSi.nThe semantics of a Datal±opgrogram is usually defined in an operational way with an algorithmic tool knownchaassethpreocedur[e12], which enforces the satisfaction of a set of dependeΣnociveesr a databa se, incrementally expanding with facts entailed via the application of the ru le,suonvteirl all of them asraetisfied .
Example 2. Consider the following majority-based definitΣioonf the relationship of control between entities in a supervision KG.
control(, ), own(, , ), sum(, ⟨⟩) > 0.5 → entity() → control(, ).
control(, ).
(
In the rest of the paper, we shall focus on more complex notions of company control, which, however, are based on the simple one of Examp2l.e
In our supervision KG for the Bank of Italy, we aim at supporting forcmonscoefrted cont,rwohlich occurs when the decision power is exerted by multiple actorasctthiantc“once”r,tin a coordinated manner, either publicly exposed or covert.
We illustrate our KG design methodology in two phscahseesm:a desig n,in which the new domain elements of the KG extensional and derived extensional component are bduesviinseesds; definition, in which the intensional component is conceived through text analysis and culminates in drafting the resulting Datal±orgules. These phases are narrated through the eyes of two skilled analysts: The Graph Architect designs the concep- The Rule Engineer encodes normative pretual model that defines the Knowledge Graph scriptions and computations as logic rules schema, ensuring that it accurately repre- guaranteeing correctness and completeness sents the domain, satisfies user requirements of the formulation while ensuring scalable and matches modelling principles. performance of the task.
A presentation of the schema design methodology is provided in S3e.c1taiolonng with a view on the Bank of Italy KG. The design journey for the case of concerted control is narrated 3in.2 Sections (extensional component) an3.d3 (derived extensional component).
Let us explore the KG modelling part. eTxhteensional componeonftthe KG contains economic actors (e.g., banks and intermediaries, companies, individuals) connected by their participation in the shareholding capital. Thientensional componencatptures the business knowledge, coming from the regulation, which is applied on the elements of the extensional component to proddeurciveead extensional compon.ent
To design the KG, we usKeGModel, a methodology inspired by model-driven software desig1n3][. In KGModel [5], the Graph Architecdtesigns a graph schema at a high level (the so-csaulpleerd schema), by adopting generic constructs rendered throcuognhceaptual visual modelling lang,uage namely,Graph Schema Language(GSL). The schema can be represented as a GSL diagram, which adopts visual grapheme.sA list of specific visual graphemes used in the super-schema of this paper is detailed in tabular form in Figu2r,ealong with their role in the system.
A View on the Bank of Italy KG. Figure3 shows an essential portion of our KG, designed using our methodology (black-coloured section). eTxtheensional componenrtevolves around the notion of Person, which embodies any actor in the world relevant for the supervision domain. To better represent the domain, these entities are modelletdoitnaladisjoint specialization hiera, rwchiych distinguishePshysicalPerson andLegalPerson; the specialization is total, as no person can exist unless it is specifically physical or legal, and disjunct, as no physical person can be a legal entity, and vice versa. ALegalPerson in turn can be (totally and disjointCloym)apany (i.e., a legal person with a shareholding capital) oNroanCompany (e.g., public entities like a Ministry or a municipality). A final more specific type of company is theSupervisedIntermediary: it has a special meaning for the context and peculiar traits (ea.gu.,thorityCode); the specialization is non-total as there exist companies that are not supervised intermediaries, and partially disjoint,SsuinpecrevaisedIntermediary can be a FinancialIntermediary. All persons in the domain have an identifyidin.gAny Person may have shares in aCompany, modelled by thOeWNS relationship withpearcentage attribute. Thdeerived extensional componenintcludes thCeONTROLS relationship, which connects the controPlelrisnogn to the controllCedompany.
Problem Statement for Concerted Control. To kickstart our analysis, we begin from phrasing the problem through the words of Banking Supervision regula10t]i.onA [relevant excerpt is depicted in Figure4. The problem ofconcerted contraosla whole can be articulated in two regulatory pillars: acting in conce,rtthe regulatory concept specifying the criat),ebr)i,aandc) to identify two or more entities that cooperate toward a commonggrooaulp; contr,otlhe regulatory concept that aggregates the ownership contributions of the entities acting in concert, to determine whether they jointly trigger th supervisory thresholds, which in turn entails additional notification and authorization procedures with the supervisory authoriti1e0s].[We will focus on one of such thresholds,ctohmepany contro.l
We now narratively simulate the design of the Knowledge graph through each choice as taken by our Graph Architec,bteginning with theextensional componenotfthe KG.
«The assessment of whether the thresholds (...) have been reached or exceeded shall be carried out (...) with reference to the aggregate holdings in the supervised entity of the parties acting in concert (...) The following parties are presumed to be acting in concert, even in the absence of share acquisitions and unless proven otherwise: a) parties adhering to an agreement, even if invalid or inefective (...) b) a company and the persons who perform management and administrative functions within it; c) an individual and their spouse, the person to whom they are bound by a civil union or de facto cohabitation, as well as relatives and in-laws in the direct line and in the collateral line up to the second degree, including the children of the spouse or cohabiting partner.
(...) the situations referred to in points a) and b) above shall also be considered jointly.»
Agreements: «Criteriona) of the regulation mentions agreements; the typical case would be shareholder agreements; since these agreements are domain concepts with their own identity, I can design them as ShareholdersAgreement entities, connecting to it any entPereirnsgon through aPARTICIPATES_IN relationship. This approach yields tangible benefits: (i) an agreement can be entered by many persons, and any person can enter any number of agreements (Sihi)aareholdersAgreement can have its own attributes (e.gd.,ocId) to keep track of important information; (iSiih) aareholdersAgreement makes it easy to navigate through connected participants; (iv) there is no impact on the existing schema.
Criteriona) mentions as well valid and invalid agreements. For example, the are cases—often not openly reported—where two or more actors coordinate to covertly acquire another company in14a].takeover [ Modelling should foresee such cases to avoid unwanted reworks in the future. As I need to design a single concept with diferent traits, I can useaabnstractiotno model a generAicgreement entity with two specific cases:ShareholdersAgreement andCovertAgreement.
Hence, I will introduce Aangreement entity—connected to participatPienrgson through aPARTICIPATES_IN relationship—withdaisjoint specializatioton represenSthareholdersAgreement (e.g., characterized withdaocId attribute) anCdovertAgreement (e.g., with anewsUrl attribute»).
Company Roles: «The information that I want to preserve for cribt)eroifotnhe regulation is that a Person has a specific type of role in aLegalPerson (typically, in a company). I can: (i) creatReoale entity with raole attribute specifying role type (em.agn.,agement), connected through a relationship to thePerson holding the role and—through another relationshipL—egtoaltPheerson where role is held; (ii) create a relationshHiApS_ROLE_IN directly connecting Ptehreson and theLegalPerson; (iii) introduce a specific HAS_GUIDANCE_ROLE_IN relationship for minimal satisfaction of regulatory requirements.
Solution (ii) appears more convenient than (i), as it allows to represent all needed information with a single construct, where (i) would use three. (iii) has several drawbacks as compared to (ii), because HAS_GUIDANCE_ROLE_IN poorly represents the domain: if today I choose to import only management and administrative roles, I hinder future analyses which can be done on other roles; if in the future we import other roles, then I would need to introduce many new relationships or to revert to (ii), thus changing the existing schema with consequences to the following computation stages (e.g., logic rules, visualization).
Hence, I will introduceHaAS_ROLE_IN relationship connecting Ptehreson holding the role to the respectiveLegalPerson, with arole attribut»e.
Familiar Relationships: «For satisfying criteriocn), I want to design the relationshipPshoysficalPerson entities. First, the disposition mentions spouse, implmyainrgriage,but evencivil unionand de facto cohabitat.ioCnreating anIN_COUPLE_WITH link between persons works well, as I can add an attribute on it, e.g., specifying couple type, and all information is represented. The regulation mentions also relatives. I can add a single catcRhE-aLlAlTED_TO relationship withtaype attribute, abstracting all possible relationships relevant for the regulation (e.g. father-in-law), but: (i) it would capture many indirect relationships, thus opening to confusion in its usage by other applications on the KG that make use of “relatedness”; (ii) we would lose the possibility of representing intermediate entities that justify the relationship (e.g., a mother, between grandfather and son); (iii) I would introduce a technical construct with no domain significance and hence no utility. To accurately represent our domain, I can create granular relationships (e.gS.,IBLING_OF, CHILD_OF) and ofload purely instrumental intermediate representations to the reasoner (e.Rg.E,LATED_TO). Additionally, I should avoid introducing relationships which may be inferred, to prevent incoherences and duplications. Relationships up to the second degree are parents, grandparents and siblings, which can be derived from the foundational cPoAnRsEtNruTc_tOF alone.
Should I aggregatPehysicalPerson entities around a family hub node? The regulation admits afinities whose meaning is not universally mapped to “family” (e.g., cohabiting partner of the granddaughter). A Family entity would introduce an ambiguous concept in the graph which can be confused and, as such, would end up with diferent variations for each domain (eS.ugp.,ervisionConcertFamily, SupervisionPoliticallyExposedFamily, and so on). This excessive specialization suggestsStuhpeartvisionConcertFamily is just another way of defining the concert group, which will have its own representation.
Hence, I will introduce a granular set of relationships bPehtywsieceanlPerson entities and avoid the Family hub. As the regulation devises specific couples and relatives, I will intINro_dCuOcUePLE_WITH for couples—along withtaype attribute valued after couple situation— PaAnRdENT_OF for relatives, while kinship and in-law relationships will be inferred from these extensional c»onstructs.
We now narrate the design of the derived extensional component of the KG.
Concert Groups: «I can model group afiliation as agroup attribute oPferson, populated with some groupId, but: (i) several situations do not warrant for meaningful group identifiers, indicating that thegroup attribute is purely artificial; (ii) I would need to implement navigationgruosuinpgas a key, thus making network traversal harder; (iii) I would change existing schemPaerfosornalnlodes, which in practice encompass almost the entire population of the domain; (iv) I do not have a way to represent group attributes (e.gty.pe) without adding other attributes tPoertshoen node. Instead, I will devise autonomousConcertGroup entities: (i) these groups are the subject of the regulation, so business users will benefit to “see” them distinctly; (ii) there is no need for an artificial group identifiePre;r(isioi)n entities are connected to the group; (iv) group control gets a representation intuitively similar to company control. As a ifnal consideration, the three criteria provided by the regulation involve diferent actoar)s:acnrditbe)ria target companies and individuals, while critce)ritoanrgetPshysicalPerson entities. Hence, the entity that can be in CaoncertGroup is that at the highest level of modelling hierPaerrcshoyn,. Finally, the regulation defines that critear)iaandb) shall be considered jointly; while multiple options are available (e.g., introducing a supergroup), for the sake of clarity I will introduce a new mixeCdotnycperftoGrroup.
Hence, I will modelCaoncertGroup as an autonomous entity, to whicPherason can belong through an IN_CONCERT_GROUP relationship. Since there are diferent criteria to identify cCoonncceretrt,Group will have acriterion attribute valued after its provenan"caeg:reement", "role", "family", or"mixed".»
Group Control: «With the introductionConfcertGroup, group control is straightforward to design as a relationship to a controlled entity. In this way, we can connect any group member to a controlled entity through a single-hop query.
Should I reuse the existiCnOgNTROLS relationship or create a new one? In this Pcearsseo, n and ConcertGroup would share a newCONTROLS relationship and thus they would be modelled by an abstraction, typically Aacntor supernodewith undefined traits, seriously compromising design integrity; second, the semantic CoOfNTROLS would change, propagating this change to existing rules and systems that use it downstream; finally, the group control is conceptually diferent from plain control, for example it is not transitive (efectively making it more similar toulatnimate contr1)o.lThese “smells” suggest that reusingCONTROLS should be avoided.
Hence, I will design group control using aGnReOwUP_CONTROLS relationship between controlling ConcertGroup and the controllCeodmpany, semantically equivalent to an ultimate co»ntrol. 1The ultimate control leorf an entity is an entity that contr olsand is not controlled by anyone.
The obtained graph schema, including all new extensional facts as well as the derived extensional facts—inferred by the rules of the intensional component that we are going to define in the next section—is shown in Figur3e(blue-coloured section). All new entities and relationships in the domain are seamlessly integrated in the model at hand, with no changes to existing objects (black-coloured).
In this Section, we model tbhuesiness definitionof concerted control, i.e., itnhteensional component of the Knowledge Graph. In the process, thReule Engineerencodes normative text into logic rules expressed in Datalo±g,mechanically following regulatory prescriptions and clearing natural language ambiguities to ensure correctness of the implementation. We will first encode the detection of concert groups (Section4.1); then, we will show the computatiognroofup contro(Slection4.2), the ultimate goal of the task at hand. In order to enhance readability, in the rules, we will assume that the extensional component constructs introduced in the schema design phasPeA(eR.EgN., T_OF) are input facts in databas e with a corresponding predicate namecaimnelCaseconvention (e.gp.,arentOf). A brief discussion about correctness, complexity and scalability is in 4S.e3c.tion
We now encode the intensional component for the identification of concert groups.
Agreement Groups. The graph schema models agreements with constrSuhcatrseholdersAgreement andCovertAgreement; a personPARTICIPATES_IN an agreement. Given that both agreement types are equally valid for the regulation of concert groups, we have: shareholdersAgreement(), participatesIn(, ) → ∃
inAgreementGroup(, , ). covertAgreement(), participatesIn(, ) → ∃
inAgreementGroup(, , ). person(), inAgreementGroup(, 1, ),
inAgreementGroup(, 2, ) → 1 = 2.
Rule3 says thatif shareholde rparticipates in a shareholder agreemetnhten participates in an agreement concert grou,pin the context of. Rule4 extends the notion to all covert agreements . Both rules introduce existentials in our reasoning,isinacleabelled nu,lil.e., an unknown value which is generated as a result of reasoning, assumed diferent for each activation of the rules. To ensure that actors participating in an agreement end up in the same grou5p),uRsuesleE(GDs: if a person is in two groups1 and2 having entered agreemen,tthen1 and2 coincide.
Role Groups. For criteriobn), a company and the persons who perform management and administrative functions are presumed to be acting in concert.
hasRoleIn(, , ), = ""|"" → hasGuidanceRoleIn(, ) → ∃ inRoleGroup(, , ), hasGuidanceRoleIn(, ).
inRoleGroup(, , ).
We first infer ahasGuidanceRoleIn relationship by filtering administration or management role types (Ru6l)e.Then, for each guidance role of a person in there exists a concert grouspuch that and both belong to that group (Rule7) due to the guidance o.fIf there are more persons with guidance roles in the same company, they would end up into diferent concert groups. Figur5eintuitively visualizes the reasoning process as a lfower: diferent inRoleGroup(, , ) relationships (petals) are inferred for each role that1, 1 and 3 hold, bound to the subject comp an(ydisk).
Applying EGDs, the reasoner unifies those groups into one.
inRoleGroup(, , ), company(), hasGuidanceRoleIn(, ) →
inRoleGroup(, , ).
company(), inRoleGroup(, 1, ), inRoleGroup(, 2, ) → 1 = 2.
(
First,if has a guidance role in,which is in a role concert grouinp the context o,fthen is in the same group (Rule8). Hence,if company is in two concert grou1ps and2 in the context o,fthen the two groups must be the same (Ru9l).e Family Groups. For criteriocn), a thorough text examination can help understand how the group is devised. «An ① individual and② their spouse, th③e person to whom they are bound by a civil unio④n or de facto cohabitation, as wel⑤larselatives and⑥ in-laws in th⑦e direct line and in t⑧hecollateral line up to the⑨ second degree, including t⑩hechildren of the spouse ⑪orcohabiting partn»erT.he sentence starts with the pivoting entity ① “individual”, to which relationships ②-④ are referred; ⑩ and ⑪ instead are referred to the partner of ①. Parental relationships ⑦-⑨ are referred to the couple: the individual (⑤) and his/her partner (⑥). We first devise family ties, and then apply them to find family groups. We first devise the relationshpipartner_to(1, 2) specifically for cases covered by the legislation (②-④, Rule10), since in the future more couple types can be added to da ta.bTahsen, we introduce relationshirpelated_to(1, 2) (⑤) between persons1 and2 in the direct line and in the collateral line up to the second degree, upwards and downwards (⑦-⑨, for parents1—1,Rfourlegrandparents as parents of parents—Ru1l2e, and for siblings as children of the same parent—1R3)u.lReelationship in_law_to(1, 2) links an individu a1l and relativ e2s of his/her spouse (⑥, Rul1e4).
inMixedGroup(, , , ), inMixedGroup(, , , ),
inMixedGroup(1, 1, , ), inAgreementGroup(, _, ), inRoleGroup(, _, ) → ∃ inMixedGroup(, , , ).
inAgreementGroup(, _, ), ≠ → inMixedGroup(, , , ).
inRoleGroup(, _, ), ≠ → inMixedGroup(, , , ).
inMixedGroup(2, 2, , ), 1 ≠ 2 → 1 = 2. partner_to(, ) → ∃ related_to(, ) → ∃ in_law_to(, ) → ∃ inFamConcertGroup(, , ), inFamConcertGroup(, , ). inFamConcertGroup(, , ), inFamConcertGroup(, , ). inFamConcertGroup(, , ), inFamConcertGroup(, , ).
spouse_to(, ), parent_of(, ) →
inFamConcertGroup(, , ). ∃ inFamConcertGroup(, , ), cohabiting_with(, ), parent_of(, ) →
inFamConcertGroup(, , ). ∃ inFamConcertGroup(, , ), inFamConcertGroup(, 2, ) → 1 = 2.
→ → person(), inFamConcertGroup(, 1, ), We create a family group around a pivoting per.soFnirst, and his/her partnerare in a family group (②-④, Rule15); the same can be said for relatives (o⑤f and ⑦-⑨, Rule16) and his/her in-laws (⑥ and ⑦-⑨, Rule17), the children of the spouse (⑩, Ru18l)eand cohabiting partner (⑪, R1u9l)e. As these rules produce separate groups, we eventually unify them sayinifg athpaetrson is in groups1 and 2 within the context of a family group of pe rs,otnhen1 and2 coincide (Rule2s0).
Mixed Groups. Finally, regulation in Figu4rsetates that critear)iaandb) shall be considered jointly.
This formulation is ambiguous, since there are multiple ways in which it can be applied (e.g., admitting
an arbitrary combinationao)-fb) groups in any number). While this is computable, especially using
reasoning, it can produce unintended patterns, however out of the scope of this work. Hence, we
assume that the regulation indicates the practical combination of exactly one caseao)facnrditerion
one case of criteriobn): we create a new mixed group around an entity that appears in both groups and
we include all entities of those groups into it.
(
We first identify the pivoting entity of the mixed group, looking for p e,rwsohnich is at the same time in an agreement group and in a role group, thus propagating the idenatnidfiersof the original pivoting entities of the groups (R2u1l).eThen, if a perso n is in the same agreement with a per son that is in a mixed gro u p, then is in (Rule22); the same holds for role groups (R2u3l)e. Finally, we unify the mixed groupi:f persons1 and2 are respectively in mixed grou1ps and2 associated to the same agreement and role groutphse,n1 and2 coincide (Rule24).
Concert Groups. Finally, theinConcertGroup relation is derived by the union all the group assignments computed by the Rule3s–24. This can be expressed with rules of the form: “inAgreementGroup(, , _) → inConcertGroup(, ) ”. The remaining rules are omitted for brevity.
Control over intermediaries shall be measured with reference to the aggregate holdings of the parties in a concert group: hence, we can think of it as an entity efectively acting on behalf of each of its members by inheriting their ownerships as if they were its own. This approach ensures that (i) we can leverage the existing formalization of control, (ii) we are accounting for every possible contribution of group members, and (iii) as we will see, that computation complexity is the same as company control, thus the reasoning problemPiTsIME-complete. Given the implementation explained in Exam2,ptlhee majority-based control definitioΣncan be easily extended to account for a concert group. inConcertGroup(, ), owns(, , ), groupControls(, ), owns(, , ), sum() > 0.5 → groupControls(, ). sum() > 0.5 → groupControls(, ).
(25) (26) As a base case, Rule25 states thaift a person owns shares of and is in grou p , and the sum of that shares is more th5a0n%, then control s; leveraging recursion, Ru2l6esays thatif a group controls a set of enti t,iewshich jointly own more th5a0n% of an entity, then control s. A visual representation of the network efect of the recursion mechanism on control is i6naF:isginurce group actsas if owning the shares held directly baynd —which belong to—then owns more than 50% of , controlling it; this unlocks the possibility of control over several other entities in the graph, as can be controlled through joint share,s oafnd ; with , control cascades further in the system, extending to and then down t o, , , opening more possibilities downstream. TheRule Engineer progresses further and implements the ruleisnfCoorncertGroup, i.e., the criteraia)-c) stated by the regulation which lead to presume the existence of a concert group6.bFdigeupircets visually the type of groups. 1 has partner2, who in turn has a chi l4d; according to criterico),n 1, 2 and 4 are in a family concert group.2 and 3 have a role in compan y1, hence 2, 3 and 1 are in a role concert group (criteriobn)). 1, 2 and 3 participate in an agreeme n1t, and so they are in an agreement group, and so d o 3 and 4, in another group due to agreemen2t(criteriona)). 1 is in two groups: as the regulation states that crai)taenridab) shall be considered jointly, then there is a coordination among all involved partie2s, 3, 1, 2 and 3. Also 3 and 2 are in two groups, but not under prescribed criteria (3 is in two agreement grou ps2, in role and family groups). We intuitively reflect on the correctness of our encoding of “concerted control” and briefly discuss the computational complexity of the problem, based on the formal analysis of proposed rules5(wSeilcltion focus instead on actual empirical simulations). For this, we structure the setting into two ontologica reasoning tasks (see Secti2o)n: identification of concert grouapnsdcomputation of group cont.rol Correctness. The correctness of ouVradalog formalization descends by construction from the faithful encoding of the regulatory semantics. The rucloenscfeorrted group identificaticoanpture the propagation of control-relevant relationships between individuals and companies through a principled use of labelled nulls and equivalence rules. The EGDs reflect the legal principle that individuals connected via shared influence over a company should be treated as a single concerted group. Similarly, the rules focroncerted group conterxotlend standard control definitions by introducing synthetic nodes that aggregate ownership, aligning with how the regulation assesses indirect or collective control. Th logic-based encoding ensures that the resulting groupings and control structures correspond exactly t the entities and relationships identified in legal interpretations.
Computational Complexity. The identification of concert grou(pRsules3-24) is encoded with a fragment of Datal±ogknown to guarantee decidabilityPaTnIdME-complete data complexit1y1[] of ontological reasoning. For example, the process of inferring role group6s–(9R)ualsessigns a fresh labelled null to each person–company pair in which the person holds a relevant role. These nulls are then propagated through people linked to the same company. If a person–company pair is assigned diferent group identifiers, the EGDs are applied to merge them. This procedure ensures termination and tractability: labelled nulls are introduced in a bounded and deterministic way, and propagated only along finite relational paths, with no arbitrary generation. Conceptually, the computation corresponds to identifying connected components in an undirected graph whose nodes are labelled nulls and whose edges represent equivalences induced by the EGDs. Since the number of nulls is finite and merges are transitively closed, the process is guaranteed to terminate and can be implemented eficiently using union–find data structures.
The computation of group cont(rRoulles25–26) can be viewed as a generalization of the classical company controplroblem, whose data complexity is also known tPoTbIMeE-complete 8[]. The extension consists in augmenting the ownership graph with artificial nodes that represent concerted groups. Each group is treated as an abstract company controlling—directly or indirectly—other companies based on aggregated ownership percentages.
The number of labelled nulls introduced to represent groups (i.e., artificial nodes) is polynomial in the size of the input (at most one labelled null is introduced for each KG relation). Therefore, the overall size of the augmented graph remains polynomial in the input size. As a result, the same fixpoint algorithm used for computing company control can be applied without modification. Hence, the concerted control computation inherits the same termination guarantees and polynomial-time complexity. Scalability. Despite its theoretical tractability, computing concerted control on large KGs poses significant scalability challenges in practice. This is due to the potentially quadratic number of group–company pairs that must be evaluated. For instance, in a KG with 10,000 entities, there could be up to 100 million possiblegroupControls(, ) pairs. This explosion in the number of candidate control relations requires eficient distributed evaluation strategies.
In this section, we present how tVhadealog system implements concerted control in a scalable manner. We first describe the distributed evaluation algorithm emploVyaedablyog to solve the problem at scale, then, we discuss the performance of the system on a real-world KG.
To address the scalability challenges of the concerted control problem we adopt a practical and scalable approach that leverages the distributed reasoning capabiliVtaiedsaolofgthsyestem [9]. Distributed Evaluation Model. To describe the evaluation model ofVtahdealog system, we consider a shared-nothing architecture with independent workers that share no memory and can communicate via messages. We calplartitiona portion of memory that can be accessed by a single worker and we call shufling the act of exchanging messages (i.e., facts) among workVeardsa. log’s computational model is based on theMap Reduceparadigm where every operation on predicates (i.e., relations containing facts) can be executed in a distributed fashion following three steps: (i) assigning a key to each fact in the predicate; (ii) shufling the facts into the same partition based on equivalent keys, and (iii) applying a user-defined operation to the facts in the same partition to derive new facts.
The evaluation oVfadalog rules is based on a variantSeomf i-Naive Evaluation(SNE) [15], adapted forVadalog rules and designed for distributed execution. SNE is a bottom-up reasoning technique that incrementally materializes all derivable facts by repeatedly applying thΣetroulaens iinnput database until a fixpoint is reached. In a distributed setVtaindga,log extends this approach to account for labelled nulls: at each iteration, only facts that are not structurally identical up to renaming of label nulls are considered new, and added to the corresponding predicate. This condition allows for the termination of everVyadalog set of rules evaluation.
To scale the reasoning proceVsasd,alog structures the SNE as a sequence of MapReduce steps. The input to the pipeline is the set of base fac tsainnd each step performs the following actions: • Facts are shufled across workers according to a partitioning criterion specific to the transformation required by the rule being applied. • Each partition applies a user-defined transformation function that encodes rule logic (e.g., joins, projections, aggregations). • The result is post-processed (e.g., to eliminate duplicates) and re-shufled for the next stage. If the rule seΣt includes recursion, a subset of these steps is repeated until no new facts are produced. Rules Evaluation Examples. To concretely illustrate the evaluation process, we present examplebased executions of Rule2s5–26 and6–9, as implemented in Algorithm1sand2. These algorithms rely on a sequence of relational transformations and auxiliary functions designed to eficiently compute ifxpoint and enforce labelled nulls equalities during rule evaluation. • Projection, join, union, diference and labelled nulls creaΠt[⋅i]odne:notes aprojectio,noptionally involving the generationlaobfelled nulflosr existential variables. The superscriinpdticates that the operation is performed under the semantics adoptVeaddbaylog, where facts are considered duplicates if they are identical up to renaming of labelle⋈d ndeunllost.es the standanradtural join between predicate∪s,denotesunion, while∇ indicates a set diference under the semantics used by Vadalog, meaning that duplicated facts are filtered out during the diference operation. • AggregationsA:ggregation operations (es.gu.m,) are expressed using SQL-stylgeroup-by with conditionnotation, writtenAaGsG,
[] () , where are the group-by variablesis, the aggregation function, is a constraint on the aggregated valuesu(em.g(.), > 0.5 ) and is the predicate name on which the aggregation is applied. • Auxiliary functionsm:ergeTransitively computes the transitive closure of equivalence classes of labelled nulls induced by the EGD enforcements. The funucptdiaotnePredicate replaces labelled nulls in a predicate according to an equivalence mapping retumrenrgeedTbryansitively. updateGroups abstracts the incremental fixpoint update of a recursive predicate by applying new aggregated facts to the current state and returning only the newly derived facts. Each of these operations can be naturally implemented using a MapReduce-style and in-memory execution model, as supported by distributed frameworkAsplaikcehe SparkSQL[16]. The pseudocode of Algorithm1s and2 follow. Note both of them use fixpoint loops (lines 5-9, 3-6, respectively), which encode the basic idea of SNE, wheVraedalog rules are applied as long as they produce facts. 3: 6: 7: 8: 10: 1: groupControls ← AGG[,] 2: Δcontrol ← groupControls 3: repeat 4: 5: 6: until Δcontrol = ∅ 7: return groupControls 4: ΔinRoleGroup ← inRoleGroup 5: repeat
new ← Π
[,,] (ΔinRoleGroup(, , ) ⋈ ΔinRoleGroup ← new ∇ inRoleGroup inRoleGroup ← inRoleGroup ∪ ΔinRoleGroup 9: until ΔinRoleGroup = ∅ 11: eqPairs ← Π [ 1, 2](inRoleGroup(, 12: equiv ← mergeTransitively(eqPairs) 13: inRoleGroup ← updatePredicate(inRoleGroup, equiv) 14: return inRoleGroup Algorithm 2 Evaluation oVfadalog Rules for Concerted Group Control (R2u5l–e2s6).
sum()>0.5 (inConcertGroup(, ) ⋈
owns(, , )) company() ⋈ hasGuidanceRoleIn(, ))
▷ Keep only new facts ▷ Accumulate derived facts 1, ) ⋈ inRoleGroup(, 2, ) ⋈ company())
▷ Rule9 ▷ Merge labelled nulls into equivalence classes ▷ Replace merged nulls ▷
Rule25 ▷ Set delta for recursion ▷ Fixpoint loop for Rul2e6 ▷
Infer indirect control ▷ Stop when no new facts are produced ▷ Final group control Algorithm 1 Evaluation oVfadalog Rules for Role Group Definition (Rule6s–9) 1: hasGuidanceRoleIn ← Π
[,] (hasRoleIn(, , ) ∣ ∈ { 2: inRoleGroup ← Π [,∃] (hasGuidanceRoleIn(, )) ∪ Π [,∃] (hasGuidanceRoleIn(, )) “administratio,n“”management}”)
▷ Rule6 ▷ Rule7 ▷ Initialize delta for recursive propagation8()Rule aggOwnNext ← AGG[s,u]m()>0.5 (Δcontrol(, ) ⋈
owns(, , )) Δcontrol ← updateGroups(groupControls, aggOwnNext) ▷ UpdategroupControls and return the delta Experimental Evaluation. We conducted our experimental evaluationViandalog.
Setup. We used the supervision KG of the Bank of Italy. The extensional component used in the experiments comprise182
nodes and more tha1n30 ownership and role relationships and has been built integrating several enterprise data assets, internal and external. The execution environment is a Spark cluster (version 3.3.2), with 4 distributed executors, each with 30 GiB of RAM.
We focused on the evaluation of Ru6l–e9s, which compute concert groups according to critbe)rion of the regulation (dubbedidaesntification of concert groupslike in Section4.3), and Rules25-26, which compute group controls (dubbedcoamsputation of group contr)o.lIn particular, the scalability of Algor1itahnmds2 was evaluated by measuring the execution time with a growing level of parallelism (i.e., the number of cores per executor). The results have been averaged over three evaluations.
Result.sThe identification of concert groupprsoduced more than 5role groups, whilceomputation of group controtlask discovered more than 2.2groupControls(, ) relationships.
The execution times, shown in Figu7r,econsistently remained below 25 minutes, thus making the computation of concerted control feasible on the real graph. We observe a linear speed-up as we increase the number of cores assigned to each executor. This trend highlights the parallelization efectiveness in distributing the workload. Going over 16 cores per executor, the performance degrades, likely because of the data transfer overhead due to abrupt broader distribution and reduced memory locality. These results—executed on our internal distributed computing infrastructure—indicate that the rule-base approach is viable on the supervision KG, achieving runtimes compatible with the requirements of the industrial use case.
We presented a logic-based methodology for tackling regulation-intensive challenges in the legal domain. We used the motivating example of “acting in concert” in banking supervision, appreciating the shift of paradigm from the soft approach of natural language encoding of the regulations to the hard process of logic-based formalizations. Logic-based approaches ofer a concrete tool to pursue regulatory simplification through optimization and restructuring. Logic-based Knowledge Graphs ofer a natural and robust framework for legal reasoning on corporate structures. Our metKhGodMooldoegly,, introduces a graph super-schema that serves as an extensible and system-agnostic domain abstraction layer. The declarative formalisation of the business case through logic rules enables transparent, precise, and scalable compliance checks. Our experience at the Bank of Italy shows that such methodology ofers a foundation for designing systems that are aligned with legal intent, responsive to change, and capable of supporting the explainability and accountability that modern governance demands.
The authors have not employed any Generative AI tools.