You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
Following discussion in openownership/lib-cove-bods#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:
The text was updated successfully, but these errors were encountered: