ISO International Organization for Standardization
ISO 20022 UNIversal Financial Industry message scheme
                                Home

Registration Process

Any community of users or organisations (hereafter called the ‘submitting organisation’ or simply the ‘submitter’) that want to develop and use UNIFI compliant messages to support its financial transactions can submit UNIFI registration requests.

The purpose may be the creation of a new set of messages to support a specific transaction or the maintenance of an existing message or message set to accommodate the evolution of the business. The request is expected to reflect global need or usage or to enhance the global relevance of the standard, without excluding large communities of users at a regional or domestic level.

The registration process for the creation of a new set of messages is described below. The registration process for maintenance requests is slightly different and is described later on this section. Click here to download a copy of the current detailed ISO20022 Registration Procedures.

Request to create new messages

The registration process includes the steps described below (see attached flow):

1. The submitter introduces a 'business justification'

The submitter creates a business justification to give an overview of the scope, reason and estimated users / volumes / savings, etc. of the intended message set. The business justification also describes the commitment of the submitter to dedicate required resources to the development and support of the new messages. A business justification template is available from the UNIFI website.

The submitter sends the business justification to the Registration Authority (RA) at iso20022ra@iso20022.org where it is logged, checked for completeness and confirmed to the submitter. From this point on, the latest status of the submission is tracked on the UNIFI website with a copy of the latest version of the business justification.

When returning a positive acknowledgement to the submitter, the RA also forwards the business justification to the Registration Management Group (RMG).

2. The RMG evaluates the ‘business justification’

The RMG evaluates the business justification and analyses how the proposed development will improve communications and bring advantages to the industry. One major consideration of the RMG is to avoid utilizing resources of the UNIFI registration bodies in the analysis, registration, documentation, evaluation and publication of messages which may not be attractive enough to the targeted community. The RMG also wants to protect the industry against the proliferation of overlapping messages.

RMG members have four weeks (actually to the middle or end of the month following the four weeks) to forward any comments or requests for clarification to be addressed by the submitter.

  • If comments have been received on the business justification during the commenting period, the RMG secretariat sends them via e-mail to the submitter. The submitter is then given up to three weeks to update the business justification document and submit it to the RA. The updated business justification shall include:

    • updates to the text of the original business justification that the submitter may want to make based on the comments received. Such updates will be clearly highlighted using 'track change' or similar mode
    • a response to each of the received comments.

    As soon as the updated business justification is received, the RA checks it for completeness, saves a copy on the UNIFI website and emails it to the RMG secretariat for immediate re-submission to the RMG members for vote. RMG voting members then have four weeks to vote on the business justification (actually, to the middle or end of the month following the four weeks).  During this period, the RA organizes a conference call with the submitter and the RMG members who are given the opportunity to discuss the response to their comments with the submitter before casting their vote.
  • On the other hand, if there are no comments on the business justification within the four-week commenting period, the RMG voting members are given two weeks to vote on the original business justification (again, actually until mid or end of the month following the two-week period).

The RMG Secretariat informs the RA and the submitter of the approval/ rejection of the business justification.

3. The SEG endorses the ‘business justification’

If the business justification is approved, the RMG allocates it to the relevant Standards Evaluation Group (SEG). The SEG has two weeks to endorse it. The endorsement confirms that the proposed development falls into the scope of the SEG and that the business justification seems attractive from a user perspective. It also confirms that the SEG will ensure that the relevant industry bodies will be involved in – or at least informed of – the development. Any comments detected by the SEG are reported to the RMG and the submitter. Issues, if any, are resolved with the RMG.

The approved business justification also helps the SEG initiating the creation of a specific 'Evaluation Team' of experts in the field, which will evaluate the new set of messages once they are developed. The Evaluation Team will include members from the parent SEG. If necessary, additional experts will be selected by the SEG members to ensure strong representation of the future users of the messages. 

The approval and endorsement of the business justification gives the green light to the submitter to start development. From this point on, the messages in development will be called 'candidate UNIFI messages'.

Note: when the scope of the business justification crosses the scope of several SEGs, the RMG will allocate it to all of the relevant SEGs and appoint a 'Lead SEG' to drive the endorsement and future evaluation. If the business justification does not fall within the scope of an existing SEG, the RMG will either initiate the creation of a new SEG or widen the scope of an existing SEG.

4. The submitter develops the candidate UNIFI messages

The submitter is expected to develop UNIFI compliant models and messages within the timeframe indicated in its business justification. If the schedule is not met, the submitter may be requested by the RMG to provide further justification.

The RA is not resourced to undertake or participate in the development of the candidate UNIFI models, but will assist the submitter in setting up the required modelling environment, provide necessary electronic versions of the UNIFI Data Dictionary and copies of any related existing UNIFI models, and provide guidance to ensure UNIFI compliance of the candidate models. The form of the submission is to be discussed with the RA.  It is important that the submitter always re-uses the existing UNIFI Repository items and/or bases its requests for new items on previously existing ones.

In the case of several concurrent submissions, the RA treats the requests on a first-come first-served basis, unless a different priority is decided by the RMG.

Once the development is completed and the RA has checked the compliance of the models as well as the quality of the requested Repository updates, the RA enters the components of the ‘candidate UNIFI messages’ in the Repository and marks them as ‘provisionally registered’.

5. The SEG evaluates the candidate UNIFI messages

The RA generates the documentation for the evaluation of the candidate UNIFI messages by the SEG's Evaluation Team. The SEG documentation includes a copy of the models, a full description of the messages (Message Definition Report), additional contextual documentation prepared by the submitter to introduce the transaction flow and/or illustrate the message usage, a copy of the XML schemas generated by the RA from the models and examples of XML message instances prepared by the submitter.

A representative of the submitter is always invited to participate in the Evaluation Team. She/he is expected to introduce the new message set to the Evaluation Team and allow the Evaluation Team members to gain additional clarification regarding the content, business context and intent of the submission during the evaluation process. When several organizations have made a joint submission, all of them are invited to participate in the Evaluation Team.

As a preliminary step, the Evaluation Team verifies that the candidate messages are within the scope expressed in the business justification that was approved by the RMG. If not, this is raised to the submitter and the RMG which may request the submitter to introduce further justification for the items not included in the original business justification.

The main task of the Evaluation Team is to evaluate the messages from a business perspective, i.e. that the developed messages actually address the users’ needs and can be used by the user community represented by each Evaluation Team member. This includes the validation of the transaction flow, the message scopes, the message descriptions, including all (new or re-used) components, definitions etc., as included in the SEG documentation.

When the candidate UNIFI messages support a specific part of a whole transaction life cycle, the Evaluation Team also takes into account the information requirements of actors that come into play earlier or later in the end-to-end transaction lifecycle.

The Evaluation Team strives to reach a 'consensus recommendation' regarding either the approval or rejection of the submission. This is done as quickly as possible and within a maximum of three calendar months, unless otherwise agreed with the RMG.

The Evaluation Team submits the Team’s consensus recommendation to its parent SEG for endorsement. The SEG is expected to endorse the recommendation of its Evaluation Team within two weeks and communicate its decision to the RA. The RA then officially notifies the submitter and the RMG of the newly approved ‘UNIFI messages’.

6. The RA publishes the UNIFI messages

It is only after the approval by the SEG that the candidate UNIFI messages can be called UNIFI messages (or UNIFI compliant messages).

The RA publishes the UNIFI messages on the UNIFI website. This includes:

  • Publishing the approved models, Message Definition Report, XML schemas and instances in the Catalogue of UNIFI messages.
  • Registering the new messages and all related message items in the Business Process Catalogue.
  • Updating the status of all related, new or updated Data Dictionary items from 'provisionally registered' to 'registered'.
  • Making a new version of the UNIFI Repository (Business Process Catalogue and Data Dictionary) accessible through the Simple Repository Search, Advanced Dictionary Search and Advanced Catalogue Search functions.

During the entire registration process, the RA keeps the status of the submissions updated.

7. Testing and implementation

Until the newly published messages have been tested or implemented, one cannot fully guarantee that:

  • the UNIFI messages are described accurately enough in the published documentation to allow users to implement them as intended and approved by the SEG;
  • the approved messages can be implemented from a technical perspective with no or minimal adverse effects on communication infrastructures and/or applications (for example, excessive processing time).

As soon as the RA is informed that the messages have been implemented, it will indicate it in the Catalogue of Messages and show the names of the implementers, when permitted. The submitter is also invited to review the published documentation and organize/encourage testing and implementation of the messages.

The submitter, testers or first implementers are invited to communicate to the RA any remarks they have on the published documentation. The remarks may include proposals for changes to clarify the documentation, align it with what was approved by the SEG, eliminate ambiguity or correct errors that prevent implementation of the messages. They may include proposals to make the messages easier to implement or process, but may normally not include new business requirements, unless (1) they are in the scope of the original business justification and (2) the SEG, the RA and submitter jointly agree that the proposed changes can and must be implemented as soon as possible to ensure adoption of the messages.

If a correction of the messages and/or documentation is approved, the new publication is clearly announced on the UNIFI website and an 'errata' with the list of the changes is published by the RA for the convenience of implementers who would have started using the initial version of the messages/documentation. If the XML message schemas have been 'patched' to correct a mistake (the schemas did not reflect what the SEG had approved) or an error (the schema was invalid), the corrected schemas bear a new generation timestamp but keep the same version number. If any other change is made to a schema (improvement, new requirement), the message version number is increased.

* Withdrawal

At any time during the registration process and until the messages are approved by the SEG for publication, the submitter may decide to withdraw or suspend its submission, simply by informing the RA. The RA will change the status of the submission accordingly and inform the RMG and SEG.

* IPR

According to the UNIFI Intellectual Property Rights policy, the submitter keeps the IPR on the messages although it grants third parties a non-exclusive, royalty-free license to use the published information. The submitter can communicate its IPR policy to the RA for publication on this website.

* Appeals and complaints

Submitting organizations may appeal to the RMG against a decision of the RA or SEG(s). The RMG shall give its decision about such an issue within 30 calendar days of receiving the appeal. A subsequent appeal may be made to secretariat of ISO TC68, the ISO committee in charge of the UNIFI standard.

Complaints regarding the service provided by the RA or the SEGs may also be sent to the RMG. All such complaints must be in written form. Complaints must be service orientated and are not considered part of the appeal process. The RMG shall aim to respond to complaints within 60 days of receipt.

Request to update existing UNIFI messages

When a submitter wants to develop a new version of one or more existing messages, the registration process is slightly different since such a new version may impact a whole community of users.

Note: in general, new versions will be developed by the original submitter, i.e., the organization that developed the original version of the messages, based on change requests received from actual or potential users. In the original business justification, which is available from the 'Status of Submissions' page on this website, the original submitter indicates whether it is committed to maintain the messages. If this is the case, actual or potential users are expected to forward their change requests to the original submitter. If the RA receives such requests directly from the users, it forwards them to the original submitter with a copy for information to the SEG which had approved the current version of the messages. If it is not the case or if, for any other reason, another organization than the original submitter wants to develop a new version, it has to invite the original submitter to participate in the development.

The maintenance process includes the following steps (see attached flow):

1. The submitter introduces a 'maintenance change request'

The organization which wants to develop a new version of the messages creates a 'maintenance change request' where it clearly identifies the existing UNIFI message(s), the proposed change(s) and the proposed timing for the development and availability of the new version. For each of the changes, the maintenance change request describes the purpose of the change, the community of users interested by the change and the urgency and expected benefit/impact of the proposed change on current or future users. The maintenance change request also describes the commitment of the submitter to dedicate required resources to the development and support of the updated messages. A maintenance change request template is available from the UNIFI website.

The submitter sends the maintenance change request to the Registration Authority (RA) at iso20022ra@iso20022.org where it is logged, checked for completeness and confirmed to the submitter. From this point on, the latest status of the submission is tracked on the UNIFI website with a copy of the latest version of the maintenance change request.

When returning a positive acknowledgement to the submitter, the RA also forwards the maintenance change request to the Standards Evaluation Group (SEG) which had approved the current version of the identified UNIFI messages.

Note: when the current version of the messages had been approved by several SEGs under the leadership of a Lead SEG, the RA forwards the request to the Lead SEG and copies the other SEGs.

2. The SEG reviews the 'maintenance change request’

The release of a new version of a message may potentially impact all current users. Therefore, maintenance change requests are first validated by the (Lead) SEG which approved the current version of the messages on behalf of the community of users. If an Evaluation Team was established by the SEG to evaluate the current version of the messages, the SEG may re-establish this Evaluation Team and ask for their expert opinion on the validity of each requested change.

The submitter of the maintenance change request is invited to participate in the Evaluation Team to present the changes and give any further clarification to the Evaluation Team members regarding the content, business context and intent of the proposed updates. When several organizations have made a joint submission, all of them are invited to participate in the Evaluation Team. When the maintenance change request is submitted by an organization different from the original submitter, the original submitter is also invited to participate in the Evaluation Team.

The result of the review is a recommendation to the RMG to either approve or reject each of the changes proposed by the submitter. It also includes an opinion on the urgency of the changes recommended for approval and gives a reason for the changes it recommends rejecting. The time that the Evaluation Team needs to review the maintenance change request and issue its recommendations depends on the number of requested changes and the time required to re-establish the Evaluation Team. In general, the Evaluation Team is able to issue a recommendation within the four weeks that follow the first meeting of the Evaluation Team.

The SEG has two weeks to endorse the recommendation of its Evaluation Team, update the 'maintenance change request' with its recommendation for each of the proposed changes and forward the updated document to the RA, which in turn, transmits it to the RMG secretariat.

3. The RMG approves the 'maintenance change request’

The RMG secretariat will transmit the maintenance change request including the recommendation of the SEG to the RMG members for vote on each of the proposed changes. The RMG members have four weeks (actually to the middle or end of the month following the four weeks) to approve or reject the proposed changes, based on the recommendations of the SEG. RMG members give a reason when they vote against a change which the SEG recommended to approve.

The RMG Secretariat updates the maintenance change request to indicate the results of the vote for each change request and sends it to the RA. The results include the approved changes and the rejected changes, with the reason given by the SEG or the RMG. The RA posts a copy of the updated maintenance change request on the UNIFI website and informs the submitter and the SEG.

The RMG may organise a conference call with the submitter when there is no clear consensus among the RMG voting members.

4. The submitter develops the new candidate UNIFI messages

The submitter is expected to develop a new UNIFI compliant version of the models and messages, which includes the changes approved by the RMG, within the timeframe indicated in the approved maintenance change request. If the schedule is not met, the submitter may be requested by the RMG to provide further justification.

The RA is not resourced to undertake or participate in the development of the new candidate UNIFI models, but will assist the submitter in setting up the required modelling environment, provide necessary electronic versions of the UNIFI Data Dictionary and copies of the current version of the UNIFI models, and provide guidance to ensure UNIFI compliance of the candidate models. The form of the submission is to be discussed with the RA. On a case by case basis, the RA may advise the use of the portfolio of registration request forms which are available as downloadable Excel files. It is important that the submitter always re-uses the existing UNIFI Repository items and/or bases its requests for new items on previously existing ones.

In the case of several concurrent submissions, the RA treats the requests on a first-come first-served basis, unless a different priority is decided by the RMG.

Once the development is completed and the RA has checked the compliance of the new models as well as the quality of the requested Repository updates, the RA enters the components of the new ‘candidate UNIFI messages’ in the Repository and marks them as ‘provisionally registered’.

5. The SEG evaluates the new candidate UNIFI messages

The RA generates the documentation for the evaluation of the candidate new version of UNIFI messages by the SEG's Evaluation Team. The SEG documentation includes a copy of the updated models, a full description of the new message version (Message Definition Report), and updated contextual documentation prepared by the submitter to introduce the new transaction flow and/or illustrate the message usage, a copy of the new XML schemas generated by the RA from the models and examples of XML message instances prepared by the submitter.

The Evaluation Team verifies that the new version of the messages actually includes the approved changes (only) and indeed better addresses the (future) users’ needs.

The Evaluation Team strives to reach a 'consensus recommendation' regarding either the approval or rejection of the submission. Although the timeframe for this evaluation is the same as for the evaluation of a new set of messages (within a maximum of three calendar months), the Evaluation Team is generally much quicker, since it has already evaluated each of the requested changes (see item 2. above).

The Evaluation Team submits the Team’s consensus recommendation to its parent SEG for endorsement. The SEG is expected to endorse the recommendation of its Evaluation Team within two weeks and communicate its decision to the RA. The RA then officially notifies the submitter and the RMG of the newly approved new version of ‘UNIFI messages’. It is only after the approval by the SEG that the candidate new version of UNIFI messages can be called UNIFI messages (or UNIFI compliant messages).

6. The RMG agrees the timing of publication

Once the new version has been approved by the SEG, the RMG is requested to approve the timing of publication of this new version. The RMG is indeed responsible for the 'packaging' and timing of release of new versions on the UNIFI website.

7. The RA publishes the new version of the UNIFI messages

The RA publishes the new version of the UNIFI messages on the UNIFI website. This includes:

During the entire registration process, the RA keeps the status of the submissions updated.

8. Testing and implementation

Until the newly published messages have been tested or implemented, one cannot fully guarantee that:

  • The updates to the UNIFI messages are described accurately enough in the published documentation to allow users to implement the new version as intended and approved by the SEG;
  • The approved new version can be implemented from a technical perspective with no or minimal adverse effects on communication infrastructures and/or applications (for example, excessive processing time).

As soon as the RA is informed that the new messages have been implemented, it will indicate it in the Catalogue of Messages and show the names of the implementers, when permitted. The submitter is also invited to review the published documentation and organize/ encourage testing and implementation of the new version of the messages.

The submitter, testers or first implementers are invited to communicate to the RA any remarks they have on the published documentation. The remarks may include proposals for changes to clarify the documentation, align it with what was approved by the SEG, eliminate ambiguity or correct errors that prevent implementation of the messages. They may include proposals to make the new version easier to implement or process, but may normally not include new business requirements, unless (1) they are in the scope of the approved maintenance change request and (2) the SEG, the RA and the submitter jointly agree that the proposed changes can and must be implemented as soon as possible to ensure adoption of the new version.

If a correction of the messages and/or documentation is approved, the new publication is clearly announced on the UNIFI website and an 'errata' with the list of the changes is published by the RA for the convenience of implementers who would have started using the published version of the messages/documentation. If the XML message schemas have been 'patched' to correct a mistake (the schemas did not reflect what the SEG had approved) or an error (the schema was invalid), the corrected schemas bear a new generation timestamp but keep the same version number. If any other change is made to a schema (improvement, new requirement), the message version number is increased.

* Withdrawal

At any time during the registration process and until the new version of the messages is approved by the SEG, the submitter may decide to withdraw or suspend its submission, simply by informing the RA. The RA will change the status of the submission accordingly and inform the RMG and SEG.

* IPR

According to the UNIFI Intellectual Property Rights policy, the submitter keeps the IPR on the messages although it grants third parties a non-exclusive, royalty-free license to use the published information. When there are several submitters, for example when the submitter of a new version is not the same as the submitter(s) of the previous version(s) of the messages, all submitters will share the IPR.

* Appeals and complaints

Submitting organizations may appeal to the RMG against a decision of the RA or SEG(s). The RMG shall give its decision about such an issue within 30 calendar days of receiving the appeal. A subsequent appeal may be made through the secretariat of ISO TC68, the ISO committee in charge of the UNIFI standard.

Complaints regarding the service provided by the RA, the SEGs or the submitting organizations may also be sent to the RMG. All such complaints must be in written form. Complaints must be service orientated and are not considered part of the appeal process. The RMG shall aim to respond to complaints within 60 days of receipt.