Owing to previously accepted changes, there are a number of editorial tweaks that are necessary. This item covers those.

Final Editorial Tweaks

The final editorial tweaks are as follows:
1. Section 8.2.1.1: add sentence: "In every instance, the metadata is specified in the information About files rather than in each ontology file." to the end of the first paragraph.
2. Table 8-1: a) remove "s" from "Identifiers" in sm:specificationTitle b)change "Industry" to "Instrument", and c) add "or Financial Instrument Global Identifier (FIGI) Specification Version 1.0"
3. Table 8-1: add "or http://www.omg.org/spec/FIGI/1.0/" to the value corresponding to sm:specificationURL.
4. Table 8-1: change value of sm:thisVersion from "RFC" to "1.0"
5. Table 8-1: from the value corresponding to sm:specificationVersionURL a) remove "RFC/" and b) add "or http://www.omg.org/spec/FIGI/1.0
6. Table 8-1: change value corresponding to sm:specificationVersionStatus from "Request For Comments (RFC)" to "Formal Specification".
7. Table 8-1: for the value corresponding to skos:historyNote a) remove the "." at the end of the string and b) add ", however. Users who wish to use Pellet due to other advantages should comment out the restriction on the hasUniqueTextIdentifier property in the definition of FinancialInstrumentIdentifier.".
8. Table 8-1: add row for value "sm:contributor" with the value "Adaptive, Inc., Thematix Partners LLC".
9. Table 8-2: change ".../20140201/..." to ".../2015/0501/..." in owl:versionIRI.
10. Section 8.2.3: change:
a) "exchange code (FI.2.9)" to "exchange code (FI.2.7)"
b) "pricing source (FI.2.8)" to "pricing source (FI.2.6)"
c) "security type (FI.2.7)" to "security type (FI.2.5)"
11. Table 8-4: change definition for ExchangeCode from "Code for the exchange on which the security trades." to "a code for the exchange on which the security trades".
12. Table 8-4: change definition for FinancialInstrumentIdentifier from "A financial instrument identifier is an identifier that identifies (that is, labels the identity of) a financial instrument with a unique, persistent, semantically meaningless ID. The abbreviation ID often refers to identity, identification (the process of identifying), or an identifier (that is, an instance of identification)." to "A financial instrument identifier is an identifier that identifies (that is, labels the identity of) a financial instrument with a unique, persistent, semantically meaningless ID. The abbreviation 'ID' often refers to identity, identification (the process of identifying), or an identifier (that is, an instance of identification). A financial instrument identifier consists of a 12 digit alpha-numeric, randomly generated ID covering active and inactive securities. In total there will be more than 852 billion potential combinations available. The first 3 characters begin with 'xxG'; where 'x' can be any upper-case consonant or 'Y' (with certain restrictions), positions 4-11 are alpha-numeric (excluding vowels) and the last digit is a check digit, which is calculated based on a variation of the Modulus 10 Double Add Double Formula."
13. Table 8-4: change definition for FinancialInstrumentName from "The English language name of the company or the financial instrument, e.g., a particular fund name, and sometimes include a brief description of the security or a differentiating feature, e.g., the issuance date. The name of an instrument may change in conjunction with corporate actions." to "the English language name of the company or the financial instrument, e.g., a particular fund name. It sometimes includes a brief description of the security or a differentiating feature, e.g., the issuance date. The name of an instrument may change in conjunction with corporate actions".
14. Table 8-4: Change explanation of Label FI2.2 from "intersection of F.2.3, F.2.4, F.2.5, F.2.6, F.2.7., F.2.8, and F.2.9" to "intersection of F.2.3, F.2.4, F.2.5, F.2.6, and F.2.7"

The new "about" files eliminate the need for redundant metadata in the headers of the three content ontologies that comprise the FIGI specification. This redundant metadata, and redundant (and erroneous) default namespace should be removed from the ontology "header" material in each of the three ontologies, following the strategy applied for the FIBO family of ontologies.

This issue affects machine-readable files only, and has no impact on the specification text.

Revise metadata and create "about" files.

The new "about" files eliminate the need for redundant metadata in the headers of the three content ontologies that comprise the FIGI specification. This redundant metadata, and redundant (and erroneous) default namespace should be removed from the ontology "header" material in each of the three ontologies, following the strategy applied for the FIBO family of ontologies.

This issue affects machine-readable files only, and has no impact on the specification text.

The current strategy for development of metadata for ontologies, based on evolutionary work on the FIBO specifications, is to move some of that metadata to "about" files, that describe the specification and specification version, as well as modules (if applicable), to limit the size of the headers in the ontologies themselves and eliminate duplication where possible.

This issue affects the machine readable files primarily, although the URIs for the about files should be provided in the FTF report inventory, and potentially on the cover page of the specification itself. The about files are provided as RDF/XML serialized OWL only at this time, not as ODM XMI, UML XMI or in ancillary model files.

About files are needed for FIGI, similar to those created for the FIBO specifications

The resolution of this issue requires development of two "about" files, one for the FIGI specification and one for the 1.0 version of that specification. It affects machine-readable files only, no specification text changes are required.

The relevant RDF/XML serialized OWL files are attached.

Ghana uses GHG as a prefix for fixed income ISINs. Add "GH" to the exclusion list in the spec and in the code.

Add both GH and KY as excluded prefixes

This affects both the specification and the machine readable files.

Detailed:
Specification:
1. In section 6.1.2, add "GH" and "KY" to the list of excluded consonant combinations on page 20.
2. In section 8.2.4, add "GH" and "KY" to the list of excluded consonant combinations in both the regex expression and in the subsequent explanation of the regex expression.

machine readables:
in FinancialInstrumentIdentifier.rdf, change regex expression associated with Financial Instrument Global Identifiers to reflect the regex expression above.

The description of the check digit algorithm in section 6.1.2 says "number" in three places, where it should more correctly say "integer":

"If the total obtained when summing up the digits is a number ending in zero, then the check digit is zero." (p18)

"40 the next highest number ending in zero" (p18)

"80 the next highest number ending in zero" (p19)

"Number" should be "integer" in three places.

1. on p. 20, replace "a number" in:

If the total obtained when summing up the digits is a number ending in zero, then the check digit is zero.

with "an integer".

2. on page 21, replace "number" in both instances of:

the next highest number ending in zero

with "integer".

All the figures in dtc/14-07-01 are bitmaps, and fuzzy at high magnifications. In addition, Figure 6.1 and Figure C.1 are JPEGs, so have compression artefacts that introduce variations in what should be blocks of solid colour (again, visiible at high magnification).

The problem is especially severe for Figure 8.3 (Identifiers), where much of the text in the diagram is unreadable at any magnification. For this reason, I suggest the issue is "Major".

All these bitmap diagrams should be replaced with vector diagrams, preferably in a standard format like Vector SVG or Vector PDF. Non-standard vector formats like Vecor WMF or Vector EMF would also be acceptable.

Bitmap/JPEG graphics are fuzzy and/or unreadable

Replace jpg-based images in specification with png-based images so as to provide images that can be magnified without loss of resolution.

In table 8.5 the definition of GlobalIdentifier begins "A 12 digit alpha-numeric, randomly generated ID covering active and inactive securities. In total there will be more than 852 billion potential combinations available. The first 3 characters begin with ‘BBG’;"

Clearly, that word "digit" should be "character".

"digit" should be "character" in Table 8.5

Change "digit" in Table 8.5 in the following sentence:

A 12 digit alpha-numeric, randomly generated ID covering active and inactive securities.

to "character".

Raised by Tom Rutt:

6.1.2 Character 12: the final paragraph states the the algorithm has been adjusted to result in a different checksum value from the "standard" algorithm. Where is this standard algorithm specified? Is it annex C of ISO 6166? If so the differences are not explained in the FIGI spec. The 6166 algorithm doubles the alternating digits starting from the rightmost, this seems to be the same algorithm as used by FIGI.

Detail checksum algorithm

Clarify the origin and differentiation of the checksum algorithm in contrast to other established algorithms. This requires the following changes to section 6.1.2 (at the very end of the section):
1. replace "algorith" with "algorithm" in the first sentence of the last paragraph (typo correction, but in context).
2. add the sentence "A familiar instantiation of this algorithm is specified in ISO 6166 and is used in generating the check digit for ISIN identifiers." as the second sentence of the last paragraph.
3. add " In particular, rather than multiplying the integer value corresponding to every second character starting with the second character in the identifier by two, as is the case with this specification, the ISIN specification begins with the first character. The result is that the check digit is different in over 90% of the logically possible strings ." as a new last sentence of the last paragraph.

Raised by Tom Rutt:

6.1.2 Characters 4-11: The table for checksum, and the conformance excludes the characters A, E, I, O, U . This text should be explicit that the values exclude the use of these vowels. It should have an explicit list of consonants and the letter Y.

String: explicit exclusion of vowels

Rather than merely stating that all consonants are permitted in section 6.1.2, list the entire set of permissible characters as follows:

"o The exact list of permissible letters is B,C, D, F, G, H, J, K, L, M, N, P, Q, R, S, T, V, W, X, Y, Z "

Raised by Tom Rutt:

Identifier: The definition does not indicate that the identifier maps to any specific entity. This definition seems to allow too many strings to be called identifiers. For example "An identifier is a name that identifies (that is, labels the identity of) either a unique object or a unique class of objects, where the "object" or class may be an idea, physical [countable] object (or class thereof), or physical [noncountable] substance (or class thereof)." is fromhttp://en.wikipedia.org/wiki/Identifier adds the concept if identification for the identifier.

Identifier Definition

at the beginning of 4.3 add the following text:

In general terms, an Identifier can be understood as follows:
An identifier is a name that identifies (that is, labels the identity of) either a unique object or a unique class of objects, where the "object" or class may be an idea, physical [countable] object (or class thereof), or physical [noncountable] substance (or class thereof). The abbreviation ID often refers to identity, identification (the process of identifying), or an identifier (that is, an instance of identification). An identifier may be a word, number, letter, symbol, or any combination of those.
The words, numbers, letters, or symbols may follow an encoding system (wherein letters, digits, words, or symbols stand for(represent) ideas or longer names) or they may simply be arbitrary. When an identifier follows an encoding system, it is often referred to as a code or ID code. Identifiers that do not follow any encoding scheme are often said to be arbitrary IDs; they are arbitrarily assigned and have no greater meaning. (Sometimes identifiers are called "codes" even when they are actually arbitrary, whether because the speaker believes that they have deeper meaning or simply because he is speaking casually and imprecisely.)

The above definition is general and applies to a range of items in this specification including Financial Instrument Names and Financial Instrument Identifiers. A more precise definition is, however, called for with respect to Financial Instrument Global Identifiers

followed by adding the following phrase after "identifier":
"when applied to the FIGI" to the following sentence in the next paragraph:
"For the purposes of this specification an identifier is understood as:"

Raised by Pete Rivett:

The definitions of the three types of identifiers does not clearly outline that the Composite Global Identifier is, in most cases, a national grouping of the identifiers used to correspond to the various exchanges in the given country. Both this definition and the corresponding definitions of the identifiers need to be revised to reflect this.

Clarificaiton of different types of identifiers

This item affects both the specification and the machine readable files. The required changes are as follows:

Specification:
1. In section 6.1.1 add the following sentence to the first bullet:
"The granularity of this identifier is found in that which it identifies. In particular, the most basic FIGI identifies a financial instrument, where applicable, at the trading venue level. That is, where applicable, the Global Identifier identifies a Financial Instrument within the context of an exchange venue ."
2. In section 6.1.1 add the following sentence to the second bullet:
"The purpose of this “version” of the identifier is to group individual identifiers, as per above, into groupings at the country level. This is not, however, merely a grouping of financial instruments. Rather, a Composite Global Identifier identifies a unique financial instrument within the context of a country."
3. In section 6.1.1 add the following sentence to the third bullet:
"Similar to a Composite Global Identifier, the Share Class Global Identifier identifies a financial instrument within the context of the global perspective, e.g., aapl common stock ."

Machine Readables:
update the definitions in the annotations for CompostieGlobalIdentifier, GlobalIdentifier, and ShareClassGlobalIdentifier to reflect the definitions in the specification.

Raised by Tom Rutt:

1 allocation of CP and prefixes: How will the OMG make its derisions to accept a new CP? Any such work would require OMG staff funding or TF volunteer efforts. How would disputes over rejected requests to become a CP be resolved?

CP Designation Process

Add a section to Appendeix B, section 3 as that specifies the process by which Certified Providers (CP) are designated:

Certified Providers are self-identified and nominated (self-nomination included) as potential Certified Providers to both the OMG Finance Domain Task Force and the RA. A committee consisting of at least one representative from the RA and at least one OMG member organization that is not the RA (CP evaluation committee) will evaluate the nomination of the CP according to the following criteria:
1. Does the potential CP have the necessary infrastructure in place or in a funded, scheduled infrastructure project that is sufficient to:
a. Scalably store and maintain the repository necessary to provide FIGIs?
b. Scalably, and with sufficient redundancy, provide only access to the FIGIs it creates?
c. Provide a sufficiently robust API interface to support the registration of new FIGIs and related items?
2. Is the potential CP committed to providing the above services in perpetuity with no restrictions on redistribution and absolutely no charge to any potential user or organization?
The CP evaluation committee will issue their response to the application within six (6) months/two OMG meetings of the completed application being presented to the Finance Domain Task Force at an OMG meeting. The response will provide appropriate documentation explaining why the decision was made as it was if the outcome is not positive. In the event of a negative outcome, the potential CP is free to reapply for CP status anytime in the future through the above process.

Raised by Tom Rutt:

Request service data points: how will additional data points be specified? Will they require subsequent versions of the FIGI spec?

Additional Data Points

There is reference to the possible need for additional data points being incorporated into FIGI moving forward. To explicate this a little, add the following text to Appendix B, section 2 immediately following the sentence "Owing to the diverse nature of financial instruments, it is expected that additional data points will be required, particularly as the coverage provided by FIGI expands, to provide decisive identification of financial instruments. ":
". (If such is viewed as necessary by either the Registration Authority or by a Certtified Provider (see B.3), a revision of this specification will be required so as to fully document the additional classes or vocabularies.) "

Raised by Tom Rutt:

7.1 Controlled vocabularies: How are the changes to the FIGI vocabularies to be specified over time? Will changes require amendments or new versions of the OMG FIGI specification over time?

Controlled vocabulary changes

Changes in controlled vocabularies are expected as part of the normal process and will be addressed through the work of revision task forces as needed. The specifics are spelled out in the sections referencing Security Types and Pricing Sources.

Raised by Tom Rutt:

6.2.4 Financial Instrument Name: if the name changes, and the FIGI identifier remains the same, how is the sequence of subsequent names managed and recorded by the RA?

Historical Names

One of the differentiating features of the FIGI is that it does not change through corporate actions. Since corporate actions can, and frequently do, include name changes, the request here is to clarify if and how FIGI addresses historical names. To address this, Section 6.2.4 shall have a paragraph added as follows:

"As it is the identifier that serves as the source of persistence through change, any changes in names are simply that, changes in names. The FIGI itself, which does not change, simply has the value of the Financial Instrument Name class change for a particular individual. Historical names are not part of the FIGI standard, though there is nothing precluding any organization from capturing and storing historical FIGI data for their own needs including, but not limited to, the Financial Instrument Name ."

Raised by Richard Beatch:

The list of pricing sources in use in support of FIGI has grown since the initial specification was advanced. This list and the corresponding definitions needs to be updated.

Update of Pricing Sources

As noted in the specification, the list of individuals that represent Pricing Sources for Financial Instruments is subject to grow over time. As the Beta version of this specification and the corresponding machine readables were generated some time ago, it is necessary to update the list of Pricing Sources in the machine readable files to reflect the latest set of 1032 individuals.

Raised by Richard Beatch:

The definitions of the security types needs to be reviewed and updated.

Security Type Definitions Review

As part of the updating process for SecurityTypes.rdf, a review of the definitions used in the ontology is necessary. Two items need to occur:
1. determine that every Security Type has a definition.
2. determine that each definition is unique to and descriptive of the Security Type in question.

Raised by Richard Beatch:

The list of security types in use in support of FIGI has grown since the initial specification was advanced. This list and the corresponding definitions needs to be updated.

Update of Security Types

As noted in the specification, the list of individuals that represent Security Types for Financial Instruments is subject to grow over time. As the Beta version of this specification and the corresponding machine readables were generated some time ago, it is necessary to update the list of Security Types in the machine readable files to reflect the latest set of 401 individuals.

Raised by Tom Rutt:

Financial Instrument. The definitions from a google search include the concept of a representation of value: from http://www.investopedia.com/terms/f/financialinstrument.asp "A real or virtual document representing a legal agreement involving some sort of monetary value. " From http://en.wikipedia.org/wiki/Financial_instrument "A financial instrument is a tradable asset of any kind; either cash, evidence of an ownership interest in an entity, or a contractual right to receive or deliver cash or another financial instrument." The definition in FIGI does not indicate the instrument as a representation. Is the cash itself a financial instrument (i.e, a 100 dollar bill)?

Financial Instrument Definition

Request was for clarification of the definition used for Financial Instrument, in particular, clarification around whether a bill, say a $50.00 bill in US currency, counts as a Financial Instrument.

This issue is being closed with no change as the definition of Financial Instrument that is being used is a duplication of the well-established OMG-standard definition of Financial Instrument used in FIBO.

FIGI, while a stand-alone standard, is seemingly related to other standards in the Finance space. In particular, ISO 6166 (ISIN), ISO 10962 (CFI), and ISO 20022 (UNIFI) seem much more closely related to FIGI than others. This item calls for some explicit treatment of if and how FIGI relates to these standards and any restrictions in place regarding possible mappings to those standards.

How FIGI relates to other standards in the space

Add an appendix that details how FIGI relates to key standards in the financial space. The expectation is that as existing standards evolve or new standards are viewed to be relevant, this appendix will expand though the revision process. The initial appendix shall read:

Appendix D: Other Standards in the Financial Space

(Informative)
While the Financial Instrument Global Identifier specification is intended as a stand-alone specification which is focused on the integrity of unique, persistent identification of Financial Instruments, the fact remains that there are standards in place at any given time that speak to Financial Instruments and may, therefore, intersect with or overlap with the FIGI specification. The purpose of this appendix is to provide some acknowledgement of those facts and to proactively counter any confusion that might arise. To that end, this appendix will consist of a listing of the relevant standards and a brief treatment of the relationship between those standards and FIGI. Again, as there are constantly emerging and evolving standards, it is expected that this appendix will change over time as part of the revision process.
D1. ISO 6166 (ISIN)
The ISIN standard overlaps with the FIGI standard in that it, too, seeks to assign unique identifiers to Financial Instruments. It differs, however, from the FIGI in a number of critical ways which will be explicated below. Because of the overlap and the differentiation, FIGI and ISIN can be viewed as complimentary, rather than competing, standards.

The ISIN and the FIGI differ in three broad ways:
1. Scope: The FIGI provides, both in practice and in future implementation, a much broader scope than does ISIN. In particular, FIGI identifies not only securities, but, potentially, all financial instruments. The reason that the scope is so much broader is a function of purpose: the ISIN is focused on serving as a reference for a fungible instrument at the initial issuance level, which serves a proper and needed function in and of itself. FIGI, in contrast, while capable of serving in that capacity, is focused on providing a consistent and unique data point that serves to identify financial instruments and the different contexts they exist in throughout their lifecyle, so as to enable robust and comprehensive data management and, from that, compliance.
2. Granularity: The ISIN provides a single identifier at the single issued level for a fungible instrument. FIGI, in contrast, provides not only that in the form of the Share Class Global Identifier (hence the overalp), but also at the country level through the Composite Global Identifier, and, where applicable, at the trading venue level as well.
3. Persistence: Corporate actions, such as name changes, acquisitions, corporate relocations, and so on, can result in the need for an ISIN to change. This is not intended as part of the ISO 6166 specification, but is a function of the distributed delivery system for ISINs. Such is not the case with FIGIs in that the characters present in the FIGI string are, with the exception of the check digit, entirely meaningless. As such, there is no hidden reference to the currency, market or country location, or company name present in the identifier—a condition which is consistently present in ISINs.
Organizations that are licensed to use ISIN are free to map between FIGI and ISIN at the Global share class level. Indeed, this is a common practice. Owing, however, to licensing restrictions on ISIN (though not on FIGI), such mappings cannot be freely redistributed.
D2. ISO 10962 (CFI)
The Classification of Financial Instruments (CFI) code is a six character string that serves to classify financial instruments both at a high-level, e.g, debt instruments vs equities, and through their attributes, e.g., fully paid vs partly paid. In a sense, this can be viewed as related to the Security Type vocabulary that is part of the FIGI specification. The mechanism by which the distinctions are made, beyond the top levels, however are very different and so these should be viewed as complimentary classification systems.

The mechanism by which CFI distinguishes between Financial Instruments at the granular level is largely a function of the legal distinctions that govern the acquisition and disposition of such instruments. For example, Future Contracts will be differentiated by whether the terms are standardized or non-standardized. In contrast, the different security types that inform FIGI reflect the manner(s) in which a financial institution would classify their positions for multiple operational and regulatory reporting purposes, and may be influenced by jurisdiction.
As with other standards, it is possible, indeed common, for organizations to map their holdings to both the FIGI listing of Security Types and to CFI. Distribution of the CFI mapping is not, however, part of the FIGI specification, nor it is required as part of FIGI compliance within the standard (though it is not precluded).
D.3 ISO 20022 (UNIFI)
ISO 20022 is a messaging standard what specifies the structure of a metadata repository containing descriptions of messages and business processes. The relationship between ISO 20022 and FIGI is potentially an intersecting, rather than overlapping, relationship. In particular, given that the identifiers associated with FIGI are, potentially, items that would be embedded in messages used within the financial sector, there is the potential that FIGI would be formally recognized as having a place within ISO 20022. Strictly speaking, however, ISO 20022 and FIGI are entirely independent of one another as they seek to do very different things.
D.4 ISO 10383 (MIC)
The Market Identifier Code (MIC) provides a universal method of identifying exchanges, trading platforms, and regulated or non-regulated markets as sources of prices and related information for Financial Instruments. This function overlaps with parts of FIGI, in particular, the Pricing Source. As with ISIN, there are key differences.
1. Scope: The MIC provides identification of places where securities can be, broadly speaking, bought and sold. As such, it only applies to tradable securities that are exchanged at a venue (broadly understood). The list of pricing sources present in FIGI goes far beyond this to support Financial Instruments that are not exchanged at a venue. In fact, FIGI can support Financial Instruments that are not tradable at all, e.g., an individual person’s home mortgage contract (not currently supported, but under consideration).
2. Embeddedness: The MIC code is a stand-alone code that identifies a Market. As such, it serves a different purpose than does the Pricing Source attribute of FIGI. The Pricing Source attribute of FIGI serves as a differentiator of otherwise identical financial instruments and that differentiation is embedded into the Financial Instrument Global Identifier. In the case of the MIC, it can be used in concert with the ISIN to deliver this to some level, but it is not fully embedded into the identifier’s meta data.
As is the case with other standards, there is nothing precluding any organization from mapping FIGIs to MIC codes. It is not, however, part of the formal requirements of the FIGI.

Remove Market Sector from the specification: both the spec and the machine readables.

remove Market Sector

This change affects both the specification and the machine readable files in that all references to Market Sector or any of its child nodes are to be eliminated. The specific tasks are:

In specification:
1. Table 2.1, removal of:
Market Sector Each global identifier will have at least one Market Sector associated with it. Section 6.2.3
2. Removal of section 6.2.3:
6.2.3 Market Sector
Financial instruments exist across a range of types. These types are captured in the FIBO ontology as types of contracts (FIBO’s general category corresponding to Financial Instrument) and parallel the breakdown we present below. Beyond the FIBO breakdown, which is far more granular than is typically reflected in regular industry distinctions, we present a fairly basic breakdown of the market sectors that reflect accepted industry distinctions. It is important to note that while these sectors do parallel specific types of financial instruments as represented in FIBO, they are not types of financial instruments strictly speaking. Rather, they are sectors within the financial markets that represent marketing distinctions.
The definitions of each market sector are presented below.
6.2.3.1 Commodity Market Sector
A commodity is an agriculture product, mineral, or other tangible asset that investors trade on a commodity exchange or Spot Market on a cash or future basis. The Commodity Market Sector is the market sector that supports the sale and exchange of commodities.
6.2.3.2 Corporate Bond Market Sector
A corporate bond is a debt security issued by a corporation, as opposed to those issued by a government or municipality. (Source: FIBO) The Corporate Bond Market Sector is the market sector that supports the sale and exchange of corporate bonds. Within the ontology, the Corporate Bond Sector is a sibling to Government Bond Sector and Municipal Bond Sector under a parent class of Bond Market Sector and with a rule specifying that the three child classes are disjoint.
6.2.3.3 Currency Market Sector
A currency is a generally accepted form of money, including coins and paper notes, which is issued by a government and circulated within an economy. Used as a medium of exchange for goods and services, currency is the basis for trade. The Currency Market Sector is the market sector that supports the sale and exchange of currencies.
6.2.3.4 Equity Market Sector
An Equity is:
1. A stock or any other security representing an ownership interest.
2. On a company's balance sheet, the amount of the funds contributed by the owners (the stockholders) plus the retained earnings (or losses). Also referred to as "shareholders' equity".
3. In the context of margin trading, the value of securities in a margin account minus what has been borrowed from the brokerage.
4. In the context of real estate, the difference between the current market value of the property and the amount the owner still owes on the mortgage. It is the amount that the owner would receive after selling a property and paying off the mortgage
5. In terms of investment strategies, equity (stocks) is one of the principal asset classes. The other two are fixed-income (bonds) and cash/cash-equivalents. These are used in asset allocation planning to structure a desired risk and return profile for an investor's portfolio.
The Equity Market Sector is the market sector that supports the sale and exchange of equities.
6.2.3.5 Government Bond Market Sector
A Government Bond is a government debt obligation (local or national) backed by the credit and taxing power of a country with very little risk of default. The Government Bond Market Sector is the market sector that supports the sale and exchange of government bonds. Within the ontology, the Government Bond Sector is a sibling to Corporate Bond Sector and Municipal Bond Sector under a parent class of Bond Market Sector and with a rule specifying that the three child classes are disjoint.
6.2.3.6 Index Fund Market Sector
An Index is a compilation of statistical data that tracks changes in the economy or in financial markets. (Source: Bloomberg LP) ) The Index Fund Market Sector is the market sector that supports the sale and exchange of index funds.
6.2.3.7 Money Market Fund Market Sector
A Money Market is an international market for dealers who trade short- term government and corporate financial instruments like banker's acceptances, commercial paper, negotiable certificates of deposit, or Treasury bills. These instruments are considered the safest and most liquid of investments. The Money Market Fund Market Sector is the market sector that supports the sale and exchange of money market funds.
6.2.3.8 Mortgage Market Sector
From the investment perspective, a Mortgage is a debt instrument that is secured by the collateral of specified real estate property and that the borrower is obliged to pay back with a predetermined set of payments. Mortgages are used by individuals and businesses to make large purchases of real estate without paying the entire value of the purchase up front. The Mortgage Market Sector is the market sector that supports the sale and exchange of mortgages.
6.2.3.9 Municipal Bond Market Sector
A Municipal Bond is a city or state-issued debt instrument. Interest on such instruments is usually exempt from federal income tax. If the bond was issued in the bondholder's state of residence, interest is also usually state and local tax exempt. The Municipal Bond Market Sector is the market sector that supports the sale and exchange of municipal bonds. Within the ontology, the Municipal Bond Sector is a sibling to Government Bond Sector and Corporate Bond Sector under a parent class of Bond Market Sector and with a rule specifying that the three child classes are disjoint.
6.2.3.10 Preferred Stock Market Sector
A Preferred Stock is an equity share in a company that has priority over other stock of the same company in dividends and claims. The Preferred Stock Market Sector is the market sector that supports the sale and exchange of preferred stocks.
3. removal of section 6.3.5:
6.3.5 Market Sector
The relationship between a Financial Instrument and a Market Sector is as follows:
• A Financial Instrument is classified by at least one, but no more than two Market Sectors.
o Note: there are only a handful of Financial Instruments with more than one Market Sector associated with them. This is owing to the peculiarities of the Bond issue in each case.
4. In section 7.2, removal of sentence:
"In a sense, the security type refines the Market Sector, although a few Security Types apply to multiple Market Sectors . "
5. In section 8.2.3, removal of the sentence:
"o financial instrument  market sector (FI.2.5 & FI.2.6 )"
6. In table 8-4 removal of the following rows:
<blank node> restriction FI.2.5 isClassifiedBy max 2 MarketSector
<blank node> restriction FI.2.6 isClassifiedBy some MarketSector
MarketSector class market sector Market sector assigned to the security.
7. Remove section 8.2.5 in its entirety, including figures 8-4, 8-6 .
8. From section 8.2.6, remove phrase:
"types which function as refinements of Market Sectors through the object property “isConstituentOf ”"
from first sentence.
9. From table 8-7, remove the following rows:
MarketSector class market sector Market sector assigned to the security. MS.4.1
<blank node> restriction ST.5.2 isConstituentOf min 1 MarketSector
10. From Appendix B, section 2, remove:
-from page 46 "• Market Sector " in the bulleted list.

