2012: Message Schema Design (ISO 20022)

nfessey — Sat, 11 Feb 2012 11:21:23 +0000

Thank you for a very good workshop on 24 January, and special thanks to Slawek, who flew in from Poland to be with us. It was good to be working on the project again. It was also a pleasure to welcome Janice Chapman from the SWIFT Standards Group, who guided our review and who will help us during the next stage of our project.

We spent the workshop reviewing the schema that Janice and her SWIFT colleagues had prepared. We started with the preliminary components – the interpretation of Company, Counterparty, and the legal definitions. It went very slowly because industry practice is particularly diverse in these sections. We also spent time understanding some of the SWIFT design choices, particularly the idea that the schema could be extended in many places by enabling proprietary identification schemes.

In the last hour of the workshop we reviewed the Rebates section of the schema. We made much faster progress there and we agreed that SWIFT’s interpretation was very good. If we can sustain the productivity of that last hour, it will not take long to complete our review and be ready to release a new schema which conforms much more rigorously to the ISO 20022 standards.

Janice has updated the schema following our meeting and provided four documents:

(1) The draft schema as an XSD file.

(2) The draft schema as an Excel file.

(3) An example message, based on the first few components of the schema.

(4) Rules and guidelines for users who will use the schema.

Please note that all of these documents are under development and will change as our review advances. Looking at the schema we see that it differs in several respects from the syntax that we defined it in our technical specification, 2011 Release 02. For example:

(a) The graph of the syntax written in SWIFT’s document is a different shape to the graph written in our technical specification. Also, some message elements that were optional in our interpretation have become mandatory (for example, DelegationPermitted has been written as a mandatory YesNoIndicator that enables a positive choice rather than as an optional Boolean flag with value fixed at 1). I recommend that you think of it as the same language in a different dialect. When our review is complete the syntax will be easier to use and its meaning will be as we intended it to be.

(b) The structured identifier LocalID has been replaced by specific local identifiers within the syntax. For example, in Rebates, it has been reduced to a much simpler single element “RebateNumber,” in which the sequence number is the value assigned to the element. It’s a much better way to write the syntax.

(c) A new identification concept has been introduced in several places: the “proprietary” identifier, or “Prtry.” It allows the message to be used in cases where the operator wishes to include an identifier scheme that we have not anticipated in detail. It enables the syntax to be extended without invalidating it. In SWIFT’s experience, it is a very helpful way to “future-proof” the syntax and to make it adaptable. Those of you who attended the workshop may recall that we discussed how fund platforms would be able to use this to create classification schemes for their participants, which might be very different from the classical promoter-distributor models that we are familiar with. I like the idea very much.

(d) Some terms have been adapted to fit the SWIFT ISO 20022 business models. For example, the term BankTransfer has been replaced by the term CreditTransferDetails. We have not yet reviewed that substitution with SWIFT but it is obvious that BankTransfer was our unique construction whereas CreditTransferDetails is taken from the ISO 20022 library and confers the benefit of having been tested under the SWIFT standards process. I expect that this will also enhance the potential for true STP in the future.

DMFSA

2012: Message Schema Design (ISO 20022)