# Linking Directors, PSCs and Companies: Building an Intelligence Portal from Companies House Data **URL:** \ **Category:** API Question\ **Created:** [October 26, 2026, 9:39am UTC](http://forum.companieshouse.gov.uk/t/linking-directors-pscs-and-companies-building-an-intelligence-portal-from-companies-house-data/13096 "2026-10-26T09:39:51Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![stewpalmer](http://forum.companieshouse.gov.uk/user_avatar/forum.companieshouse.gov.uk/stewpalmer/32/2215_2.png) [@stewpalmer](http://forum.companieshouse.gov.uk/u/stewpalmer)\ **Post date:** [October 26, 2026, 9:39am UTC](http://forum.companieshouse.gov.uk/t/linking-directors-pscs-and-companies-building-an-intelligence-portal-from-companies-house-data/13096/1 "2026-10-26T09:39:51Z")
Hi Everyone, I’ve been experimenting with building a Director and Company Intelligence Portal using Companies House bulk data and would be interested in hearing how other developers are approaching similar challenges. The focus is on linking director appointment data with company records to make it easier to move between a company and the individuals associated with it. Users can view company details, explore current and historical director appointments, and navigate between directors and the organisations they are connected to. By combining this with PSC data, the platform can reveal both management and ownership relationships, providing a more complete picture of corporate structures and business connections. One of the most interesting aspects has been treating Companies House data as a network rather than a collection of individual records. By joining director and company datasets, it becomes possible to uncover relationships and business connections that are difficult to see through standard company searches alone. The platform is built using Python, Flask, Azure SQL and DuckDB, and currently combines Officer/Director data (Product 195), Company Basic Data and PSC data from Companies House. I’d be interested to hear: - How others are working with Director and PSC data - Whether you’ve built similar relationship-mapping or investigation tools - What additional datasets or features would make this type of analysis more valuable - Any lessons learned when handling large Companies House datasets ---
**Author:** ![companieshousedata](http://forum.companieshouse.gov.uk/user_avatar/forum.companieshouse.gov.uk/companieshousedata/32/2190_2.png) [@companieshousedata](http://forum.companieshouse.gov.uk/u/companieshousedata)\ **Post date:** [October 27, 2026, 2:22pm UTC](http://forum.companieshouse.gov.uk/t/linking-directors-pscs-and-companies-building-an-intelligence-portal-from-companies-house-data/13096/2 "2026-10-27T14:22:18Z")
Hi Stew, I’ve been developing something remarkably similar (I call it **Corporate Investigator** ). It started from much the same observation: Companies House data becomes considerably more useful when treated as a network of connected entities rather than a collection of individual company records. My platform uses Python, DuckDB, Parquet, Neo4j and a React frontend. I’ve approached the technical implementation slightly differently, but the investigative objectives sound very familiar! A few observations from my experience that might be useful: **1. Working with Director and PSC data** One of the biggest challenges has been identifying individuals consistently across the datasets. I initially approached Officer and PSC records as separate sources of evidence, but soon realised that neither should necessarily be treated as a definitive representation of an individual. I’ve subsequently developed a separate, resolved Person entity that can consolidate Officer and PSC observations while retaining their original identities, source records and the information used to establish each connection. Identity resolution has proved particularly challenging. Different individuals can share identical names, while the same person may appear under different name formats, addresses or source identifiers. Birth month/year helps, but isn’t always available or sufficient. I’ve implemented evidence-based identity resolution, candidate comparison and review mechanisms. Avoiding incorrect merges is just as important as finding genuine connections. **2. Relationship mapping and investigation tools** I’ve built an interactive graph investigation environment using Neo4j, with companies, people, corporate entities and addresses represented as connected nodes. - Interactive network expansion between companies, Officers, PSCs and addresses. - Identifying shared company appointments and control relationships. - Historical views and timelines to understand when relationships existed. - Finding connections between apparently unrelated companies. - Investigating possible duplicate or fragmented personal identities. - Analysing shared addresses and understanding their significance. - Saving investigations, exporting networks and retaining the source records behind each finding. One architectural decision that has worked particularly well is treating Neo4j as a derived graph rather than the authoritative dataset. I keep the original bulk files unchanged, with versioned Parquet datasets providing a consistent source from which I can rebuild the graph whenever necessary. **3. Additional datasets and features** Financial accounts and filing history are high on my list of future additions. They would provide useful financial and historical context around the relationships already identified. Charges, insolvency information and other corporate events could also be valuable. However, one lesson I’ve learned is that improving the interpretation of existing relationships can be more useful than simply adding additional datasets. For example, establishing that two individuals were directors of the same company is relatively straightforward. Establishing whether their appointments actually overlapped, whether the underlying identities are reliable, and which source records support the conclusion is considerably more challenging. **4. Lessons from processing large Companies House datasets** - Using Parquet and DuckDB has worked well for processing and analysing large datasets without requiring everything to live in a conventional relational database. - Retaining the original source records so I can trace every relationship back to the data from which it was created. - Validating source formats carefully, including duplicates and inconsistent fields. - Normalising addresses without accidentally combining distinct locations. - Maintaining reproducible dataset versions and thoroughly validating new builds before making them active. - Distinguishing relationships that are explicitly recorded from connections inferred during identity matching. - Being explicit about incomplete dates and gaps in historical coverage. A particularly interesting complication is that Companies, Officers and PSC bulk snapshots can represent different dates. Consequently, the combined graph doesn’t necessarily describe one precise point in time. One area I’ve only recently started exploring is the Companies House Accounts data, and the sheer volume of information available is quite eye-opening. Unlike the company and appointment records, I’m now looking at potentially years of individual financial filings for millions of companies, many containing substantial amounts of detailed financial information. Adding all of that directly to the existing Neo4j graph could dramatically increase the number of nodes and relationships, potentially affecting query performance and the responsiveness of the interactive network unless it’s running on a suitably heavyweight machine with plenty of RAM and fast storage. I haven’t benchmarked Accounts integration yet, so this is currently an architectural concern rather than a measured problem. I’m considering keeping the detailed financial records in Parquet/DuckDB, adding only the most useful financial summaries and relationships to Neo4j, and retrieving more detailed information when needed. That could provide the additional investigative depth without sacrificing the responsiveness of the existing graph. Another challenge I’m interested in tackling is keeping the platform continuously updated using Companies House APIs or streaming services. The absence of a directly usable streaming timepoint in bulk snapshots makes establishing a reliable transition from a bulk import to incremental updates less straightforward than it might initially appear. My platform currently operates from bulk snapshots, so I haven’t solved that particular problem yet. I’ve also produced an illustrated user guide for my Corporate Investigator, including screenshots of the actual application, worked investigations, network visualisations and some of the identity-resolution challenges. I’ve made it available for you here: [Corporate Investigator User Guide - 27 October 2026](https://www.nickaskew.com/research/corporate-investigator/). Are you approaching this primarily from a business intelligence or due-diligence perspective, or is there a more specific investigative problem you’re hoping to address? Either way, it sounds as though I’m exploring much the same territory as you! Regards, Nick ![companies-house-bulk-data-processing-pipeline](http://discourselive.s3.dualstack.eu-west-1.amazonaws.com/original/2X/e/e592c70a4c704ba570b9665feb8fe32172a733a6.png) ---
**Author:** ![stewpalmer](http://forum.companieshouse.gov.uk/user_avatar/forum.companieshouse.gov.uk/stewpalmer/32/2215_2.png) [@stewpalmer](http://forum.companieshouse.gov.uk/u/stewpalmer)\ **Post date:** [October 28, 2026, 8:00am UTC](http://forum.companieshouse.gov.uk/t/linking-directors-pscs-and-companies-building-an-intelligence-portal-from-companies-house-data/13096/3 "2026-10-28T08:00:20Z")
Hi Nick Thanks for the detailed explanation. The Neo4j aspect was especially interesting. While my current work focuses on bringing together company, director and PSC datasets, a graph model looks like an effective way of exploring the increasingly complex relationship networks that emerge from appointment histories. It’s definitely an interesting technique that I’d like to investigate further. Kind Regards Stewart