How to specify a USI code?

, ,
1

Imported from previous forum

2

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

3

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

4

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

5

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

6

Thanks… I was wondering is anyone has a link to EP161?

In the documents attached below, I could not find the tag numbers for RegulatoryTradeID (in RegulatoryTradeIDGrp), and other fields in RegulatoryTradeIDGrp such as RegulatoryTradeIDSource, etc. Have these tag numbers been assigned already, or is this something that happen in the next few weeks?

We would like to adopt this proposal, since it will, most likely, become a standard.

On another matter, are there any proposals to make the RegulatoryTradeIDGrp a part of Execution Reports? USI codes are supposed to be assigned during trading, and it would make sense to have them be a part of ERs (at least, the final fills).

Sincerely,
George Svedloff

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

7

Sorry, George, but EP161 is not completed yet and hence there cannot be a link yet. The submitted Gap Analysis document and slides for EP161 can be found on the GTC website under the link already posted below. The new tags you mention below have so-called pre-assigned tag numbers but they do not become official until they are posted. You can contact me off-line if you need those tags now.
I agree that the component can also be useful on an ExecutionReport but I am not aware of a Gap Analysis being submitted for that. This is needed to make it part of the FPL Repository. You can always bilaterally agree with your counterparties to use these new fields in the ER. I do not see any conflict with existing fields of the ER.
Regards,
Hanno.

Thanks… I was wondering is anyone has a link to EP161?

In the documents attached below, I could not find the tag numbers for RegulatoryTradeID (in RegulatoryTradeIDGrp), and other fields in RegulatoryTradeIDGrp such as RegulatoryTradeIDSource, etc. Have these tag numbers been assigned already, or is this something that happen in the next few weeks?

We would like to adopt this proposal, since it will, most likely, become a standard.

On another matter, are there any proposals to make the RegulatoryTradeIDGrp a part of Execution Reports? USI codes are supposed to be assigned during trading, and it would make sense to have them be a part of ERs (at least, the final fills).

Sincerely,
George Svedloff

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

8

Hi all,

Ive been informed that SEF’s will generate their own USI codes, so i presume they will be sent on the 35=AB or 35=D that are sent to end bank? If so would we use the same component block?

thanks

Nadeem

Sorry, George, but EP161 is not completed yet and hence there cannot be a link yet. The submitted Gap Analysis document and slides for EP161 can be found on the GTC website under the link already posted below. The new tags you mention below have so-called pre-assigned tag numbers but they do not become official until they are posted. You can contact me off-line if you need those tags now.
I agree that the component can also be useful on an ExecutionReport but I am not aware of a Gap Analysis being submitted for that. This is needed to make it part of the FPL Repository. You can always bilaterally agree with your counterparties to use these new fields in the ER. I do not see any conflict with existing fields of the ER.
Regards,
Hanno.

Thanks… I was wondering is anyone has a link to EP161?

In the documents attached below, I could not find the tag numbers for RegulatoryTradeID (in RegulatoryTradeIDGrp), and other fields in RegulatoryTradeIDGrp such as RegulatoryTradeIDSource, etc. Have these tag numbers been assigned already, or is this something that happen in the next few weeks?

We would like to adopt this proposal, since it will, most likely, become a standard.

On another matter, are there any proposals to make the RegulatoryTradeIDGrp a part of Execution Reports? USI codes are supposed to be assigned during trading, and it would make sense to have them be a part of ERs (at least, the final fills).

Sincerely,
George Svedloff

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

9

Nadeem,
We had thought that the USI would be generated on fill (ExecutionReport) or on reporting to the SDR (TradeCaptureReport). But if there is a SEF work flow that requires generation of the USI earlier then yes you would use the same component block in NewOrderSingle or NewOrderMultileg.
Dean

Hi all,

Ive been informed that SEF’s will generate their own USI codes, so i presume they will be sent on the 35=AB or 35=D that are sent to end bank? If so would we use the same component block?

thanks

Nadeem

Sorry, George, but EP161 is not completed yet and hence there cannot be a link yet. The submitted Gap Analysis document and slides for EP161 can be found on the GTC website under the link already posted below. The new tags you mention below have so-called pre-assigned tag numbers but they do not become official until they are posted. You can contact me off-line if you need those tags now.
I agree that the component can also be useful on an ExecutionReport but I am not aware of a Gap Analysis being submitted for that. This is needed to make it part of the FPL Repository. You can always bilaterally agree with your counterparties to use these new fields in the ER. I do not see any conflict with existing fields of the ER.
Regards,
Hanno.

Thanks… I was wondering is anyone has a link to EP161?

In the documents attached below, I could not find the tag numbers for RegulatoryTradeID (in RegulatoryTradeIDGrp), and other fields in RegulatoryTradeIDGrp such as RegulatoryTradeIDSource, etc. Have these tag numbers been assigned already, or is this something that happen in the next few weeks?

We would like to adopt this proposal, since it will, most likely, become a standard.

On another matter, are there any proposals to make the RegulatoryTradeIDGrp a part of Execution Reports? USI codes are supposed to be assigned during trading, and it would make sense to have them be a part of ERs (at least, the final fills).

Sincerely,
George Svedloff

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

10

thanks for the reply Dean, seems like some of the ECN we work with will want to become SEF’s and will geneerate the USI, so it seems this component block maybe uses in 35=D/AB and 35=8 by us here.

Also i am writing the FIx spec here and the Dev team wanted to code for this and have asked me for FIX tags, i can see they are not yet available int he doc in this email chain, do you have an idea when these will be public?

Cheers

Nadeem

Nadeem,
We had thought that the USI would be generated on fill (ExecutionReport) or on reporting to the SDR (TradeCaptureReport). But if there is a SEF work flow that requires generation of the USI earlier then yes you would use the same component block in NewOrderSingle or NewOrderMultileg.
Dean

Hi all,

Ive been informed that SEF’s will generate their own USI codes, so i presume they will be sent on the 35=AB or 35=D that are sent to end bank? If so would we use the same component block?

thanks

Nadeem

Sorry, George, but EP161 is not completed yet and hence there cannot be a link yet. The submitted Gap Analysis document and slides for EP161 can be found on the GTC website under the link already posted below. The new tags you mention below have so-called pre-assigned tag numbers but they do not become official until they are posted. You can contact me off-line if you need those tags now.
I agree that the component can also be useful on an ExecutionReport but I am not aware of a Gap Analysis being submitted for that. This is needed to make it part of the FPL Repository. You can always bilaterally agree with your counterparties to use these new fields in the ER. I do not see any conflict with existing fields of the ER.
Regards,
Hanno.

Thanks… I was wondering is anyone has a link to EP161?

In the documents attached below, I could not find the tag numbers for RegulatoryTradeID (in RegulatoryTradeIDGrp), and other fields in RegulatoryTradeIDGrp such as RegulatoryTradeIDSource, etc. Have these tag numbers been assigned already, or is this something that happen in the next few weeks?

We would like to adopt this proposal, since it will, most likely, become a standard.

On another matter, are there any proposals to make the RegulatoryTradeIDGrp a part of Execution Reports? USI codes are supposed to be assigned during trading, and it would make sense to have them be a part of ERs (at least, the final fills).

Sincerely,
George Svedloff

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

11

Nadeem,
There is a white paper on USI soon to be published on the FPL website but in the meantime here are the current tags. “RegTrdID” is the FIXML element name:

1907 NoRegulatoryTradeIDs
– 1903 RegulatoryTradeID @ID [String]
– 1905 RegulatoryTradeIDSource @Src [String: i.e. namespace of the ID to be assigned by regulator]
– 1904 RegulatoryTradeIDEvent @Evnt [int: 0=Initial block trade, 1=Allocation, 2=Clearing, 3=Compression, 4=Novation, 5=Termination, others are coming]
– 1906 RegulatoryTradeIDType @Typ [int: 0=Current, 1=Previous, 2=Block, 3=Related]

I’ve double-checked the tag numbers - these are correct.

Dean

thanks for the reply Dean, seems like some of the ECN we work with will want to become SEF’s and will geneerate the USI, so it seems this component block maybe uses in 35=D/AB and 35=8 by us here.

Also i am writing the FIx spec here and the Dev team wanted to code for this and have asked me for FIX tags, i can see they are not yet available int he doc in this email chain, do you have an idea when these will be public?

Cheers

Nadeem

Nadeem,
We had thought that the USI would be generated on fill (ExecutionReport) or on reporting to the SDR (TradeCaptureReport). But if there is a SEF work flow that requires generation of the USI earlier then yes you would use the same component block in NewOrderSingle or NewOrderMultileg.
Dean

Hi all,

Ive been informed that SEF’s will generate their own USI codes, so i presume they will be sent on the 35=AB or 35=D that are sent to end bank? If so would we use the same component block?

thanks

Nadeem

Sorry, George, but EP161 is not completed yet and hence there cannot be a link yet. The submitted Gap Analysis document and slides for EP161 can be found on the GTC website under the link already posted below. The new tags you mention below have so-called pre-assigned tag numbers but they do not become official until they are posted. You can contact me off-line if you need those tags now.
I agree that the component can also be useful on an ExecutionReport but I am not aware of a Gap Analysis being submitted for that. This is needed to make it part of the FPL Repository. You can always bilaterally agree with your counterparties to use these new fields in the ER. I do not see any conflict with existing fields of the ER.
Regards,
Hanno.

Thanks… I was wondering is anyone has a link to EP161?

In the documents attached below, I could not find the tag numbers for RegulatoryTradeID (in RegulatoryTradeIDGrp), and other fields in RegulatoryTradeIDGrp such as RegulatoryTradeIDSource, etc. Have these tag numbers been assigned already, or is this something that happen in the next few weeks?

We would like to adopt this proposal, since it will, most likely, become a standard.

On another matter, are there any proposals to make the RegulatoryTradeIDGrp a part of Execution Reports? USI codes are supposed to be assigned during trading, and it would make sense to have them be a part of ERs (at least, the final fills).

Sincerely,
George Svedloff

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

12

thanks for the help Dean,

Nadeem

Nadeem,
There is a white paper on USI soon to be published on the FPL website but in the meantime here are the current tags. “RegTrdID” is the FIXML element name:

1907 NoRegulatoryTradeIDs
– 1903 RegulatoryTradeID @ID [String]
– 1905 RegulatoryTradeIDSource @Src [String: i.e. namespace of the ID to be assigned by regulator]
– 1904 RegulatoryTradeIDEvent @Evnt [int: 0=Initial block trade, 1=Allocation, 2=Clearing, 3=Compression, 4=Novation, 5=Termination, others are coming]
– 1906 RegulatoryTradeIDType @Typ [int: 0=Current, 1=Previous, 2=Block, 3=Related]

I’ve double-checked the tag numbers - these are correct.

Dean

thanks for the reply Dean, seems like some of the ECN we work with will want to become SEF’s and will geneerate the USI, so it seems this component block maybe uses in 35=D/AB and 35=8 by us here.

Also i am writing the FIx spec here and the Dev team wanted to code for this and have asked me for FIX tags, i can see they are not yet available int he doc in this email chain, do you have an idea when these will be public?

Cheers

Nadeem

Nadeem,
We had thought that the USI would be generated on fill (ExecutionReport) or on reporting to the SDR (TradeCaptureReport). But if there is a SEF work flow that requires generation of the USI earlier then yes you would use the same component block in NewOrderSingle or NewOrderMultileg.
Dean

Hi all,

Ive been informed that SEF’s will generate their own USI codes, so i presume they will be sent on the 35=AB or 35=D that are sent to end bank? If so would we use the same component block?

thanks

Nadeem

Sorry, George, but EP161 is not completed yet and hence there cannot be a link yet. The submitted Gap Analysis document and slides for EP161 can be found on the GTC website under the link already posted below. The new tags you mention below have so-called pre-assigned tag numbers but they do not become official until they are posted. You can contact me off-line if you need those tags now.
I agree that the component can also be useful on an ExecutionReport but I am not aware of a Gap Analysis being submitted for that. This is needed to make it part of the FPL Repository. You can always bilaterally agree with your counterparties to use these new fields in the ER. I do not see any conflict with existing fields of the ER.
Regards,
Hanno.

Thanks… I was wondering is anyone has a link to EP161?

In the documents attached below, I could not find the tag numbers for RegulatoryTradeID (in RegulatoryTradeIDGrp), and other fields in RegulatoryTradeIDGrp such as RegulatoryTradeIDSource, etc. Have these tag numbers been assigned already, or is this something that happen in the next few weeks?

We would like to adopt this proposal, since it will, most likely, become a standard.

On another matter, are there any proposals to make the RegulatoryTradeIDGrp a part of Execution Reports? USI codes are supposed to be assigned during trading, and it would make sense to have them be a part of ERs (at least, the final fills).

