The Beneficial Ownership Data Standard (BODS) is an open standard providing a specification for modelling and publishing information on the beneficial ownership and control of corporate vehicles
Currently there's a normative requirement 'If an address in the addresses array is of type "alternative" then there is also another address in the array'
There's 2 possible edge cases here:
two addresses with 'alternative'
one address with no 'type' and one with 'alternative'
it's made me think that 'alternative' is just an unhelpful code. We should probably turn it into 'other', make the field required and reduce constraints. I can't see that loosening constraints would open up any particular loophole wrt BO verification. (For example, I don't imagine that red-flagging would depend on categorisation of addresses: if a BODS statement from one source categorised an entity's address as 'business' but the same entity's address in another source was categorised as 'other' that would not be of great interest. The address itself is the target of interest.)
Following discussion in https://github.com/openownership/lib-cove-bods/issues/123
Currently there's a normative requirement 'If an address in the addresses array is of type "alternative" then there is also another address in the array'
There's 2 possible edge cases here: