1. Introduction

During the last ISO/TC68/SC4 meeting held in Santa-Fe on September 26-27, 2000, Mr Gerrit de Marez Oyens (FIBV) commented on the preliminary report issued by his working group (WG5) on the MIC (Market Identifier Code). The conclusions were summarized as follows :

The MIC is not a widely used code, almost limited as it seems to be to SWIFT, that uses the code for identification of the exchanges that are part of its system. The use of MIC is not mandatory and its lay-out is free formatted, which could make it rather more user-friendly, than today seems to be the case. The MIC is competing with other existing codes for exchanges and such a proliferation is undesirable and inefficient.

That document did also report the following weaknesses and recommendations from the industry:

Weaknesses

• The use of the MIC is not mandatory and its lay-out is free formatted.
• Regulated markets as the MIC refers to are not anymore the way to trade securities.
• Trade may be cleared by any clearing organization, not only the one of the home arrket.
• A country of reference for a trade seems no longer valid.
• The reference ''Regulated markets'' is no longer valid either.
• The current list of codes is outdated, inconsistent and erratic.
• Complying with BIC is cumbersome and limits a flexible use.
• Registration Authority acts on demand without guidelines.
• Relatively unknown code due to lack of marketing and promotion.
• A market identifier only is today unsufficiently clear to define a trade.

Recommendations

• The way of identifying trading systems must be flexible and fast.
• Players may trade any product, anywhere, in any currency.
• MIC codes should keep as close as possible to already widely used abbreviations.
• The use of the first ''X'' character should not be longer required.
• The full four characters can be used for a unique and friendly identification.
• The place in the message should identify the meaning of the MIC.
• The place where it is used will indicate its role.
• The MIC code should not be a qualifier but an identifier.

During the same meeting, the following important decisions were also taken:

• SWIFT will remain the Registration Authority for the issuance of MIC codes.
  
• ANNA will be responsible for issuing the guidelines which are missing today.

The purpose of this document is to check the exact positioning of the ''Market Identifier Code - MIC'' vis a vis several other related ISO standards such as the ISIN or the BIC, in order to find pertinent ways to promote the use of the MIC and to expand its scope.

Consequently, in order to better understand the present weaknesses of the MIC and to make appropriate suggestions, we need to outline particularities of the four standards reported hereafter:

• ISO-6166 ISIN - International Securities Identification Number
• ISO-9362 BIC - bank Identifier Code
• ISO-10383 MIC - Market Identifier Code
• ISO-15022 Data Field Dictionary

2. ISO-6166 - ISIN - International Securities Identification Number

The allocation of ISIN codes is governed by two different documents:

The ISO-6166 standard describing the structure of the ISIN codes and which organizations are allowed to allocate ISIN codes to which securities. ANNA acts as Registration Authority for this standard which has been recently updated (Version-6) with a wider scope now including financial instruments other than securities.

The ISIN guidelines the aim of which is to obtain a uniform process among the various National Numbering Agencies for the allocation of ISIN codes. These guidelines insist on two key words which are ''fungibility'' and ''uniqueness''.

In the securities industry ''fungible'' means that a security ranks pari passu in all respects with a different version of the same security and can be exchanged into the other form and vice versa at anytime: The fungible securities will be identified by a unique ISIN code.

3. ISO-9362 - BIC - Bank Identifier Code

SWIFT is the Registration Authority for the Bank Identifier Code (BIC) which is composed of either 8 or 11 consecutive characters as follows :

• BANK CODE: 4an allocated by SWIFT acting as Registration Authority
• COUNTRY CODE: 2a allocated in accordance with the ISO-3166 standard
• LOCATION CODE: 2an allocated with a distinction for entities connected to SWIFT
• BRANCH CODE: 3an this code is optional

4. ISO-10383 - MIC - Market Identifier Code

Scope
The current version of this standard stipulates that the Market Identifier Code (MIC) is indeed a BIC allocated to a ''Regulated Market.''

Structure
The code consists of four contiguous characters. The first character should be an X. The remaining three characters shall be assigned by the Registration Authority and shall uniquely identify the market.

5. ISO-15022 - Data Field Dictionary

As a general principle, SWIFT would like to ''decouple'' the MIC from the BIC and to integrate the MIC as part of the ISO-15022 Data Field Dictionary. In the ISO-15022 DFD there exists already a field in which the MIC can be used, i.e. field 94B : TRAD/EXCH/MIC.

By making the MIC part of the ISO-15022 Data Field Dictionary, the MICs can be attributed by SWIFT in its role as the ISO-15022 Registration Authority, i.e. no changes to the ISO-15022 standard are necessay since this falls under the ISO-15022 RA contract.

This means that new MICs can be created at anytime upon request respecting the delays as described in the ISO-15022 service level agreement and the information can be published on www.iso15022.org within a very short time frame.

6. SWIFT's answers to ANNA-WG2 questionnaire

During our ANNA-WG2 meeting in December, we decided to focus on the revision of the ISO-10383 standard before spending time on the MIC guidelines. During our discussion, the following questions were raised and referred to SWIFT:

1. Keeping the present length
In order to keep software investments to a minimum and to sensibly accelerate the use of the MIC worldwide, we could continue to use the MIC as a component of the BIC but, with a wider scope, the new MIC would not be human readable anymore.

Question: Is human readability such an important issue from SWIFT viewpoint?

Answer: SWIFT agrees that the current length should be kept in order to preserve the users' systems. However, as indicated above, SWIFT prefers to ''decouple'' the MIC from the BIC. As for the human readability, this is not required from SWIFT's perspective, however, some users prefer to use human readable codes.

2. The present MIC is four alpha-numeric characters
However, we have not found any example where a number was used as a MIC component and all MICs allocated so far appear with alpha characters only.

Question: Is there a technical reason why SWIFT did not use any number within a MIC until today?

Answer: The only reason why until today the MIC never contained any number is because ISO-10983 describes that the MIC is composed of the first four characters of the BIC and the format of these four characters is 4!a, i.e. 4 alphanumeric characters.

3. The MIC is supposed to start with an ''X''
This constraint appears to be in conflict with the flexibility we need to expand the use of the MIC to non regulated markets, CSOs, etc… Moreover, an exception exists with Christriana Bank which has been allocated ''XIAN''.

Question: Could we change ''Article 3'' of ISO-10383 to start all MICs with a digit instead of an ''X?"

Answer: SWIFT agrees that the MIC could start with a digit instead of an X. When you say that the first character should be a digit (0 to 9), will each digit have a specific meaning , e.g. 0 for all the exchanges, 1 for all ECNs, etc… or will the number be assigned at random?

4. Full update of MICs already allocated
Based on answers given to the above questions, it could happen that all MICs already allocated have to be changed.

Question: Would t be possible on the SWIFT side to consider a big-bang update where all MICs would be changed at the same time? What about those entities requiring a MIC while they have already been allocated a BIC?

Answer: As mentioned before, SWIFT prefers a big-bang update. We could even think about deleting all existing MICs , once new codes are created in order to avoid confusion. However, ANNA and SWIFT should discuss a communication plan in order to inform those institutions that have already a MIC today about their new MIC. In addition, a promotion plan should be established in order to promote the new MIC to all other financial institutions.

7. Conclusions / next steps

As explained during our first ISIN User Group meeting in New York and based on the new elements reported above, it appears that we must coordinate our efforts and work actively on the three following items:

• Extension of the scope of the ISO-10383 standard
  The ''new MIC'' code should be used to identify:

1. The market (regulated or not) on which the trade took place.
2. The clearing system through which the trade will clear.
3. The central depository or ICSD where the trade will settle.
4. The market price capture mechanism.
5. Any other pertinent information such as register, etc…

• Revision of the ISO-10383 standard
  Such an extension of the scope and the possibility to decouple the MIC from the BIC, to take advantage of the ISO-15022 Data Field Dictionary, means a full re-writing of the standard, while keeping in mind the two following aspects:

1. The MIC should be structured in such a way that software developments are kept to a minimum.
2. Its prompt implementation will sensibly reinforce the credibility of the ISIN and will have a positive impact for market players anticipating to use the ISIN codes as primary key.

• Issuance of guidelines by ANNA
  The issuance of guidelines should be quite simultaneous with the revision of the ISO standard, since it will enable ANNA-WG2 and the ISIN User Group members to be sure that the standard and the guidelines remain compatible at anytime.