Sincerely,
George Svedloff

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

13

Hi Dean,

Just wanted to confirm if the following is an option:

For when a SEF will specify the USI on a swap order, in the 35=AB, can we add the RegTrdID element within the component LegOrdGrp and the repeating group 555 for each leg?
Please let me know if this is clear, if not i can message you in private with an example.

Thanks

Nadeem

Nadeem

Nadeem,
There is a white paper on USI soon to be published on the FPL website but in the meantime here are the current tags. “RegTrdID” is the FIXML element name:

1907 NoRegulatoryTradeIDs
– 1903 RegulatoryTradeID @ID [String]
– 1905 RegulatoryTradeIDSource @Src [String: i.e. namespace of the ID to be assigned by regulator]
– 1904 RegulatoryTradeIDEvent @Evnt [int: 0=Initial block trade, 1=Allocation, 2=Clearing, 3=Compression, 4=Novation, 5=Termination, others are coming]
– 1906 RegulatoryTradeIDType @Typ [int: 0=Current, 1=Previous, 2=Block, 3=Related]

I’ve double-checked the tag numbers - these are correct.

Dean

thanks for the reply Dean, seems like some of the ECN we work with will want to become SEF’s and will geneerate the USI, so it seems this component block maybe uses in 35=D/AB and 35=8 by us here.

Also i am writing the FIx spec here and the Dev team wanted to code for this and have asked me for FIX tags, i can see they are not yet available int he doc in this email chain, do you have an idea when these will be public?

Cheers

Nadeem

Nadeem,
We had thought that the USI would be generated on fill (ExecutionReport) or on reporting to the SDR (TradeCaptureReport). But if there is a SEF work flow that requires generation of the USI earlier then yes you would use the same component block in NewOrderSingle or NewOrderMultileg.
Dean

Hi all,

Ive been informed that SEF’s will generate their own USI codes, so i presume they will be sent on the 35=AB or 35=D that are sent to end bank? If so would we use the same component block?

thanks

Nadeem

Sorry, George, but EP161 is not completed yet and hence there cannot be a link yet. The submitted Gap Analysis document and slides for EP161 can be found on the GTC website under the link already posted below. The new tags you mention below have so-called pre-assigned tag numbers but they do not become official until they are posted. You can contact me off-line if you need those tags now.
I agree that the component can also be useful on an ExecutionReport but I am not aware of a Gap Analysis being submitted for that. This is needed to make it part of the FPL Repository. You can always bilaterally agree with your counterparties to use these new fields in the ER. I do not see any conflict with existing fields of the ER.
Regards,
Hanno.

Thanks… I was wondering is anyone has a link to EP161?

In the documents attached below, I could not find the tag numbers for RegulatoryTradeID (in RegulatoryTradeIDGrp), and other fields in RegulatoryTradeIDGrp such as RegulatoryTradeIDSource, etc. Have these tag numbers been assigned already, or is this something that happen in the next few weeks?

We would like to adopt this proposal, since it will, most likely, become a standard.

On another matter, are there any proposals to make the RegulatoryTradeIDGrp a part of Execution Reports? USI codes are supposed to be assigned during trading, and it would make sense to have them be a part of ERs (at least, the final fills).

Sincerely,
George Svedloff

This is part of EP161 which has been approved by the GTC but has not been fully implemented and published yet. This should happen in the next few weeks.
Regards,
Hanno.

Thanks for the replies. I have a question. In which FIX version was RegulatoryTradeIDGrp/RegulatoryTradeID added to TradeCaptureReport?

We don’t have this specific business requirement yet but sometimes when we run into similar situations then we just re-purpose post trade fields in order entry. There is a new component block in the TCR which is being used to report the main USI value in the RegulatoryTradeID field as well as a component block in the TCR which is being used to report the USI for a side in the SideRegulatoryTradeID field.

It seems that the latter would be a better fit for an execution report.

This shows the message flow →
http://www.fixprotocol.org/documents/7066/CDS%20Netting-Credit-Succession%20Events.zip

This shows the new component blocks → http://www.fixprotocol.org/documents/6969/CFTC%20Part%2043-45%20Phase%201%20changes.zip

–Aditya Kapur

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?

14

I don’t think you should do that. The new RegTrdID element is on the root level of the TCR, it is not inside of TrdInstrmtLegGrp. Hence it would also be on the root level of the Execution Report and not inside InstrmtLegExecGrp.
Why would the SEF issue NewOrderSingle or NewOrderMultileg with regulatory trade IDs? In FIX, the order submitter never assigns trade identifiers upon order entry. They would not be unique across users. He can do so as part of the TCR where FirmTradeID(1041) and SecondaryFirmTradeID(1042) are available.
Regards,
Hanno.

Hi Dean,

Just wanted to confirm if the following is an option:

For when a SEF will specify the USI on a swap order, in the 35=AB, can we add the RegTrdID element within the component LegOrdGrp and the repeating group 555 for each leg?
Please let me know if this is clear, if not i can message you in private with an example.

Thanks

Nadeem

15

Nadeem,
I agree with Hanno that USIs are meant to be assigned post-trade. Pre-trade the SEF’s order identifier should be communicated in OrderID(37) in the NOS and NOM, and the USI would be supplied by the SEF on fill at the earliest. For a multi-leg trade there would normally be separate ExecutionReports for each leg and the USI of each leg trade would appear in the root. If the business flow requires the multi-leg trade to remain intact, e.g. through clearing, there is an extension in the pipeline for that but no tag number has yet been assigned.
Dean

I don’t think you should do that. The new RegTrdID element is on the root level of the TCR, it is not inside of TrdInstrmtLegGrp. Hence it would also be on the root level of the Execution Report and not inside InstrmtLegExecGrp.
Why would the SEF issue NewOrderSingle or NewOrderMultileg with regulatory trade IDs? In FIX, the order submitter never assigns trade identifiers upon order entry. They would not be unique across users. He can do so as part of the TCR where FirmTradeID(1041) and SecondaryFirmTradeID(1042) are available.
Regards,
Hanno.

Hi Dean,

Just wanted to confirm if the following is an option:

For when a SEF will specify the USI on a swap order, in the 35=AB, can we add the RegTrdID element within the component LegOrdGrp and the repeating group 555 for each leg?
Please let me know if this is clear, if not i can message you in private with an example.

Thanks

Nadeem

16

Hi Dean/Hanno

Thanks for the quick replies. Just to give some background in regards to how we ( HSBC/Banks/liquidity providers) interact with ECN’s (who will become SEF’s eg Currenex) specific for FX.

In integrating to execution venues that arbitrate a transaction, liquidity providers (such as ourselves) will sometimes re-use their execution API for trade STP. In this case, FIX (35=D/AB) are in fact notification of a good trade and as such guaranteed to be honoured.

SEFs are responsible for generating a USI(s) for a transaction, and the final rules say these should be “generated at the earliest possible point when the swap is executed.” In other words, in the instance described above, it follows the SEF should include the USI(s) on the 35=D/AB

Note, in the case of a USI there should be no possibility of duplication as the SEF will use their own legal entity identifier namespace.

So as you mention this is in-fact a post-trade execution, but from a technical view it leave us ( Banks/Liquidity providers) in a situation as we can expect this USI on the order sent from the ECN.

For this reason we were hoping to use the new tags as part of the 35=AB for swaps.

Any suggestions for this situation will be appreciated.

Ps Hanno please say hi To Daniel Volstedt from me if he is still with the DB

Nadeem,
I agree with Hanno that USIs are meant to be assigned post-trade. Pre-trade the SEF’s order identifier should be communicated in OrderID(37) in the NOS and NOM, and the USI would be supplied by the SEF on fill at the earliest. For a multi-leg trade there would normally be separate ExecutionReports for each leg and the USI of each leg trade would appear in the root. If the business flow requires the multi-leg trade to remain intact, e.g. through clearing, there is an extension in the pipeline for that but no tag number has yet been assigned.
Dean

I don’t think you should do that. The new RegTrdID element is on the root level of the TCR, it is not inside of TrdInstrmtLegGrp. Hence it would also be on the root level of the Execution Report and not inside InstrmtLegExecGrp.
Why would the SEF issue NewOrderSingle or NewOrderMultileg with regulatory trade IDs? In FIX, the order submitter never assigns trade identifiers upon order entry. They would not be unique across users. He can do so as part of the TCR where FirmTradeID(1041) and SecondaryFirmTradeID(1042) are available.
Regards,
Hanno.

Hi Dean,

Just wanted to confirm if the following is an option:

For when a SEF will specify the USI on a swap order, in the 35=AB, can we add the RegTrdID element within the component LegOrdGrp and the repeating group 555 for each leg?
Please let me know if this is clear, if not i can message you in private with an example.

Thanks

Nadeem

17

Thanks for the background information. So the SEF sends you a NewOrderSingle(35=D) or NewOrderMultileg(35=AB) to notify a trade to you? They should send an ExecutionReport(35=8) and/or a TradeCaptureReport(35=AE) to do this. An order maintenance message should not be used as final message for a trade. NewOrderCross(35=s) also needs to be confirmed before it is an actual trade.
Maybe I am missing part of the workflow here but I still believe there is no need to add a USI to order maintenance messages such as 35=D/AB. You say that SEFs are responsible for generating USIs and do so as soon as the swap is executed. Why do they not use a TradeCaptureReport to report the execution? Even if only half trades are reported that are matched by the recipient, it should still be a TCR with TradeHandlingInst(1123) denoting the model. e.g. 2=One-party report for matching.
Thanks,
Hanno.
PS: I will let Daniel know you said hi, he is still here.

Hi Dean/Hanno

Thanks for the quick replies. Just to give some background in regards to how we ( HSBC/Banks/liquidity providers) interact with ECN’s (who will become SEF’s eg Currenex) specific for FX.

In integrating to execution venues that arbitrate a transaction, liquidity providers (such as ourselves) will sometimes re-use their execution API for trade STP. In this case, FIX (35=D/AB) are in fact notification of a good trade and as such guaranteed to be honoured.

SEFs are responsible for generating a USI(s) for a transaction, and the final rules say these should be “generated at the earliest possible point when the swap is executed.” In other words, in the instance described above, it follows the SEF should include the USI(s) on the 35=D/AB

Note, in the case of a USI there should be no possibility of duplication as the SEF will use their own legal entity identifier namespace.

So as you mention this is in-fact a post-trade execution, but from a technical view it leave us ( Banks/Liquidity providers) in a situation as we can expect this USI on the order sent from the ECN.

For this reason we were hoping to use the new tags as part of the 35=AB for swaps.

Any suggestions for this situation will be appreciated.

Ps Hanno please say hi To Daniel Volstedt from me if he is still with the DB

Nadeem,
I agree with Hanno that USIs are meant to be assigned post-trade. Pre-trade the SEF’s order identifier should be communicated in OrderID(37) in the NOS and NOM, and the USI would be supplied by the SEF on fill at the earliest. For a multi-leg trade there would normally be separate ExecutionReports for each leg and the USI of each leg trade would appear in the root. If the business flow requires the multi-leg trade to remain intact, e.g. through clearing, there is an extension in the pipeline for that but no tag number has yet been assigned.
Dean

I don’t think you should do that. The new RegTrdID element is on the root level of the TCR, it is not inside of TrdInstrmtLegGrp. Hence it would also be on the root level of the Execution Report and not inside InstrmtLegExecGrp.
Why would the SEF issue NewOrderSingle or NewOrderMultileg with regulatory trade IDs? In FIX, the order submitter never assigns trade identifiers upon order entry. They would not be unique across users. He can do so as part of the TCR where FirmTradeID(1041) and SecondaryFirmTradeID(1042) are available.
Regards,
Hanno.

Hi Dean,

Just wanted to confirm if the following is an option:

For when a SEF will specify the USI on a swap order, in the 35=AB, can we add the RegTrdID element within the component LegOrdGrp and the repeating group 555 for each leg?
Please let me know if this is clear, if not i can message you in private with an example.

Thanks

Nadeem

18

Thanks Hanno,

From a technical view i agree with what you say, i had these thoughts when i moved from futures to FX. The issue is that currently large vendors such as Currenex,FXALL , EBS, Bloomberg work in this way and hence will be sending the USI on the orders passed to us/other banks. They have already started to use custom tags for USI ( i have seen 2 fix specs which use their own custom tags) and we may see this with other liquidity providers.

I will discuss this further with some of the ECN’s and see what their feedback is, id rather them use the 1907 NoRegulatoryTradeId group then custom tags. than each of them using their own custom tags as it will make the integration process hard for all.

Thanks for the help so far,

