1. What do industry participants need for unique security identification (at what level of granularity and for which type of product) to perform their function?

ASB communications should fall under the 15022 catalogue with all enclosed fields defined in accordance with its data dictionary.

i. Issuer Properties – for example the [Official Company Name] (as locally registered).
ii. General Attributes (of the Security Type) – for example the [Exercise Style].
iii. Terms & Conditions (of the Security) – for example the [Maturity Date].

ii) is the domain of 10962. The provision of CFI Codes should be deemed mandatory. The constituent arguments are (on the whole) required for unambiguous identification (for example - "ESVUFR": "Fully Paid, Ordinary Share with Voting Rights, Held in Bearer Form – No Ownership Restrictions"). This change reduces dependency upon the freeform [Issue Description]; enabling improved QA at the NNA side and expediting vendor processing. At the same time, various established (GIAM-2) fields would become redundant, for example the [Debt/Equity Code], [Bearer/Registered Flag] & [Syndication Code].

The CFI format would then govern requirements for Terms & Conditions – adding context. So, for example, where CFI = "DBFUGB" (a fixed rate bond), [Interest Rate] is compulsory, but where CFI = "ESVUFR" (a stock) it’s irrelevant.

The standard itself is weakest in areas where ISIN assignment is limited (e.g. OTC derivatives) – (10962) would need to be developed and enforced as the target universe for numbering expands. In the same vein, iii) lacks a few properties (e.g. [Strike Price] & [Conversion Ratio]).

2. Are these data elements needed for identification of the attributes of the security or attributes of an event/transaction?

Bridge uses ISINs heavily in the collection and distribution of various services, including pricing, news and research – it is an immediate concern to improve width/quality in securities identification (6166) via the ASB project. In general we have adopted some (relevant) standards (for example 4217 and 3166), while ignoring others (where they are deficient, for example we internally allocates exchange codes). As a result, reports (or query expressions) characterizing events are currently assembled using a mish-mash of ISO terms and Bridge proprietary arguments. So, for example, [ISIN] = DE0005190003 extracts multiple pricing for BMW ordinary share… but you might add [Currency] = CHF (and target SWX) or [Exchange] = XTTP (and isolate TradePoint). The identification of entities like registrars & settlement/clearing organizations seems to be a "specific application of 9362", parallel to 10383 for exchanges and regulated markets.

3. How do various segments of the industry currently get the information they need to fulfill their security identification functions?