Replace tables 8.5, 8.6 and 8.7 with new consolidated table. Revise metadata tables to include updated version IRIs, contributors, license and copyright details with current dates.

Add Market Sector to 8.2.5 as a classifier

Update references to new Table 8-5

Update the FIGI ontology and metadata files to reflect the changes made to the specification document.

Revised the specification with respect to tables describing the ontologies in clause 8 as well as corresponding ontologies

The contents of the tables describing the concepts and relationships in the ontology, including metadata tables, were significantly out of date in FIGI 1.2. Further, the ontologies, including 2 metadata vocabularies (1 new for FIGI 1.3 and the more general about FIGI vocabulary) required updates to conform with changes made in other issue resolutions addressed via prior ballots. This includes removal of references to the two reference data vocabularies for security types and pricing sources, as well as confirming, and in a few cases making minor edits, to definitions that were not properly updated in earlier ballots.

To remove Pricing Source and add new restriction for Market Sector

This resolution replaces the existing Figure 8.2 with a new figure to update restrictions on Financial Instrument

The figure describing the Financial Instrument class needs revision to support the use of certain Commons properties, such as isIdentifiedBy and isClassifiedBy, to remove dependencies on the now deprecated pricing source class, and to add an optional restriction classifying a financial instrument based on the new Market Sector class

Figure to remove Pricing Source, and to add new Classifier Class->Market Sector class

The attached figure replaces Figure 8-1, Top-Level Hierarchy

The class hierarchy for FIGI 1.3 removes the deprecated Pricing Sources class, though it is still available as deprecated in the ontology, removes now deprecated classes that are reused from Commons, includes the new Commons dependencies, and adds Market Sector, per other resolutions covered in the FIGI 1.3 report.

AboutFIGI-1.0 TTL file provided in spec 1.2 was .rdf format, not ttl and will be replaced/revised with the proper format.

file ref in 1.2 is dtc/24-08-32. The final supplied files for 1.3 submission will fix this file format issue.

Fix AboutFIGI 1.0 TTL file

AboutFigi 1.0 TTL file submitted with 1.2 revision was an rdf copy not a ttl. To submit proper ttl file with 1.3 revision beta

SomeValuesFrom is syntactic sugar for min 1 cardinality, but is more efficient from a processing perspective than min 1 cardinality, so best practice is to use someValuesFrom.

The FIGI ontology should use someValuesFrom rather than min 1 cardinality

This issues is a duplicate of FIGI13-6 and is closed to the resolution of FIGI13-6.

The URI should be https://www.omg.org/spec/DPROD rather than ekgf.github.io.
We should retain the Beta version at the github.io location for forward compatibility.

Issue not related to this RTF

This issue was entered in error in the FIGI 1.3 RTF and refers to a different RTF

6.3.8 Market Sector
The relationship between a Financial Instrument and a Market Sector is as follows:
• A Financial Instrument may have up to, but not exceeding, one Market Sector.