Thanks for the background information. So the SEF sends you a NewOrderSingle(35=D) or NewOrderMultileg(35=AB) to notify a trade to you? They should send an ExecutionReport(35=8) and/or a TradeCaptureReport(35=AE) to do this. An order maintenance message should not be used as final message for a trade. NewOrderCross(35=s) also needs to be confirmed before it is an actual trade.
Maybe I am missing part of the workflow here but I still believe there is no need to add a USI to order maintenance messages such as 35=D/AB. You say that SEFs are responsible for generating USIs and do so as soon as the swap is executed. Why do they not use a TradeCaptureReport to report the execution? Even if only half trades are reported that are matched by the recipient, it should still be a TCR with TradeHandlingInst(1123) denoting the model. e.g. 2=One-party report for matching.
Thanks,
Hanno.
PS: I will let Daniel know you said hi, he is still here.

Hi Dean/Hanno

Thanks for the quick replies. Just to give some background in regards to how we ( HSBC/Banks/liquidity providers) interact with ECN’s (who will become SEF’s eg Currenex) specific for FX.

In integrating to execution venues that arbitrate a transaction, liquidity providers (such as ourselves) will sometimes re-use their execution API for trade STP. In this case, FIX (35=D/AB) are in fact notification of a good trade and as such guaranteed to be honoured.

SEFs are responsible for generating a USI(s) for a transaction, and the final rules say these should be “generated at the earliest possible point when the swap is executed.” In other words, in the instance described above, it follows the SEF should include the USI(s) on the 35=D/AB

Note, in the case of a USI there should be no possibility of duplication as the SEF will use their own legal entity identifier namespace.

So as you mention this is in-fact a post-trade execution, but from a technical view it leave us ( Banks/Liquidity providers) in a situation as we can expect this USI on the order sent from the ECN.

For this reason we were hoping to use the new tags as part of the 35=AB for swaps.

Any suggestions for this situation will be appreciated.

Ps Hanno please say hi To Daniel Volstedt from me if he is still with the DB

Nadeem,
I agree with Hanno that USIs are meant to be assigned post-trade. Pre-trade the SEF’s order identifier should be communicated in OrderID(37) in the NOS and NOM, and the USI would be supplied by the SEF on fill at the earliest. For a multi-leg trade there would normally be separate ExecutionReports for each leg and the USI of each leg trade would appear in the root. If the business flow requires the multi-leg trade to remain intact, e.g. through clearing, there is an extension in the pipeline for that but no tag number has yet been assigned.
Dean

I don’t think you should do that. The new RegTrdID element is on the root level of the TCR, it is not inside of TrdInstrmtLegGrp. Hence it would also be on the root level of the Execution Report and not inside InstrmtLegExecGrp.
Why would the SEF issue NewOrderSingle or NewOrderMultileg with regulatory trade IDs? In FIX, the order submitter never assigns trade identifiers upon order entry. They would not be unique across users. He can do so as part of the TCR where FirmTradeID(1041) and SecondaryFirmTradeID(1042) are available.
Regards,
Hanno.

Hi Dean,

Just wanted to confirm if the following is an option:

For when a SEF will specify the USI on a swap order, in the 35=AB, can we add the RegTrdID element within the component LegOrdGrp and the repeating group 555 for each leg?
Please let me know if this is clear, if not i can message you in private with an example.

Thanks

Nadeem

19

็Hi Nadeem,
I have just started studying the USI and have same the issue as you. The portals such as CNX, FXAll (Taker role) want to send the USI to our system (Maker role). So, we may need to add a new custom into NewOrderSingle(35=D) or NewOrderMultileg(35=AB). If we not support the USI tag in these message. How do we get their USI from?

One more question: As I know, USI is created from the first touch of execution. If we have 2 parties (Taker and Maker sides) to execute the swap trade and both have registered the namespace, which namespace (Taker or Maker) should be used for creating USI?

Regards,
Anon

Thanks Hanno,

From a technical view i agree with what you say, i had these thoughts when i moved from futures to FX. The issue is that currently large vendors such as Currenex,FXALL , EBS, Bloomberg work in this way and hence will be sending the USI on the orders passed to us/other banks. They have already started to use custom tags for USI ( i have seen 2 fix specs which use their own custom tags) and we may see this with other liquidity providers.

