UNIFI (ISO 20022) Introduction to ISO –

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 does not 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, its ingredients and the various UNIFI ‘registration bodies’ which provide the ISO development platform. The presentation will not, however, 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)_v32

Agenda UNIFI (ISO 20022): value proposition the standard the actors
the registration process the Repository UNIFI registration platform 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 the 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 us start with the value proposition of UNIFI. UNIFI_(ISO_20022)_v32

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 in 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 their own dialect…… and this is what has happened: several standardisation initiatives started developing XML messages each using 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)_v32

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 the duplication of efforts and the messages developed in parallel by all these initiatives would look as if they were developed by a single developer. UNIFI (ISO 20022) UNIFI_(ISO_20022)_v32

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)_v32 Source: John Mersberg, IBM Corporation

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 us 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, we have ten standards altogether that each need to communicate with the nine others. Therefore, we need more than the double number of interfaces, in fact 10*9 = 90 interfaces. TWIST 42 interfaces = n * (n-1) UNIFI_(ISO_20022)_v32 Source: John Mersberg, IBM Corporation

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 two translation interfaces 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)_v32 Source: John Mersberg, IBM Corporation

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 then be transformed into message formats according to the desired syntax. The current preferred UNIFI syntax is XML, but should a new and 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)_v32

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 us 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 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 is 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 and 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 is 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)_v32

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 the 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 once and for all approved the recipe of development and the approval of UNIFI messages, which is described in the standard. UNIFI_(ISO_20022)_v32

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 five parts published 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)_v32

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 Clearstream CLS EPAS Euroclear FIX FpML IFX ISITC ISTH MDDL OAGI Omgeo SWIFT TWIST TBG5 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)_v32

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 Technical Support Group, TSG (to be created) Assist RMG, SEGs, RA and submitting organisations 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 up 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 prioritises 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 (SEGs). 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. The Registration Authority (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 guide submitting organisations, ensure compliance of the developed models with the UNIFI technical specifications and perform 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 for the maintenance of the UNIFI website ( and publishes updated extracts of the UNIFI Repository on a regular basis. Finally, the (to-be-created) Technical Support Group (TSG) is a group of technical experts nominated by ISO to help any of the other registration bodies and the submitting organisations with technical problems related to the use of the ISO recipe. A call for experts has been issued by ISO on 4 April 2008 with a response deadline of 31 May 2008. Let us now look at the registration process itself. UNIFI_(ISO_20022)_v32

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 This is an illustration of the process for development and registration of new sets of messages. There is a more detailed description of it on 1) The entry point of 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) 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 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 SEG(s) and/or the RA is high, the RMG decides on 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 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 will create 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 with the submitter prepares 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 SEG(s) is to get the buy-in of the future users from a business perspective. 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 publishes the new ‘UNIFI messages’ in the Business Process Catalogue on (Note: provisionally registered messages are not shown in the Business Process Catalogue.) 7) When messages are first piloted or implemented, first users are invited to comment on the ‘technical implementability’ of the messages and the accuracy of the documentation published on the website. Possible changes or corrections requested by first implementers will be evaluated by the SEG, the RA and the submitter and may lead to changes to the messages and/or documentation. All along, the RMG monitors the work and if need be, arbitrates any disputes. It is worth noting that the process described above is for proposals of new sets of messages. A slightly different process is being followed for the maintenance of existing UNIFI messages. These two processes are described in more details on Official registration and publication RA Repository Dictionary Catalogue Optional pilot testing or first implementers Submitter & users UNIFI_(ISO_20022)_v32

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 Candidate UNIFI messages Submitter & RA Development & provisional registration SEG Business validation 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, the messages are called ‘UNIFI messages’ or ‘UNIFI compliant messages’. UNIFI messages Official registration and publication RA Repository Dictionary Catalogue Optional pilot testing or first implementers Submitter & users UNIFI_(ISO_20022)_v32

 Business justification UNIFI Registration Management Group UNIFI Standards Evaluation Groups UNIFI Registration Authority ISTH Omgeo UNIFI Financial Repository  Business models Securities CLS UNIFI Users SWIFT Data Dictionary  Candidate UNIFI messages Payments Let us 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 on the candidate UNIFI messages for evaluation by the assigned SEG(s).  Once the SEG(s) approve(s) the submission, the RA changes the status of new dictionary items from ‘provisionally registered’ to ‘registered’ and publishes the UNIFI models and messages in the Business Process Catalogue. Euroclear  UNIFI messages Business Process Catalogue ISITC Trade Services ACBI Forex UNIFI_(ISO_20022)_v32

UNIFI – 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 extracts of 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 the 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 that 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 into 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)_v32

Continuing with today’s agenda
UNIFI (ISO 20022) UNIFI registration platform Now that we have seen the ‘theory’ of UNIFI, let us describe how it has been concretely deployed, who is participating and what has been accomplished so far. UNIFI_(ISO_20022)_v32

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. The first two SEGs had their first meeting in June 2005. And the first set of UNIFI messages was approved for publication by the Payment SEG in September 2005. The UNIFI platform is live, 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)_v32

UNIFI – How does it fit into the ISO structure?
ISO Technical Committee TC68 Financial Services SC2 Security SC4 Securities SC7 Banking WG4 UNIFI Review UNIFI RMG TSG RMG members nominated by P-member countries and A-liaison organisations TSG & SEG members nominated by all member countries and liaison organisations RA Where does the UNIFI platform fit in the ISO structure? ISO is a federation of 157 national standards bodies, ie, the ISO member countries. The standardisation work is spread over various ‘Technical Committees’ (TCs) to which the 157 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 and many others including UNIFI-ISO 20022). The work of TC68 is further split among three ‘Sub-committees’ (SCs), each in charge of standards for a specific area. In total, 63 ISO member countries are involved in the work of TC68 and its Subcommittees, among which 27 are 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 they participate actively in a committee, these Liaison Organisations are called category ‘A’ liaison organisations. In total, TC68 and its sub-committees have accepted 24 liaison organisations among which 16 category ‘A’ Liaisons, such as UN/CEFACT TBG5, ISDA/FpML, FIX Protocol Ltd (FPL), MDDL, ISITC, IFX, TWIST, AMEX, Mastercard, VISA, Euroclear, Clearstream and SWIFT. UNIFI, because it covers all financial messages, is the only standard which reports directly to TC68. All other standards report to the Subcommittees. As such, the UNIFI Registration Management Group reports to TC68 and the RMG members can be nominated by the 27 P-member countries and the 16 category ‘A’ liaison organisations. The RMG monitors the RA, the TSG and the SEGs. The RA is nominated by TC68 and has a specific contract with ISO. The TSG and SEG members can be nominated by any of the 63 TC68 member countries or 24 liaison organisations. Also reporting directly to TC68 is the Working Group 4 (WG4) which was created 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). WG4 is working in close cooperation with the RMG to smoothly plan the introduction of improvements and avoid detrimental impacts on users. SEG Securities SEG Trade Services SEG Payments SEG FX UNIFI_(ISO_20022)_v32

UNIFI – Registration Management Group
Members - 50 senior managers from: 18 countries: AT, AU, CA, CH, DE, DK, FI, FR, GB, IT, JP, KR, LU, NL, NO, SE, US, ZA. 9 liaison organisations: Clearstream, Euroclear, FPL, FpML, ISITC, SWIFT, TWIST, UN/CEFACT/TBG5, VISA. Convener: Gerard Hartsink, ABN Amro (NL); Vice-convener: Bob Blair, JPMorgan Chase (US); Secretary: Cynthia Fuller, X9 (US) Meetings: twice a year Key decisions: Creation of Payments and Securities SEGs in 2005 Creation of Trade Services and Forex SEGs in 2006 Approval of 26 projects (Business Justifications) The RMG has been very successful from the start. 18 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, 50 senior managers involved in various financial industry sectors are participating in the RMG. The RMG is convened by Gerard Hartsink, who is also the chairman of the European Payments Council (EPC), and the vice-convener is Robert Blair, who is a well-known expert in the payments industry standards. The RMG holds regular meetings. Among the key decisions taken so far are: The creation of the four Standards Evaluation Groups, Payments and Securities in 2005, Trade Services and FX in 2006. The approval of the first 25 Business Justifications for the development of candidate UNIFI messages. The list and latest status of all submissions is maintained on the UNIFI website at UNIFI_(ISO_20022)_v32

UNIFI – The Payments SEG (1/3)
Members – 39 experts 13 countries: AT, AU, CH, DE, DK, FI, FR, GB, NL, NO, SE, US, ZA 5 liaison organisations: Euroclear, IFX, SWIFT, TWIST, UN/CEFACT/TBG5 Convener: Len Schwartz, ABN Amro (NL); Vice-convener: Bob Blair, JP Morgan Chase (US); Secretary: Deb Hjortland, FRB (US) Kick-off meeting: in June 2005 Approved: C2B payment initiation (SWIFT/ISTH), Interbank credit transfers and direct debits (SWIFT), Exceptions and investigations (SWIFT), B2C advice & statement (ISTH/ISITC) Next: Change/Verify Account Identification (GUF), Cash management (SWIFT) The Payments SEG has attracted 32 industry experts from 13 countries and 5 liaison organisations. These figures are also evolving and the list of SEG members is kept 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 works mainly via conference calls. In September 2005, they approved the very first set of UNIFI messages: a set of four messages covering the area of ‘customer to bank credit transfer initiation’, which included the so-called ‘core payment kernel’ developed by the IST Harmonisation Team. In June 2006, they approved 12 messages covering a new version of the payment initiation messages and the direct debit and interbank credit transfer payments. These interbank direct debit and credit transfer messages were developed by SWIFT and will be used in the new SEPA environment. In July 2006, the SEG approved a set of 14 messages developed by SWIFT to cover exceptions and investigations in the payments area. In March 2007, the SEG approved 3 bank to customer advice and statement messages developed by the IST Harmonisation Team and ISITC. The UNIFI payments messages now offer UNIFI users a comprehensive solution to accommodate payment transactions end-to-end. Next on their plate are: The next release of the already approved message set which is planned to be published in 2009 A set of messages to verify the account of the beneficiary before instructing a payment, to be developed by the French SWIFT Users Group A whole suite of cash management messages developed by SWIFT that would be made available in 2010. Two additional business justifications have been submitted to the RMG for approval: E-Mandates submitted by SWIFT Creditor Payment Activation Request submitted by the Associazone per il Coporate Banking Interbancario (ACBI). UNIFI_(ISO_20022)_v32

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

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’, which is 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 of 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)_v32

UNIFI – The Securities SEG (1/3)
Members – 54 experts 16 countries: AU, CA, CH, DE, DK, FI, FR, GB, JP, LU, NL, NO, SE, TR, US, ZA 7 liaison organisations: Clearstream, Euroclear, ISDA/FpML, ISITC, FISD/MDDL, FPL, SWIFT Convener: Karla McKenna, Citigroup (US); Vice-convener: Didier Hermans, Euroclear; Secretary: Dana Brants, SWIFT Kick-off meeting: in June 2005 Approved: Investment funds (SWIFT), Transaction regulatory reporting (SWIFT), Proxy voting (SWIFT) Under evaluation: Pre-trade/trade (SWIFT) Next: Total portfolio valuation statement (ISITC), Issuer’s agents communication for CA (Euroclear), Post-trade (Omgeo), Registration & holder identification (Euroclear), Market claims & automatic transformations (Euroclear), Corporate actions (SWIFT), Settlement & reconciliation (SWIFT), Securities issuance (Euroclear), Triparty collateral management (SWIFT), Fund processing passport report (SWIFT) The Securities SEG has 55 experts from 16 countries and 7 liaison organisations. The convener, Karla McKenna, is also the chairman of ISO TC68. The SEG members are listed on 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 approved a first set of 45 UNIFI messages developed by SWIFT for the Funds industry in November 2005 and a second set of 4 Transaction Regulatory Reporting messages developed by SWIFT in August In April 2008, the SEG approved 8 Proxy Voting messages and a new release of the Funds message set, including 22 additional messages submitted by SWIFT. The SEG received the evaluation documentation for 44 pre-trade and trade messages developed by SWIFT upon a joint submission by SWIFT and FIX. Next on their plate is a series of projects submitted by various organisations and approved by the RMG. UNIFI_(ISO_20022)_v32

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

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, not that long ago the securities industry invested in migrating from ISO 7775, the very first securities message standard developed by ISO in the ‘80s, to ISO which was developed just prior the advent of the 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 an RMG, but there are no SEGs and ISO does not 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. The first UNIFI projects were covering areas not already covered – or poorly covered - by ISO 15022: investment funds, pre-trade/trade, proxy voting, etc… Later on, business justifications were introduced and approved for the development of messages in areas already covered by ISO 15022, such as Post-Trade, Settlement and Reconciliation, and Corporate Actions. The development of these UNIFI messages does not mean that the equivalent ISO messages will be automatically removed. They will co-exist as long as desired by the user community. To facilitate this co-existence, the new UNIFI messages will initially mirror precisely the equivalent ISO messages to ensure easy translation form one standard to the other. Collateral, repos, securities lending & borrowing UNIFI_(ISO_20022)_v32

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 us 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 concepts 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 industry 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 are no standard tools to help program the formats. UNIFI uses XML, an open standard which is used already in about all institutions. It does not 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 was 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) remain 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)_v32

UNIFI – The FX SEG (1/3) Members – 26 experts
11 countries: AU, CA, CH, DE, FR, GB, NL, NO, SE, TR, US 3 liaison organisations: FPL, ISITC, SWIFT Convener: Ludy Limburg, ABN Amro (NL); Vice-convener: Tony Smith, JP Morgan Chase (UK); Secretary: Joshua Derrick, SWIFT Kick-off meeting: in September 2006 Approved: Forex notifications (CLS) The Forex SEG, created in September 2006, approved 15 ‘Forex Notifications’ messages submitted by CLS in March 2007. UNIFI_(ISO_20022)_v32

