Lessons learned so far from two months of building OpenCheck
For the past two months, I’ve been building a new tool called OpenCheck and I want to share some of the lessons I’ve learned so far.
What is OpenCheck?
OpenCheck is an open source project to show how to do live due diligence risk checks powered by the Legal Entity Identifier (LEI), open data and open standards including the Beneficial Ownership Data Standard (BODS).
You give OpenCheck an LEI and, thanks to LEI mappings, it uses this global identifier to look up corporate information in dozens of open datasets from national registries, the Global Legal Entity Identifier Foundation, OpenSanctions, OpenCorporates, OpenAleph, EveryPolitician and Wikidata before returning a free, detailed open-source intelligence report on any of the three million entities with an LEI.
The more datasets can be linked using the LEI and the more corporate information is structured in line with BODS, the more detailed these reports can be.
Common risk checks can easily be run on the data once it has been standardised into BODS format.
With access to high-quality open company data, I’ve been able to quickly add new features including AI summaries, historical timelines, PDF export, interactive graph visualisations, an OpenCheck API, an MCP server and full data exports.
Key lessons learned so far
Data quality and predictability help AI do the right thing
It almost goes without saying that the higher the quality and predictability of open datasets, the easier they are to use.
But this has proved to be especially true in the new world of developing tools such as OpenCheck where generative AI coding assistants such as Claude Code, Google Antigravity or ChatGPT can be harnessed to quickly develop and iterate — but only if they can understand the information they are working with.
I’ve mainly used Claude Code when building OpenCheck and have been careful to read, store and create full documentation of all the decisions and choices made. But there have been many dead-ends or wasted explorations due to some sources lacking detailed information about how to work with their data.
As a counterpoint, the open data published by the Global Legal Entity Identifier Foundation (GLEIF) has been a joy to work with and I’ve harnessed their API, golden copy files, MCP servers and AI skills to help me along the way.
As recommended in this recent paper on connecting ownership data, “well-established foundations for interoperability - including consistent use of identifiers, well-documented APIs or bulk-data access mechanisms, and use of metadata to assist interpretation” should be adopted by more registers.
API access and documentation is crucial
Many of the sources in OpenCheck were added in minutes where they made API access swift and had detailed documentation about how to write API requests and what information to expect in response.
This was because I gave Claude Code access to a wealth of existing information about the open standards maintained by GLEIF as well as the open documentation for BODS.
Coupled with the initial project plan, this set the direction of travel meaning that potential sources could quickly be assessed to see if they could have adapters set up for them or otherwise discounted.
On the flip side, several registries ban access to API documentation sites by AI chatbots which made it more challenging to capture and share all the information required for mapping to take place.
Kudos to the New Zealand Companies Office for their approach where they provide detailed resources accessible to chatbots while restricting access to full documentation to logged in, approved API users.
Exposing the need for entity-resolved knowledge graphs
Once the data from each source in OpenCheck has been transformed and standardised in line with BODS, I use it to power all of the features from risk signals to interactive graph visualisations to historical timelines.
But these are currently dealt with on a source-by-source basis to show what information is coming in from each source and linking it back to original, verifiable records.
To understand all of the information that OpenCheck can pull together on a company in one go, it would be better in future if all this information can be brought together in a single graph to be examined and investigated.
I’ve already started down this path by - for example - offering all the collected BODS data for an entity in a single downloadable bundle as well as experimenting with exporting data in the Neo4J format.
In the coming weeks, I will be doing more work in this space to see how OpenCheck could take advantage of approaches around entity-resolved knowledge graphs.
Lack of open company ownership information from some European Union countries
Under the Open Data Directive, European Union member states were all supposed to have released open, machine-readable data on companies and company ownership by mid-2024. This does not cover beneficial ownership data where access is more restricted.
The EU wanted this because such data was seen as particularly high-value with officials stating that “making high-value datasets available will benefit both the economy and society”.
But eight EU countries have still not released this information or fail to make it available via API, based on my experience so far with OpenCheck.
A 2025 OECD study found that the “categories of [high-value data] least likely to be available as open data are companies and company ownership”.
I will continue to monitor a variety of sources to see if there are further rich sources of open company data which can be included in OpenCheck, so please let me know if you know of any good candidates missing from the list of sources.
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.
