Imported from previous forum
The ‘BrokerOfCredit’ field in the allocation repeating group in the Allocation msg for FIX 4.2 has been replaced with the NestedParties component in 4.4. The NestedParties component requires a NestedPartyIDSource for any NestedPartyID that is specified. There is also a NestedPartyRole, but the spec does not state that it is required for each NestedPartyID.
First question - shouldn’t the NestedPartyRole be required for each NestedPartyID?
Second question - the spec on PartyIDSource states that if the role is ‘BrokerOfCredit’, then the IDSource is I:
"For PartyRole="Broker of Credit":
I = Directed broker three character acronym as defined in ISITC ‘ETC Best Practice’ guidelines document"
Does that mean that the role must be ‘I’ for BrokerOfCredit, or that ‘I’ is another valid choice, in addition to the default list of valid choices:
"Applicable to all PartyRoles unless otherwise specified:
B = BIC (Bank Identification Code—Swift managed) code (ISO 9362 - See "Appendix 6-B")
C = Generally accepted market participant identifier (e.g. NASD mnemonic)
D = Proprietary/Custom code
E = ISO Country Code
F = Settlement Entity Location (note if Local Market Settlement use “E = ISO Country Code”) (see “Appendix 6-G” for valid values)
G = MIC (ISO 10383 - Market Identifier Code) (See "Appendix 6-C")
H = CSD participant/member code (e.g. Euroclear, DTC, CREST or Kassenverein number)"
To me, the latter interpretation (that all default codes plus ‘I’ are allowed) sounds right, but the most straightforward reading of the spec is contrary to that.
[ original email was from Alvin Mullan - alvin.mullan@ubs.com ]
Terry,
For more information, please refer to the "FIX 4.4 Implementation Guide for Allocations, Confirmations and Settlement Instructions” document that is present on the Resource Archive link within Working Groups, Allocations on the FIX Protocol website. This is still a draft document, but is being produced within the workings for the FIX Allocations Working Group to define best practices for implementing these messages within FIX 4.4.
Q1 - Should the NestedPartyRole be required for each NestedPartyID.
Answer - Yes. Please refer to definition of tag 539 in volume 1 of the FIX 4.4 Specification - "Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole". For each occurrence of this group as defined by NoNestedPartyIDs <539>, then the following should ALWAYS be defined:
NestedPartyID <524>
NestedPartyIDSource <525>
NestedPartyRole <538>
Q2 - the spec on PartyIDSource states that if the role is ‘BrokerOfCredit’, then the IDSource is I.
I can’t find in the spec that you are referring to. The implementation guide referred to above defines the NestedPartyID <524> “Takes value B (BIC) or I (ISITC 3 character acronym as defined in ISITC ETC Best Practices document)” when NestedPartyRole <538> = 2 (Broker Of Credit). Additionally the table for Broker of Credit as given at the end of Volume 6 of the FIX 4.4 specification provides a list of possible values - B, I or D (Proprietary/Custom code).
If you need any more information or would like to discuss further, then please contact me.
Regards,
Alvin
020 7568 9617
> The ‘BrokerOfCredit’ field in the allocation repeating group in the Allocation msg for FIX 4.2 has been replaced with the NestedParties component in 4.4. The NestedParties component requires a NestedPartyIDSource for any NestedPartyID that is specified. There is also a NestedPartyRole, but the spec does not state that it is required for each NestedPartyID.
>
> First question - shouldn’t the NestedPartyRole be required for each NestedPartyID?
>
> Second question - the spec on PartyIDSource states that if the role is ‘BrokerOfCredit’, then the IDSource is I:
>
> “For PartyRole=“Broker of Credit”:
> I = Directed broker three character acronym as defined in ISITC ‘ETC Best Practice’ guidelines document”
>
>
> Does that mean that the role must be ‘I’ for BrokerOfCredit, or that ‘I’ is another valid choice, in addition to the default list of valid choices:
>
> “Applicable to all PartyRoles unless otherwise specified:
> B = BIC (Bank Identification Code—Swift managed) code (ISO 9362 - See “Appendix 6-B”)
> C = Generally accepted market participant identifier (e.g. NASD mnemonic)
> D = Proprietary/Custom code
> E = ISO Country Code
> F = Settlement Entity Location (note if Local Market Settlement use “E = ISO Country Code”) (see “Appendix 6-G” for valid values)
> G = MIC (ISO 10383 - Market Identifier Code) (See “Appendix 6-C”)
> H = CSD participant/member code (e.g. Euroclear, DTC, CREST or Kassenverein number)”
>
> To me, the latter interpretation (that all default codes plus ‘I’ are allowed) sounds right, but the most straightforward reading of the spec is contrary to that.
>
>