Cosmin Marginean

February 6, 2023

Ultimate parents and corporate control with Open Ownership

When discussing corporate ownership, the term ultimate parent usually refers to entities (non-individuals) at the top of ownership chains. Determining ultimate parent(s) provides context for a corporate group and it's an essential requirement in various Risk & Compliance use cases. In this article we'll explore the process to identify ultimate parents and intermediate entities using Open Ownership and BODS RDF.

You might find various definitions for ultimate parent, but for this exercise, we'll (loosely) stick to the following:
"An ultimate parent is a relevant entity which is not a consolidated subsidiary of another entity that is itself an ultimate parent." (source)

The first thing to point out is the fact that a company can have multiple ultimate parents. It's a misconception that there is always a single entity with significant (ultimate) control over a target. Yes, it's true this is most often the case, but there are plenty of counter-examples where several top-level entities have control over an asset.

There is a debate about which use cases would consider any form of control vs significant control. But more often than not, a company that has any control (directly or indirectly) over a target, is considered relevant information. So for our purposes we'll call ultimate parents any top-level entities with control over a target.

The assumption we have to start with then is that there can be multiple parents when querying the Open Ownership register, and our design must allow for that. Another thing worth mentioning here is that the query results we're discussing in this article are real-world ownership structures, but the company names have been (consistently) anonymised.


Querying ultimate parents with SPARQL

This logic is similar to the one we've used to identify UBOs, but it identifies legal entities (companies, trusts, etc) rather than individuals.

PREFIX rdf:      <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX foaf:     <http://xmlns.com/foaf/0.1/>
PREFIX bods:     <http://bods.openownership.org/vocabulary/>
PREFIX bods-res: <http://bods.openownership.org/resource/>

SELECT ?ultimateParent ?ultimateParentName
WHERE  {
    ?ultimateParent bods:ownsOrControls+
        bods-res:openownership-register-12337862642105981237 .
    ?ultimateParent foaf:name ?ultimateParentName .
    ?ultimateParent rdf:type bods:Entity .

    # An ultimate parent is an entity that isn't
    # controlled by another entity
    FILTER NOT EXISTS {
        ?s bods:ownsOrControls ?ultimateParent .
        ?s rdf:type bods:Entity .
    }
}



For our example we've selected a company with the (anonymised) name "GUTKOWSKI-PACOCHA" (openownership-register-12337862642105981237), and below is the result set we'd get for this query. 



Ownership structure

Next we would want to identify the intermediate entities involved in the ownership structure between the ultimate parent and the target.

PREFIX rdf:      <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX foaf:     <http://xmlns.com/foaf/0.1/>
PREFIX bods:     <http://bods.openownership.org/vocabulary/>
PREFIX bods-res: <http://bods.openownership.org/resource/>

SELECT ?parentName ?childName
WHERE {
    ?ultimateParent bods:ownsOrControls* ?parent .
    ?ultimateParent rdf:type bods:Entity .
    ?parent foaf:name ?parentName .
    ?parent bods:ownsOrControls ?child .
    ?child foaf:name ?childName .
    ?child bods:ownsOrControls* 
        bods-res:openownership-register-12337862642105981237.

    FILTER NOT EXISTS {
        ?s bods:ownsOrControls ?ultimateParent .
        ?s rdf:type bods:Entity .
    }
}
# To avoid duplicate entries
GROUP BY ?parentName ?childName 

The output is a list of (parent -> child) direct-ownership pairs, which can then be processed to produce the ownership network for our target.




This is a good example where another assumption is challenged: the notion that corporate ownership structures are linear or tree-like and can be represented as such. As we can see, these relationships can get very complex very quickly and visualising this data for various use cases becomes a challenge in itself. But we'll leave that discussion for another time.

Resources: