ANNA Ingestion Training Manuals post QMS PDF

ANNA Ingestion Training Manuals post QMS ANNA Process Document 1. Objective of ANNA: - a. The objective of this linking application is to integrate the ANNA data from the ANNA Vendor to S&P GLOBAL MARKET INTELLIGENCE database so that all the content can be provided under...

ANNA Ingestion Training Manuals post QMS ANNA Process Document 1. Objective of ANNA: - a. The objective of this linking application is to integrate the ANNA data from the ANNA Vendor to S&P GLOBAL MARKET INTELLIGENCE database so that all the content can be provided under one roof as ‘Integrated Desktop Solutions’ to our clients. b. Introduction: ANNA Feed i. About ANNA and National Numbering Agencies (NNAs): The ANNA (Association of National Numbering Agencies) Service Bureau has paired with number of other agencies to build a product consisting of the most complete coverage of ISIN (International Securities Identification Number) data. It is an industry association that acts as a central hub to receive ISIN data from the 79 ANNA members and 25 partners. It has presence in about 120 countries. ii. National Numbering Agencies (NNAs): ISINs are assigned by governing bodies in each country, known as the national numbering agency (NNA). The NNAs are coordinated through ANNA. In North America, for example, the NNA is the CUSIP organization, meaning that CUSIPs can easily be converted into ISINs by adding the US or CA country code to the beginning of the existing CUSIP code and adding an additional check digit at the end. In the United Kingdom and Ireland, the NNA is the London Stock Exchange and the NSIN is the SEDOL, converted in a similar fashion. Swiss ISINs are issued by SIX Financial Information and are based on the VALOR number. iii. Substitute Agencies (SNAs): In places where no NNAs exist, following four NNAs have been assigned as substitute agencies: 1. Standard & Poor´s - CUSIP Service Bureau in the US. 2. WM Datenservice from Germany. 3. SIX Financial Information. 4. National Settlement Depository (MICEX Group) from Russia. iv. Partners: Partners of ANNA are smaller National Numbering Agencies with the following rights and obligations: 1. They get assistance from ANNA in establishing the ISIN codification system in their country. 2. They are not entitled to vote or participate at General Meetings, as they are not shareholders. 3. They provide their ISINs and updates for dissemination through the products of the ANNA Service Bureau (ASB) via an ANNA member. 4. They have no financial obligation  2. Structure of An ISIN Identifier: - a. ISIN is the International Securities Identification Number regulated by the ISO 6166 standard. It is a 12- character identifier that captures an issue’s important differentiating characteristics within a common structure. It generally consists of three parts: - b. letter country code: - i. Equity Securities: The country code is the ISO code for the country where the issuer of securities is legally registered or in which it has legal domicile. ii. Two Debt Securities: The country code is the ISO code for the country of ISIN allocating NNA (National Numbering Agency). iii. Depository Receipts: The country code for the organization who issued the receipt instead of the one who issued the underlying security. c. 9-character alpha-numeric national security identifier: -These are taken up from the local number (assigned by the National Numbering Agency of the country) of the security concerned. Where the national number consists of fewer than nine characters, zeros are inserted in front of the number so that the full nine spaces are used. d. Single check digit 3. Corporate Actions (Identifier Changes): - a. Currently, ANNA does not maintain details of ISIN changes. Consequently, we will have to carefully review all incoming ISINs that could not be auto linked and investigate whether the incoming ISIN is a successor of an existing security. For this purpose, we will also leverage our existing security feeds like Telekurs/CGS to capture ISIN changes and use the information to consolidate ISINs to one security ID, if necessary. b. Below are the points providing a few corporate actions that we commonly come across, along with explanation of what identifier changes will happen for ISINs. i. In the name Changes Corporation scenario: 1. ISIN Treatment will be: The ISIN code remains unchanged except in the United States (paperless securities) where a new ISIN is issued only if the old security is exchanged for a new one (physical certificates). 2. CAPITAL IQ’S TREATMENT will be: New identifiers will be linked to existing CIQ security ID to which old identifier was already associated. If an entity changed its name due to reverse merger, then a new CIQ security ID will be created and new CUSIP will be linked to it. ii. In Reverse Mergers (one company is fully acquired by another company) : 1. ISIN Treatment will be: Merger by absorption (One of the companies incorporates the other(s) which legally disappear(s)) - ISINs of shares of the former companies must become inactive after a certain period. Merger by amalgamation: The two companies merge to form a new legal entity after a certain period - A new ISIN has to be allocated for the stock of the new company and the former ISINs must become inactive. 2. For CAPITAL IQ’S TREATMENT will be: If one company is fully absorbed by another company, then any new identifier will be associated to a different securityID and different CIQ ID (different Issuer). iii. In the Splits event Action for ISIN:  1. ISIN Treatment will be: Stock split and reverse split - The ISIN code is changed only if necessary, for technical reasons (paperless securities). A new ISIN is required in case of exchange of the old certificates (physical certificates) 2. For CAPITAL IQ’S TREATMENT will be: A new CUSIP assigned as a result of reverse split will be associated to the existing CIQ security ID. iv. Domicile change event: 1. ISIN Treatment will be: No change of ISIN for securities already existing. A new ISIN only if the old security is exchanged for a new one (physical certificates) 2. For CAPITAL IQ’S TREATMENT will be: Company changes its Domicile from one country to another, potentially resulting in identifier changes. 3. For CAPITAL IQ’S TREATMENT will be: When the company changes its domicile, it may lead to changes in the security characteristics as per the regulations of the new domicile. v. Liquidation/ Bankruptcy: 1. ISIN Treatment will be: The ISIN becomes inactive after deletion of the company in the register of commerce. 2. For CAPITAL IQ’S TREATMENT will be: The active/inactive status of the ISIN will be updated accordingly. 4. Reference Data: - a. This section briefly explains about the raw data points that are received in the ANNA feed that can be leveraged during our linking initiative. b. Among many others, following is the list of key data points that are received from ANNA: ISIN, Date/Time of Last Update, ISIN Type & Status, Issuer Name (long), Issuer Name (short), Issue Description, CFI Code/ Debt/Equity Code, Country of Issuer, Currency of Issue. 5. Linking ANNA ISIN In S&P CIQ Database: - a. Integrating ANNA ISIN : i. ISIN is a security identifier; therefore, like all other vendor ISINs, ANNA ISIN will also be ingested at the Security Level only. ii. What will be ingested at the Trading Item Level (TID Level): Since we are not receiving any cross- reference information with the ANNA ISIN, we would have no Trading level information for the corresponding TID although a new TID to be created. Thus, we will be creating blank TID with exchange as UNQ. b. Exclusions from the feed: i. Before we attempt to do any auto-linking or manual linking, we will have to exclude any ISIN that meets one of the below criteria. ii. If ISIN value that contains ‘?’ (Or any other special character) is excluded from linking process.  iii. If ISIN value that contains lower case letter is an invalid ISINs and thus is excluded from linking process. 6. Linking ANNA ISIN: - a. While integrating data from a third-party, we follow three steps to link the incoming unique identifiers to the Company ID, Security ID and Trading ID, to ensure that all data representing the same entity are linked to the same record. b. Auto linking: i. It is a process where the incoming unique value can be linked to CIQ entity, security, or trading item identifier as a result of the same value already been ingested from other vendor (i.e., IDC, CGS) feeds. ii. For ISIN linking, each ISIN ID that represents equity or debt security can be linked to CIQ securityID only if it can be linked to one CIQ securityID. c. Finding Potential SecurityID Link: i. For ISIN linking, since we are not receiving any cross-reference identifiers in the ANNA feed, the logic will derive National Security Numbers (NSNs) from the ISIN to find a potential security ID match. ii. As explained above, the ISIN has an embedded local security number that is assigned to the security by the National Numbering Agencies (NNA) for that country. These include the CUSIPs, SEDOLs, VALORSs, Austrian National Security Numbers, German National Security Numbers and others. iii. The auto linking logic will use these embedded National Security Numbers in the ISIN to find a Security ID match for the ISIN. d. To find a clean match for auto-linking purpose, the logic will go through the following steps: i. The ISIN is truncated by dropping the two-letter country code from the beginning and the check digit from the end of the ISIN. ii. Search the NSN in the CIQ DB: 1. If derived NSM is a CUSIP/Valor/SEDOL then in these cases, the derived NSN is CUSIP/VALOR/SEDOL, i.e., the country code for the corresponding ISIN was US/CH/GB respectively. The logic will directly check for a unique SECURITY ID match for the CUSIP/VALOR/SEDOL in the CIQ DB. 2. Derived NSN is other than CUSIP/VALOR/SEDOL: For such cases, where we have not ingested the NSNs in the CIQ DB, but we had received the same in the Telekurs feed, the logic will refer to the Telekurs raw files to find the corresponding VALOR for the NSN. Next, the logic will search for a unique SECURITY ID match for the VALOR in the CIQ DB. iii. Finding a unique SECURITY ID match: Different procedures are defined to find a unique Company ID/SECURITY ID match. Only “trusted” ISIN symbol types are being used while finding potential securityID matches. 1. What we are using If there is CUSIPs Symbol type: Symbol type name should be there like., IDC CUSIP 9, Mergent Debt CUSIP 9 (Security), Standard and Poors Municipal CUSIP, RatingsXpress Security CUSIP, CGS CUSIP 9, Telekurs CUSIP 9, CGS MBS CUSIP 9, Telekurs CINS 9, CGS CINS 9, QH CINS9, QH CUSIP9. 2. What we are using If there is ISIN Symbol type: IDC ISIN, Mergent Debt ISIN, RatingsXpress Security ISIN, Telekurs ISIN, ANNA ISIN, QH ISIN. 3. What we are using If there is VALOR Symbol type: Telekurs Valor, QH Telekurs Valor: 4. What we are using If there is VALOR Symbol type: IDC International SEDOL, RatingsXpress Security SEDOL, IDC Domestic SEDOL, Telekurs SEDOL, Telekurs SEDOL + Exchange, IDC  Domestic SEDOL + ExchangeId, RatingsXpress TradingItem SEDOL, IDC International SEDOL + ExchangeId, QH SEDOL + Exchange. 5. Note, while finding CIQ securityID matches based on SEDOL, we use both security and trading item level SEDOL symbol types to find our match. iv. Once potential CIQ securityID is found, the following is saved: 1. Associate ANNA ISIN symbol type to securityIDs. 2. Audit all the changes in CIQ audit_tbl using the defined audit types (they all need to be created). 7. Note of the Auto-Linking Process for the ANNA ISIN: - a. ISIN value present in a unique SID: If the same value of ISIN (active/inactive) is present in a unique SID, the incoming ANNA ISIN will be linked to the SID. b. ISIN value is present in multiple SIDs, active in one SID: If the same value of ISIN is present in multiple SIDs, but is active in only one SID, the ANNA ISIN is linked to the SID where the symbol is present as active. c. ISIN value is present in multiple SIDs, active in all SIDs: If the same ISIN value is present as active identifier in multiple SIDs, the logic will check the SID start/end dates. If the vendor (ANNA) dates fall in between the existing SID start/end dates, the ISIN will get linked to that SID. In case of conflict, the ISIN should be queued in the manual Linking Queue. d. ISIN and derived NSNs present in different SIDs: If the ISIN value and the corresponding derived NSN are present in two different SIDs, the corresponding ANNA ISIN should be queued in the manual Linking Queue. e. Auto Creation: Automation is a process where incoming unique value (unique identifier) does not exist in Capital IQ database, but other identifiers (Company level) related to the incoming value do. If the logic can identify a unique CIQ record to link the identifiers, it creates a new SECURITY ID/TID to link the vendor identifier. i. However, we will not be auto creating any CIQ Security ID/TID for the ANNA ISINs for the following reasons: 1. Since we are not receiving any ISIN changes from ANNA, auto-creation can lead to creation of duplicate SECURITY IDs. 2. We do not receive any company level identifier in the ANNA feed. f. Manual Linking: In this process, all the identifiers that could not be auto linked need to be manually reviewed and associated to the either existing or newly created CIQ entities. i. The following type of cases will be queued for manual linking: 1. Where there was no exact match found based on the ISIN or any of the NSNs embedded in the ISIN. 2. The identifiers are present in more than one CIQ ID/SECURITY ID, i.e., conflict case due to presence of dupes in the database and needs to be manually reviewed.  8. Highlights (To be Noted for Manual Linking): - a. ANNA Identifiers: i. ANNA does not provide any cross-reference data. We receive only the ISIN identifier (and related details) along with the issuer name and security description form ANNA. ii. To enhance the linking process and to ensure that we do not create duplicate object IDs in the CIQ db, we have truncated the ISIN to extract the embedded National Security Identifiers (NSNs) and include the same in the LOAD count. This will ensure that if any NSN linked through other linking processes is not missed out on. b. No Auto-Creation: However, we will not be auto creating any CIQ Security ID/TID for the ANNA ISINs for the following reasons: i. Since we are not receiving any ISIN changes from ANNA, auto-creation can lead to creation of duplicate SECURITY IDs. ii. We do not receive any company level identifier in the ANNA feed. c. ANNA ISIN type/Status: For ANNA, we also receive the symbol type & status for the ISINs. The different type/status received are mentioned below: i. Any ISIN type or status with a D code is inactive. ii. This ISIN type/status will be used to update the symbol active/inactive flag. d. All ISINs, irrespective of the type& status can be linked based on the cross reference information as received from the vendor. When ANNA indicates ISIN was deleted, the backend logics should inactivate the ISINs but will NOT physically delete the identifier. The ISIN active/inactive flag of the symbol will be adjusted accordingly. e. If researchers receive any case where the ISIN type/status falls in ‘ND = New Deleted ISIN, UD = Update a Deleted ISIN, DA = Delete an Active ISIN, DD = Delete a Deleted ISIN, DR = Delete a Reused ISIN’ and there is a conflict between the issuer name, these might need further review. In this case, we might need to get more clarity from the Vendor’s side. f. ANNA Queue Priority: As per the latest update the ANNA securities should be queued in the following order of priority. 1. Active Securities should be queued at the top of the queue. 2. LIFO – Incremental load. 3. Based on Security Subtype (Equity securities followed by debt securities). 9. ANNA ISIN Incremental Process: - a. On daily basis, ANNA will be providing all adds, updates, and deletes of ISIN data. Thus, we will need to update those changes at our end. When ANNA indicates ISIN was deleted, we will ensure that ISIN itself is inactivated but will NOT be physically deleting them. The ISIN Type and Status field will indicate whether information related to existing ISIN need to be updated or whether ISIN is new. DateTimeofLastUpdate field will indicate when changes were made. b. For different data points that are added or updated, or deleted by ANNA, we will receive daily delta files. The changed/updated ISIN ID could be either already ingested in the CIQ DB, or could be queued in the manual linking queue. c. As a rule, the following actions would be taken under different scenario s:  i. If the ISIN is updated and not integrated by ANNA ISIN then Action would be re-queued in the manual linking queue, with the changes attached. ii. If the ISIN is updated and integrated by ANNA ISIN then the data in the base tables need to be updated. Also, some cases will have to be manually reviewed, and changes will have to be made In the CIQ DB, if required. d. Below is a list of scenarios when specific data points are added/updated/deleted: i. Newly added ISIN (does not exist in the master file) ii. Existing ISIN - ISIN Type & Status field is updated from “active” to inactive” status or vice versa iii. Existing ISIN - Issuer Name (long) is updated, Issuer Name (short) is updated, Issue Description is updated, CFI Code is updated, Country of Issuer is updated, Debt\Equity is updated, CIQ Security SubTypeID is updated, Derived VALOR is changed due to Telekurs linking local identifiers to a different VALOR, ISIN Type and Status set to NR, Updated Comments or Cross References. e. ANNA ISIN Testing & Sampling: - i. Testing for the ANNA ISIN auto-linking has been done to validate the proposed structure and the related concerns and suggestions have been raised. The category of checks can be classified as in the diagram below: 1. Security Subtype Related: Exclusion of derivative Securities. 2. Issuer Name/Issue description Related: Issuer Name containing Special characters, Test records, Issuer name = Issue description, Issuer name = Currency. 3. Derived NSN related: Length of the derived SEDOL/CUSIP, Incorrect SEDOLs derived from the ISIN, NSNs not derived from the ISIN. 4. Ingestion/Application Related Related: Audit Comments - Do not contain the 'Security ID'. f. The data was tested both manually and through QC checks. Below is a brief review of the types of checks and concerns raised and the resolution for the same. g. Security Subtype Related: - i. Structured Products/Hybrid Securities: Based on the publicly available data from regulating/trade authorities, issuer factsheets and so forth, financial instruments can be classified into three major categories; Traditional Debt, Traditional Derivatives and Structured Products (SPs). ii. Structured products are synthesized to meet specific investment objectives – ones that cannot be met from the standardized financial instruments available in the markets. iii. Structured products can be used as an alternative to a direct investment; as part of the asset allocation process is to reduce risk exposure of a portfolio; or to utilize the current market trend. iv. A bond product or another element of capital safeguard. An alpha generator - which is any financial instrument (i.e., a stock, Group of shares, Index, currency, etc.) as a derivative. v. Private Funds – ABS/MBS: It was observed that researchers were linking such ABS/MBS securities to the main record which is a wrong practice. Any ABS/MBS security that we receive in the application without the series will be skipped going forth. These can be retrieved later and linked in case more information is available from other vendors or from outside sources. Such securities will be skipped with the below skip reason and comment: 1. Skip Reason: Others 2. Skip Comments: Fund Series not clear. h. Issuer Name/Issue description Related: - i. Issuer Name containing Special characters: The securities with issuer name as a special character should be excluded from auto/manual linking. However, while testing, we came across Issuer name = “?”. 1. Resolution: This issue was raised and should be fixed. ii. Issuer name and Issuer Description containing ‘test’: We came a few cases where both the “Issuer Name” and the “Issuer Description” are “Test”.  1. Resolution: This issue was raised. For other issue description cases containing “test”, it was suggested that we can include “test test” in the logic to exclude such cases. This is because the issuer names might potentially be included in issue Description and some companies might contain the word test in their names. If test cases end up in manual linking queue, then researchers should be able to identify them and skip the same iii. Issuer name = Issue description: These refer to the cases where the issuer name is also populated in the issue description column. 1. Resolution: This should not affect the auto-linking process as the security description is not overwritten. For the manual linking process, we have suggested that wherever the security description is not available, it should be populated as “NULL”. iv. Issuer name = Currency: While manually validating the data, we came across cases where the issuer name was a “Currency” name. We are not sure if this is an issue case. 1. Resolution: It seems that ANNA is getting these as it is from NNAs. As we can see, the data is not perfect and NNAs don’t have checks in place to avoid populating bad data. We can just hope an incremental file will update the names accordingly. 10. Derived NSN related: - a. Length of the derived SEDOL/CUSIP: We came across cases where the length of the derived SEDOL was 7 and the length of the derived CUSIP 9. Here it seems, since we are truncating all the leading zeros, this is further leading to improper SEDOLs/CUSIPs at our end. i. Resolution: This issue was raised and should be fixed. b. Incorrect SEDOLs derived from the ISIN: Here it seems, since we are truncating all the leading zeros, this lead to generation of wrong SEDOLs. i. Resolution: It was suggested that the zeroes should be dropped only till the 4th place. The code for the same should be fixed and needs to be revalidated once fixed. c. SEDOLs not derived for ISINs starting with 'GB' or 'IR': We found few cases where logic is not deriving the SEDOLS for ISINs starting with 'GB' or 'IR'. i. Resolution: It was found that the SEDOL derived from these ISINs were improper, i.e. the length of the SEDOL7. There were no leading zeroes to be dropped to create 7 digits. d. CUSIP not derived for ISINs starting with 'US' or 'CA': No such issue case was observed. e. VALORS not derived for ISINs starting with 'CH': No such issue case was observed. Ingestion Related: - f. Audit Comments: It was observed that the audit created for auto-linking of ANNA ISINs do not mention the ‘Security ID’ to which the symbol was auto-linked, in the audit comments. Ideally, we should have the SecurityID along with CompanyID available in the audit comments. i. Resolution: It was suggested the audit comments should be kept the same as for other cross ref vendors like CGS and include the ‘Security ID’ also. This was noted and should be fixed. g. The ANNA application was tested on TEST environment. No major bugs or enhancements were observed.  11. Creating New Company ID: - a. Definition: “Company ID” is an auto-generated unique identifier in S&P GMI database representing every unique entity. We should have only one identifier for each entity. i. For example - Microsoft Corp.’s company ID in S&P GMI is 21835 no other entity can have company ID 21835 in the database. The term Company ID has been used for companies, funds, indices, and many other company types and does not necessarily means it is a company. b. In most of the cases, the incoming IDC Issuer code in Security Linking Application is already linked to an existing S&P GMI company record. However, in some cases either we need to “Move” the issuer code to another record or create a “New” entity to maintain the current data structure. As a general practice, if we get a new CUSIP6 in the3 linking application, we do create new record for each CUSIP6. Below are the situations, where we create a separate entity even if the CUSIP 6 is same: i. Index Records ii. ETFs/Mutual Funds iii. ABS/MBS 12. Creating New Security ID: - a. Definition: Like Company ID, security ID is an auto-generated unique ID representing every unique security in the database. However, one company can have multiple security IDs. Security ID is created for almost every new ISIN that is being assigned to a new security. We do not create new security ID in case there is either no change in the security properties or it is the post-event ISIN or created due to a name change (CUSIP change) or a dual listing for the same security. b. Security IDs are stored in symbol table with the respective Company ID and are visible on company symbol page. It also stores information like Security Subtype, Security Name, and Security Type ID etc in the table. c. Situations Where New Security ID is Created: i. Confirm from IDC website if the incoming security is new one, the researcher can confirm this by looking at the issue date or figure out if the new Security ID is created as a result of some change in the existing security ID. We can identify this by looking at the “Cross-reference” section of the security on IDC. ii. Once we are sure this is either a new security and there is no other security ID in the database for the same security, we can create a “New Security ID”  13. Creating New Trading Item ID: - a. Definition: TradingItem ID is a unique identifier with respect to S&P GMI database that stores the trading related information for securities/instruments mentioned in the company’s Security ID section. TradingItem IDs are created based on different exchanges. Hence, one security trading on different exchanges will have different trading items although they might have the same security ID. b. Following Action type should be taken: i. If New Instrument Issued then we will add Add New TradingItem ID and will not Add to Existing TradingItem ID. ii. If Company Name Change then we will not Add New TradingItem ID and will Add to Existing TradingItem ID. iii. If same Security in a different exchange then we will add Add New TradingItem ID and will not Add to Existing TradingItem ID. 14. Corporate Action Section: - a. In order to incorporate the corporate action of various issuers like name changes, mergers, reorganizations, acquisitions and withdrawn CUSIPs, among many others, which are captured by CGS, a few enhancements have been made to the linking application. b. Each issuer that exists in the linking queue may not have a corporate action associated with it. Alternatively, an incoming issuer may have multiple corporate actions associated with them. Therefore, one data column is displayed in the main grid view of the Incoming Issuer Information that allows the researchers to know that a corporate action took place. The additional information, such as symbol start dates and end dates, can be available in the right monitor Corporate Action module display. c. Changes in the User Interface of the application: i. Primary Screen - Main Issuer Grid View: An issuer can be involved in more than one Corporate Action. So, Corporate Actions can have many to one relationship. To display all the information in the main issuer grid, we use the following logic: 1. If there is only one Corporate Action for a CUSIP6: Display “Corporate Action” in main issuer grid, or Display “Announce Date” in main issuer grid. 2. If there is more than one corporate action for a CUSIP6: Display the most recent corporate action in main issuer grid under “Corporate Action” column, Display the date associated with this corporate action in the “Effective Date” column. d. We display two columns in the main issuer grid so users are aware that a corporate action was applied to a particular issuer. All further details of the CA will be displayed in the right monitor Corporate Action grid. e. The following data points will be displayed in the main issuer grid as retrieved from the cross-reference data received from CGS. i. Corporate Action Type: Corporate action type as received from CGS. 1. The column is labeled as “Corporate Action.” 2. This is a new field displayed in a column in the main incoming issuer information grid under the company level information. 3. Users can have the ability to copy this text after selecting it using the “Ctrl + C” functionality. ii. Event Announce Date: The date upon which the action is effective from. 1. The column is labeled as “Announce Date”. 2. This column is displayed on the right side of the Corporate action on the main incoming issuer information grid. 3. The date format is be YYYY-MM-DD.  iii. Corporate Actions Grid View: In order to view ‘all’ corporate actions in a clean format, we display full details in a grid format in the right monitor module titled “Corporate Actions”. Generic logic for all data fields in the grid: 1. All date fields should display dates in MM-DD-YYYY format. 2. Users should have the ability to copy all text fields after selecting and using the “Ctrl + c” functionality. f. The following columns are available in the Corporate Action (CA) Grid on the right monitor in the following order: i. Corporate Action Type: This column displays the type of corporate action, being changes, mergers, reorganizations, acquisitions and withdrawn CUSIPs, among many others. ii. Corporate Action Status: This column displays the status of the corporate action. iii. Event Announce Date: This represents the date when the CA was announced. g. Old Issuer Description (child): This field represents the name of the former issuer of the security. i. This Data will be shown in non-CAPS format. Only first letter separated by each space, hyphen. Other non-alpha characters such as percent (%), ampersand (&), backslash (/) or numbers (0-9) are to be ignored. ii. Old Symbol Type Value (child): This is the symbol value which has undergone CA. iii. Old Symbol Status (child): this represents the status of the old symbol. h. New Symbol Type Value (parent): This is the new symbol value. i. New Symbol Status (parent): this represents the status of the new symbol. j. New Issuer Description (parent): i. This field represents the name of the latter issuer with which the security is now associated.This Data will be shown in non-CAPS format. ii. Only first letter separated by each space, hyphen. Other non-alpha characters such as percent (%), ampersand (&), backslash (/) or numbers (0-9) are to be ignored. k. Event Comments: Field shows the comments with respect to the type of corporate action. l. Existing Counts: i. Gives the count of matching same symbol value of CC6 (both old & new symbol type value) present in S&P GMI Database from other vendors. ii. If the count is non – zero, clicking on load button will load the matching company records.