New 6.3.x (6.3.8 Market Sector

6.3.8 Market Sector
The relationship between a Financial Instrument and a Market Sector is as follows:
• A Financial Instrument may have up to, but not exceeding, one Market Sector.

Section 6.2 includes the Instrument Name (primarily "the name of the company") which as described does not gurantee uniqueness and is liable to change.
While it should not be mandatory the Legal Entity Identifier, which if available is a far better indicator of uniqueness, should be included in the list of data points. And is increasingly required by many regulators including for US Agencies complying with the FDTA and even for crypto asset registration.
The same goes for Annex B.2 which includes data points for a new LEI request.

LEI addition updates

Add LEI as element with descriptions

Use of min 1 cardinality constraints is effectively syntactic sugar for someValuesFrom in OWL. However, someValuesFrom is far more efficient from a reasoning perspective. The ontology should be revised to use someValuesFrom rather than min 1 cardinality.

Revise ontology as noted for someValuesFrom

Use of min 1 cardinality constraints is effectively syntactic sugar for someValuesFrom in OWL. However, someValuesFrom is far more efficient from a reasoning perspective. The ontology should be revised to use someValuesFrom rather than min 1 cardinality.

Some of the related text was revised via the 1.1 revision to the specification, and through issues raised in 1.2. The definitions and annotations in the FIGI ontology should be updated so that they are ISO 704 compliant and to reflect the updated details in the FIGI 1.1+ issues.

Revise FIGI ontology definitions

Ontology file definitions to be revised to be sure to match the definitions revised in the specification, as well as descriptions and any examples.

Remove the following files, as .xml and .xml are outdated and no longer used generally;

1. FIGI UML XMI
FIGI/20150501/GlobalInstrumentIdentifiers.xml
dtc/15-05-29

2. GlobalInstrumentIdentifiers
FIGI/GlobalInstrumentIdentifiers.xmi
dtc/15-05-05

3. PricingSources
FIGI/PricingSources.xmi
dtc/15-05-05

4. SecurityTypes
FIGI/SecurityTypes.xmi
dtc/15-05-05

Removal of old unused xmi files

Removal of files that are not used (xmi) from specification files

Remove:

The FIGI specification includes two subordinate vocabularies: - SecurityTypes.rdf, which contains all of the named individuals for security types as of the date of publication, and - PricingSources.rdf, which contains all of the named individuals for pricing sources as of the date of publication.

Pricing sources have been removed and security types is set to an external codeset

8.1 remove reference to subordinate vocabularies

Remove:

The FIGI specification includes two subordinate vocabularies: - SecurityTypes.rdf, which contains all of the named individuals for security types as of the date of publication, and - PricingSources.rdf, which contains all of the named individuals for pricing sources as of the date of publication.

Pricing sources have been removed and security types is set to an external codeset

Revise bullet, 2nd paragraph of Composite Global Identifier that reads;
"The Composite Global Identifier only applies to a limited subset of Global Identifiers. In particular, it only applies to those Global Identifiers that can be differentiated based on either the venue on which the asset is traded or on the pricing source of the asset"

Remove this text

Remove Pricing Source in 6.1.1

Revise bullet, 2nd paragraph of Composite Global Identifier that reads;
"The Composite Global Identifier only applies to a limited subset of Global Identifiers. In particular, it only applies to those Global Identifiers that can be differentiated based on either the venue on which the asset is traded or on the pricing source of the asset"

Remove this text

Remove point 3 that references "Two controlled vocabularies". These have been removed elsewhere and turned to external references

Remove point 3 in 1.1 Overview

Remove point 3 that references "Two controlled vocabularies". These have been removed elsewhere and turned to external references

revise last sentence that reads:
It is grouped, along with Pricing Source, as an associated Code. Exchange codes are associated with Financial Instruments through the “has” object property. (“has” is used rather than a more descriptive object property such as “hasAssociatedCode” in order to leverage reasoning facilities and be “mappable” to FIBO relations.)

to read:

It is an associated Code. Exchange codes are associated with Financial Instruments through the “has” object property. (“has” is used rather than a more descriptive object property such as “hasAssociatedCode” in order to leverage reasoning facilities and be “mappable” to FIBO relations.)

Revise 6.2.2

revise last sentence that reads:
It is grouped, along with Pricing Source, as an associated Code. Exchange codes are associated with Financial Instruments through the “has” object property. (“has” is used rather than a more descriptive object property such as “hasAssociatedCode” in order to leverage reasoning facilities and be “mappable” to FIBO relations.)

to read:

It is an associated Code. Exchange codes are associated with Financial Instruments through the “has” object property. (“has” is used rather than a more descriptive object property such as “hasAssociatedCode” in order to leverage reasoning facilities and be “mappable” to FIBO relations.)

Revise paragraph that reads:
"Multiple Financial Instruments can be associated with a single name as there is no requirement that the name of a Financial Instrument specify all of the individuating characteristics of a Financial Instrument, e.g., the pricing source. There is, however, nothing precluding such specificity either. "

to read:

"Multiple Financial Instruments can be associated with a single name as there is no requirement that the name of a Financial Instrument specify all of the individuating characteristics of a Financial Instrument, e.g., the exchange code. There is, however, nothing precluding such specificity either. "

Revise 6.3.5 Financial Instrument Name Text

Revise paragraph that reads:
"Multiple Financial Instruments can be associated with a single name as there is no requirement that the name of a Financial Instrument specify all of the individuating characteristics of a Financial Instrument, e.g., the pricing source. There is, however, nothing precluding such specificity either. "

to read:

"Multiple Financial Instruments can be associated with a single name as there is no requirement that the name of a Financial Instrument specify all of the individuating characteristics of a Financial Instrument, e.g., the exchange code. There is, however, nothing precluding such specificity either. "

to add new 6.2.x (6.2.6 Market Sector:
A market sector is a category of a financial instrument that provides a general categorization based on prevailing industry conventions, such as Equity based versus currency based instruments. A set of individuals that are members of the class “MarketSector” are maintained by the Registration Authority and have an association with the “SecurityType” class.

6.2.x (6.6.6 Market Sector Added

to add new 6.2.x (6.2.6 Market Sector:
A market sector is a category of a financial instrument that provides a general categorization based on prevailing industry conventions, such as Equity based versus currency based instruments. A set of individuals that are members of the class “MarketSector” are maintained by the Registration Authority and have an association with the “SecurityType” class.

To add to 1. SCOPE section as paragraph prior to 1.1 Overview;

The Financial Instrument Global Identifier specification details an open data based approach for identifying financial instruments through use of a permanent, semantically meaningless code key with associated identifying metadata.

The Financial Instrument Global Identifier provides a data model approach to identifying financial instruments in various contexts. These contexts relate to different processes across asset classes and operational needs where associated metadata needs may differ for the same financial instrument or collection of financial instruments (such as baskets).

Through use of a persistent, semantically meaningless code (e.g. the FIGI), the methodology allows for creation of a self referential data model and creation of object entities that can satisfy different needs requiring different levels of granularity through associated metadata based on contextual usage.

Add Scope paragraph

To add to 1. SCOPE section as paragraph prior to 1.1 Overview;

The Financial Instrument Global Identifier specification details an open data based approach for identifying financial instruments through use of a permanent, semantically meaningless code key with associated identifying metadata.

The Financial Instrument Global Identifier provides a data model approach to identifying financial instruments in various contexts. These contexts relate to different processes across asset classes and operational needs where associated metadata needs may differ for the same financial instrument or collection of financial instruments (such as baskets).

Through use of a persistent, semantically meaningless code (e.g. the FIGI), the methodology allows for creation of a self referential data model and creation of object entities that can satisfy different needs requiring different levels of granularity through associated metadata based on contextual usage.

Pricing source was determined to not be a differentiator in regards to assignment of a unique FIGI as opposed to Exchange Code. Pricing sources typically refer to individual brokers providing RFQ (request for quote) pricing for individual trading requests as opposed to Exchange Codes (which include central markets) that create differentiation in processes not limited to settlement, execution location, matching and other activities.

As such the following should be removed:

2.1 Introduction;

Table entry for Pricing Source

6.2.4 Pricing Source

within 6.2.6 Ticker; "or specific pricing sources" referenced in the second sentence

6.3.6 Pricing Source; remove section

7.3 Pricing Sources; remove section

Table 8-5; remove pricing source entries

B.2 Request Service; remove pricing source from bulleted list

B.4 Remove "and New Pricing Sources" from title. Remove pricing sources references from section of text (4 references)

Remove Pricing Sources references

Pricing source was determined to not be a differentiator in regards to assignment of a unique FIGI as opposed to Exchange Code. Pricing sources typically refer to individual brokers providing RFQ (request for quote) pricing for individual trading requests as opposed to Exchange Codes (which include central markets) that create differentiation in processes not limited to settlement, execution location, matching and other activities.

As such the following should be removed:

2.1 Introduction;

Table entry for Pricing Source

6.2.4 Pricing Source

within 6.2.6 Ticker; "or specific pricing sources" referenced in the second sentence

6.3.6 Pricing Source; remove section

7.3 Pricing Sources; remove section

Table 8-5; remove pricing source entries

B.2 Request Service; remove pricing source from bulleted list

B.4 Remove "and New Pricing Sources" from title. Remove pricing sources references from section of text (4 references)

Page 12, Section 6.2.5 Security Type.
Last sentence says "A set of individuals that are members of the class “SecurityType” are specified in an associated ontology included as part of this specification."

should be revised to say: "A set of individuals that are members of the class “SecurityType” are specified in an associated ontology to be maintained and provided by the Registration Authority in a machine readable format and updated as changes occur."

Update Section 6.2.5 Security Type

Page 12, Section 6.2.5 Security Type.
Last sentence says "A set of individuals that are members of the class “SecurityType” are specified in an associated ontology included as part of this specification."

should be revised to say: "A set of individuals that are members of the class “SecurityType” are specified in an associated ontology to be maintained and provided by the Registration Authority in a machine readable format and updated as changes occur."

edit for clarification

4.2; add to financial instrument description ; “or baskets thereof.”

4.2 clarify definition for financial instrument

edit for clarification

4.2; add to financial instrument description ; “or baskets thereof.”

D.4; revise/ fix (missing words, and account for latest 20022 revision);
“ISO 20022 is a business modelling standard that specifies the structure of a metadata repository containing descriptions of business processes such that physical messages can be generated for business communication. The relationship between ISO 20022 and FIGI is an intersecting, rather than overlapping, relationship. In fact, the FIGI standard is formally recognized as having a place within ISO 20022 within the accepted external codesets. Strictly speaking, however, ISO 20022 and FIGI are entirely independent of one another as they seek to do very different things.”

Revise D.4 20022 definition

D.4; revise/ fix (missing words, and account for latest 20022 revision);
“ISO 20022 is a business modelling standard that specifies the structure of a metadata repository containing descriptions of business processes such that physical messages can be generated for business communication. The relationship between ISO 20022 and FIGI is an intersecting, rather than overlapping, relationship. In fact, the FIGI standard is formally recognized as having a place within ISO 20022 within the accepted external codesets. Strictly speaking, however, ISO 20022 and FIGI are entirely independent of one another as they seek to do very different things.”

D.3 CFI
Add paragraph;
It should be noted that multiple different classification systems, taxonomies, and ontologies exist, will persist, and it is unlikely a single definitive system will emerge. This is due to multiple factors, notwithstanding legal, regional, jurisdictional, operational and other differences. As such, the primary function of the FIGI Security Type classification is to enable interoperability across approaches.

Edit to D.3 CFI

D.3 CFI
Add paragraph for further context;
It should be noted that multiple different classification systems, taxonomies, and ontologies exist, will persist, and it is unlikely a single definitive system will emerge. This is due to multiple factors, notwithstanding legal, regional, jurisdictional, operational and other differences. As such, the primary function of the FIGI Security Type classification is to enable interoperability across approaches.

Page 31, Section B.2 Request Service;
“Meeting the first condition is trivial: since the RA serves as the system of record for all FIGIs, assigning a novel FIGI is merely a matter of creating a new identifier and checking against the existing inventory to ensure that the identifier is new. Exactly how the RA (or a CP, see below) might elect to do this is left open to the organization in question, provided that uniqueness obtains.”

Correct last sentence of “provided that uniqueness obtains.” To be “provided that uniqueness is obtained.”

Clarify B.2 wording

Page 31, Section B.2 Request Service;
“Meeting the first condition is trivial: since the RA serves as the system of record for all FIGIs, assigning a novel FIGI is merely a matter of creating a new identifier and checking against the existing inventory to ensure that the identifier is new. Exactly how the RA (or a CP, see below) might elect to do this is left open to the organization in question, provided that uniqueness obtains.”

Correct last sentence of “provided that uniqueness obtains.” To be “provided that uniqueness is obtained.”

D.5 MIC (fixes to MIC purpose and relationship to exchange and/or pricing source)
Revise first paragraph to read:
“The Market Identifier Code (MIC) provides a method of identifying exchanges, trading platforms, and systemic internalizers as locations where Financial Instruments are exchanged or transacted. This function relates to parts of FIGI, in particular, the Exchange Code. Differentiation exists in:”

Revise D.5 MIC

D.5 MIC (fixes to MIC purpose and relationship to exchange and/or pricing source)
Revise first paragraph to read:
“The Market Identifier Code (MIC) provides a method of identifying exchanges, trading platforms, and systemic internalizers as locations where Financial Instruments are exchanged or transacted. This function relates to parts of FIGI, in particular, the Exchange Code. Differentiation exists in:”

In addition, remove 'pricing source' references as follows;

in 1. Scope; the sentence: "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). "

should read

"The list of exchange codes present in FIGI includes codes to support Financial Instruments that are not exchanged at a venue that is not eligible for a MIC. In fact, FIGI can support Financial Instruments that are not technically tradable at all, e.g., an individual person’s home mortgage contract. "

In 2. Embeddedness, revise paragraph that reads: "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 and is definitional different, although there may be similarities 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 as part of the defining metadata. In the case of the MIC, it can be used in concert with the ISIN for informational purposes, as when used together, the combination can provide a certain context that is usable in certain functions. However, in general, it is not part of the core metadata of the ISIN in this particular circumstance. "

to read:

2. Embeddedness: The MIC code is a stand-alone code that identifies a Market. As such, it serves a different purpose than does the Exchange Code attribute of FIGI and is definitionally different, although there may be similarities The Exchange Code attribute of FIGI serves as a differentiator of otherwise identical financial instruments and that differentiation is embedded into the Financial Instrument Global Identifier as part of the defining metadata. In the case of the MIC, it can be used in concert with the ISIN for informational purposes, as when used together, the combination can provide a certain context that is usable in certain functions. However, in general, it is not part of the core metadata of the ISIN in the same functional context as Exchange Code attribute exists within FIGI metadata

D.2 point 1;

Revise paragraph
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 lifecycle, so as to enable robust and comprehensive data management and, from that, compliance.

To

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 and inherent self relationships. 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 model that serves to identify financial instruments and the different contexts they exist in throughout their lifecycle, so as to enable robust and comprehensive data management and, from that, compliance.

Revise Annex D.2 point 1

D.2 point 1;

Revise paragraph
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 lifecycle, so as to enable robust and comprehensive data management and, from that, compliance.

To

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 and inherent self relationships. 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 model that serves to identify financial instruments and the different contexts they exist in throughout their lifecycle, so as to enable robust and comprehensive data management and, from that, compliance.

The list of sources is way out of date. A mechanism is needed for keeping them updated with the monthly-changing MIC codes.
FIBO already does this - they should share a mechanism if not a file.

Updating Pricing Sources

Pricing sources is being removed from the specification as noted elsewhere, so this specific issue should be marked duplicate and removed

Revise first paragraph that states: “As specified above, each Global Identifier has at least one Security Type associated with it. The Security Types are specified in the associated SecurityTypes.rdf vocabulary.”
To:
“As specified above, each Global Identifier has at least one Security Type associated with it. The Security Types are to be maintained and provided by the Registration Authority in a machine readable format or reference to such.”

Revise paragraph under “New Security Types are invented” from
“The financial sector is dynamic and new financial instruments are constantly being created. Some are simply variations on existing instruments, e.g., a new mutual fund, but some are genuinely novel. Given the granularity of the security types currently inventoried in this controlled vocabulary (375 uniquely specified security types), it is likely that new financial instruments will emerge that require a new label.”
To
“The financial sector is dynamic and new financial instruments are constantly being created. Some are simply variations on existing instruments, e.g., a new mutual fund, but some are genuinely novel. Given the granularity of the security types currently inventoried, it is likely that new financial instruments will emerge that require a new identifier and description.”

And revise descriptive paragraph regarding “the coverage of FIGI expands” from:
As of the 2014 OMG publication of this standardFIGI covered over 150 million financial instruments. A large number to be sure, but given the granularity of FIGI, e.g., differentiating between AAPL being traded on one exchange as opposed to another, this list is certainly incomplete. Over time, additional financial instruments that simply are not covered at present will be incorporated into FIGI at which point the security type list will need to be expanded.
To:
As of the 2025 OMG publication of this standard, FIGI covers over 1.4 billion financial instruments, across particular contexts that necessarily differ across security types. Over time, additional financial instruments that are not covered at present will be incorporated into FIGI at which point the security type list will need to be expanded.

Revise Section 7.2 Security Types

Revise first paragraph that states: “As specified above, each Global Identifier has at least one Security Type associated with it. The Security Types are specified in the associated SecurityTypes.rdf vocabulary.”
To:
“As specified above, each Global Identifier has at least one Security Type associated with it. The Security Types are to be maintained and provided by the Registration Authority in a machine readable format or reference to such.”

Revise paragraph under “New Security Types are invented” from
“The financial sector is dynamic and new financial instruments are constantly being created. Some are simply variations on existing instruments, e.g., a new mutual fund, but some are genuinely novel. Given the granularity of the security types currently inventoried in this controlled vocabulary (375 uniquely specified security types), it is likely that new financial instruments will emerge that require a new label.”
To
“The financial sector is dynamic and new financial instruments are constantly being created. Some are simply variations on existing instruments, e.g., a new mutual fund, but some are genuinely novel. Given the granularity of the security types currently inventoried, it is likely that new financial instruments will emerge that require a new identifier and description.”

And revise descriptive paragraph regarding “the coverage of FIGI expands” from:
As of the 2014 OMG publication of this standardFIGI covered over 150 million financial instruments. A large number to be sure, but given the granularity of FIGI, e.g., differentiating between AAPL being traded on one exchange as opposed to another, this list is certainly incomplete. Over time, additional financial instruments that simply are not covered at present will be incorporated into FIGI at which point the security type list will need to be expanded.
To:
As of the 2025 OMG publication of this standard, FIGI covers over 1.4 billion financial instruments, across particular contexts that necessarily differ across security types. Over time, additional financial instruments that are not covered at present will be incorporated into FIGI at which point the security type list will need to be expanded.

The current list is unstructured and unanchored to any recognized classification scheme - there's no way to even review it.
Further it misses crypto assets now in scope for FIGI.
No information is given about each of the types besides their name, not even an external reference - hardly semantic!
Ideally there should be a link to FIBO or similar, without requiring FIBO compliance.

Security types covered in 13-16

Security type issues resolved through FIGI13-16