Skip to main content
  • FAQs Last Updated:

What are the circumstances under which a firmDesignatedID value representing a single, unique account, relationship or entity identifier can change over time?

What are the circumstances under which a firmDesignatedID value representing a single, unique account, relationship or entity identifier can change over time?

Firm Designated ID (FDID) is defined in Section 1.1 of the CAT NMS Plan and replicated in the Industry Member Technical Specifications and Reference Database Technical Specifications.

The firmDesignatedID field is required on certain events reported to the Transaction system. Every firmDesignatedID (FDID) reported to the Transaction system must also be reported to the Reference Database along with all associated CAT Customers. FDIDs are used to link activity reported to the Transaction system to specific CAT Customers reported to the Reference Database. Therefore, any FDID reported to the Transaction system and the Reference Database must be unique, persistent and consistent. The “unique, persistent and consistent” requirement includes all systems and vendors that an Industry Member may use to report to the Transaction system and the Reference Database. The “unique, persistent and consistent” requirement also includes any masking methodology the Industry Member may use to mask an account number or relationship prior to submission to CAT. Further, it is not permissible for an Industry Member to report one firmDesignatedID value to the Transaction system and a different firmDesignatedID value to the Reference Database for an FDID representing a single, unique account, relationship or entity identifier.

Given the importance of the FDID, a change/replacement in the FDID value associated with a particular account, relationship or entity identifier would be an isolated event that is only permissible in certain limited circumstances, such as: 

  • System migration. For example, an Industry Member changes from System A to System B, which necessitates the generation of different FDID values for the same account, relationship or entity identifier.
  • Change of vendors. For example, an Industry Member changes from Vendor A’s Order Management System (“OMS”) to Vendor B’s OMS. Vendor B’s OMS does not support some of the characters supported by Vendor A so the Industry Member must change the FDID. 
  • Change in Clearing Firm. For example, an Industry Member changes from Clearing Firm A to Clearing Firm B. Clearing Firm B does not permit FDIDs in the same format as Clearing Firm A so the Industry Member must change the FDID.
  • Change in masking methodology. 
    • Changing the algorithm which creates the FDID value for the account, relationship or entity identifier
    • Masking a previously unmasked FDID value
    • Only for proprietary accounts: unmasking a masked FDID value of a proprietary account. 

A change/replacement in FDID value must be reported to the Reference Database in accordance with the requirements detailed in the Reference Database Technical Specifications. Please note that a change/replacement of FDID value is a different concept from correcting an erroneously reported FDID value. Please see the Reference Database Technical Specifications for details regarding other FDID End Reasons. 

Archive
No