Foreign eXchange UNIFI – The FX SEG (2/3)
covering instruments such as: Foreign eXchange Spot Trading portals, matching services providers covering actors such as: Swaps Hedge funds Investment managers Forward Custodians Currency Options Dealers The mission of the FX SEG covers a wide spectrum of currency contracts, business actors and…. Application providers CLS and CLS settlement members Industry associations (ISDA) Money brokers UNIFI_(ISO_20022)_v32

Foreign eXchange UNIFI – The FX SEG (3/3)
including business areas such as: Trade: order, execution, allocation, affirmation, etc. Pre-trade: IOI, quotes, etc. Post-trade: confirmation, matching, assignment, novation, etc. Foreign eXchange Notification of trades to third parties …business areas. Clearing and Settlement, including netting and related reporting Trigger events, option exercises UNIFI_(ISO_20022)_v32

UNIFI – The Trade Services SEG (1/3)
Members – 23 experts 12 countries: AU, CH, DE, DK, FI, FR, GB, IS, IT, NL, US, ZA 2 liaison organisations: ISITC, SWIFT Convener: Katja Lehr, IFSA (US); Vice-convener: Dominique Pierre Barthares, BNP Paribas (FR); Secretary: Jim Wills, SWIFT Kick-off meeting: in September 2006 Approved: Invoice Financing Request (ACBI), Trade Services Management (SWIFT) Next: e-Invoice (UN/CEFACT/TBG5) The Trade Services SEG was created to evaluate messages supporting transactions and business processes related to the Trade Finance business and the Financial Supply Chain management. The Trade Services SEG already approved: 3 ‘Invoice Financing Request’ messages submitted by the Associazone per il Coporate Banking Interbancario (ACBI) in October 2007 50 ‘Trade Services Management’ messages (also known as the ‘TSU’) from SWIFT in April 2008 Next on their plate: The ‘e-Invoice’ messages from UN/CEFACT TBG5 UNIFI_(ISO_20022)_v32

covering products… Collection Trade Services …and services such as: Documentary credit Reconciliation (A/R, A/P), remittance data Open Account Trading Letter of credit Guarantee EBPP The scope of the Trade Services SEG covers a wide spectrum of products and services of the traditional Trade Finance business and the Financial Supply Chain management…. Pre/post-shipment financing & factoring Purchase order, transport documents Invoice financing e-Invoicing, EBPP UNIFI_(ISO_20022)_v32

including actors such as: Financial Institutions Private and corporate customers (treasurers) Associations providing rules and master agreements (eg IFSA, ICC) Trade Services Risk management entities It covers a wide range of actors… Trade facilitators: chambers of commerce, insurance co, freight forwarders, carriers, customs, factoring co Application providers UNIFI_(ISO_20022)_v32

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 need to be communicated across industries, such as ‘address’, ‘buyer’ and ‘seller’, ‘invoice’ and ‘amount’ to give a few simple examples. This is where UN/CEFACT can play a role. UNIFI_(ISO_20022)_v32

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 modelling 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 worldwide coordination 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 at a 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)_v32

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 takes over technological alignment 2007: First official submission from UNIFI to UN/CEFACT 2008: Customer-to-bank payment components harmonised and accepted in UN/CEFACT core component library 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 an 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. 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 has allowed for the refinement of the gap analysis document. In 2006, the alignment of UNIFI and CCTS was transferred to the newly created TC68/WG4, in charge of reviewing UNIFI technical specifications. The trial submission from 2005 has been turned into a real submission. UN/CEFACT (TBG17) started processing this submission in 2007 and harmonized and accepted it in early 2008. The RA is also participating in UN/CEFACT TBG17 - Harmonisation, the group in charge of reviewing and ‘harmonizing’ submissions of new components made to the UN/CEFACT Registry. UNIFI_(ISO_20022)_v32

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

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

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 the translation of a message in one syntax into the equivalent message in the other syntax. Let us focus on the overlap in the areas of ‘Order’ and ‘Execution’. UNIFI_(ISO_20022)_v32

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 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 into either standard. Execution (FIX) Execution (ISO 15022) Execution (FIX) Execution (ISO 15022) UNIFI_(ISO_20022)_v32

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 an 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 an 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)_v32

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

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

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

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 us look at one concrete example from payments area: a customer may need to adapt to the format of the banks… UNIFI_(ISO_20022)_v32

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

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 CustomerCreditTransferInitiation, 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)_v32

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

& Answers uestions www.iso20022.org iso20022ra@iso20022.org
We have reached the end of this UNIFI presentation, and are ready to answer your questions. Remember, a lot of information is available on the UNIFI website ( which is updated on an ongoing basis. Questions and comments can also be sent to the RA: UNIFI_(ISO_20022)_v32

UNIFI (ISO 20022) Introduction to ISO –

Similar presentations

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

Similar presentations

About project

Feedback

Log in

Auth with social network:

UNIFI (ISO 20022) Introduction to ISO –

Similar presentations

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

Similar presentations

About project

Feedback