Presentation is loading. Please wait.

Presentation is loading. Please wait.

UNIFI (ISO 20022) Introduction to ISO –

Similar presentations


Presentation on theme: "UNIFI (ISO 20022) Introduction to ISO –"— Presentation transcript:

1 UNIFI (ISO 20022) Introduction to ISO 20022 –
UNIversal Financial Industry message scheme UNIFI (ISO 20022) UNIFI is the nickname of ‘ISO UNIversal Financial Industry message scheme’, the platform proposed by ISO to develop all financial messages. UNIFI doesn’t describe the messages themselves, it is a ‘recipe’ to develop message standards. The main ingredients of this recipe are a development methodology, a registration process and a central repository. This presentation gives an introduction to UNIFI. When going through it, you will become familiar with the recipe and its ingredients and with the various UNIFI ‘registration bodies’ which provide the ISO development platform. The presentation will however not go into technical details on modelling or XML. Note to the presenter: Add info as appropriate to this slide (your name, institution, etc). You may also want to add your own address to the Q&A slide at the end of the presentation (last slide). This presentation contains a lot of slides and information since it is also used as a ‘self study’ introduction guide for new UNIFI participants. If you use it as a real presentation, feel free to select the slides you want to present depending on your audience and allocated time slot. UNIFI_(ISO_20022)_v18

2 Agenda UNIFI (ISO 20022): value proposition the standard
registration bodies registration process the Repository The deployment of UNIFI Cross industry harmonisation Interoperability within the financial industry Q & A This is the agenda for the presentation. As you can see, we will spend most of the time on various aspects of what UNIFI is and how the platform is built. (We will also explain how it compares with ISO 15022, the securities message scheme which you may be familiar with). We will then see concretely how the platform has been successfully deployed, who is participating and what has been accomplished so far. We will also spend a few minutes on how UNIFI fits into the more global picture of harmonisation of communications across all industries. We will end with two concrete examples of how UNIFI can help interoperability with other financial message standards Let’s start with the value proposition of UNIFI. UNIFI_(ISO_20022)_v18

3 The UNIFI value proposition (1/5)
Objective To enable communication interoperability between financial institutions, their market infrastructures and their end-user communities Major obstacle Numerous overlapping standardisation initiatives looking at XML financial messages: MDDL, FIX, FinXML, VRXML, RIXML, XBRL, FpML, IFX, TWIST, SWIFT, RosettaNet, OAGi, ACORD, CIDX, etc. I think you will agree that we would all benefit from tremendous cost savings if we could use ONE single message standard for all our financial communications: whichever the counterparty (financial institutions, market infrastructures, supplier of financial information, private and corporate customers, etc.); whichever the business domain (payments, securities, treasury, trade services, etc.); whichever the network (public or proprietary, domestic or international). At the beginning of the decade, the general interest for IP (Internet Protocol) and XML was perceived as a unique opportunity for the industry to move to such a single, common XML-based language. There was a problem however: XML is not a language, but a meta-language which everyone can use to define his own dialect…… and this is what has happened: several standardisation initiatives started developing XML messages using each their own dialect. This led to: an increased risk for several ‘languages’ and a waste of resources (duplicated efforts) and a further risk of divergence when more than one initiative focus on the same business area. UNIFI_(ISO_20022)_v18

4 The UNIFI value proposition (2/5)
Proposed solution A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives In an attempt to solve that problem, ISO proposes ONE single standardisation approach, a common ‘recipe’ - which includes a common development methodology, a common process and a common repository - to be used by ALL financial standards initiatives. This recipe is called UNIFI or ISO If all financial standards initiatives were using this recipe, we would avoid duplication of efforts and the messages developed in parallel by all these initiatives would look like if they were developed by a single developer. UNIFI (ISO 20022) UNIFI_(ISO_20022)_v18

5 The UNIFI value proposition (3/5)
Convergence into ONE standard is the long term objective…. ONE standard approach used by ALL is however a very long term objective. It will not happen overnight. In the interim, several standards need to coexist – if we want to respond efficiently to competitive pressures and regulatory demands. One of the most interesting characteristics of UNIFI is that it provides a way to achieve the long term ‘convergence’ objective, and, at the same time, it also provides a way to facilitate the short term ‘coexistence’ of several standards.... …but in the interim several standards need to coexist to enable quick response to competitive pressures and regulatory demands UNIFI_(ISO_20022)_v18 Source: John Mersberg, IBM Corporation

6 The UNIFI value proposition (4/5)
Growth adds exponential complexity and expense… EDIFACT RosettaNet Without common building blocks: Point-to-point connection Data is mapped directly from one application to another Costly, unscalable and difficult to implement and maintain Process, routing, rules logic needs to be coded to specific message types IFX SWIFT Proprietary format OAGi When standards are developed independently of each other, ‘translating’ from one standard to another requires to map data directly from one application to another and vice-versa. This is costly, unscalable and difficult to implement and maintain. Each time you add a new standard to support, it increases the complexity and cost exponentially. Let’s take an example. If we have seven standards that each need to communicate back and forth with each and every single one of the six others, we need 7*6 = 42 translation interfaces, but if we increase the number of standards with, say, three additional ones, so we have ten standards altogether that each need to communicate with the nine others, we need more than the double number of interfaces, in fact 10*9 = 90 interfaces. TWIST 42 interfaces = n * (n-1) UNIFI_(ISO_20022)_v18 Source: John Mersberg, IBM Corporation

7 The UNIFI value proposition (5/5)
Standardised implementation reduces cost, time to effect change and improves overall performance… EDIFACT RosettaNet Canonical message model = True process integration Reduced brittleness, faster to respond to change Shared message services – single/shared parser, message independent rules engine, etc. Unified monitoring / audit trail IFX SWIFT Canonical Message Model (i.e. ISO 20022) Proprietary format OAGi Using a single message model, for each of our seven standards, the translation would only need to be made once into the message model and once to receive from the model. In other words, we would need to develop only 2 translation interface per standard (to the model and from the model). Such an approach of developing syntax-independent business models is the core of the UNIFI standard… Longer term the XML messages generated from the model would become the one and only standard we are looking for. While getting there, the message model helps co-existence. TWIST 14 interfaces = n * 2 UNIFI aims at long term convergence, while facilitating short term coexistence… UNIFI_(ISO_20022)_v18 Source: John Mersberg, IBM Corporation

8 UNIFI - Illustrating business modelling
ISO standardises common data objects… Account Order Date All institutions have their own sets of data objects …and groups them into ‘syntax-neutral’ message models, which... Order Date This slide illustrates the concept of syntax-independent business modelling. Each institution has its own set of internal ‘data objects’ (or ‘words’) to express the various business concepts. The goal of UNIFI is to identify and standardise the ‘words’ that are shared between institutions, and store them in the ‘data dictionary’ of the UNIFI Repository. Using the agreed standard ‘words’ as lego blocks, the developers can build syntax-independent message models, which can be transformed into message formats according to the desired syntax. The current preferred UNIFI syntax is XML, but, should a new better syntax be chosen, the models would not need to be changed: only the rules to transform the message models in the desired message formats would change. Syntax independent business modelling is key to the UNIFI standard… The models evolve with the business, while the formats evolve with the technology to benefit from the latest innovations with regard to automation, ease of implementation, openness and cheapness of products, etc. The UNIFI recipe offers a better, cheaper and faster way of developing and implementing message standards. XML ISO 15022 … can be ‘transformed’ in message formats in the desired syntax FIX EDIFACT UNIFI_(ISO_20022)_v18

9 The UNIFI recipe – Major ingredients (1/2):
Modelling-based standards development - Syntax-independent business standard - Validated by the industry Syntax-specific design rules for XML - Predictable and ‘automatable’ - Protect standard from technology evolution Let’s now look at the main ingredients of the UNIFI recipe: - As we just said, the syntax independent business modelling methodology is the most important and most innovative feature of the standard. This modelling methodology allows developers to capture the ‘business standard’ prior to, and independently of, the physical format of the future messages. The modelling methodology uses ‘UML’ (Unified Modelling Language) and proposes a two-step approach. First, the developer will describe the overall ‘business model’: who are the actors, what kind of processes they complete, what kind of information they need to complete these processes, etc. Once it’s done, they will define, still using UML, the best transaction flow to communicate the information required to the right actors at the right time. Before acceptance, the candidate UNIFI models are validated by representatives of the future users from the industry, nominated by ISO. This is to get the buy-in of the future users before the messages are published in the UNIFI Repository. Another major component of UNIFI is its set of pre-agreed design rules to transform the message models into physical message formats in the desired syntax - currently XML as we have already seen. These design rules ensure that all UNIFI XML schemas are structured consistently, in a way that is ‘predictable’ to the receiver (and application vendors) and thus easier to automate. The fact that the syntax design rules are clearly separated from the modelling methodology ensures that models will not need to be changed when/if XML is superseded by a new better syntax solution Also part of the standard is a ‘reverse engineering’ technique to ‘re-capture’ the functionality of existing non UNIFI compliant message standards and feed it into the UNIFI models, thereby facilitating interoperability, co-existence and migration from existing messages to their UNIFI compliant equivalent. It’s the combination of the business modelling and the reverse engineering which makes UNIFI so unique in supporting interoperability. Reverse engineering approach - Protect industry investment and ease interoperability - Prepare for future migration UNIFI_(ISO_20022)_v18

10 The UNIFI recipe – Major ingredients (2/2):
Development / registration process - Clearly identified activities and roles - Business experts and future users involved upfront Repository on the ISO website - Business Process Catalogue & Data Dictionary Outside of official standard (maintained by registration bodies) Two additional major ingredients of UNIFI: - UNIFI describes a strict registration process to avoid duplication of efforts and ensure the right priority of developments. Business experts and future users are involved at an early stage to ensure all business requirements have been addressed. This involvement of the community may take time but is absolutely critical to get a good standard, a standard that will be used. Finally, the cornerstone of the UNIFI framework is its Financial Repository where approved models, transactions, messages and their components are stored. The Repository content is published on the UNIFI website: It contains two parts the ‘Data Dictionary’, with all the components (‘lego blocks’) used in models and message formats, and the Business Process Catalogue, with the business models, transactions and messages. The organisation of the repository is described in the UNIFI standard as well as the process to approve the repository items, but the content of the repository is kept outside of the standard itself. This is to avoid that the issuance of a new or updated message be submitted to the lengthy approval process of ISO International Standards, which may take several years. Instead, ISO has approved once and for all the recipe of development and approval of UNIFI messages, which is described in the standard. UNIFI_(ISO_20022)_v18

11 UNIFI – The five parts of ISO 20022
International Standard: Overall methodology and format specifications for inputs to and outputs from the ISO Repository International Standard: Roles and responsibilities of the registration bodies Technical Specification: ISO modelling guidelines Technical Specification : ISO XML design rules Technical Specification: ISO reverse engineering Part 1: Part 2: Part 3: Part 4: The standard itself consists of the shown 5 parts published in December 2004 under the name ‘ISO Financial Services - UNIversal Financial Industry message scheme’: Together they cover the major components of UNIFI which we have just looked at. Part 1 and 2 have been approved as ‘International Standards’. Parts 3, 4 and 5 have been approved as ‘Technical Specifications’, a lower level of ISO document, as the ISO Working Group of experts that defined the standard felt that they were pioneering new methodologies that could still mature and benefit from the experience of the users before being presented for approval as ‘International Standards’. In December 2005, ISO formed a new Working Group, WG4, which will review the technical specifications in the years to come based on technological evolution, best practice and experience gained from using the standard. Copies of the five parts of the ISO standard can be purchased from your national standards body or directly from the website. Part 5: Copies can be obtained from UNIFI_(ISO_20022)_v18

12 UNIFI – The actors (1/2) Submitting organisations Could be Reasons
Communities of users or organisations that want to develop UNIFI compliant messages to support their financial transactions Could be ACBI ACORD Clearstream CLS Euroclear FED FIX FpML IFX ISITC ISTH MDDL OAGI Omgeo SWIFT TWIST Etc. To whom is the UNIFI recipe targeted? The UNIFI platform is available to all developers of message standards. And the UNIFI message standards are freely and publicly available to all communities of users. The goal is that the ISO platform will attract all developers of financial message standards. It allows each financial standards body to continue to focus on its domain of expertise and keep its Intellectual Property Rights (IPR) on the UNIFI-compliant messages it will develop, while, all together, offering the community a range of messages in the same language, as if they were developed by a single body. The derived benefits in terms of interoperability and coexistence are, on their own, a key reason to opt for UNIFI. Market infrastructures (ACHs, RTGS, CSDs, stock exchanges, etc) are adopting and pushing developers to embrace the UNIFI standard for the benefit of their common customers. Industry initiatives and regulatory requirements, such as SEPA, Giovannini, MiFID and FATF, which all look for open standards to support their harmonisation of business practices, are likely to see UNIFI as an ideal recipe. It is important to note that the so-called ‘submitting organisations’ that want to use the UNIFI recipe to develop financial messages do not need to be affiliated to ISO, they just have to follow the UNIFI registration process. The organisations ‘in yellow’ on the slide have already proposed development projects to UNIFI. Reasons Creation of a new set of UNIFI messages to support a specific transaction Update of existing UNIFI message sets to accommodate the evolution of the business UNIFI_(ISO_20022)_v18

13 UNIFI – The actors (2/2) Registration Management Group, RMG
Overall governance / court of appeal Approve business justifications for new standards Create Standards Evaluation Groups, SEGs Standards Evaluation Groups, SEGs Represent future users of specific financial areas Validate message standards Registration Authority, RA Ensure compliance Maintain and publish UNIFI Repository The registration process is described in part 2 of the standard. It involves three registration bodies, which interact with the ‘submitting organisations’ wanting to use the UNIFI recipe to develop financial messages: The Registration Management Group (RMG) is the highest registration body. It is made of senior industry experts nominated by ISO, who, all together, represent all sectors of the financial industry. The RMG monitors the overall registration process including the performance of the other registration bodies. It acts as a ‘court of appeal’ if no consensus can be found or if there are conflicts between the various parties involved in the process. The RMG evaluates and prioritizes the business justifications introduced by submitting organisations that want to develop new (or update existing) UNIFI messages. The RMG also initiates the creation of the Standards Evaluation Groups (SEG). The Standards Evaluation Groups (SEGs), are groups of industry experts nominated by ISO, which each represents the future users of UNIFI messages in a particular financial domain. Their role is to ensure that the candidate UNIFI messages actually address the needs of the future users. All candidate UNIFI messages are validated by one or more SEG(s) depending on the scope of the messages. Finally, the Registration Authority, the RA, is the guardian of the UNIFI financial repository. SWIFT has been nominated by ISO to provide the RA services. The role of the RA is to support the development of submitting organisations, ensure compliance of the developed models with the UNIFI technical specifications and performs the transformation of message models into compliant XML schemas. SWIFT has developed a ‘standards workstation’ that generates the XML schemas from the models automatically according to the UML-to-XML design rules described in part 4 of the standard. The RA is also responsible to maintain the UNIFI website ( and publish updated extracts of the UNIFI Repository on a regular basis. Let’s now look at the registration process itself UNIFI_(ISO_20022)_v18

14 UNIFI - The registration process (1/3)
M G m o n i t r s Submitter Financial industry group or standards body Business justification Business justification RMG Project approval & allocation to a SEG SEG Endorsement of scope and developers Submitter & RA Development & provisional registration SEG Business validation & technical assessment 1) The entry point in the registration process is the preparation of a ‘Business Justification’ by the submitting organisation. The Business Justification must describe the high level scope of the messages to be developed and the reason why they are needed. It must identify the communities of potential users and the kind of benefits that these potential users are expected to enjoy. To the extent possible, the submitter will also give a concrete idea of the estimated number of users and volume of messages, as well as the expected benefits or savings for the industry. Finally, the submitter will give some indication about the other organisations that will be involved in the development, if any, the kind of support that will be required from the RA and the development timing. A template for the Business Justification is available for download from the UNIFI website. The Business Justification is normally a ‘high level’ justification, which is introduced by the submitter before starting the actual development. Therefore, it is not expected to already include a detailed description of the future messages, which will only be known after the modelling. 2) The Business Justification is reviewed by the RMG. The RMG will decide whether the proposed development fits into the UNIFI spectrum, does not duplicate the already existing messages and is indeed beneficial to the community. If the request is approved, the RMG decides which SEG(s) will be in charge of the evaluation of the messages, once developed. When the workload of the SEGs and/or the RA is high, the RMG decides about the priority of approved submissions. 3) The approved Business Justification is then forwarded to the assigned SEG(s) which reviews and endorses the scope. As representatives of the future users, the SEG is best place to confirm whether the proposed scope is indeed attractive for the market. The SEG also checks that the right organisations are involved in the development. 4) The submitting organisation starts developing UNIFI compliant business and message models. The RA assists the submitter as much as possible during this phase in order to ensure that the models are compliant and use the right components from the Data Dictionary. If need be, the RA creates additional dictionary items. All these new items appear as ‘provisionally registered’ in the Repository. When the development is completed, the RA generates the XML schemas and prepares with the submitter a comprehensive documentation for the SEG. The documentation includes the provisional message models, the full description of the message formats, the XML schemas and some examples. 5) Based on this documentation, the SEG(s) evaluates the candidate UNIFI messages. The main goal of the SEGs is to get the buy-in of the future users from a business perspective, although they are also asked to verify the technical ‘implementability’ of the proposed solution. The submitting organisation is participating to the evaluation to help the SEG understand the proposed solution and address any question that would be raised by the SEG members. 6) When/if the SEG approves the messages, the RA changes the provisional registration status to an official registration status in the UNIFI Data Dictionary and publish the new ‘UNIFI messages’ in the Business Process Catalogue on (Note: provisionally registered messages are not shown in the Business Process Catalogue.) All along, the RMG monitors the work and if need be, arbitrates any disputes. It is worth noting that the above registration process is valid for both the creation of new messages and the update of existing messages. RA Official registration Repository Dictionary Catalogue Publication UNIFI_(ISO_20022)_v18

15 UNIFI - The registration process (2/3)
M G m o n i t r s Submitter Financial industry groups & standards bodies Business justification Business justification RMG Project approval & allocation to a SEG Candidate UNIFI messages SEG Endorsement of scope and developers Submitter & RA Development & provisional registration SEG Business validation & technical assessment Once the Business Justification is approved by the RMG and as long as the messages have not been approved by the SEG, the messages are called ‘candidate UNIFI messages’. Once they are approved by the SEG for publication in the Repository, the messages are called ‘UNIFI messages’ or ‘UNIFI compliant messages’. RA Official registration UNIFI messages Repository Dictionary Catalogue Publication UNIFI_(ISO_20022)_v18

16 UNIFI - The registration process (3/3)
Business justification UNIFI Registration Management Group UNIFI Registration Authority UNIFI Standards Evaluation Groups ISTH MDDL UNIFI Financial Repository Business models FpML Securities UNIFI Users SWIFT Data Dictionary Candidate UNIFI messages Let’s use this other illustration to summarize the registration process:  The first step is the submission of a ‘business justification’ by the potential developer to the RMG. If it approves it, the RMG also decides which SEG(s) will be in charge of following the development of the messages from the perspective of the future users.  The developing organisation starts building the business and message models, using what already exists in the repository. If something is missing, they ask the RA to create additional ‘provisionally registered’ dictionary items.  From the candidate message models, the RA generates the XML schemas and prepares an exhaustive documentation about the candidate UNIFI messages for evaluation by the assigned SEG(s).  Once the SEG(s) approve(s) the submission, the RA changes the new dictionary items from being ‘provisionally registered’ to being ‘registered’ and publishes the UNIFI models and messages in the Business Process Catalogue. FIX UNIFI messages Payments Business Process Catalogue ISO WGs TBG5 UNIFI_(ISO_20022)_v18

17 The Financial Repository
UNIFI – The Repository The Financial Repository Data Dictionary - Business Concepts - Message Concepts - Data Types Business Process Catalogue - Financial business process models - Financial business transactions, including messages - XML message schemas The UNIFI Repository is maintained by the RA which publishes it on on a regular basis to show newly registered items. As already said, the repository consists of two parts: the Data Dictionary and the Business Process Catalogue The Data Dictionary contains the common ‘lego blocks’ that are used to express pieces of information in: business models, ie, the business concepts, and messages, ie, the message concepts, which are derived from the business concepts. The Dictionary also contains the data types which describe the various formats or values used to express data in business concepts or message concepts. All these dictionary items are first created and ‘provisionally registered’ by the RA upon request of submitters that develop new models and messages. They become officially ‘registered’ after approval of the SEGs. Of course, the goal of UNIFI is to always use the same message component in all messages that need to transport the same piece of information. Both provisionally registered and registered Dictionary items are shown on the UNIFI website for use by developers. The Business Process Catalogue is intended to contain three categories of items: The business models which describe the various business processes performed by the business actors in each business area and the kind of information these actors need to receive to be able to perform the business processes they are in charge of. The business transactions that describe how to convey the right information to the right actors at the right time across the various business processes necessary to complete the end-to-end lifecycle of a financial transaction. This transaction includes the flow of messages and the description of each message model. The XML message schemas derived from the message models, which can be viewed as ‘computer processable’ message formats. The models are developed by the submitting organisations and provisionally registered by the RA, which transforms the message models in XML schemas. All these ‘provisionally registered’ Catalogue items are NOT shown on the UNIFI website until they are approved by the SEG and officially registered by the RA. UNIFI_(ISO_20022)_v18

18 Continuing in today’s agenda
UNIFI (ISO 20022) The deployment of UNIFI Now that we have seen the ‘theory’ of UNIFI, let’s describe how it has been concretely deployed, who is participating and what has been accomplished so far. UNIFI_(ISO_20022)_v18

19 UNIFI - The deployment Approval of the international standard 
Selection of the Registration Authority  Set-up of  Creation of Registration Management Group  Creation of the first Standards Evaluation Groups  Registration and publication of first ‘UNIFI messages’  The deployment of the UNIFI platform took place over 2004 and 2005: The standard was approved and published in 2004. SWIFT has been approved as the Registration Authority in 2004. The website was also set up in It gives access to the ISO Repository, but also to e.g. Information about the registration process, including the template for business justifications, the latest registration status of the various submissions information about the registration bodies, FAQ, etc. The Registration Management Group (RMG) had its first meeting in January 2005, where it initiated the creation of the first two Standards Evaluation Groups, one for the payments area and one for the securities industry. These first two SEGs had their first meeting in June 2005 And the first set of UNIFI messages were approved for publication by the Payment SEG in September 2005. The deployment of the UNIFI platform is completed, but, of course, the promotion of the platform to users and developers is still going on… Ongoing: promotion to developers (standardisers, industry bodies) and users (vendors, end-users) UNIFI_(ISO_20022)_v18

20 UNIFI – How does it fit into the ISO structure?
ISO Technical Committee TC68 Financial Services SC7 Core banking SC4 Securities SC2 Security SC6 Retail UNIFI RMG SEG Payments Securities RA WG4 UNIFI Review RMG members nominated by P-member countries and A-liaison organisations SEG members nominated by all member countries and liaison organisations Where does the UNIFI platform fit in the ISO structure? ISO is a federation of 146 national standards bodies, ie, the ISO member countries. The standardisation work is spread over various ‘Technical Committees’ (TCs) to which the 146 ISO member countries can decide to participate. Technical Committee TC68 is in charge of all ISO standards related to Financial Services (such as the BIC, the IBAN, the ISIN, the CFI, the MIC, ISO 8583, ISO 15022, and many others including UNIFI-ISO 20022). The work of TC68 is further split among four ‘Sub-committees’ (SCs), each in charge of standards for a specific area. In total, 61 ISO member countries are involved in the work of TC68 and its Subcommittees, among which 25 are really actively participating in the standardisation work (they are called the ‘P’-member countries). In addition, standards organisations, which, because of their international nature, cannot access the ISO work through a specific country, can be authorized to establish a direct ‘Liaison’ with the TCs or SCs they are interested in. When really active in a committee, these Liaison Organisations are called category ‘A’ liaison organisations. In total, TC68 and its sub-committees have accepted 23 liaison organisations, among which 17 category ‘A’ Liaisons, such as UN/CEFACT TBG5, ISDA/FpML, FIX, MDDL, ISITC, TWIST, AMEX, VISA, Euroclear, Clearstream and SWIFT. UNIFI, because it covers all financial messages, is the only standard which reports directly to TC68 instead of one of its Subcommittees. As such, the UNIFI Registration Management Group reports to TC68 and the RMG members can be nominated by the 25 P-member countries and the 17 category ‘A’ liaison organisations.The RMG monitors the RA and the SEGs. The RA is nominated by TC68 and has a specific contract with ISO. The SEG members can be nominated by any of the 61 TC68 member countries or 23 liaison organisations. Also reporting directly to TC68 is the new Working Group 4 (WG4) which met for the first time in December As said earlier, the mandate of WG4 is the general review of the UNIFI standard focusing on the Technical Specifications (parts 3 to 5) which should be submitted as International Standards in the next 3 to 6 years. WG4 is working in close cooperation with the RMG to smoothly plan the introduction of improvements and avoid detrimental impacts on users. UNIFI_(ISO_20022)_v18

21 UNIFI – Registration Management Group
Members - 47 senior managers from: 17 countries: AT, AU, CA, CH, DE, DK, FI, FR, GB, JP, KR, LU, NL, NO, SE, US, ZA. 9 liaison organisations: Clearstream, ECBS, Euroclear, FIX, FpML, ISITC, SWIFT, TWIST, UN/CEFACT/TBG5. Convener: Sandy Throne, DTCC (US); Vice-convener: Gerard Hartsink, ABN Amro (NL) Meetings: Jan 2005, Sep 2005, Jan 2006, May 2006 Key decisions: Creation of a Payments and a Securities SEGs Creation of Trade Services SEG in 2006 Approval of first 13 projects (Business Justifications) The RMG has been very successful from the start. 17 P-member countries and 9 ‘A’ liaison organisations have already decided to participate in the RMG and these figures are still increasing, demonstrating the interest of the community for UNIFI. In total, 47 senior managers involved in various financial industry sectors are participating in the RMG. The RMG is convened by Sandy Throne, who is a well known expert in securities industry standards, and the vice-convener is Gerard Hartsink, also chairman of the European Payments Council (EPC). The RMG holds regular meetings. Among the key decisions taken so far are: The creation of the first two Standards Evaluation Groups in 2005, with a third one planned to be created in the course of 2006 The approval of the first 13 Business Justifications for development of candidate UNIFI messages. Additional Business Justifications are under evaluation. The list and latest status of all submissions is maintained on the UNIFI website at UNIFI_(ISO_20022)_v18

22 UNIFI – The Payments SEG (1/3)
Members – 30 experts 13 countries: AT, AU, CH, DE, DK, FI, FR, GB, NL, NO, SE, US, ZA 4 liaison organisations: Euroclear, IFX, SWIFT, UN/CEFACT/TBG5 Convener: Len Schwartz, ABN Amro (NL); Vice-convener: Bob Blair, JPMorganChase (US) Kick-off meeting in June 2005 Approved: C2B payment initiation (SWIFT/ISTH) Under evaluation: Exceptions and investigations (SWIFT), Direct Debits (SWIFT) Next: Interbank credit transfers (SWIFT), Cash management (SWIFT/ISTH) the Payments SEG has attracted 30 industry experts from 13 countries and 4 liaison organisations. These figures are also evolving and the list of SEG members is maintained up-to-date on the UNIFI website. Len Schwartz and Bob Blair, Convener and Vice-convener, are active in many standards initiatives focusing on payments, such as the IST Harmonisation Group (a MoU between IFX, OAGi, TWIST and SWIFT) and the sponsoring CSTP Banks Group. The Payments SEG had a physical kick-off meeting in June 2005 and has since worked via conference calls. In September 2005, they approved the very first set of UNIFI messages: a set of 4 messages covering the area of ‘customer to bank credit transfer initiation’, which includes the so-called ‘core payment kernel’ developed by the IST Harmonisation Team. They are currently evaluating a set of 16 messages developed by SWIFT to cover exceptions and investigations in the payments area. Also on their plate are: - 2 messages covering the direct debit payments, followed by 6 interbank credit transfer payments. These direct debit and credit transfer messages are developed by SWIFT and will be used in the new SEPA environment. - a whole suite of 31 cash management messages developed by SWIFT, and the IST Harmonisation Team for the bank-to-customer portion (advice and statements). It is expected that all these messages will be evaluated and eventually approved by Q3 2006, which would offer to UNIFI users a comprehensive solution to accommodate payment transactions end-to-end. UNIFI_(ISO_20022)_v18

23 UNIFI – The Payments SEG (2/3)
covering instruments such as: Payments Credit transfers Cheques covering actors such as: Financial institutions Direct debits Private & corporate customers Clearing houses & RTG systems Debit & credit cards The scope of the Payments SEG covers the various payment instruments, all payments business actors, including the (non financial) initiators or beneficiaries of a payment, and.. Central banks Payment ‘factories’ UNIFI_(ISO_20022)_v18

24 UNIFI – The Payments SEG (3/3)
Clearing & settlement including business areas such as: Interbank transfers via correspondent banking or ACHs, high value payments, low value bulk payments, RTGS, etc. Payment initiation Retail / commercial payments, communications between the ordering customer and its bank, etc. Payments Cash management between various actors: … the various payments business areas, including the customer-to-bank space and the interbank space. The composition of a SEG - and the ability of its members to interface with the right external sources of expertise - is critical to ensure that the UNIFI messages proposed for worldwide adoption address the actual needs of the targeted community of users. The SEG members are the representatives of the future end-users of UNIFI messages. They evaluate the benefits of the proposed sets of messages, the expected attractiveness and the impact on existing applications and business processes. Each time a SEG is assigned a new Business Justification by the RMG, it pulls out of its various pools of expertise the right experts that form the ‘Evaluation Team’ in charge of validating the proposed messages. When the SEG doesn’t have the right expertise to represent the future community of users, the SEG members consult or invite additional experts to participate in the evaluation of the submission. When the scope of the submission covers more than one SEG, the Evaluation Team includes experts from all these SEGs. Account opening, standing orders, transaction and account information, advices & statements from … ...the account servicing institutions to account owners, including reporting from the financial institution… …to the ordering & beneficiary customers, reconciliation, exceptions & investigations handling. UNIFI_(ISO_20022)_v18

