Create user-friendly web forms to collect data in line with the Beneficial Ownership Data Standard
Beneficial ownership data should be easy to submit as well as to use.
That sounds obvious. But in practice, everyone has long invested more heavily in the use side of the equation than the collection side.
We have APIs, data explorers, graph databases and analytical pipelines. What we have had less of are simple, accessible tools that help the people who actually know who owns what including company secretaries, compliance officers and obliged entities to submit that information cleanly, consistently, and in a form that machines can actually process.
The quality of beneficial ownership data is ultimately determined at the point of collection. If a declarant is confronted with an ambiguous paper form, an opaque portal or no guidance at all about what “beneficial owner” means or which fields are required, the data that is collected will reflect that confusion.
Analysts working with registers across multiple jurisdictions will recognise the pattern: inconsistent name formatting, missing dates of birth, ownership percentages that don’t add up, legal entity types that vary by jurisdiction with no common code.
The Beneficial Ownership Data Standard (BODS), developed by Open Ownership and Open Data Services, addresses these problems at the structural level:
BODS provides a common schema for representing persons, entities and the relationships between them. It distinguishes between direct and indirect ownership, supports multiple interest types simultaneously, handles chains of control and is designed to be interoperable across jurisdictions.
But BODS is a publication standard — it describes how data should be structured once collected. It doesn’t on its own tell you how to collect it.
That’s what BODS Forms is designed to address. Built using Claude Code and published at github.com/StephenAbbott/bods-forms, BODS Forms is a working prototype of a web-based data collection interface that is directly aligned with the BODS v0.4 schema:
Users move through a structured declaration flow — identifying the entity being disclosed, providing details of the beneficial owner as a person statement, and then capturing the relationship between them.
The output is valid BODS JSON: data that can be validated against the schema, ingested into a pipeline, or passed to a register system without further transformation.
The design choices are deliberate. Form fields map to BODS properties. Codelists — for interest types, nature of control, source types — are presented as human-readable options. Required fields are clearly marked. The interface is plain and functional, aimed at the person submitting a declaration rather than the developer implementing a system.
This matters beyond the prototype. The EU’s draft implementing regulation on beneficial ownership data formats linked to the Anti Money Laundering Regulation is pushing member states toward standardised data structures.
As AMLA takes on its supervisory role and registers across the EU are expected to interoperate, the question of how data gets in to those registers becomes as important as how it flows between them.
Collecting structured, schema-aligned data at source is far more efficient than attempting to clean and map inconsistent register outputs after the fact.
The code is open source. The approach is intentionally simple: a starting point rather than a finished product. If you’re working on register implementation, obliged entity reporting or data quality in the beneficial ownership space, I’d welcome your thoughts.
The collection layer deserves as much attention as everything that comes after it.
For four years, I was the product owner of the Beneficial Ownership Data Standard, the world’s leading open standard for beneficial ownership information and continue to advocate to improve beneficial ownership data quality and standardisation. To learn more or if you need technical guidance or consultancy support, contact me via beneficialownership.co.uk.
