SIGIL SARL — Buea, Cameroon
BODS: the Beneficial Ownership Data Standard
What the Beneficial Ownership Data Standard is
Registry software comes and goes; the ownership data it holds has to outlive it. The Beneficial Ownership Data Standard (BODS) is, in its maintainers' words, an open standard "providing guidance for collecting, sharing and using high-quality beneficial ownership data". For anyone weighing beneficial ownership data standard software — a registrar, a ministry, a development partner — the standard is the fixed point in the evaluation: if a system can export its register faithfully to BODS, the data has a life independent of the software that produced it.
The standard is developed and maintained by Open Ownership, a non-profit organisation dedicated to beneficial-ownership transparency, working with Open Data Services. Its current documented version is 0.4, and its schema is defined in JSON Schema 2020-12. That last detail matters more than it may appear to: because the schema is published and machine-checkable, whether a data file conforms to BODS is not a matter of opinion or marketing — the file validates against the schema, or it does not.
It helps to be precise about what BODS is not. It is not a law: legal frameworks decide who must declare, what must be verified, and what may be published. It is not software: no product ships with the standard built in by decree. It is a shared language for the results — a way of recording who owns and controls legal entities such that the record can be read, checked, combined, and questioned by people and systems far beyond the registry that produced it.
A model built from statements
A BODS dataset is built from statements, and the design decision that gives the model its character is that statements are claims, not facts. In the standard's words, each statement "represents a claim made by a source at a particular point in time", and every statement carries its source, its date, and its context. When the underlying facts change — a shareholder sells, a trustee is replaced — the register does not edit the old statement: it publishes a new one carrying the same stable record identifier, amending or confirming what was said before. The result, as the standard puts it, is a write-only ledger; the history of what was claimed, by whom, and when, remains readable in full.
Ownership and control are carried by relationship statements as typed interests. The standard recognises that an interest may be rooted in legal ownership, come from controlling the entity, or come from using its assets, and its published interest-type codelist names the forms this takes: shareholding, voting rights, appointment of the board, rights granted by contract, senior managing official, nominee arrangements, and others. Relationships may be direct or run indirectly through intermediary entities — which is precisely where concealment tends to live, and why a structured, typed record matters more than a free-text one.
The statements themselves are of three kinds, described in the standard's key concepts:
| Statement type | What it records |
|---|---|
| Entity statement | A claim about a company, trust, or other legal arrangement — the vehicle whose ownership is being described. |
| Person statement | A claim about a natural person who owns, controls, or benefits from an entity. |
| Relationship statement | A claim about the interests that connect an interested party to an entity — the ownership or control itself. |
Why an open standard matters for a registry
The first argument is portability. A register is a public institution's memory of who ultimately owns and controls the legal entities on its territory (the glossary holds the working vocabulary), and that memory should not be hostage to a procurement decision. Data held only in a vendor's private schema is, in practice, the vendor's data: leaving means reverse-engineering your own register. Data exported to BODS can be carried to a successor system — or simply held, readable, against the day the software changes.
The second argument is analysis. Standardised statements can be read by tools the register's operator never built: cross-jurisdiction comparison, network analysis, screening by procurement authorities and financial institutions, investigative journalism. Because each statement carries its source and date, an analyst can weigh evidence rather than merely accept totals. None of that tooling has to be commissioned by the registry; an open standard lets an ecosystem do the work.
The third argument is scrutiny — of the software itself. When the export format is open and the schema machine-checkable, a registry operator can test a vendor's central claim instead of trusting it. That inverts the usual relationship between an institution and its supplier, and it is the healthiest inversion in public technology: the standard, not the sales material, defines what counts as working.
What BODS asks of registry software
Conformance in BODS 0.4 has a precise floor: the standard's conformance section requires that an implementation serialising to JSON "MUST validate against the standard's JSON schema", use the schema's terms consistently with their definitions, and reach outside them only where they are insufficient. But schema validity is the easy part. Exporting well is a property of the whole registry system, and it asks for four disciplines:
- Stable identifiers. Every entity, person, and relationship needs a record identifier that survives updates, corrections, and migrations. Without stable identifiers, new statements cannot amend or confirm earlier ones, and the register's history collapses into disconnected snapshots.
- Completeness. Typed interests only mean something if the register captures interests in their variety — percentages held, voting rights, control by contract, nominee arrangements — rather than flattening them into a single free-text field that no tool can interrogate.
- Update discipline. BODS models change as new statements, never as silent edits. A registry system should treat its own records the same way: append events, preserve history, and let the export reflect what was claimed at each point in time.
- Machine-readable export as a first-class function. An export assembled occasionally and by hand drifts out of conformance the first time the data model moves. The export must be a maintained, tested output of the system, produced the same way every time.
How RÉCOR aligns
One consequence of the open schema deserves emphasis: verification does not require trust. Open Ownership's Data Review Tool validates a data file's conformance to the JSON schema and to further requirements that can be checked programmatically. Anyone — an operator, an auditor, a journalist — can run a registry's export through it. A vendor's claim to export BODS is therefore a claim the vendor does not get to referee.
RÉCOR is a sovereign beneficial-ownership registry designed for Cameroon, and it is built to export to BODS v0.4. The alignment is structural rather than cosmetic. RÉCOR's records are designed to map onto the standard's three statement kinds — persons, entities, and the ownership-or-control relationships between them, with typed interests such as shareholding and voting rights. Its declaration log is append-only by design, which answers the standard's write-only ledger of claims; its records carry stable identifiers, which is what lets an exported statement amend or confirm an earlier one; and verification precedes publication, so what is exported is what survived scrutiny.
The machine-readable detail of that mapping is published as a self-declared BODS v0.4 export profile — the canonical statement of how RÉCOR's records map to the standard. It exists so that the sentence "exports to BODS" can be examined field by field rather than taken on faith. The profile is declared by SIGIL; it has not been certified by any third party.
RÉCOR was fully demonstrated to, and acknowledged by, Open Ownership on 1 July 2026. This is a technical demonstration, not an endorsement. We record it because it is the kind of claim this page argues for: specific, dated, and bounded — a demonstration of an export working, not a badge.
What we do not claim
The limits of this page are as deliberate as its claims. There is no certification programme for BODS conformance — no body issues a "BODS-certified" badge — so RÉCOR's alignment is self-declared, as every vendor's must honestly be. What can be offered instead is examinable: a published export profile, an open schema to validate against, and a dated demonstration. RÉCOR is pre-deployment; it has no customers, deployments, or pilots to report, and this page reports none.
That restraint is not modesty; it is method. A company proposing to operate an institution's memory should be legible in the same way it asks ownership to be. How SIGIL makes and bounds its claims is set out in the doctrine, and the wider context of this work sits with the rest of our governance-infrastructure practice.
Frequently asked
What is BODS?
The Beneficial Ownership Data Standard (BODS) is an open standard for collecting, sharing, and using beneficial-ownership data, developed and maintained by Open Ownership. Its current version, 0.4, models ownership as statements — about persons, entities, and the relationships between them, with typed interests such as shareholding and voting rights — defined in a JSON schema that data files can be validated against.
Is RÉCOR BODS-certified?
No — and neither is any other system, because no certification programme for BODS conformance exists. RÉCOR's alignment is self-declared: it is built to export to BODS v0.4, and SIGIL publishes the export profile that specifies the mapping so it can be examined. RÉCOR was fully demonstrated to, and acknowledged by, Open Ownership on 1 July 2026. This is a technical demonstration, not an endorsement.
Why does portability matter?
Because a register outlives any single piece of software. Ownership data exported to an open standard can be read by tools the register's operator did not build, compared across jurisdictions, and carried to a successor system without loss. Data held only in a vendor's private format is, in practice, the vendor's data.