• The sentence: "(If such is viewed as necessary by either the Registration Authority or by a Certtified Provider (see B.3), a revision of this specification will be required so as to fully document the additional classes or vocabularies.)"

In Machine readables:
1. remove Market Sector class and all of its child classes from the FinancialInstrumentIdentifier.rdf ontology. (this takes with it all references to those classes within that file.
2. remove all references to Market Sector or any of its child classes in SecurityTypes.rdf.

The individuals present in pricing sources and security types were also present, at least in part, in the main ontology. Given that the main ontology is imported by both pricing sources and security types, this is entirely redundant and creates the real possibility that the two lists will be out of sych. Removing the individuals from the main ontology is the right approach.

Eliminate unnecessary replication of individuals in machine readable files.

This only affect machine readable files. Individuals representing both Pricing Sources and Security Types were present in both their respective ontology files as well as in the FinancialInstrumentIdentifier.rdf file. The task here is to simply remove all individuals that are representations of Pricing Sources or Security Types from the FinancialInstrumentIdentifier.rdf file.

Raised by Doug Tolbert:

The handling of Associated Data is way underspecified. Where are these items stored? How are they retrieved? Who can update them? Can I create a new one? Who decides what the legal values are? etc.

Clarification regarding process(es) by which the controlled vocabularies get updated.

This affects the specification in a number of places as follows:
1. Section 7.1:
remove ", primarily" from the sentence "While the vocabularies described below and included as a part of the specification are current as of the writing of this document, they are subject to change, primarily through growth, over time."
2. Add a second paragraph to 7.1 reading:
"The process by which the controlled vocabularies changes is directly related to the activities of both the Registration Authority and the Certified Providers (see Appendix B )."
3. Add a new subsection to Appendix B (B.4) as follows:
B.4 New Security Types and new Pricing Sources
In addition to new identifiers, new Security Types and new Pricing Sources can, and will, be created from time to time. The mechanism by which these can be created are entirely parallel to the mechanisms by which new identifiers are created. In particular, as the two conditions necessary for a new identifier: 1. Uniqueness, and 2. Novelty, apply also the Security Types and Pricing Sources, the exact same process will be followed:
• The Registration Authority, as the holder of the definitive repository, is responsible for confirming the uniqueness and novelty of each new Security Type and Pricing Source it creates.
• The Certified Provider(s) are responsible for:
o Confirming the uniqueness and novelty of each new Security Type and Pricing Source it creates against their own inventory.
o Making a call to the RA’s API to confirm the global uniqueness and novelty of the new vocabulary item.
o It is expected that this process can either stand alone as the registration of a vocabulary item or can be packaged as part of the request process for a new identifier which is such that a new vocabulary item is required to support it.

Raised by Matthew Rawlings:

There are multiple places in the ontology where the data types specified are too general. These need to be reviewed and narrowed as appropriate. In many instances, XSD String should be replaced with XSD NMToken.

XSD String Review

This affects the machine readable files only. In FinancialInstrumentIdentifier.rdf specify that the class financialInstrumentIdentifier has an xsd:type of "token" rather than string.