The Data Field Dictionary and Catalogue of Messages are available over the Internet on Monday to Friday from 00:00 hours to 23:59 hours UCT (Universal Co-ordinated Time). There is no restriction on who can access the information. The Registration Authority (RA) will not charge for the service.

The RA may provide the Data Field Dictionary and Catalogue of Messages information in another format. For such services the RA may make a reasonable charge.

The following procedure should be adopted if it is required to use a new message, or change the scope, functionality or format of a message or field in any way.

Requests for the creation of both new Enhanced ISO 7775 data fields and/or EDIFACT data elements will be centralised by the RA.

The request for a new field must include all the items which would have to be included in the Data Field Dictionary, eg, class of field, field name, definition, format, where used, etc. The request must state the business justification for the new field and demonstrate why similar already existing fields, if any, do not accommodate the need.

The RA will validate the completeness of the request and return a positive or negative acknowledgement of receipt within one week of the receipt. In case the request is invalid, the acknowledgement will state the reason(s) for invalidity, eg, which items are missing.

The analysis of a complete request for one new field shall not take more than five business days. In case of multiple concurrent demands, they will each not require more than five business days and will be treated on a first in first out basis.

The RA will systematically map each newly created Enhanced ISO 7775 data field into the equivalent EDIFACT field. However, they will only create the Enhanced ISO 7775 data field for a new EDIFACT field if explicitly requested.

The relevant EDIFACT body (currently EEG04) will be notified by the RA of any need for new EDIFACT fields.

The RA may refuse to create a new field in the following, not limitative, list of cases:

The procedure to request a change to an existing field, including new qualifiers, new code words, new code values and new data source schemes, is similar to the procedure to request a new field, except that the request must highlight the difference with the current field description.

When the request changes the structure of the field and might impact current users of the field (eg, the format is changed), it must be processed like a request for deletion and a request for a new field. The adding of a new code word or code value to a field would not normally affect the structure of the field.

The RA will process the request for an amendment to an existing field in the same way and time scale as for a new field.

Requests for deletion of field(s) are generally introduced at the same time as a request for deletion of the message type(s) where the field(s) appear(s). The request for deletion may also relate to an amendment (see Request for Amendment of an Existing Field) or to a field which relates to a message type not yet recorded in the Catalogue of Messages (see Request for Creation of a New Message Type or Version Number).

To give users an opportunity to disagree with the deletion, the field to be deleted will be marked as such for a one-year period. If, after this period, nobody identifies himself as a user, the field shall be deleted from the dictionary. Changes required to the UN/EDIFACT Directories will be communicated to and managed by the relevant EDIFACT body (currently EEG04).

In case of deletion for amendment, the field marked for deletion will refer to the new version of the data field.

Institutions and market organisations may register for a specific "message version issuer code" to be used in message descriptors, when they need to identify proprietary sub-formats. Only one issuer code shall be allocated per issuer.

The request must include the list of the message type versions for which this message version issuer code will be used and, for each message type version, the format of the message version issuer sub-code to be used in connection with the issuer code and a short description of the related sub-format.

Whenever possible, message version issuer codes will be based on standard codes, such as the ISO 10383 Market Identifier Code (MIC) or the first four characters of the ISO 9362 Bank Identifier Code (BIC). The spelling of the message version issuer code may be proposed by the requester but is the exclusive decision of the RA.

The RA will validate the completeness of the request and return a positive or negative acknowledgement of receipt within one week of the request. In the case of an invalid request, the acknowledgement will state the reason(s) for invalidity. In the case of a valid request, the acknowledgement will contain the attributed issuer code.

The inclusion of related message version issuer code and sub-codes in the Catalogue of Messages shall be performed within the month following the positive acknowledgement.

Issuers shall communicate updates to be performed to the identification or description of their sub-formats in the Catalogue of Messages. The procedure and timing for update requests is similar to the procedure and timing to request registration of a new issuer code.

To ensure confidentiality, requests for the reservation of a message type number or a version number can be addressed to the RA before the request to include the message itself in the Catalogue of Messages. The request must however mention when the message description will be provided for inclusion in the Catalogue of Messages. It shall not be later than one year after the message type number or version number reservation.

The message type number or version number may be proposed by the requester but is the exclusive decision of the RA. A reserved message type number or version number is subject to final confirmation after the message description is provided. The RA may decide, after analysis of the message description that, for example, the new message does not even justify a specific version number since it is too close to an existing message type or version (see Request for Inclusion of a New Message in the Catalogue of Messages).

The reserved message type numbers or version numbers will be communicated to the requester within five business days of the receipt of the request.

Requests for the creation of both new Enhanced ISO 7775 messages and/or EDIFACT messages will be centralised by the RA.

The request for inclusion of a new message must include all the items and descriptions which would have to be included in the Catalogue of Messages. The request must state the business justification for the new message type or version and demonstrate why similar already existing messages, if any, do not accommodate the need. The business justification must identify the future community of users and give an idea of the number of users and the volume of messages.

The RA will validate the completeness of the request and return a positive or negative acknowledgement of receipt within three weeks of the receipt. In case the request is invalid, the acknowledgement will state the reason(s) for invalidity, eg, which items are missing.

The analysis of a complete request for one new message shall not take more than twenty business days. When a new message requires new fields or amendment to existing fields, a specific request for a new field or amendment must be introduced for each such field according to the procedures set forth in this annex. Whenever possible, these new or amended fields will be requested, and assigned, before the introduction of the new message. The delay to analyse a new message does not start until all fields required have been created or amended by the RA.

In case of multiple concurrent demands, they will each not require more than twenty local business days and will be treated on a first in first out basis.

The RA will systematically map each newly created Enhanced ISO 7775 message into the equivalent EDIFACT message. However, they will only create the equivalent Enhanced ISO 7775 message for a new EDIFACT message if explicitly requested.

The relevant EDIFACT body (currently EEG04) will be notified by the RA of any need for a new EDIFACT message.

The RA shall generally not refuse the inclusion of a message provided it is made of approved fields, it is constructed along the message design rules, and it is different from all existing messages.

When the difference with an existing message is minor and the need to have a specific message type or version is unclear, the RA shall investigate the added value of the new message with the requester and analyse the possibility of either using an alreadyexisting message or updating an already existing message to include the requirements of the requester. If the requester maintains its request and the RA remains unconvinced, the RA shall refer the request to the RMG with a fair description of the pros and cons for the message. The RA may question the need for a new message in the following, not limitative, list of cases:

The procedure to request a change to an existing message type or version is similar to the procedure to request inclusion of a new message type or version, except that the request must highlight the differences with the current message description.

When the request changes the structure of the message and might impact current users (eg, a mandatory field is suppressed), it must be processed like a request for deletion and a request for inclusion of a new message.

To give users an opportunity to disagree with the deletion, the message to be deleted will be marked as such for a one-year period. If, after one year, nobody identifies himself as a user, the message shall be deleted from the catalogue.

Changes required to the UN/EDIFACT Directories will be communicated to and managed by the relevant EDIFACT body (currently EEG04).

In case of deletion for amendment, the message marked for deletion will refer to the new version of the message.

In exceptional circumstances the RMG may agree to allow the RA to modify the response times and priorities in the Service Level Agreement. An example of when this could occur would be if an interested party had requested say 100 new fields just before another interested party had requested one new field.

The electronic version of the data dictionary and the catalogue of messages will be updated in the same time-scale as the requester changes. If the RA agrees to amend the Data Field Dictionary or Catalogue of Messages for any reason, then the electronic version will be updated within 24 hours of the requester being informed.

When a request has been rejected by the RA, the requester may appeal to the Registration Management Group (RMG). The RMG shall review the original request

and the reason for rejection. Based upon this evaluation, the RMG will render its decision. This decision will normally be within 30 calendar days of receiving the appeal. A subsequent appeal may be made to ISO/TC68/SC4.

Complaints may be sent to the RMG regarding the service provided by the RA. All complaints shall be in written form. Complaints shall be service orientated and will not be considered as part of the appeals process. The RMG will aim to respond to complaints within 90 calendar days of receipt.

All decisions rendered by the RMG shall be by vote consisting of a two-thirds majority of those voting. ISO/TC68/SC4 shall have the right to overrule a decision of the RMG by a two-thirds majority vote of its P-members, provided written notification of an appeal against the RMG decision is received within four weeks of that decision. Voting in both cases may occur through a postal vote or through a meeting. An interested party may not vote.