I will discuss this further with some of the ECN’s and see what their feedback is, id rather them use the 1907 NoRegulatoryTradeId group then custom tags. than each of them using their own custom tags as it will make the integration process hard for all.

Thanks for the help so far,

Thanks for the background information. So the SEF sends you a NewOrderSingle(35=D) or NewOrderMultileg(35=AB) to notify a trade to you? They should send an ExecutionReport(35=8) and/or a TradeCaptureReport(35=AE) to do this. An order maintenance message should not be used as final message for a trade. NewOrderCross(35=s) also needs to be confirmed before it is an actual trade.
Maybe I am missing part of the workflow here but I still believe there is no need to add a USI to order maintenance messages such as 35=D/AB. You say that SEFs are responsible for generating USIs and do so as soon as the swap is executed. Why do they not use a TradeCaptureReport to report the execution? Even if only half trades are reported that are matched by the recipient, it should still be a TCR with TradeHandlingInst(1123) denoting the model. e.g. 2=One-party report for matching.
Thanks,
Hanno.
PS: I will let Daniel know you said hi, he is still here.

Hi Dean/Hanno

Thanks for the quick replies. Just to give some background in regards to how we ( HSBC/Banks/liquidity providers) interact with ECN’s (who will become SEF’s eg Currenex) specific for FX.

In integrating to execution venues that arbitrate a transaction, liquidity providers (such as ourselves) will sometimes re-use their execution API for trade STP. In this case, FIX (35=D/AB) are in fact notification of a good trade and as such guaranteed to be honoured.

SEFs are responsible for generating a USI(s) for a transaction, and the final rules say these should be “generated at the earliest possible point when the swap is executed.” In other words, in the instance described above, it follows the SEF should include the USI(s) on the 35=D/AB

Note, in the case of a USI there should be no possibility of duplication as the SEF will use their own legal entity identifier namespace.

So as you mention this is in-fact a post-trade execution, but from a technical view it leave us ( Banks/Liquidity providers) in a situation as we can expect this USI on the order sent from the ECN.

For this reason we were hoping to use the new tags as part of the 35=AB for swaps.

Any suggestions for this situation will be appreciated.

Ps Hanno please say hi To Daniel Volstedt from me if he is still with the DB

Nadeem,
I agree with Hanno that USIs are meant to be assigned post-trade. Pre-trade the SEF’s order identifier should be communicated in OrderID(37) in the NOS and NOM, and the USI would be supplied by the SEF on fill at the earliest. For a multi-leg trade there would normally be separate ExecutionReports for each leg and the USI of each leg trade would appear in the root. If the business flow requires the multi-leg trade to remain intact, e.g. through clearing, there is an extension in the pipeline for that but no tag number has yet been assigned.
Dean

I don’t think you should do that. The new RegTrdID element is on the root level of the TCR, it is not inside of TrdInstrmtLegGrp. Hence it would also be on the root level of the Execution Report and not inside InstrmtLegExecGrp.
Why would the SEF issue NewOrderSingle or NewOrderMultileg with regulatory trade IDs? In FIX, the order submitter never assigns trade identifiers upon order entry. They would not be unique across users. He can do so as part of the TCR where FirmTradeID(1041) and SecondaryFirmTradeID(1042) are available.
Regards,
Hanno.

Hi Dean,

Just wanted to confirm if the following is an option:

For when a SEF will specify the USI on a swap order, in the 35=AB, can we add the RegTrdID element within the component LegOrdGrp and the repeating group 555 for each leg?
Please let me know if this is clear, if not i can message you in private with an example.

Thanks

Nadeem

20

FPL will be issuing a short “white paper” in the next couple weeks specifically around USI.

There has been a enhancements proposed to the Global Technical Committee (GTC) to extend FIX for Swaps Data Repository (SDR) reporting. Three new component blocks are being added to the TradeCaptureReport (35=AE) for the purpose of specifying the USI in the TradeCaptureReport when reporting to SDRs.

I would encourage those out in the FIX community who are members to get involved with the GTC or other committees/working group to raise and help address regulatory requirements. The standard doesn’t write itself - it is members who help do that.

We have a need to specify a regulation-related USI code for an order in Execution Reports. Something like this should be standard enough (many organizations are probably having to do that now), yet it is not in the FIX spec (the FIX spec, of course, came out long before the regulations came out).

I was wondering if anyone else has had to place USI codes in Exec Reports, and which field(s) have you used?