ISO 15022 Data Field Dictionary

Administrative Information

A. Accessing Hours

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.

B. Other Format

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.

C. Procedure for Registering New and Modified Messages and Fields

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.

Messages

    • Before any contact is made with the RA, the designers should check whether a message is already registered in the Catalogue of Messages for the scenario in question.
    • If one exists, the designers should evaluate whether the message meets all their requirements. If not, they can submit a New Message Version Request to the RA. This may lead to a new version of the message, if accepted.
    • If one does not exist, designers may submit a Message Registration Request to the RA to add a new message.
    • Requests for registration of a new message need to properly describe the scenario(s), the relationships, the information exchange and the states of the transaction(s) being covered.
    • The RA will ensure that:
    • All messages with the same business function have the same message type.
    • The code (that is, message type and version) and name of a message will be unique in the ISO 15022 Catalogue of Messages.

Fields

    • When a field is needed, designers shall first check whether a generic field is already registered in the Data Field Dictionary for the purpose in question.
    • If one exists, designers shall evaluate whether the field meets all their requirements. If not, they can submit a Field Change Request to the RA. This will frequently be for the registration of a new qualifier.
    • If one does not exist, designers may submit a Field Registration Request to the RA to add a new field.
    • Requests for registration of a new field need to properly describe the purpose.
    • The RA will ensure that the field identification and the field name are unique in the ISO 15022 Data Field Dictionary.

New Code Word

    • If it is a request for a new code word for an existing field, sub-field or qualifier, which does not affect the usage of existing code words, or the format of the field, a New Code Word Request should be sent to the RA for approval.

D. Requests and Response Times

Request for a New Field

The request for a new field must include all the items which would have to be included in the Data Field Dictionary, that is, 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, for example, 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 may refuse to create a new field in the following, not limitative, list of cases:

    • the field does not comply with the syntax rules;
    • the format does not conform with another ISO standard;
    • the proposed field is the concatenation of existing data fields;
    • part of the proposed field is already covered by existing field(s) and only the remaining part needs to be catered for;
    • a field already exists which meets the request;
    • a field already exists which can be modified to cover the request via an additional qualifier.

Request for Amendment of an Existing Field

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 (for example, 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.

Request for Deletion of a 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.

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

Request for Registration of a New Message Version Issuer Code

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). 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.

Request for Creation of a New Message Type or Version Number

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 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.

Request for Inclusion of a New Message in the Catalogue of Messages

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, for example, 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. 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 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 already existing 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:

    • there is a message with exactly the same fields;
    • the difference with an existing message is limited to the absence in the new message of fields which are optional in the existing message;
    • the update which would be required to include the specific requirements in an existing message is minor and has no impact on the users of the existing message (for example, wider scope).

Request for Amendment of a Message

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 (for example, a mandatory field is suppressed), it must be processed like a request for deletion and a request for inclusion of a new message.

Request for Deletion of a Message from the Catalogue of Messages

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.

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

Exceptional Circumstances

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.

Updating the Electronic Form of the Data Field Dictionary and Catalogue of Messages

The electronic version of the data field 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.

E. Appeal Procedure

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.

F. Complaints

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 appeal 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.

 

 

Consult the ISO 15022 Terms of use and Privacy Statement