beneficial-ownership-data

name: beneficial-ownership-data version: "1.17.0" description: "Expert reference for beneficial ownership data, policy, and BODS. Trigger on: BODS JSON/schema/tools (bodsdata, CoVE-BODS, RDF/SPARQL, open issues), BO registries, FATF R24/R25, FATF mutual evaluations (MERs, FSRBs: APG/CFATF/MONEYVAL/ESAAMLG/MENAFATF/GIABA/EAG/GAFILAT), EU AML/AMLD6/AMLR/BORIS, country BO data (UK, Norway, France, Indonesia, Denmark, Canada/Ontario, Sri Lanka, BVI, Philippines, Ghana, Sweden), GLEIF, corporate data (OpenCorporates, Kyckr, Kausate, Sayari, ICIJ), FtM/OpenSanctions, Neo4j, BODS case studies (Latvia, Armenia, Nigeria), BO in procurement (OCDS, ChileCompra, Slovakia, PhilGEPS), BO in energy/extractives (EITI, GEM), BO in fisheries (GFW, FiTI), BO forms (Ghana, Namibia, PSC01), ICIJ/Panama Papers, BO reports (World Bank, TI, TI-UK), GODIN, UBO APIs (Kyckr, Kausate, KvK, Signicat, Companies House), BO verification (FATF, OECD toolkit, TJN), BOVS, or 2026 developments (BVI, Sri Lanka, Sweden, Ontario, Philippines, St Helena). If the question is about who owns what, use this skill."

Beneficial Ownership Data — Expert Reference

This skill covers the full beneficial ownership data landscape: the BODS technical standard, OpenOwnership's ecosystem of tools, the regulatory policy context (FATF, EU AML), country-specific register designs, international advocacy, mapping corporate data sources to BODS, interoperability with other data models, beneficial ownership in procurement, and beneficial ownership in extractives.

Important context: This skill is used by Stephen Abbott Pugh — the original product owner of BODS at Open Ownership, now running the consultancy Understand Beneficial Ownership (beneficialownership.co.uk). His writing is at stephenabbottpugh.medium.com and beneficialownership.co.uk/news-articles-and-blog-posts. When helping Stephen, you can assume deep domain expertise on his part — be direct and specific rather than over-explaining fundamentals.

Always fetch live documentation when you need precise schema details; the standard is versioned and evolving.

Quick reference: Key URLs

BODS Standard & Tools

Stephen's BODS Conversion Repositories

GLEIF → BODS 0.4

Corporate Ownership Data Sources

Private Sector & Register APIs: UBO/PSC Data

Neo4j Graph Database: BO Ownership Analysis

BODS Interoperability: Other Data Models

BODS RDF: Linked Data & SPARQL

Beneficial Ownership in Procurement

Beneficial Ownership in Extractives (EITI)

Public Beneficial Ownership Registers

Policy & Regulation

FATF Mutual Evaluations & Country Reports

International Endorsements & Resources

Country-Specific Registers

EU BORIS: BO Registers Interconnection System

Stephen's Writing & Consultancy

BODS Case Studies & Implementations

Full case studies index: https://www.beneficialownership.co.uk/case-studies

ICIJ Investigations & Offshore Leaks

Key Beneficial Ownership Research Reports

GODIN: Global Open Data Integration Network

BO Declaration & Data Collection Forms

Beneficial Ownership Data Verification

BODS Development: GitHub Issues & Feature Tracker

Sectoral Use Cases: Energy & Extractives (Global Energy Monitor)

Sectoral Use Cases: Fisheries

For detailed reference material, read:

• references/bods-standard.md — BODS 0.4 schema in depth
• references/tools-ecosystem.md — OpenOwnership tools
• references/regulatory-context.md — FATF, EU AML, policy context
• references/international-registers.md — country-specific BO register APIs

The BODS Data Model

BODS represents beneficial ownership as a collection of Statements. The current version is 0.4.

Three statement types

1. Person Statements Describe a natural person who holds or may hold a beneficial ownership interest. Key fields: statementId, statementType: "personStatement", names[], identifiers[], nationalities[], birthDate, placeOfBirth, addresses[], pepStatus[], hasPepStatus.

2. Entity Statements Describe a legal entity (company, trust, foundation, etc.) in the ownership chain. Key fields: statementId, statementType: "entityStatement", entityType, names[], identifiers[], incorporatedInJurisdiction, addresses[], foundingDate, dissolutionDate, isComponent.

3. Ownership-or-Control Statements Link a person or entity (the interested party) to an entity (the subject), describing the nature of their interest. Key fields: statementId, statementType: "ownershipOrControlStatement", subject (entity statementId), interestedParty (person or entity statementId), interests[] (type, share, directOrIndirect), isComponent, componentStatementIDs[].

Key structural concepts

• statementId: UUID-based unique identifier for each statement
• isComponent: boolean; marks whether a statement is part of an indirect ownership chain (v0.4 addition)
• componentStatementIDs: array of statementIds making up an indirect chain
• publicationDetails: metadata on publisher, date, bodsVersion
• Temporal versioning: multiple statements can describe the same entity over time; use replacesStatements[] to link them

A BODS dataset is a JSON array of statement objects. There is no wrapping container object — just a flat array.

Using BODS for Corporate Ownership Structures (without BO declarations)

BODS is designed for beneficial ownership but is equally capable of representing corporate ownership and control structures where the ultimate beneficial owners are unknown, undisclosed, or not the focus. This is a key use case for mapping commercial corporate data sources to BODS.

Why map corporate ownership data to BODS without BO declarations

Many real-world datasets — company registries, commercial data providers, financial data feeds — record legal entity ownership chains (parent/subsidiary relationships, shareholdings, directorship) without capturing natural-person beneficial owners. BODS accommodates this in several ways.

Entity-to-entity ownership: An ownership-or-control statement can link two entity statements, not just a person to an entity. This is the standard pattern for parent/subsidiary chains, joint ventures, and corporate group structures.

Unknown or anonymous interested parties: The interestedParty field supports unspecified as a value to indicate the interested party is not known. Use unknownPersons or anonymousEntity as the entity type when the ultimate owner is deliberately obscured or simply not recorded in the source data.

Partial chains: A dataset might record that Company A owns 60% of Company B, without knowing who owns Company A. This is perfectly valid BODS — just publish what is known. The isComponent flag and componentStatementIDs can be used to mark that a chain is incomplete.

entityType values for corporate structures: Beyond registeredEntity, BODS supports arrangement (for trusts, partnerships), anonymousEntity, unknownEntity, and stateBody. For offshore vehicles and special-purpose entities from sources like ICIJ Offshore Leaks, arrangement and anonymousEntity are most appropriate.

Mapping heuristics for source data without BO

When mapping a dataset that records corporate relationships but not BO:

• Map each company/legal entity to a BODS entity statement with the appropriate entityType
• Map each ownership/control link to a BODS ownership-or-control statement with entityType-based interestedParty
• For natural persons appearing in officer/director roles (not BO roles), create a person statement and an ownership-or-control statement with interests[].type = "controlViaDirectorship" or "otherInfluenceOrControl"
• Use heuristics to distinguish natural persons from corporate entities when source data is ambiguous (e.g. ICIJ officer names that could be either)
• Record interests[].share.exact where share percentages are available; otherwise leave omitted or use minimum/maximum fields

Stephen's BODS Conversion Repositories

These are Stephen's Python repositories for transforming third-party corporate data sources into BODS 0.4. All are pure Python, structured as src/bods_<source>/ packages with tests.

bods-icij-offshoreleaks

Source: ICIJ Offshore Leaks database — covering Panama Papers (2016), Pandora Papers (2021), Bahamas Leaks (2016), Paradise Papers (2017), Offshore Leaks (2013). 810,000+ offshore entities.

Mapping approach:

• ICIJ Entity nodes → BODS entity statements (registeredEntity or arrangement for offshore vehicles)
• ICIJ Officer nodes → person statements or entity statements (heuristics classify names as natural person vs. corporate)
• ICIJ Intermediary nodes → entity statements (registeredEntity, service provider firms)
• ICIJ relationship types (officer_of, intermediary_of, etc.) → BODS ownership-or-control statements with appropriate interests[].type
• Neo4J export also available for graph database workflows

