FpML Issues Tracker
closed
Minor
Have not tried
Coordination
Admin
mgratacos
Summary
The FpML specification is silent on what can be inferred from list of Identifiers. Please add to the FpML specification a clear definition.
The specific problem experienced is an external application conveying mappings between Identifiers based on appearing in the same list of PartiesAndAccounts.model/party/partyId, and also for PartiesAndAccounts.model/account/@id. The problem occurs when downstream apps try to infer a 1:1 relationships between the list of identifiers for other usages.
For example if 4 different partyId's are given by the 3rd party external app, downstream apps are inferring a 1:1 linkage between them, and adding them to their general reference data.
This has gone wrong where there is a many-to-one relationships, and we can safely traverse in one direction only.
FpML doesn't say whether the definition of partyId makes this safe or not. It says nothing about whether lists of codes are safe to traverse and use again later, for other purposes.
I suggest either saying in the spec, not to infer anything beyond what is meant/explicit - i.e. best practise; or to state in list of identifiers what the relationship is or isn't between them. i.e. whether it is safe to learn and reuse that mapping or not.
My personal view is that FpML wasn't designed to transport reference data, and that it should be notes as unreliable to learn identifier mappings this way.
Perhaps simply state that "the relationship between identifiers isn't guaranteed outside of the message"?
Either answer would be good for me. Clarity of the spec is the most important goal. We can adopt whatever is decided.
Notes:
JCP
06/25/19 7:15 am
I agree.
I’ve seen Party used for distinct and indistinct legal entities, parent corporations, branches, and trading desks.
When adding cross references it’s useful to verify the relationship between the identifiers first.
JCP
06/25/19 7:20 am
Suggest we add text as requested, that says something like
“Identifiers may have different scopes. This means that a kind of id may have a smaller scope than another kind of id, so that there might be many fine ids for a coarse id. Applications should take this into account.
Eg. Party Identifier, one identifier may be the trading desk, another the legal entity, another the reporting group.”
mgratacos
07/15/19 9:35 am
Minutes AWG 2019-06-27:
mgratacos
07/29/19 9:48 am
The sentence has been added to The Party Component section. It will be published in FpML 5.11 Last Call Working Draft.