25 UNIFI – The Securities SEG (1/3)
Members – 39 experts 12 countries: CA, CH, DE, DK, FR, GB, LU, NL, NO, SE, US, ZA 7 liaison organisations: Clearstream, ECBS, Euroclear, ISDA/FpML, ISITC, MDDL, SWIFT Convener: Karla McKenna, Citigroup (US); Vice-convener: Didier Hermans, European Banking Federation (BE) Kick-off meeting in June 2005 Approved: Investment Funds (1) (SWIFT) Under evaluation: Pre-trade/trade (SWIFT) Next: Investment Funds (2) (SWIFT), Total Net Asset Value Statement (ISITC), Proxy voting (SWIFT), Issuer’s agent communication for CA (Euroclear) The Securities SEG has 39 experts from 12 countries and 7 liaison organisations. Here also, the convener and vice-convener offer a good balance of US-EU representation. The Securities SEG had its kick-off meeting at the same time as the Payments SEG, in June 2005 and has worked by conference calls thereafter. It formed a specific Evaluation Team to validate a first set of 45 candidate UNIFI messages developed by SWIFT for the Funds industry. The messages were approved in November They are published on the UNIFI website. The received the evaluation documentation for the 44 pre-trade and trade messages developed by SWIFT upon a joint submission by SWIFT and FIX. Next on their plate, are a series of projects approved by the RMG or in the process of approval. UNIFI_(ISO_20022)_v18

26 UNIFI – The Securities SEG (2/3)
covering instruments such as: Securities Equities Service bureaux covering actors such as: Fixed income Broker / dealers Investment managers, distributors, transfer agents, fund administrators Funds Custodians Deriva-tives Regulators The mission of the Securities SEG covers a wide spectrum of instruments, business actors and…. CSDs, ICSDs Stock exchanges, ETC providers Market Data Providers Clearing houses, CCPs UNIFI_(ISO_20022)_v18

27 UNIFI – The Securities SEG (3/3)
including business areas such as: Clearing & settlement Custody Initiation, pre-trade Income, corporate actions, market data, proxy voting Securities Securities management Trade, post-trade Account opening, standing orders, transaction and account information, advices & statements, queries & investigations Collateral management …business areas. The securities industry might take more time to develop and move to UNIFI messages. Indeed, the securities industry has recently invested in migrating from ISO 7775, the very first securities message standard developed by ISO in the 80ies, to ISO which was developed just prior the advent of internet and XML. ISO is the precursor of ISO It also uses a central dictionary and catalogue of messages maintained by a RA under the supervision of a RMG, but there is no SEGs and ISO doesn’t use a syntax independent modelling methodology. Furthermore, its syntax is specific to ISO 15022, thereby requiring specific knowledge and programming expertise. ISO messages include a range of messages covering almost all areas from trading to settlement and reconciliation, and corporate actions for traditional instruments such as bonds and equities. It is expected that UNIFI will first be used to cover areas not already covered – or poorly covered - by ISO 15022, as demonstrated by the business justifications received so far: investment funds, pre-trade/trade, proxy voting, etc… Collateral, repos, securities lending & borrowing UNIFI_(ISO_20022)_v18

28 Looking at the advantages UNIFI (ISO 20022) brings over ISO 15022
builds on the ISO data dictionary concept and registration infrastructure, but strengthens the monitoring by the industry uses a more robust, syntax independent development methodology based on UML modelling of business processes and transactions uses XML as the syntax for the actual physical messages has a wider scope than ISO 15022, which is only for securities messages is in line with directions taken by other industries (UN/CEFACT) Let’s take the opportunity to highlight the advantages that ISO brings over ISO ISO is a first step to decoupling the business elements from their physical representation in a message and ensuring that business elements are always represented in the same way, whatever the message. 1) UNIFI takes over the data dictionary and catalogue of messages concept from ISO It also builds on the ISO registration infrastructure which has a Registration Authority (RA) and a Registration Management Group (RMG), but the UNIFI registration process strengthens the involvement from the industry: The UNIFI RMG is directly involved in the acceptance and management of the submissions, whereas the ISO RMG responsibility is limited to a court of appeal in case of conflicts between the RA and the submitter. The UNIFI Standards Evaluation Groups (SEG) is a new concept which ensures that experts validate the proposed messages before issuance. 2) ISO is still very much ‘message centric’: the focus is on the development of a message format, while UNIFI uses a syntax independent business modelling methodology to capture the underlying business processes and requirements and ensure that the end-to-end transaction is taken into account before focusing on message formats. These models are the real standard, validated by industry representatives. They can be used to generate message formats in any desired syntax. As the ‘de facto’ standard for IP communication at present is the XML syntax, UNIFI is currently using XML. This can however be changed if a new and better syntax would be available in the future. 3) ISO uses its own syntax for message formats. This means that understanding ISO message formats and implementing them requires building a specific expertise. And, because the syntax is specific, there is no standard tools to help program the formats. UNIFI uses XML, an open standard which is used already in about all institutions. It doesn’t require building specific expertise and about all software developers offer a range of XML tools to help programming. The XML schemas can be seen as a kind of ‘machine processable’ message formats that can be ‘injected’ in interfaces, thereby saving a lot of money and time. The migration to ISO has been known as a very costly migration, whereas ISO is supposed to allow users to implement standards better, cheaper and faster. 4) The scope of ISO is limited to securities messages, while UNIFI covers all financial messages, thereby allowing securities players to use the same language for all their financial communications. 5) The use of a syntax neutral modelling methodology with a central repository is in line with what other industries are opting for, thereby opening ways for convergence and interoperability of message standards across industries. In particular, UN/CEFACT (the United Nations Centre for Trade Facilitation and e-Business) is going into the same direction as we will see in a minute. Syntax independent business modelling is key to the UNIFI (ISO 20022) standard, because it ensures that the business standard (the models) remains very stable and evolve with the business only, while the formats evolve with the technology to benefit from the latest innovations with regard to automation, ease of implementation, openness and cheapness of products, etc. … Syntax independent business modelling is key to the UNIFI (ISO 20022) standard ! UNIFI_(ISO_20022)_v18

29 Continuing in today’s agenda
UNIFI (ISO 20022) Cross industry harmonisation Interoperability within the financial industry is good, but interoperability with all industry sectors is even better since financial communications include the communication between financial institutions and their clients from other industries. Several business concepts are shared and needs to be communicated across industries, such as ‘address’, ‘buyer’ and ‘seller’, ‘invoice’, ‘amount’ to give a few simple examples. This is where UN/CEFACT can play a role. UNIFI_(ISO_20022)_v18

30 Harmonising across all industries with UN/CEFACT
United Nations/CEFACT – Centre for trade facilitation and e-business Created in 1997 to improve world-wide co-ordination of trade facilitation across all industries Focusing on international standards for electronic transactions (e.g., ebXML venture with OASIS) Promoting technology neutral business modeling and a central repository of core components UN/CEFACT (which stands for Centre for trade facilitation and e-business) was created in 1997 by the UN/ECE (Economic Commission for Europe) to improve world-wide co-ordination of trade facilitation across all industries. UN/CEFACT is the ‘successor’ of UN/ECE Working Party 4 (WP4) which created UN/EDIFACT, a first attempt of global e-business standard. The EDIFACT approach was similar to ISO 15022, although much wider in scope. UN/CEFACT now promotes a ‘technology neutral’ business modelling with a central library of ‘core components’ and the use of the XML syntax. Something similar to ISO 20022, but which would encompass all industries. In 1999, UN/CEFACT launched an 18-month joint initiative with OASIS (Organisation for the Advancement of Structured Information Standards) to define ‘ebXML’ (electronic business XML), a global framework for the standardised use of XML in e-business on internet based networks. OASIS and, to a lesser extent UN/CEFACT, started developing a series of specifications which were contributed to ISO as ‘Technical Specifications’ under the number ISO The specifications developed by OASIS are more technical and network centric. The only technical specification contributed by UN/CEFACT so far is called ‘CCTS’ (Core Component Technical Specification) and is closer to UNIFI. To avoid divergence and duplication of efforts, the financial arms of ISO and UN/CEFACT agreed to work together on harmonising their specifications. The ultimate goal is that UNIFI provides the financial portion of the UN/CEFACT repository… Ultimate goal is that UNIFI provides the financial portion of the UN/CEFACT repository UNIFI_(ISO_20022)_v18

31 Harmonisation between ISO and UN/CEFACT
2004: TC68, TBG5 and SWIFT sign a cooperation agreement to investigate alignment in line with the objectives of the ‘MoU on e-Business’ A workplan is agreed between the signatories 2005: Recommendation for alignment of methodologies Trial submission from UNIFI to UN/CEFACT 2006: WG4 will pursue technological alignment Real submission from UNIFI to UN/CEFACT In 2003, the chairmen of the ISO and UN/CEFACT ‘financial arms’ (ISO/TC68 and UN/CEFACT/TBG5) met for the first time and agreed on working together. In June 2004, TC68, TBG5 and SWIFT signed a MoU to investigate the alignment of their methodologies in line with the objectives set out in the ‘Memorandum of Understanding on e-business’, a cooperation agreement between the four international standards setters (ISO, IEC, UN/ECE and ITU). A workplan was put together and agreed between the parties. The first two steps of the workplan were achieved in 2005: SWIFT made a ‘gap analysis’ to describe the differences between UNIFI and UN/CEFACT’s CCTS and proposed ways to bridge these gaps. T The RA made a ‘trial submission’ of some components from the UNIFI Customer-to-Bank Payment Initiation messages to the UN/CEFACT group (TBG17) in charge of ‘harmonising’ components used in the various industries before their registration in the future UN/CEFACT repository. The processing of this submission will permit to refine the gap analysis document. In 2006, the alignment of UNIFI and CCTS is transferred to the newly created TC68/WG4 in charge of reviewing UNIFI technical specifications. The trial submission from 2005 will be turned into a real submission. UNIFI_(ISO_20022)_v18

32 Long term convergence goal A single ISO-UN/CEFACT approach
UNIFI Registration Management Group UNIFI Users UNIFI Registration Authority UNIFI Standards Evaluation Groups ISTH UN / CEFACT (All Industries) MDDL ebXML Registry/ Repository UNIFI Financial Repository FpML Business Requests Securities SWIFT Core Components Data Dictionary This slide illustrates the long term convergence goal, when the UN/CEFACT repository will be up and running and the exchange of information with the UNIFI repository will be operational. TBG17 Harmo- nisation FIX Message Models Payments Common Business Processes Business Process Catalogue ISO WGs TBG5 UNIFI_(ISO_20022)_v18

33 Continuing in today’s agenda
UNIFI (ISO 20022) Interoperability within the financial industry - securities The purpose of this last part of the presentation is to illustrate how UNIFI can help supporting interoperability between different message standards, using two concrete examples: first a concrete case study from the securities industry, in the pre-trade trade domain followed by a concrete example in the customer-to-bank payment domain. UNIFI_(ISO_20022)_v18

34 Two overlapping standards to support the end-to-end transaction
FIX ISO 15022 Trade Messages FIX ISO 15022 Indication Quotation Order Execution (Pre-)Allocation Confirmation Settlement Reconciliation The first example is based on the work done by FIX and SWIFT in preparing the candidate UNIFI ‘securities pre-trade and trade’ messages. The FIX protocol covers the early stages of the securities trade life cycle: from pre-trade to post-trade, while ISO covers the later stages starting from trade through to settlement and reconciliation. There are two interoperability problems: the information has to ‘flow’ throughout two different standards from the beginning to the end of the transaction life cycle there is an overlap in the scope of the standards which may require to translate a message in one syntax into the equivalent message in the other syntax. Let’s focus on the overlap in the areas of ‘Order’ and ‘Execution’ UNIFI_(ISO_20022)_v18

35 Working towards co-existence and convergence
Ordering Party Trade Counterparty Executing Party Trade Counterparty Ordering Party Order (FIX) Order (ISO 15022) Order (FIX) Order (ISO 15022) If the buyer and the seller are not using the same standard, the Executing Party in the middle would need to ‘understand’ the two standards, process them and eventually ‘map’ the information back in either standard. Execution (FIX) Execution (ISO 15022) Execution (FIX) Execution (ISO 15022) UNIFI_(ISO_20022)_v18

36 Working towards co-existence and convergence
FIX ISO 15022 Single Order Execution UNIFI Order New Order - single MT 502 Execution Execution Report MT 513 The ‘order’ information flow is covered by a ‘New Order - single’ message in the FIX protocol, whereas ISO has a MT 502 ‘Order to buy or sell’ message. Similarly, the order execution is confirmed through an ‘Execution Report’ in the FIX syntax, while ISO proposes MT 513 ‘Client confirmation of purchase or sale’ . Using the UNIFI reverse engineering technique, a business model was derived and based on the two sets of messages. The resulting UNIFI candidates were called ‘SingleOrder’ and ‘SingleExecution’. UNIFI_(ISO_20022)_v18

37 Working towards co-existence and convergence
FIX UNIFI ISO 15022 Order to buy/sell Security Quantity Limit price Expiry date Account USD 54=1 22 = 4; 48 = <ISIN> 38 = 1000 44 = 112; 40 = 2 432 = YYYYMMDD 1 = myAccount Side/BUYI ISIN/<ISIN> OrderQuantity3/Quantity Order3/OrderPrice/Price1 OrderExpiryDate AccountIdentification :22F::BUSE//BUYI :35B::<ISIN> :36B::ORDR//UNIT/1000 :90B::LIMI//ACTU/USD112 :98A::EXPI//YYYYMMDD :97A::CASH//myAccount ORDER The reverse engineering work led to the identification of the business concepts which, in the two syntaxes, were semantically equivalent, and to the design of UNIFI message models that could transport the business information contained in either the FIX or ISO messages. This table can be used to facilitate the migration from either FIX or ISO to the UNIFI equivalent (convergence), but also to ‘translate’ the FIX message into the ISO equivalent and vice versa (co-existence). Executed quantity Executed price Execution date Settlement date 32 = 750 31 = 110; 15 = USD 75 = YYYYMMDD 64 = YYYYMMDD ExecutedTradeQuantity ExecutedTradePrice TradeDate SecuritiesSettlement1/Date :36B::CONF//UNIT/750 :90B::DEAL//ACTU/USD110 :98A::TRAD//YYYYMMDD :98A::SETT//YYYYMMDD EXECUTION UNIFI_(ISO_20022)_v18

38 Working towards co-existence and convergence
Ordering Party Trade Counterparty Executing Party Trade Counterparty Ordering Party Order (FIX) Order (ISO 15022) Order (FIX) Order (ISO 15022) Execution (FIX) Execution (ISO 15022) Execution (FIX) Execution (ISO 15022) Going back to our example, the ‘convergence table’ can help the Executing Party to handle both syntaxes, and eventually, migrate to UNIFI at the pace of the community. Order (FIX) Order (UNIFI) Order (FIX) Order (UNIFI) Execution (FIX) Execution (UNIFI) Execution (FIX) Execution (UNIFI) UNIFI_(ISO_20022)_v18

39 Continuing in today’s agenda
UNIFI (ISO 20022) Interoperability within the financial industry - payments The second concrete example is related to the customer-to-bank payment initiation. UNIFI_(ISO_20022)_v18

40 Working towards interoperability and convergence
Bank A IFX format Proprietary format Bank B Customer A If a private or corporate customer is working with several banks, it may need to use a different format to request initiation of a payment to each institution… SWIFT MT 101 Bank C Let’s look at one concrete example from payments area: a customer may need to adapt to the format of the banks… UNIFI_(ISO_20022)_v18

41 Working towards interoperability and convergence
Customer A IFX format Customer B Proprietary format Bank A …or it may be the bank that will need to adapt to several formats to please their range of customers. SWIFT MT 101 Customer C …or banks may need to accept many formats… UNIFI_(ISO_20022)_v18

42 Working towards interoperability and convergence
Proprietary TWIST OAGi UNIFI Core Payment Kernel model SWIFT MT IFX, OAGi, TWIST and SWIFT formed the ‘IST Harmonisation Team’ to ‘reverse engineer’ existing formats and propose a single UNIFI message model to cover the customer-to-bank payment initiation. The resulting UNIFI message, the CoreCreditTransferInitiation, is also known as the ‘core payment kernel’. It was the first UNIFI message, approved in September 2005. On top of the single message model, one of the derived products of the reverse engineering is a set of ‘convergence tables’ which can be used to translate each standard into the model and vice versa. IFX The reverse engineering produces a canonical UNIFI message model and ‘convergence tables’ UNIFI_(ISO_20022)_v18

43 Working towards interoperability and convergence
Core Payment Kernel IFX MT 101 MT 101 UNIFI Adoption of the UNIFI model and the ‘convergence tables’ derived from the reverse engineering work increases the independence of senders and receivers on multiple external formats, waiting for the ultimate convergence to a single language. Core Payment Kernel IFX Adopting UNIFI facilitates convergence and co-existence UNIFI_(ISO_20022)_v18

44 & Answers uestions www.iso20022.org iso20022ra@iso20022.org
We have reached the end of this UNIFI presentation, but you may still have some outstanding questions? Remember, a lot of information is available on the UNIFI website ( which is updated on an ongoing basis, but questions and comments can also be sent to the RA: Note to the presenter: you may want to add your own address on this slide. UNIFI_(ISO_20022)_v18


Download ppt "UNIFI (ISO 20022) Introduction to ISO –"

Similar presentations


Ads by Google