Repo: https://github.com/StephenAbbott/bods-icij-offshoreleaks

bods-opencorporates

Source: OpenCorporates relationship data — the world's largest open company database, 200M+ companies.

OpenCorporates tracks four relationship types: control_statement, subsidiary, branch, and share_parcel. The Relationships Supplement contains 30M+ relationships extracted from primary datasets (SEC, UK Companies House, etc.).

Repo: https://github.com/StephenAbbott/bods-opencorporates

bods-brightquery

Source: BrightQuery corporate data via opendata.org — 324M organisations, 512M locations, 1.2B contacts across 222 countries. Government-sourced data including corporate family structures, legal status, and identity crosswalks (LEI, CIK, ISIN, NPI, etc.).

Repo: https://github.com/StephenAbbott/bods-brightquery

bods-kyckr

Source: Kyckr relationship data — a company intelligence platform providing corporate registry data and ownership relationships.

Repo: https://github.com/StephenAbbott/bods-kyckr

bods-ftm

Conversion: BODS 0.4 ↔ FollowTheMoney (FtM) — bidirectional.

Repo: https://github.com/StephenAbbott/bods-ftm

Note: this is distinct from the archived opensanctions/bods-ftm (which only converted OpenOwnership data dumps to FtM and is no longer maintained). Stephen's bods-ftm is a current, bidirectional converter designed for general BODS 0.4 data.

BODS → FtM mappings:

• entityStatement → FtM Company
• personStatement → FtM Person
• ownershipOrControlStatement → FtM Ownership, Directorship, or UnknownLink (depending on interest type)

FtM → BODS mappings: reverse conversion using deterministic UUID5 hashing for consistent identifier generation.

Technical approach: two-pass processing (entities/persons first, then relationships); indirect ownership chains consolidated rather than split; converts between org-id.guide scheme codes (e.g., GB-COH) and FtM named properties (e.g., registrationNumber).

CLI: cli.py | Input: BODS or FtM JSON/JSONL | Output: converted format with full ownership relationship chains preserved.

bods-aml-ai

Conversion: BODS 0.4 → Google Anti-Money Laundering AI input format.

Repo: https://github.com/StephenAbbott/bods-aml-ai

Google's AML AI data model has no native concept of party-to-party ownership relationships, so the tool encodes beneficial ownership creatively through available AML AI constructs:

Output (three NDJSON files):

• party.ndjson — persons and entities as COMPANY or CONSUMER types
• party_supplementary_data.ndjson — numeric ownership attributes (e.g., bo_ownership_pct_{subject_id}, bo_is_beneficial_owner, interest types)
• account_party_link.ndjson — synthetic "ownership accounts" linking subjects (PRIMARY_HOLDER) to owners (SUPPLEMENTARY_HOLDER)

CLI: cli.py | Input: BODS v0.4 JSON/JSONL | Output: NDJSON files for AML AI ingestion.

bods-neo4j

Conversion: BODS 0.4 ↔ Neo4j graph database — bidirectional, with built-in graph analysis.

Repo: https://github.com/StephenAbbott/bods-neo4j

Note: this is Stephen's BODS-native converter. For the broader Neo4j + UK Companies House PSC demo (without BODS), see erikbijl/neo4j-company-house-demo in the Neo4j section of Developer workflows.

Three primary workflows:

1. BODS → Neo4j: import BODS ownership datasets into graph form via CSV export or direct driver loading; produces Neo4j-importable CSV files and Cypher scripts
2. Neo4j → BODS: export graph data back to standardised BODS JSONL, preserving all metadata (round-trip fidelity)
3. Graph analysis: built-in queries for UBO detection, corporate group mapping, and circular ownership identification

CLI: cli.py | Input: BODS v0.4 JSON/JSONL or Neo4j instance | Output: Neo4j CSVs/Cypher or BODS JSONL.

bods-xml

Conversion: BODS 0.4 JSON → XML, in two output modes.

Repo: https://github.com/StephenAbbott/bods-xml

Two modes:

1. Canonical (canonical.py): a faithful XML serialisation of BODS 0.4 that preserves every field and mirrors the JSON structure, under the standard's namespace
2. MRAS preBODS (profiles/mras.py): transforms the flat BODS statement array into Canada's Multijurisdictional Registry Access Service (MRAS) hierarchical XML format

Architecture: extensible profile system — additional output profiles (BORIS, XBRL, etc.) can be added as modules alongside the existing two.

CLI: cli.py | Input: BODS 0.4 JSON or JSONL | Output: XML | Tests: 31

bods-stream

Type: Live streaming web application — UK beneficial ownership changes in real time as BODS v0.4.

Repo: https://github.com/StephenAbbott/bods-stream Live demo: https://bods-stream.onrender.com/

Consumes the Companies House PSC Streaming API and converts every live PSC (Person with Significant Control) filing event into BODS v0.4 statements the moment it's filed — displayed as a BOVS diagram with the raw Companies House event and the mapped BODS statements side by side.

This is notable because almost no beneficial ownership registers offer a streaming API. The UK PSC stream is the standout public exception, and BODS is purpose-built to represent change (recordStatus new/updated/closed, replacesStatements, append-only). bods-stream makes that change model visible live.

What you see per event:

• BOVS diagram: interested party → subject company, interest type on the edge, jurisdiction/nationality flags, identity-verification tick, tinted by lifecycle
• Lifecycle badge: NEW / UPDATED / CEASED (driven by BODS recordStatus)
• Risk signals (structural, no external calls): FATF black/grey list, non-EU jurisdiction, trust/arrangement, nominee, super-secure (opaque), sanctioned flag
• Prolific PSC signal: flags when one person appears as PSC of multiple companies in the session
• Live insight bar: individual vs corporate split, cessation rate, identity-verification rate, prolific PSC of the day
• Top-20 PSC nationalities (live flag tally)
• Pause/play with live event counter

Architecture: FastAPI backend (SSE relay — one long-lived CH stream connection, fan-out to many browsers) + React/Vite frontend. Single-process, in-memory state (lifecycle tracking, prolific tracker); nothing persisted to disk.

Lifecycle handling: The CH stream has no new/updated/closed concept. bods-stream maintains an in-memory map keyed on resource_uri (stable PSC id) to emit correct recordStatus values and replacesStatements references, including reconstructing a closed record from last-seen state when a deletion event arrives.

Privacy: Address and date of birth stripped at ingress — never broadcast or shown in UI. Date of birth used only briefly in-process for the prolific disambiguator.

Key dependency: bods-mapper — a separate shared repo containing the core Companies House → BODS v0.4 mapping logic, used by both bods-stream and OpenCheck to prevent the two apps drifting.

Replay mode: Set BODS_STREAM_REPLAY_FILE to a captured .jsonl to feed pre-recorded events through the live pipeline (useful outside UK office hours when the live feed is quiet).

Deployment: Docker image builds frontend and serves it with the API (same origin). Deployed on Render via render.yaml. Must run as one instance/one worker (in-memory state).

bods-mapper

Type: Shared Python library — canonical UK Companies House PSC → BODS v0.4 mapping core.

Repo: https://github.com/StephenAbbott/bods-mapper

Extracted from OpenCheck so that both opencheck and bods-stream use one canonical mapper and cannot drift apart. Takes a single Companies House PSC streaming event (the data block is identical to the REST PSC endpoint response) and emits a BODS v0.4 bundle containing:

• the subject company entity statement
• the interested party — a knownPerson (individual PSC), entity statement (corporate/legal-person PSC), or anonymousPerson (super-secure PSC)
• an ownership-or-control relationship statement

Key features:

• All 86 official natures_of_control codes mapped to valid BODS interestType, each with the official Companies House short descriptor in interest.details
• Cessation lifecycle: a ceased PSC produces a relationship with recordStatus: "closed" — stable recordId, distinct statementId, interest.endDate, and replacesStatements pointing to the original new statement, per BODS information updates / record identifiers modelling rules
• Robust country handling: emits a BODS Country code only when a valid 2-letter ISO code resolves

Public API: map_psc_event, company_number_from_uri, parse_nature, describe_nature, PSC_NATURE_DESCRIPTIONS, country_object, statement factories (make_entity_statement, make_person_statement, make_relationship_statement), BODSBundle, stable_id, validate_shape

Requirements: Python ≥ 3.10, pycountry. MIT license (vendored CH nature descriptors under OGL v3.0).

