Property identifiers help connect records. Portfolio analysis also needs to distinguish buildings, individual units and the financial interests attached to them.
A block of flats can appear many times in an insurer's or lender's data. There may be a record for the building, records for individual flats and several policies or loans associated with those addresses.
That structure is useful. Problems arise when every row is treated as a separate building or when an attempt to remove duplicates also removes legitimate exposure.
Decide what you are counting
An address count, a building count, a policy count and a sum of insured interests describe different aspects of a portfolio. None should silently stand in for another.
Ordnance Survey explains the role of the Unique Property Reference Number in identifying spatial addresses in Great Britain. Chimnie's property schema also includes parent and sibling relationships, allowing a flat to be associated with its containing building and related units where those links are available.
Those relationships help organise analysis. They do not establish what each policy covers, whether interests overlap or how a claim would be allocated. That information must come from the policy or financial record.
Keep physical and financial records separate
Consider a fictional six-flat block. Your dataset contains six flat records and one parent-building record. A cladding assessment is attached to the building and inherited by the flats.
Counting seven cladding flags as seven affected buildings would exaggerate the physical count. Collapsing the records into one row and discarding the individual policies would lose information about the insured interests.
A better approach is to maintain a building view and a policy or unit view, joined through explicit relationships. Report one assessed building, the number of relevant flats and the associated policies separately. Aggregate financial values only after defining how shared and overlapping interests should be handled.
The same principle applies to lending. Several loans secured on flats in one block may share a building-level issue while retaining distinct balances, borrowers and security arrangements.
Apply shared attributes at the right level
Some information belongs naturally to the building, such as a facade assessment. Other information may vary between flats, including floor level, internal condition and refurbishment history. Do not propagate every attribute through a parent link simply because the relationship exists.
Store the level at which a field was assessed. If a building-level result is displayed on a flat record, make that origin clear. Otherwise an analyst may assume the flat was separately inspected or modelled.
Check unusual structures explicitly. Mixed-use buildings, split addresses and campuses can expose weaknesses in otherwise tidy rules. Missing parent links should be visible in the quality report; a shared postcode or similar address string is not sufficient evidence to merge records automatically.
Once the grouping is established, test it against a small set of known buildings. Reconcile the expected units, identify any duplicate records and confirm that legitimate financial interests remain intact.
This gives portfolio teams a more useful view of concentration. They can identify a shared physical issue without overstating the number of buildings or understating the policies affected by it.
Contact Chimnie to explore parent and sibling property relationships for your portfolio and the checks needed to use them consistently.
Other Articles
Put this data to work
Everything discussed here is available through the Chimnie API, with up to £16 of free balance to try it.