Imported from previous forum
A while back, I opened a thread here on USI codes, and our need to use them in NewOrderXXX and ExecReport messages. The recent extensions introduced by FPL make it clear that the NoRegulatoryTradeIDs (field #1907) repeating group should be used for representing USI codes (with fields like RegulatoryTradeID - #1903, RegulatoryTradeIDSource - #1905, etc).
The nature of our business is such that messages that represent orders that come in to and leave our system can be subdivided into allocations. For example, in NewOrderSingle, we use the NoAllocs (#78) repeating group to represent the allocation breakdown, where the NewOrderSingle itself represents a block, and every element under noAllocs represents an individual allocation. In such case, we, for example, use the NoNestedPartyIDs (#524) repeating group under NoAllocs to represent allocation-specific parties, while we also make use of the NoPartyIDs (#453) repeating group to represent “header-level” (block-level) parties for the block - both allocation-level and block-level parties are applicable to our business.
When looking at USI codes, the NoRegulatoryTradeIDs (#1907) repeating group fits well with our concept of the “block-level” USI code (it will be on “header level”), but it would be great if there was something that we could use to represent “allocation-level” USI codes (something like “NoNestedRegulatoryTradeIDs” repeating group). Would anyone happen to know if something like that is defined by the FIX protocol extensions?
If nothing is defined, than it should be. Allocations in the NoAllocs (#78) repeating group in NewOrderSingle (and similar structures in other NewOrderXXX messages and in ERs) are distinct trading transactions that can most definitely have their own regulatory trading IDs.
Is anyone aware whether FPL has considered this issue, and, if no - what would be the way to create a proposal and submit it to FPL? Would anyone be willing to cooperate with us on the proposal if there is a need for one?
George,
There is already a group of fields defined for the allocations. Go to the FIXimate for the latest EP here:
http://www.fixprotocol.org/FIXimate3.0/latestEP/index.html
and look for the AllocRegulatoryTradeIDGrp component.
The component currently is only within the TradeCaptureReport msg’s TrdAllocGrp. However, this should not prevent you from using the AllocRegulatoryTradeIDGrp within the PreAllocGrp of the order or within AllocGrp of an AllocationInstruction (and AllocationReport) message.
What’sneeded is a proposal to add this component to the messages where needed (besides the TradeCaptureReport which is what the original proposal only needed for Swaps Data Repository reporting).
Hope that helps.
Lisa
A while back, I opened a thread here on USI codes, and our need to use them in NewOrderXXX and ExecReport messages. The recent extensions introduced by FPL make it clear that the NoRegulatoryTradeIDs (field #1907) repeating group should be used for representing USI codes (with fields like RegulatoryTradeID - #1903, RegulatoryTradeIDSource - #1905, etc).
The nature of our business is such that messages that represent orders that come in to and leave our system can be subdivided into allocations. For example, in NewOrderSingle, we use the NoAllocs (#78) repeating group to represent the allocation breakdown, where the NewOrderSingle itself represents a block, and every element under noAllocs represents an individual allocation. In such case, we, for example, use the NoNestedPartyIDs (#524) repeating group under NoAllocs to represent allocation-specific parties, while we also make use of the NoPartyIDs (#453) repeating group to represent “header-level” (block-level) parties for the block - both allocation-level and block-level parties are applicable to our business.
When looking at USI codes, the NoRegulatoryTradeIDs (#1907) repeating group fits well with our concept of the “block-level” USI code (it will be on “header level”), but it would be great if there was something that we could use to represent “allocation-level” USI codes (something like “NoNestedRegulatoryTradeIDs” repeating group). Would anyone happen to know if something like that is defined by the FIX protocol extensions?
If nothing is defined, than it should be. Allocations in the NoAllocs (#78) repeating group in NewOrderSingle (and similar structures in other NewOrderXXX messages and in ERs) are distinct trading transactions that can most definitely have their own regulatory trading IDs.
Is anyone aware whether FPL has considered this issue, and, if no - what would be the way to create a proposal and submit it to FPL? Would anyone be willing to cooperate with us on the proposal if there is a need for one?
Thanks a lot, Lisa, this is exactly what we were looking for!
For the record, the fields are:
1908 - NoAllocRegulatoryTradeIDs
1909 – AllocRegulatoryTradeID
1910 – AllocRegulatoryTradeIDSource
1911 – AllocRegulatoryTradeIDEvent
1912 – AllocRegulatoryTradeIDType
George,
There is already a group of fields defined for the allocations. Go to the FIXimate for the latest EP here:
http://www.fixprotocol.org/FIXimate3.0/latestEP/index.htmland look for the AllocRegulatoryTradeIDGrp component.
The component currently is only within the TradeCaptureReport msg’s TrdAllocGrp. However, this should not prevent you from using the AllocRegulatoryTradeIDGrp within the PreAllocGrp of the order or within AllocGrp of an AllocationInstruction (and AllocationReport) message.
What’sneeded is a proposal to add this component to the messages where needed (besides the TradeCaptureReport which is what the original proposal only needed for Swaps Data Repository reporting).
Hope that helps.
Lisa
A while back, I opened a thread here on USI codes, and our need to use them in NewOrderXXX and ExecReport messages. The recent extensions introduced by FPL make it clear that the NoRegulatoryTradeIDs (field #1907) repeating group should be used for representing USI codes (with fields like RegulatoryTradeID - #1903, RegulatoryTradeIDSource - #1905, etc).
The nature of our business is such that messages that represent orders that come in to and leave our system can be subdivided into allocations. For example, in NewOrderSingle, we use the NoAllocs (#78) repeating group to represent the allocation breakdown, where the NewOrderSingle itself represents a block, and every element under noAllocs represents an individual allocation. In such case, we, for example, use the NoNestedPartyIDs (#524) repeating group under NoAllocs to represent allocation-specific parties, while we also make use of the NoPartyIDs (#453) repeating group to represent “header-level” (block-level) parties for the block - both allocation-level and block-level parties are applicable to our business.
When looking at USI codes, the NoRegulatoryTradeIDs (#1907) repeating group fits well with our concept of the “block-level” USI code (it will be on “header level”), but it would be great if there was something that we could use to represent “allocation-level” USI codes (something like “NoNestedRegulatoryTradeIDs” repeating group). Would anyone happen to know if something like that is defined by the FIX protocol extensions?
If nothing is defined, than it should be. Allocations in the NoAllocs (#78) repeating group in NewOrderSingle (and similar structures in other NewOrderXXX messages and in ERs) are distinct trading transactions that can most definitely have their own regulatory trading IDs.
Is anyone aware whether FPL has considered this issue, and, if no - what would be the way to create a proposal and submit it to FPL? Would anyone be willing to cooperate with us on the proposal if there is a need for one?
I have captured this in FIXwiki - see Welcome fixwiki.org - BlueHost.com
Thanks a lot, Lisa, this is exactly what we were looking for!
For the record, the fields are:
1908 - NoAllocRegulatoryTradeIDs
1909 – AllocRegulatoryTradeID
1910 – AllocRegulatoryTradeIDSource
1911 – AllocRegulatoryTradeIDEvent
1912 – AllocRegulatoryTradeIDTypeGeorge,
There is already a group of fields defined for the allocations. Go to the FIXimate for the latest EP here:
http://www.fixprotocol.org/FIXimate3.0/latestEP/index.htmland look for the AllocRegulatoryTradeIDGrp component.
The component currently is only within the TradeCaptureReport msg’s TrdAllocGrp. However, this should not prevent you from using the AllocRegulatoryTradeIDGrp within the PreAllocGrp of the order or within AllocGrp of an AllocationInstruction (and AllocationReport) message.
What’sneeded is a proposal to add this component to the messages where needed (besides the TradeCaptureReport which is what the original proposal only needed for Swaps Data Repository reporting).
Hope that helps.
Lisa
A while back, I opened a thread here on USI codes, and our need to use them in NewOrderXXX and ExecReport messages. The recent extensions introduced by FPL make it clear that the NoRegulatoryTradeIDs (field #1907) repeating group should be used for representing USI codes (with fields like RegulatoryTradeID - #1903, RegulatoryTradeIDSource - #1905, etc).
The nature of our business is such that messages that represent orders that come in to and leave our system can be subdivided into allocations. For example, in NewOrderSingle, we use the NoAllocs (#78) repeating group to represent the allocation breakdown, where the NewOrderSingle itself represents a block, and every element under noAllocs represents an individual allocation. In such case, we, for example, use the NoNestedPartyIDs (#524) repeating group under NoAllocs to represent allocation-specific parties, while we also make use of the NoPartyIDs (#453) repeating group to represent “header-level” (block-level) parties for the block - both allocation-level and block-level parties are applicable to our business.
When looking at USI codes, the NoRegulatoryTradeIDs (#1907) repeating group fits well with our concept of the “block-level” USI code (it will be on “header level”), but it would be great if there was something that we could use to represent “allocation-level” USI codes (something like “NoNestedRegulatoryTradeIDs” repeating group). Would anyone happen to know if something like that is defined by the FIX protocol extensions?
If nothing is defined, than it should be. Allocations in the NoAllocs (#78) repeating group in NewOrderSingle (and similar structures in other NewOrderXXX messages and in ERs) are distinct trading transactions that can most definitely have their own regulatory trading IDs.
Is anyone aware whether FPL has considered this issue, and, if no - what would be the way to create a proposal and submit it to FPL? Would anyone be willing to cooperate with us on the proposal if there is a need for one?