opencheck

Type: Full customer due diligence (CDD) web application — LEI-powered, BODS v0.4 throughout.

Repo: https://github.com/StephenAbbott/opencheck Live demo: https://opencheck.onrender.com/

OpenCheck is a comprehensive open-source CDD tool that uses the Legal Entity Identifier as a connector spine to fan out across 29 national and international corporate data sources, mapping everything to BODS v0.4. Currently at Phase 50 (50 phases of active development, 337+ commits).

How it works: paste a LEI → GLEIF lookup → derive every cross-source identifier available (Companies House number, Norwegian org number, Irish CRO, Finnish Y-tunnus, Latvian, Lithuanian, Estonian, Czech IČO, Polish KRS, Austrian Firmenbuchnummer, Slovak IČO, French SIREN, Dutch KvK, Swedish org number, Swiss UID, Canadian corp number, Belgian enterprise number, Danish CVR, Croatian MBS, Australian ACN/ABN, OpenCorporates ID, Wikidata Q-ID, and more) → fan out across all active adapters → assemble into a single BODS v0.4 bundle → apply risk signals → offer export.

National ID search (Phase 50): look up any company by local registration number (CH number, KvK, orgnr, CVR, SIREN, etc.) — queries GLEIF's three registration-ID filter fields in parallel, scoped to the RA code. Covers 17 countries with active adapters.

Risk signal layer (12 signals) — mirrors the EU AMLA draft CDD RTS conditions for "complex corporate structures":

• Source-derived signals (nominee, super-secure/opaque, sanctioned flag)
• AMLA CDD RTS signals (trust/arrangement, non-EU jurisdiction, ≥3 ownership layers, composite threshold rule, subjective obfuscation advisory)
• FATF jurisdiction (black/grey list)
• Cross-source name match discrepancies
• ICIJ Offshore Leaks match

Export formats: JSON / JSONL / XML / ZIP (downloaded bundle includes LICENSES.md listing every contributing source).

Architecture: FastAPI backend (Python 63%) + React/TypeScript frontend, cache-first dispatch (stub mode without API keys, live mode opt-in per source via env vars). Uses bods-dagre for BOVS ownership diagrams and bods-mapper for CH PSC → BODS mapping.

Roadmap: live opentender.eu procurement integration; BODS RDF/SPARQL backbone via Oxigraph (load assembled BODS bundle into triple store, expose /sparql for Open Ownership red-flag queries).

bods-gql

Conversion: BODS 0.4 → Google BigQuery property graph, queryable with GQL (ISO/IEC 39075).

Repo: https://github.com/StephenAbbott/bods-gql

GQL (ISO/IEC 39075) is the international standard graph query language adopted in April 2024. It uses pattern-matching syntax similar to Cypher but with different syntax for quantified paths and aggregation. BigQuery now supports GQL for property graph queries.

Output:

• Node tables: entity and person nodes with names, jurisdictions, and identifiers
• Edge tables: ownership interest relationships with stake percentages
• Property graph DDL: CREATE PROPERTY GRAPH statements via graph_schema/property_graph.py

Includes 14 pre-built GQL queries across three modules covering UBO detection, corporate group mapping, and circular ownership analysis. 59 tests. Demonstrated with public BigQuery datasets containing GLEIF and UK Companies House beneficial ownership data.

CLI: cli.py | Input: BODS v0.4 JSON/JSONL | Output: BigQuery CSV tables + GQL schema.

GLEIF Level 1 & 2 Data → BODS 0.4

The Global Legal Entity Identifier Foundation (GLEIF) publishes two levels of open data for the 2.6M+ entities holding a Legal Entity Identifier (LEI):

• Level 1 (LEI-CDF): Entity identity data — legal name, registered address, jurisdiction, entity status, entity type, registration dates
• Level 2 (RR-CDF — Relationship Records): Ownership relationships between LEI holders — parent/subsidiary links, percentage ownership, relationship status, and dates
• Level 2 (Reporting Exceptions): Cases where an LEI holder cannot or will not report their direct/ultimate parent — with a stated reason code

GLEIF → BODS 0.4 mapping

The bods-gleif-pipeline (https://github.com/openownership/bods-gleif-pipeline) is the reference implementation. It runs on AWS (Kinesis data streams for pipeline stages, Elasticsearch for persistence between runs, EC2 for compute). The raw GLEIF concatenated files are 8GB+ uncompressed.

GLEIF was the first dataset published in BODS 0.4, making it the reference example for temporal change tracking with replacesStatements and the isComponent pattern.

Key mapping decisions in the BODS 0.4 update:

• Reporting Exceptions are now modelled as BODS statements (rather than being dropped), allowing the reason for non-disclosure to be captured
• Temporal lifecycle of LEI data changes is represented via replacesStatements links rather than overwriting

Published data: https://bods-data.openownership.org/source/gleif_version_0_4/ OpenOwnership news release: https://www.openownership.org/en/news/global-legal-entity-ownership-data-available-in-line-with-latest-version-of-data-standard/ Mapping blog post: https://www.openownership.org/en/blog/updating-our-mapping-of-gleif-data-to-bods-to-better-capture-the-lifecycle-of-lei-data-changes/

Corporate Ownership Data Sources: Background Reference

These are sources useful for mapping work or for contextualising BO data. Fetch live documentation for precise field-level detail.

Sayari

A corporate intelligence platform covering 450M+ entities from 700+ sources across 250+ jurisdictions, with 2B+ ownership and control records. Sayari applies entity resolution to link records across sources, generating possibly-same-as relationships where confidence is insufficient to fully merge. Coverage includes parent-subsidiary, shareholder, and beneficial ownership structures. Particularly strong on hard-to-access jurisdictions.

• Data model: https://documentation.sayari.com/sayari-library/data-model/data-model
• Documentation: https://documentation.sayari.com/home/overview

OpenCorporates

The world's largest open company database (200M+ companies). Offers four relationship types in its Relationships File/Supplement: control_statement, subsidiary, branch, share_parcel. The Relationships Supplement has 30M+ relationships from primary sources (SEC, UK Companies House, etc.) and is separately licensed from the company data. Also provides person-with-significant-control and beneficial_owner flags. The API (v0.4.8) exposes companies, officers, and relationships.

• API reference: https://api.opencorporates.com/documentation/API-Reference
• Relationships dictionary: https://knowledge.opencorporates.com/knowledge-base/data-dictionary-relationships/
• Officers dictionary: https://knowledge.opencorporates.com/knowledge-base/data-dictionary-officers/
• Relationship file key info: https://knowledge.opencorporates.com/knowledge-base/count-of-relationship-records/

BrightQuery / OpenData.org

BrightQuery (founded OpenData.org) provides government-sourced corporate data on 324M organisations, 512M locations, and 1.2B contacts across 222 countries. Data is structured around three core data dictionaries: organisations, locations, and people-business relationships. Key differentiator: comprehensive reference ID crosswalks (LEI, CIK, ISIN, NPI, PermID, OpenFIGI, SAM UEI, PlaceKey, OSM ID, etc.) and corporate family/hierarchy structures. OpenData.org was built with Senzing AI for entity resolution and positions itself as a consortium-governed open data platform.

• Organisations dictionary: https://opendata.org/data-dictionary/organizations
• Locations dictionary: https://opendata.org/data-dictionary/locations
• People-business dictionary: https://opendata.org/data-dictionary/people-business

InfobelPro

A global company data provider with 375M companies across 220 countries, sourcing data from 1,100+ official registries, tax authorities, and regulated filings. Provides 460+ firmographic, hierarchical, and technographic attributes per record, including ownership links and up to 8 years of historical records. Claims to trace every record to an official source (not aggregators or web scrapes). GDPR/CCPA compliant with stable entity IDs and standardised delivery across 200+ markets.

• Data overview: https://www.infobelpro.com/data
• Methodology: https://www.infobelpro.com/data/methodology

OECD-UNSD Multinational Enterprise Information Platform (MEIP)

A joint OECD/UN Statistics Division initiative tracking the 500 largest MNEs globally. The platform comprises a Global Register (subsidiary ownership structures and geographic footprint), a web presence register, and a media monitor. The 2024 data release (covering data as of 31 December 2024) added financial data (employees, revenue, net profit, R&D) extracted via AI from company filings and annual reports. Structured as an interactive dashboard with downloadable XLSX.

This is a useful reference dataset for mapping MNE corporate group structures to BODS, and for validating coverage of other corporate data sources.

• Platform: https://www.oecd.org/en/data/dashboards/oecd-unsd-multinational-enterprise-information-platform.html
• Methodology publication: https://www.oecd.org/en/publications/the-oecd-unsd-multinational-enterprise-information-platform_b7d90a06-en.html
• Global Register 2024 (XLSX): https://www.oecd.org/content/dam/oecd/en/data/dashboards/oecd-unsd-multinational-enterprise-information-platform/Global%20Register%202024%20-%20OECD-UNSD%20Multinational%20Enterprise%20Information%20Platform.xlsx
• 2026 data release blog: https://www.oecd.org/en/blogs/2026/03/MNE-thing-is-possible-New-OECD-UNSD-data-release-strengthens-open-evidence-on-multinational-enterprises.html

BODS Interoperability: Mappings to Other Data Models

FollowTheMoney (FtM) / OpenSanctions

FollowTheMoney (FtM) is the data model used by OpenSanctions and the broader Aleph investigative data ecosystem. It represents persons, companies, assets, relationships, and documents in a property graph format designed for investigative and compliance work.

bods-ftm — there are two distinct repos with this name:

• StephenAbbott/bods-ftm (https://github.com/StephenAbbott/bods-ftm) — current, bidirectional BODS 0.4 ↔ FtM converter for general use (see Stephen's BODS Conversion Repositories section for full details)
• opensanctions/bods-ftm (https://github.com/opensanctions/bods-ftm) — archived; was a one-way converter from OpenOwnership BODS data dumps to FtM object graphs. Its functionality has been incorporated into opensanctions/graph (https://github.com/opensanctions/graph), which now handles BODS and GLEIF RR files as inputs.

The OpenOwnership dataset on OpenSanctions (https://www.opensanctions.org/datasets/openownership/) republishes OpenOwnership BODS data in FtM format, making it available for cross-dataset analysis alongside sanctions lists, PEPs data, and company registries.

Practical use: BODS data in FtM format can be combined with OpenSanctions sanctions data and public procurement data (Open Contracting Data Standard) for cross-dataset risk detection. The OpenScreening proof-of-concept built on this approach matches beneficial owners to sanctions names via a graph database.

Senzing sz-semantics / RDF

The Senzing sz-semantics namespace (https://github.com/senzing-garage/sz-semantics/wiki/ns) defines an RDF Metadata Application Profile for representing entity resolution results as a knowledge graph. It explicitly aligns with BODS, NIEM, and FollowTheMoney as "popular controlled vocabularies used by Senzing partners."

The namespace provides:

• sz:Entity — resolved entity (top-level concept)
• sz:Person, sz:Organization — entity subtypes
• sz:DataRecord — source records contributing to entity resolution
• sz:member_of — relationship predicate applicable to ownership/membership

This is relevant when combining BODS data with Senzing entity resolution output, or when building linked data representations that need to align BODS concepts with Senzing's resolved-entity model. The OpenData.org platform (BrightQuery) was built using Senzing AI for entity resolution.

Developer workflows

Validating BODS data

Use CoVE-BODS web tool: https://datareview.openownership.org Or use lib-cove-bods from the command line:

pip install lib-cove-bods
libcovebods your-data.json

Checks: required fields, valid enums, internal reference integrity, version compliance (0.1–0.4).

bods-validator — an alternative online validation and visualisation tool for BODS v0.4 data: Repo: https://github.com/StephenAbbott/bods-validator

Built with FastAPI (backend) and React/TypeScript (frontend). Performs two layers of validation:

• JSON schema compliance checks against BODS v0.4 schema
• 26 additional regulatory compliance assessments via lib-cove-bods

Three input methods: direct JSON paste, file upload, or URL retrieval. Outputs validation results with actionable guidance, interactive ownership visualisations using BOVS design conventions, and side-by-side comparisons of national data formats mapped to BODS standards. Includes example datasets from UK, France, Indonesia, and Norway.

Testing BODS implementations

Two companion packages provide a shared, canonical fixture suite for testing any tool that ingests, transforms, or emits BODS v0.4 statements:

bods-fixtures — the fixture data pack:

• Repo: https://github.com/StephenAbbott/bods-fixtures
• PyPI: https://pypi.org/project/bods-v04-fixtures/ (pip install bods-v04-fixtures)
• Provides small, curated BODS v0.4 statement bundles targeting specific semantic edge cases, each paired with a .expected.md specification file describing correct adapter/query engine behaviour
• Current coverage (v0.1.1): direct ownership, circular ownership, anonymous persons
• Import: from bods_fixtures import load, list_cases
• Acts as "the single source of truth" for fixtures across the BODS adapter ecosystem — ensures an entity observed in two sources produces equivalent BODS output

pytest-bods-fixtures — pytest plugin wrapping the data pack:

• Repo: https://github.com/StephenAbbott/pytest-bods-fixtures
• PyPI: https://pypi.org/project/pytest-bods-v04-fixtures/ (pip install pytest-bods-v04-fixtures)
• Exposes bods_fixture as an auto-parametrized pytest fixture — one test function runs against every conformance case in the data pack without manual parametrization boilerplate
• Displays fixture name in test IDs, making failures easy to identify
• Supports filtering by record type via by_record_type()

Both packages require Python ≥ 3.9. Fixture content is licensed CC-BY-SA 4.0; code is MIT.

Processing BODS data into flat formats

bodsdata (https://github.com/openownership/bodsdata) converts BODS JSON to:

• CSV / TSV
• SQLite
• Parquet
• PostgreSQL dump

It also runs consistency checks (required fields, duplicate statement IDs, broken internal references) and supports pandas/polars dataframe workflows. Use it when you need to load BODS data into a database or do tabular analysis.

BODSKit (https://bodskit.readthedocs.io) is a newer CLI suite with similar goals — worth checking for the latest capabilities.

Analysing BODS data in Python (notebooks)

bodsanalysis (https://github.com/openownership/bodsanalysis) provides:

• qbods.py: functions for reading, summarising and analysing BODS 0.2 data
• Jupyter notebooks: latvia_demo.ipynb (Latvia register), Insights_UK_PSC_BODS-02.ipynb (UK People with Significant Control)
• Runs on local Jupyter, Deepnote, or Google Colab

Note: the notebooks currently target BODS 0.2. For 0.4 data, adapt the field names (especially for isComponent and statement references).

Beneficial Ownership Visualisation System (BOVS)

The Beneficial Ownership Visualisation System (BOVS) is an OpenOwnership specification for how to illustrate beneficial ownership structures as clearly as possible.

URL: https://www.openownership.org/en/publications/beneficial-ownership-visualisation-system/

BOVS defines the rules for drawing BOVS Diagrams — a standardised visual language for representing ownership and control structures. Key characteristics:

• Compatible with any brand, style, colour scheme, or language
• Published under the GNU Free Documentation License (free to use by anyone building BO visualisations)
• Designed to help implementers choose how to represent different aspects of ownership — direct vs. indirect interests, unknown intermediaries, control vs. ownership, etc.
• Offered to anyone building visualisations of beneficial ownership structures, not just BODS users

BODS Visualisation Library — the BODS-specific implementation of BOVS: URL: https://www.openownership.org/en/publications/beneficial-ownership-data-standard-visualisation-library/

The BODS Visualisation Library bakes many of the BOVS rules into a reusable library designed for rendering BODS-structured data. It is already in production use in the official beneficial ownership registers of Armenia, Bermuda, and Botswana.

The bods-dagre npm package (see below) is the developer-facing tool that implements this library.

Visualising ownership graphs

visualisation-tool / bods-dagre turns BODS JSON into directed graph diagrams.

Input: a JSON array of BODS statements (person, entity, ownership-or-control). Output: SVG/canvas network diagram with:

• Person nodes (name, nationality flag, person-type icon)
• Entity nodes (name, jurisdiction flag, entity-type icon, public company indicator)
• Directed edges showing ownership/control relationships

npm package: @openownership/bods-dagre

npm install @openownership/bods-dagre

The tool handles temporal data — it filters to a snapshot at a given point in time when multiple versions of records exist. See the full spec at https://github.com/openownership/visualisation-tool/blob/main/docs/spec.md.

Neo4j Graph Database: UK Companies House UBO Analysis

Graph databases are a natural fit for beneficial ownership data — ownership chains, loops, and ultimate parent traversal are graph problems that relational databases handle poorly. Two resources demonstrate this with UK data:

Neo4j developer guide — Company Ownership & UBO Graphs URL: https://neo4j.com/developer/industry-use-cases/finserv/retail-banking/company-ownership-ubo-graphs/

Covers the conceptual case for graph technology for UBO analysis in financial services (retail banking context). Explains variable-length path traversal for finding ultimate beneficial owners, and introduces the UK PSC dataset as a practical source.

erikbijl/neo4j-company-house-demo Repo: https://github.com/erikbijl/neo4j-company-house-demo Webinar recording: https://go.neo4j.com/WBREDU260210FinServ_On-Demand.html

A working implementation using UK Companies House open data (snapshots from January 2026):

• Data sources: Companies House Company Data Product + PSC Data Product
• Graph model: five node types (Company, LegalEntity, Individual, Address, SIC-code) with three relationship types (OWNS, REGISTERED_AT, HAS_SIC)
• Key notebooks: company_house_companies.ipynb (loads company/address/SIC data) and company_house_psc.ipynb (processes PSC ownership relationships)
• Includes: pre-built Neo4j dashboard (Company_Profile_Dashboard_2026-03-31.json) and a database backup via Google Drive
• Enables variable-length ownership traversal, root entity identification, and detection of circular ownership structures

GraphAware Hume platform: BODS data + graph technology for UBO investigations Blog/event page: https://www.openownership.org/en/blog/join-our-event-master-complex-ubo-investigations-with-advanced-graph-technology/ YouTube recording: https://www.youtube.com/watch?v=BO6TVN5UL14

A webinar co-presented with Stephen Abbott Pugh showing how BODS-structured beneficial ownership data can be used alongside other data types in GraphAware's Hume platform (powered by Neo4j). Hume is a graph-based investigation platform used in financial crime, compliance, and investigative journalism contexts. The session demonstrated how BODS data integrates with Hume's entity resolution and link analysis capabilities for complex UBO investigations.

Relationship to BODS: The neo4j-company-house-demo uses UK PSC data directly rather than BODS JSON, but the graph model (person/entity nodes + ownership edges) closely mirrors the BODS statement model. BODS data — which standardises this structure across jurisdictions — maps naturally onto Neo4j's property graph model and would enable cross-jurisdictional UBO traversal in a single graph.

Generating test / sample BODS data

The BODS data generator is a Google Sheets template that lets anyone produce valid BODS JSON without writing code. It's the fastest way to create test data or demonstrate the standard to non-technical audiences.

• Template: https://docs.google.com/spreadsheets/d/1PHjwqiOguG8DqyXN75dNSpl_tNhTyelYav1B6sk8nRQ/
• User guide: https://www.openownership.org/en/publications/beneficial-ownership-data-standard-generator/user-guidance/

The sheet has three tabs mirroring the three BODS statement types:

• 1_person_main — person statement data
• 2_entity_main — entity statement data
• 3_ownership_control_main — ownership-or-control statement data

Output: paste from the Upload sheet into CoVE-BODS for validation and JSON download. Can also feed directly into the bods-dagre visualiser.

Note: the generator currently targets BODS 0.3. For 0.4 you may need to adjust output for isComponent and componentStatementIDs fields.

Working with BODS as Linked Data / RDF

bodsld (https://github.com/openownership/bodsld) provides:

• BODS 0.4 RDF vocabulary in Turtle format: bods-vocabulary-0.4.0.ttl
• HTML documentation: https://vocab.openownership.org/terms/bods-vocabulary-0.4.0.html
• Scripts to regenerate vocabulary from the JSON Schema

Note: bodsld maps the BODS schema to RDF vocabulary — it does not convert BODS instance data to RDF triples. If you need to convert actual BODS records to RDF, you'll need to write a custom transformation.

Common patterns and gotchas

Resolving references: Ownership-or-control statements reference persons and entities by statementId. When loading data, build a lookup dict keyed by statementId first, then resolve references.

Indirect ownership chains: In BODS 0.4, isComponent: true marks statements that are part of an indirect chain. The top-level statement uses componentStatementIDs to list the supporting component statements.

Temporal data: The same real-world entity may have multiple statements over time. To get the current picture, filter to the most recent statement for each statementId group (using replacesStatements).

Version detection: Check publicationDetails.bodsVersion to know which version of BODS the data conforms to. Field names and required properties differ between 0.2, 0.3, and 0.4.

Missing beneficial owners: BODS allows for unknownPersons, anonymousEntity, and similar placeholders — your code should handle these rather than assuming all interested parties resolve to named individuals.

Corporate-only datasets: When the source has no BO data, every interestedParty in an ownership-or-control statement will reference an entity statement (not a person statement). This is valid BODS — entity-to-entity ownership chains are fully supported.

Policy & Regulatory Context (summary)

For full detail, read references/regulatory-context.md.

FATF Recommendations 24 & 25

The Financial Action Task Force sets the global anti-money-laundering standards that drive most beneficial ownership register legislation.

• R.24 (Legal Persons): Requires countries to ensure that competent authorities have timely access to adequate, accurate and up-to-date beneficial ownership information on companies and other legal persons. Revised to be significantly stronger in 2022. Guidance published March 2023.
• R.25 (Legal Arrangements): Parallel requirements for trusts and similar legal arrangements (fiducie, fideicomiso, Waqf, Treuhand, etc.). Revised 2023 to bring requirements broadly in line with R.24.

A country's compliance with R.24 and R.25 is assessed during FATF mutual evaluations, which have significant diplomatic and financial consequences.

FATF Mutual Evaluations: Country-Level AML/CFT Assessments

Mutual evaluations are the primary mechanism by which FATF assesses whether countries are actually implementing the 40 Recommendations. When researching what AML/CFT legislation or BO requirements a specific country has in place — or how effectively they are enforcing them — the published mutual evaluation reports (MERs) and follow-up reports are the most authoritative and detailed source available.

How to find country reports

All FATF publications, filterable by country, are at: https://www.fatf-gafi.org/en/publications.html

This page lists every published MER, follow-up report, and other country-specific output for all FATF members and associate members. Each country has a tag page accessible from the publications index. Important: for countries that are members of a FATF-Style Regional Body (FSRB) rather than FATF itself, the full mutual evaluation report may be published on the FSRB's own website, with the FATF country page linking out to it. The Montserrat example illustrates this: the FATF page (https://www.fatf-gafi.org/en/publications/Mutualevaluations/Follow-upreportstothemutualevaluationofmontserrat.html) links to a report hosted on the CFATF website (https://www.cfatf-gafic.org/). When looking for a country's full MER, always check the FSRB's own website if the FATF page only shows a summary or a link.

Additional entry points:

• All countries page: https://www.fatf-gafi.org/en/countries.html — direct links to each country's profile and published reports
• Consolidated assessment ratings: https://www.fatf-gafi.org/en/publications/Mutualevaluations/Assessment-ratings.html — a spreadsheet of all technical compliance and effectiveness ratings from 2014 onwards across all assessed countries; the fastest way to compare multiple countries at once
• Mutual evaluations topic page: https://www.fatf-gafi.org/en/topics/mutual-evaluations.html — explains the process and links to recent reports

What mutual evaluations assess

The 4th-round methodology (https://www.fatf-gafi.org/en/publications/Mutualevaluations/Fatf-methodology.html) assesses countries on two dimensions:

Technical compliance — whether the country's laws, regulations, and institutional frameworks meet the requirements of each of the 40 Recommendations. Rated: Compliant (C), Largely Compliant (LC), Partially Compliant (PC), or Non-Compliant (NC). For BO purposes, the key ratings are on R.24 (legal persons) and R.25 (legal arrangements).

Effectiveness — whether the country's AML/CFT system is actually working in practice. Assessed across 11 Immediate Outcomes (IOs). For BO specifically, IO.5 covers "Legal persons and arrangements are prevented from misuse for money laundering or terrorist financing, and information on their beneficial ownership is available to competent authorities without impediment." Effectiveness ratings: Substantial, Moderate, Low, or Negligible.

A country can have high technical compliance (good laws) but low effectiveness (poor enforcement) — a common pattern revealed in MERs. Conversely, some countries with imperfect legislation may have robust enforcement practices. Reading both dimensions together is essential.

Post-evaluation monitoring

After an MER is published, countries enter a follow-up process. Reports are typically published:

• Regular follow-up: annual or biennial reports on progress against recommended actions
• Enhanced follow-up: for countries with significant deficiencies, more frequent and intensive monitoring

Countries with serious and strategic AML/CFT deficiencies may be placed on the Jurisdictions under Increased Monitoring list (the "grey list") — https://www.fatf-gafi.org/en/publications/High-risk-and-other-monitored-jurisdictions/ — which triggers enhanced due diligence by financial institutions globally and carries significant reputational and economic consequences. Countries with the most serious deficiencies may be called to action on the High-Risk Jurisdictions list (the "black list").

The FATF Global Network: FSRBs

The FATF Global Network comprises FATF itself (39 member jurisdictions) plus nine FATF-Style Regional Bodies (FSRBs), which collectively cover more than 200 jurisdictions globally. FSRBs conduct mutual evaluations of their member jurisdictions using the same FATF methodology, and publish their own reports — which are the primary source for most non-FATF-member country assessments.

When researching a non-FATF member country's AML/CFT framework or BO requirements, identify which FSRB it belongs to and check that FSRB's website for the most recent MER and follow-up reports — these will contain the most detailed analysis of what legislation is in place and how effectively it is being implemented.

Using MERs for BO research

Mutual evaluation reports are typically 200–400 pages and contain the most granular publicly available analysis of a country's BO legal framework. For BO-specific research within an MER, the most relevant sections are:

• The Technical Compliance Annexe: detailed analysis of R.24 (legal persons) and R.25 (legal arrangements) — what laws are in place, what they require, where they fall short of the FATF standard, and the resulting rating
• Immediate Outcome 5: the effectiveness assessment of whether the BO framework is working in practice — how well competent authorities access and use BO information, how well obliged entities conduct customer due diligence, and what the quality of BO information in registers actually is
• Country context (early chapters): background on the country's legal system, entity types, and the scale of the corporate sector — essential context for understanding why certain BO risks are higher or lower

EU AML Package (2024)

The EU adopted a sweeping new AML package in May 2024, effective from 2027:

• AMLR — Regulation 2024/1624: Directly applicable rules for obliged entities (banks, lawyers, crypto). Lowers UBO threshold from >25% to ≥25% shareholding/voting rights. Requires multi-source verification of BO information.
• AMLD6 — Directive 2024/1640: Member State rules for central BO registers. Registers must hold more data, cover more entity types including non-EU entities with EU business. Registers must interconnect via European Central Platform. Transposition deadline: 10 July 2026.
• EC consultation on BO data formats: The Commission is consulting on standardised data formats for BO submissions to central registers — directly relevant to BODS adoption. See https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/14851

UK government endorsement of BODS

The UK has formally adopted BODS as its open standard for beneficial ownership data: https://www.gov.uk/government/publications/open-standards-for-government/collect-use-and-exchange-beneficial-ownership-information

The UK Anti-Corruption Strategy 2025 includes commitments to push for international adoption of BODS.

BODS RDF: Linked Data and SPARQL Querying

The BODS RDF vocabulary (https://vocab.openownership.org/) enables beneficial ownership data to be published and queried as linked data. This extends the power of BODS significantly: ownership chains become graph traversal problems expressible in SPARQL.

What the vocabulary provides

The BODS 0.4 RDF vocabulary maps all three BODS statement types — person, entity, and ownership-or-control — to RDF classes and properties. The key property is bods:ownsOrControls, which captures a direct ownership or control relationship between two entities (or between a person and an entity). This allows chains to be traversed with path queries.

The full vocabulary documentation is at https://vocab.openownership.org/ with the data model at https://vocab.openownership.org/pages/1_datamodel.html.

SPARQL use cases (world.hey.com/cos series)

Four blog posts by the BODS RDF team document real SPARQL queries against the Open Ownership register:

• Linking BODS with other datasets (https://world.hey.com/cos/using-bods-rdf-to-link-beneficial-ownership-records-with-other-datasets-0383cbd9): How to combine BODS RDF with other linked datasets (e.g. Wikidata, company registries) using shared entity identifiers. Covers federated queries and URI alignment.

• SPARQL examples for BO use cases (https://world.hey.com/cos/bods-rdf-sparql-examples-for-various-beneficial-ownership-use-cases-284d6f73): A broad collection of queries covering: finding all companies owned by a person, tracing ownership chains of a given depth, identifying share percentages along a chain, filtering by interest type, and finding companies with anonymous/unknown owners.

• Ultimate parents and corporate control (https://world.hey.com/cos/ultimate-parents-and-corporate-control-with-open-ownership-bd1ee35b): How to use property path queries (bods:ownsOrControls+) to traverse chains and identify ultimate controlling entities regardless of chain length. Covers the distinction between direct and indirect control.

• Querying UBOs (https://world.hey.com/cos/querying-ubos-with-open-ownership-and-bods-rdf-6a272004): How to identify ultimate beneficial owners — the natural persons at the end of an ownership chain — using SPARQL. Includes queries that retrieve share percentages and interest types across intermediate links.

Risk detection proof of concept (bodsriskdetection)

The bodsriskdetection repository (https://github.com/openownership/bodsriskdetection) is a proof-of-concept system built on BODS RDF. It combines:

• BODS data from the UK register (converted to RDF)
• Public procurement data published in OCDS format
• Sanctions data from OpenSanctions
• ICIJ Offshore Leaks data

The SPARQL graph can then identify: companies owned/controlled by sanctioned individuals; networks that have been awarded large volumes of public contracts; and indirect risks — third parties connected to a target that are themselves sanctioned or PEPs.

Technical details: https://www.openownership.org/en/publications/bods-risk-detection/bods-risk-tdetection-technical-details/

Beneficial Ownership in Public Procurement

Linking beneficial ownership data with public procurement (contracting) data is one of the highest-impact use cases for BO transparency. It enables detection of conflicts of interest, sanctions exposure, bid-rigging networks, and related-party contracts.

OCDS and BODS: the core linkage mechanism

The Open Contracting Data Standard (OCDS) (https://standard.open-contracting.org/) is the open standard for publishing procurement data. It covers the full contracting cycle: planning, tender, award, contract, and implementation.

The key to combining OCDS and BODS is shared organisation identifiers. Both datasets should use the same identifier scheme (typically from the org-id.guide list) for the same legal entities. The OCDS guidance page on beneficial ownership (https://standard.open-contracting.org/latest/en/guidance/map/beneficial_ownership/) explains two approaches:

1. Separate registers with linked identifiers: BO data is published using BODS; procurement data is published using OCDS; they are joined via shared company identifiers. This is the preferred approach for countries with a central BO register.

2. BO data embedded in OCDS: The OCDS beneficial owners extension (https://extensions.open-contracting.org/en/extensions/beneficialOwners/master/) allows BO information to be published directly within an OCDS contracting process record. Useful when no separate BO register exists, or when the procurement system has a lower disclosure threshold than the register.

ChileCompra: the leading implementation

Chile has the most advanced operational integration of BO and procurement data globally (as of 2025–2026).

• Chile's procurement law was amended in December 2023 to require BO disclosure by all suppliers as a condition of participation.
• Every supplier that participated in 2025 disclosed its ownership information — covering 1M+ procurement procedures worth US$13 billion (January–September 2025). Over 185,000 beneficial owners are now on record.
• ChileCompra, the Comptroller-General, and the National Economic Prosecutor's Office have full access to BO data and use it for investigating economic crimes and non-competitive bidding practices.
• The definition of conflict of interest was broadened to cover all public officials and their relatives. Over 7,000 complaints received via a whistleblower hotline between 2023–2025, including 114 relating to conflicts of interest.
• In January 2026, ChileCompra announced detection of potential conflicts of interest worth CLP 3.452 billion through mass data cross-referencing.
• ChileCompra uses OCDS for structured procurement data publication.

Case study (OCP/OO, May 2025): https://www.open-contracting.org/resources/casestudy-bot-pp-chile/ OO publication: https://www.openownership.org/en/publications/beneficial-ownership-in-chiles-public-procurement-reform/

Slovakia RPVS: procurement-linked BO register

The Slovak Register partnerov verejného sektora (RPVS) (https://rpvs.gov.sk/rpvs) was one of the first purpose-built procurement BO registers, established in 2015. It lists individuals and organisations receiving public funds above a legal threshold. Companies face a ban of up to three years and fines up to €1 million for participating in procurement without registering.

RPVS data is available on OpenSanctions (https://www.opensanctions.org/datasets/sk_rpvs/) — sourced directly from the Ministry of Justice API — and on the BODS data explorer (https://bods-data.openownership.org/source/slovakia/).

Philippines PhilGEPS

The Philippines passed the New Government Procurement Act (Republic Act No. 12009) in July 2024, mandating BO disclosure by all bidders and contractors, with public access to the data. Key milestones:

• From 15 July 2025, corporations must submit GIS forms reflecting BO information to the Securities and Exchange Commission (SEC).
• A Data Sharing Agreement between PS-DBM and the SEC facilitates data exchange.
• PhilGEPS enhanced its Open Data Portal in October 2025, providing real-time procurement data including BO information.

Open data: https://philgeps.gov.ph/CmsHomePages/open-data

Entity identifiers in UK procurement data

A key technical challenge for joining BODS and OCDS data is identifier quality. A detailed analysis of entity identifier practices in UK public procurement data is available at: https://world.hey.com/cos/entity-identifiers-in-uk-public-procurement-data-5f3f3815

Beneficial Ownership in Extractives (EITI)

The Extractive Industries Transparency Initiative (EITI) is the primary global framework for transparency in the oil, gas, and mining sectors. BO disclosure is a mandatory requirement for EITI implementing countries.

EITI 2023 Standard: strengthened BO requirements

The 2023 EITI Standard significantly strengthened BO requirements (Requirement 2.5):

• Countries are encouraged to adopt a BO threshold of 10% or lower (down from the previous 25% norm). As of 2025, 50 EITI countries have defined BO thresholds; half set it at 10% or below. Specific examples: Argentina (1 share), Colombia (5%), Nigeria (5%), Senegal (2%).
• New requirement for full disclosure by politically exposed persons (PEPs) regardless of ownership level — to detect conflicts of interest in licensing.
• New requirement to disclose legal ownership structures as well as beneficial ownership, to enable tracing of full ownership chains.
• Encouragement for companies to disclose their complete ownership structure and chain where beneficial ownership is held indirectly.

2023 Standard PDF: https://eiti.org/sites/default/files/2023-06/2023%20EITI%20Standard.pdf

EITI State-Owned Enterprises (SOE) database

EITI launched a dedicated database of state-owned enterprises (https://soe-database.eiti.org/) covering ~100 SOEs across EITI implementing countries, with data going back to 2017. Key features:

• Data on SOE payments to government and other extractives disclosures
• Uses UUIDs for entities, enabling time-series analysis and interoperability with international databases
• Filterable by country, company, and sector
• API endpoint: https://soe-database.eiti.org/eiti_database

BODS mapping: A Jupyter notebook demonstrating how the EITI SOE database maps to BODS is at: https://github.com/civicliteracies/EITI_SDT_data_verification_and_validation/blob/sqlite/5_publish/1_test/eiti_bods_mapping.ipynb

The notebook shows how state bodies (ministries, agencies) holding direct or indirect controlling interests in SOEs can be represented using BODS entity statements and ownership-or-control statements, including the stateBody entityType and control interests without share percentages.

BODS guidance for representing SOEs

The BODS standard has specific guidance on representing state-owned enterprises: https://standard.openownership.org/en/0.3.0/schema/guidance/repr-state-owned-enterprises.html

Key modelling decisions for SOEs in BODS:

• Use entityType: "stateBody" for the state or government agency holding the interest
• Control relationships (e.g. board appointment powers, policy direction) use interests[].type: "otherInfluenceOrControl" rather than shareholding types
• Where the state holds both equity and control, use multiple interests[] entries within a single OOC statement

Public Beneficial Ownership Registers: Selected Examples

These are examples of live public BO registers — useful as reference implementations, data sources for mapping work, or for understanding diverse approaches to BO disclosure.

For a global overview of BO register status by country, see the OpenOwnership map: https://www.openownership.org/en/map/

EU BORIS: Beneficial Ownership Registers Interconnection System

BORIS (Beneficial Ownership Registers Interconnection System) is the EU's attempt to create a single search point for beneficial ownership data across EU and EEA member states, hosted on the European e-Justice Portal. In concept it should allow anyone — a compliance officer, investigator, or journalist — to conduct a single search and retrieve BO records from all connected national registers. In practice, its implementation has fallen significantly short of this goal.

Regulatory basis

BORIS is mandated by three successive AML directives and an implementing regulation:

• AMLD4 (2015/849): First required member states to establish central BO registers. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32015L0849
• AMLD5 (2018/843): Required public access to BO registers and mandated interconnection of national registers. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32018L0843
• Regulation 2021/369: The specific implementing regulation establishing the technical and functional specifications for BORIS. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32021R0369&from=EN

AMLD6 (2024/1640) and the 2024 AML Regulation (2024/1624) will significantly reshape the BO disclosure landscape from 2027, including interconnection requirements.

Current status and limitations

As of April 2026, BORIS has fallen well short of its original 2020 go-live target, though connectivity is gradually growing. Only 6 member states (Austria, Denmark, Greece, Latvia, Malta, Netherlands) have records fully searchable by name or company ID through the portal. Norway joined in April 2026 as the 17th connected jurisdiction, bringing the total number of EU/EEA countries that have completed the technical steps to provide data to the platform to 17 of 30 — but most records are either inaccessible or accessible only in paid PDF format.

Key structural limitations Stephen identifies in his Medium analysis (https://stephenabbottpugh.medium.com/challenges-in-realising-the-goal-of-the-eus-beneficial-ownership-registers-interconnection-system-7ec7b52575ae):

• No machine-readable data: Users can only download BO records as PDFs for individual companies; bulk data access is not available through BORIS
• Paywalled records: Most records require payment to access, limiting use by civil society and journalists
• Incomplete ownership chains: Records often show only direct beneficial owners; full chains through intermediate holding companies are rarely visible
• UBO Data Rulebook scope gap: The Rulebook underlying BORIS only covers legal persons — not legal arrangements (trusts, nominee relationships). BODS supports both, creating a structural gap between what BORIS captures and what full BO transparency requires
• Identifier fragmentation: BORIS relies on EUID-structured identifiers but many legal persons and arrangements lack an EUID, creating linkage failures across borders
• Uneven national data quality: The 17 connected registers have highly variable data quality, field coverage, and update frequencies. A search across BORIS does not guarantee comparable results across jurisdictions

Related analysis

• Stephen's Bluesky post on BORIS: https://bsky.app/profile/stephenabbottpugh.bsky.social/post/3lkbe4wona22j
• OO: value of connecting EU BO data: https://www.openownership.org/en/blog/the-value-of-connecting-beneficial-ownership-data-across-the-european-union/
• Transparency International: barriers for investigators across EU: https://www.transparency.org/en/news/barriers-investigators-face-across-eu-tracing-asset-ownership

Canada: Corporations Canada and the Pan-Canadian BO Register

Canada has moved from a fragmented, non-public BO regime to a public federal register and an ambitious programme to create a pan-Canadian repository using BODS.

Corporations Canada federal register

Canada launched its public, searchable beneficial ownership registry in January 2024 under Bill C-42 (An Act to amend the Canada Business Corporations Act). The register covers corporations incorporated under the Canada Business Corporations Act (CBCA), which includes all federally incorporated companies.

• Register search: https://ised-isde.canada.ca/cc/lgcy/fdrlCrpSrch.html?lang=eng
• The federal register uses BODS to structure and publish BO data. Open Ownership worked directly with ISED to implement BODS as the technical foundation.
• OO news: https://www.openownership.org/en/news/canada-passes-law-to-create-public-beneficial-ownership-register/

BOP2P: Beneficial Ownership Policy to Practice

The Beneficial Ownership Policy to Practice (BOP2P) programme (https://ised-isde.canada.ca/mras/partners/bop2p/) is Canada's federal-provincial-territorial initiative to create a pan-Canadian BO repository — a single point of access to BO data from federal and provincial/territorial registries across Canada, not just CBCA companies.

The programme operates through the Multijurisdictional Registry Access Service (MRAS), which already interconnects business registry data across Canadian jurisdictions. BOP2P is extending this to include BO data using BODS as the common data standard across jurisdictions.

Key design choices: BODS enables each jurisdiction to publish BO data in its own format and map to the standard, while the central MRAS layer aggregates into a coherent pan-Canadian view. Open Ownership is providing technical support including working with British Columbia — one of the first provinces implementing a provincial BO register expected around 2025.

Beneficial Ownership Declaration and Data Collection Forms

BO declaration forms are the primary mechanism through which companies and their owners submit beneficial ownership information to a register. Form design has significant downstream implications for data quality: poorly specified fields, missing validation, and ambiguous instructions produce unreliable data that cannot be effectively used or linked across registers.

OpenOwnership guidance: design principles and recommended fields

OpenOwnership has produced a suite of resources specifically for regulators and form designers.

Guide for regulators and designers (https://www.openownership.org/en/publications/beneficial-ownership-declaration-forms-guide-for-regulators-and-designers/): Covers the full process of form design — from defining legal scope, to structuring questions, to handling edge cases (joint ownership, nominee arrangements, trusts). Key principles: use unambiguous legal definitions for each data field; capture machine-readable identifiers (national ID number, date of birth, country of nationality) rather than relying on free-text names alone; include a clear effective date for each declaration; and design explicitly for update workflows, not just initial registration.

Example declaration form (https://www.openownership.org/en/publications/example-beneficial-ownership-declaration-form/): A reference implementation of a BO declaration form reflecting BODS data model requirements. Contains separate sections for: (1) company/legal entity being declared; (2) each beneficial owner — name, date of birth, nationality, country of residence, national identifier, nature of interest (shareholding percentage, voting rights, control mechanisms); (3) declarant details and signed attestation.

Example paper forms (https://www.openownership.org/en/publications/example-paper-forms-for-collecting-beneficial-ownership-data/): A set of five modular paper forms designed to be adaptable to different legal contexts. Covers natural persons, corporate beneficial owners, trusts, nominees, and declarations of no beneficial owner meeting the threshold.

Annex — information fields (https://www.openownership.org/en/publications/sufficiently-detailed-beneficial-ownership-information/annex-examples-of-information-fields-in-beneficial-ownership-declaration-forms/): A comparative analysis of the actual data fields used in BO forms across multiple jurisdictions. Useful for benchmarking what a register collects against best practice and BODS field coverage.

EITI model declaration form

The EITI model beneficial ownership declaration form (https://eiti.org/guidance-notes/beneficial-ownership-model-declaration-form) is designed for the extractive sector and aligned with the 2023 EITI Standard (Requirement 2.5). It collects: beneficial owner full name, nationality, country of residence, national ID number, date of birth; level of ownership (percentage); how control is exerted (direct equity, indirect equity, voting rights, right to appoint management, other); whether the owner is a PEP (full disclosure required regardless of ownership level); and a signed attestation with effective date. The form explicitly captures reporting exceptions — cases where a BO cannot be identified — with a reason field.

Country examples

Ghana — Office of the Registrar of Companies (ORC)

Ghana's Companies Act 2019 (Act 992) mandates BO disclosure for all companies registered in Ghana. The ORC uses a suite of differentiated forms depending on entity type:

• BO1 — general companies (natural persons as beneficial owners)
• BO2 — companies whose beneficial owners are themselves companies
• BO3 (https://orc.dntsystems.net/wp-content/uploads/2025/08/BO3-Listed-Company-BO-Form.pdf) — listed companies: captures the same core fields but with additional sections for stock exchange listing, ISIN/ticker, public float percentage, and identification of any beneficial owners who hold ≥5% of listed shares directly or indirectly
• BO4 (https://orc.dntsystems.net/wp-content/uploads/2025/08/BO4-Government-BO-Form.pdf) — government-owned entities: covers state bodies and SOEs; replaces natural-person BO identification with the details of the government ministry or agency holding the interest, the name and role of the political or administrative authority responsible, and the legal basis for government ownership

The form family illustrates how a register can accommodate the full range of entity types BODS models — registeredEntity, publiclyListedCompany, stateBody — within a single coherent disclosure regime.

Namibia — Business and Intellectual Property Authority (BIPA)

Namibia's Companies Amendment Act 2 of 2023 introduced mandatory BO disclosure. BIPA administers two forms:

• BO1: The primary declaration. Three sections — (A) company information and BO type; (B) beneficial owner particulars (full names, date of birth, nationality, residential address, national ID number, nature and extent of the beneficial interest); (C) completion notes and attestation. Covers natural persons, publicly listed companies, and government agencies as possible beneficial owner types.
• BO2 (https://www.bipa.na/download/beneficial-ownership-declaration-form-bo2/): A "no change" declaration for annual returns confirming that no material change to BO information has occurred since the last filing.

The August 2024 deadline required all existing companies to file or bring BO information up to date. As of 2026, compliance stands at approximately 45%.

UK — PSC01 (Companies House)

The UK PSC (Persons with Significant Control) regime is the world's largest public BO register by record count and the canonical reference implementation for BODS. The PSC01 form v4.0 (https://assets.publishing.service.gov.uk/media/6911eb1ce9348ac8fb54f480/PSC01_v4.0-FINAL.pdf) — updated November 2025 — is used to notify Companies House of an individual PSC.

Five conditions for significant control (any one triggers PSC status):

1. Holds, directly or indirectly, more than 25% of shares
2. Holds, directly or indirectly, more than 25% of voting rights
3. Holds the right, directly or indirectly, to appoint or remove a majority of the board of directors
4. Has the right to exercise, or actually exercises, significant influence or control over the company
5. Has the right to exercise, or actually exercises, significant influence or control over a trust or firm that itself meets one of the above conditions

Fields collected: full name; date of birth (month and year only — day withheld from public register); nationality; country/state of residence; service address; usual residential address (protected — not on public register); nature of control (checkbox against each of the five conditions, with percentage bands for conditions 1–2: 25–50%, 50–75%, 75–100%); date of notification; and from November 2025, confirmation of identity verification status.

The v4.0 update brings mandatory identity verification into the form, aligning with the Economic Crime and Corporate Transparency Act 2023. PSCs are required to verify their identity with Companies House directly.

BODS Development: Open Issues and Feature Tracker

The BODS data-standard repository (https://github.com/openownership/data-standard) currently has 79 open issues. The BODS Feature Tracker project board (https://github.com/orgs/openownership/projects/9/views/1) organises feature development into Research, Proposed, and Implementation phases.

When helping with BODS schema questions, check this tracker first — some apparent "gaps" in 0.4 are already documented as known issues with active research underway.

Feature: Representing Assets (#752)

Status: Research. Urgency: Not currently urgent.

Proposal to extend BODS beyond its current scope of legal vehicles to represent the assets connected to beneficial ownership networks. Minimum viable fields suggested: assetType, assetId, assetName.

Asset classes identified as requiring representation: mining and drilling concessions (EITI); media outlets (Euromedia Ownership Monitor); energy projects (Global Energy Ownership Tracker); fishing and shipping vessels (Global Fishing Watch, Triton); financial assets (EU AMLD6, OECD CRS); mixed assets for wealth investigations.

Key design decision: financial assets derived from legal entity ownership (shares, options, fund units) should remain as interest types rather than distinct asset objects, to avoid complexity. Physical assets — land, vessels, bank accounts, concessions — are the primary target for a new assetStatement type.

See also: OO publication Bridging the Gap (https://www.openownership.org/en/publications/bridging-the-gap-for-effective-asset-transparency/).

Feature: BODS Simplification (#737)

Status: Open / Backlog.

Goal: identify and remove unnecessary complexity from BODS to make it easier to understand and implement. Areas under discussion:

• Terminology: Remove redundant synonyms (element, claim, assertion); rename assertedBy → statedBy; replace subject with clearer language
• Schema restructuring: Streamline metadata outside recordDetails; clarify declaration vs record distinction
• Potential removal: isComponent and componentRecordIds fields

Content truncated for page performance. Open the source repository for the full SKILL.md file.