Download presentation
Presentation is loading. Please wait.
Published byHillary Payne Modified over 6 years ago
1
ISO 20022 Introduction to ISO – Universal financial industry message scheme ‘ISO Universal financial industry message scheme’ is the platform proposed by ISO to develop all financial messages. ISO 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 ISO When going through it, you will become familiar with the recipe, its ingredients and the various ISO ‘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 ISO 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. ISO_20022_LV_v92
2
Agenda ISO 20022: Value proposition The standard The actors
The registration process The Repository ISO 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 ISO 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 ISO fits into the more global picture of the harmonisation of communications across all industries. We will end with a concrete example of how ISO can help interoperability with other financial message standards. Let us start with the value proposition of ISO ISO_20022_LV_v92
3
The ISO 20022 value proposition (1/5)
Objective To enable communication interoperability between financial institutions , their market infrastructures and their end-user communities Major obstacle Numerous overlapping standardization initiatives looking at XML financial messages: 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. MDDL, FIX, FinXML, VRXML, RIXML, XBRL, FpML, IFX, TWIST, SWIFT, RosettaNet, EPC, OAGi, ACORD, CIDX, etc. ISO_20022_LV_v92
4
The ISO 20022 value proposition (2/5)
Proposed solution A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives ISO 20022 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 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. ISO_20022_LV_v92
5
The ISO 20022 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 ISO 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 ISO_20022_LV_v92
6
The ISO 20022 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 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) ISO_20022_LV_v92 Source: John Mersberg, IBM Corporation
7
The ISO 20022 value proposition (5/5)
Standardized implementation reduces cost, time to effect change and improves overall performance… 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 RosettaNet EDIFACT SWIFT IFX 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 ISO 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 ISO aims at long term convergence, while facilitating short term coexistence… ISO_20022_LV_v92
8
ISO 20022 Illustrating business modelling
Account Order Date All institutions have their own sets of data objects …and groups them into ‘syntax-neutral’ message models, which... Order Date ISO standardizes common data objects… 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 ISO is to identify and standardise the ‘words’ that are shared between institutions and store them in the ‘data dictionary’ of the ISO Repository. Using the agreed standard ‘words’ as lego blocks, the developers can build ISO syntax-independent message models, which can then be transformed into message formats according to the desired syntax. The current preferred ISO 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. Furthermore, if it is more efficient to use another syntax for a particular business area or a particular market segment, the use of the ISO message models ensures that the business information will flow smoothly from one message to another whichever the syntax used to transport this business information. Syntax-independent business modelling is key to the ISO 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 ISO recipe offers a better, cheaper and faster way of developing and implementing interoperable message standards. ISO XML ISO 15022 … can be ‘transformed’ in message formats in the desired syntax FIX ASN.1 ISO_20022_LV_v92
9
The ISO 20022 recipe Main 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 Reverse engineering approach Protect industry investment and ease interoperability Prepare for future migration Let us now look at the main ingredients of the ISO 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 ISO 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 ISO Repository. Another major component of ISO 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 ISO 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 ISO compliant message standards and feed it into the ISO models, thereby facilitating interoperability, co-existence and migration from existing messages to their ISO compliant equivalent. It is the combination of the business modelling and the reverse engineering which makes ISO so unique in supporting interoperability. ISO_20022_LV_v92
10
The ISO 20022 recipe Main ingredients (2/2):
Development / registration process Clearly identified activities and roles Business experts and future users involved upfront Technical experts involved when required Repository on the ISO website Business Process Catalogue & Data Dictionary Outside of official standard (maintained by registration bodies) Two additional major ingredients of ISO 20022: ISO 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 ISO framework is its Financial Repository where approved models, transactions, messages and their components are stored. The Repository content is published on the ISO 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 ISO 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 ISO messages, which is described in the standard. ISO_20022_LV_v92
11
The six parts of ISO 20022 Copies can be obtained from www.iso.org
PART 1: International Standard: Overall methodology and format specifications for inputs to and outputs for the ISO Repository PART 2: International Standard: Roles and responsibilities of the registration bodies PART 3: Technical specification: ISO modelling guidelines PART 4: Technical specification: ISO XML design rules PART 5: Technical specification: ISO reverse engineering PART 6: International Standard: Message transport characteristics The standard itself consists of the shown six parts published under the name ‘ISO Financial Services - Universal financial industry message scheme’: Together, they cover the major components of ISO which we have just looked at. The first five parts were issued in Part 1 and 2 were approved as ‘International Standards’. Parts 3, 4 and 5 were 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 has reviewed the ISO specifications based on technological evolution, best practice and experience gained from using the standard. In 2007, WG4 issued a new edition of Part 2 and, in 2009, complemented the standard with a new Part 6, which has not yet been implemented. WG4 re-drafted the whole standard into 8 Parts that have been approved in June ISO is expected to publish this new edition of ISO before the end of The implementation of this new edition is scheduled for May 2013. Copies of the ISO standard can be purchased from your national standards body or directly from the website. Copies can be obtained from ISO_20022_LV_v92
12
ISO 20022: The actors (1/2) Submitting organisations Could be
Communities of users or organisations that want to develop ISO compliant messages to support their financial transactions Could be ANBIMA ASF Berlin Group CBI Consortium Clearstream CLS EPASOrg EPC Euroclear FFI FISD FPL FpML IFX ISITC NBB OAGi Omgeo SC7/WG9 SWIFT UN/CEFACT TWIST UK Payments Council 4CB etc. To whom is the ISO recipe targeted? The ISO platform is available to all developers of message standards. And the ISO 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 ISO 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 ISO Market infrastructures (ACHs, RTGS, CSDs, stock exchanges, etc.) are adopting and pushing developers to embrace the ISO 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 ISO as an ideal recipe. It is important to note that the so-called ‘submitting organisations’ that want to use the ISO recipe to develop financial messages do not need to be affiliated to ISO, they just have to follow the ISO registration process. The organisations ‘in yellow’ on the slide have already proposed development projects to ISO ISO_20022_LV_v92
13
ISO 20022: The actors (2/2) Registration Management Group, RMG
Overall governance, court of appeal Approve business justifications for new standards Create Standard Evaluation Groups (SEGs) Standards Evaluation Groups, SEGs Represent future users in specific financial areas Validate candidate message standards Approve change requests Registration Authority, RA Ensure compliance Maintain and publish ISO Repository Technical Support Group, TSG Assist RMG, SEGs, RA and submitting organisations The registration process is described in part 2 of the standard. It involves four registration bodies, which interact with the ‘submitting organisations’ that use the ISO 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 ISO 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 ISO messages in a particular financial domain. Their role is to ensure that the candidate ISO messages actually address the needs of the future users. All candidate ISO messages are validated by one or more SEG(s) depending on the scope of the messages. The SEGs also approve changes to existing messages. The Registration Authority (RA) is the guardian of the ISO 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 ISO 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 ISO website ( and publishes updated extracts of the ISO Repository on a regular basis. Finally, the 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. Let us now look at the registration process itself. ISO_20022_LV_v92
14
ISO 20022 The registration process (1/3)
M G m o n i t r s Submitting organisation Financial industry group or standards body Business justification Business justification RMG Project approval & allocation to a SEG Submitting organisation & 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 organisation that wants to develop the messages (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 submitting organisation 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 submitting organisation will give some indication about the other organisations that will be involved in the development and the development timing. A template for the Business Justification is available for download from the ISO website. The Business Justification is normally a ‘high level’ justification, which is introduced by the submitting organisation before starting the actual development. Therefore, it is not expected to include a detailed description of the future messages, which will only be available after the modelling. 2) The Business Justification is reviewed by the SEG(s) and the RMG. The RMG will decide whether the proposed development fits into the ISO 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 submitting organisation starts developing ISO compliant business and message models. The RA assists the submitting organisation during this phase in order to ensure that the models are compliant and use the right components from the Data Dictionary. If need be, additional ‘provisionally registered’ components are created. When the development is completed, the RA generates the XML schemas and, with the submitting organisation, 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. 4) Based on this documentation, the SEG(s) evaluates the candidate ISO 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. 5) When/if the SEG approves the messages, the RA officially registers new components in the ISO Data Dictionary and publishes the new ‘ISO messages’ in the Catalogue of ISO messages on 6) 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 submitting organisation 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. Official registration and publication RA Repository Dictionary Catalogue Optional pilot testing or first implementers Submitting organisation & users ISO_20022_LV_v92
15
ISO 20022 The registration process (2/3)
M G m o n i t r s Submitting organisation Financial industry group or standards body Business justification Business justification RMG Project approval & allocation to a SEG Candidate ISO messages Submitting organisation & RA Development & provisional registration SEG Business validation ISO messages 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 ISO messages’. Once they are approved by the SEG for publication, the messages are called ‘ISO messages’ or ‘ISO compliant messages’. Official registration and publication RA Repository Dictionary Catalogue Optional pilot testing or first implementers Submitting organisation & users ISO_20022_LV_v92
16
ISO 20022 registration process (3/3) Yearly maintenance process
Timing By June 1 Users introduce Change Requests to the RA Users CRs SEG SEG screens Change Requests (CRs) By July 7 Submitting organisation prepares ‘Maintenance Change Request’ with each CR implementation By August 21 Submitting organisation SEG By October 1 SEG approval/rejection By December 1 Submitting organisation & RA Development of new versions Once approved, the ISO messages can be maintained upon request of the users. The ISO maintenance process is described at The yearly maintenance cycle includes the following steps: 1) All Change Requests (CRs) are to be sent to the RA by June 1 using a “Change Request Template” . Anybody can introduce a CR. All received CRs are published in the Catalogue of Change Requests ( 2) Valid CRs received prior to June 1 are evaluated by the SEG(s) that approved the initial version of the messages. Purpose of this initial evaluation is to eliminate the CRs that are not worth investigating further and to decide whether CRs that are worth considering should be implemented in the upcoming yearly maintenance cycle or can wait for another year. 3) Selected CRs for the upcoming cycle are forwarded to the submitting organisation in charge of the maintenance of the messages for investigation. This results in a “Maintenance Change Request” document describing how each change request could be implemented. The Maintenance Change Requests are published in the Status of Submissions ( 4) The SEG reviews the Maintenance Change Request and approves or rejects each of the CRs. 5) The submitting organisation develops new versions of the messages incorporating the approved CRs. 6) The SEG validates that the new versions indeed include the approved changes. 7) The approved new versions of messages are published by the RA. 8) The first implementers of the new versions 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 submitting organisation and may lead to changes to the messages and/or documentation. If approved by the SEG, this maintenance cycle can be used in a more ‘fast-track’ mode in case of urgent Change Requests that cannot wait for the next yearly cycle. SEG Validation of new versions By February 1 RA Registration and publication Repository Dictionary Catalogue April-May First implementers Submitting organisation & users ISO_20022_LV_v92
17
ISO 20022 - 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 ISO Repository is maintained by the RA which publishes extracts of it on on a regular basis to show newly registered items. 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 code 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 submitting organisations that develop new models and messages. They become officially ‘registered’ after approval of the SEGs. Of course, the goal of ISO 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 ISO 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 ISO website until they are approved by the SEG and officially registered by the RA. ISO_20022_LV_v92
18
ISO 20022 Registration Platform
Continuing with today’s agenda… ISO 20022 ISO Registration Platform Now that we have seen the ‘theory’ of ISO 20022, let us describe how it has been concretely deployed, who is participating and what has been accomplished so far. ISO_20022_LV_v92
19
ISO 20022 - The Deployment Approval of the international standard
Selection of the Registration Authority Set-up of the Creation of Registration Management Group Creation of the first Standards Evaluation Groups Registration and publication of first ‘ISO messages’ The deployment of the ISO 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 and the Catalogue of Messages, but also to e.g., Information about the registration process, including the template for business justifications and change request 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 ISO messages was approved for publication by the Payment SEG in September 2005. The ISO platform is live, but the promotion of the platform to users and developers is ongoing. Ongoing: promotion to developers (standardizers, industry bodies) and users (vendors, end-users) ISO_20022_LV_v92
20
ISO 20022 How does it fit into the ISO structure?
ISO Technical Committee TC68 Financial Services SC2 Security SC4 Securities SC7 Banking ISO 20022 RMG WG4 ISO 20022 Review TSG RMG members nominated by P-member countries and A-liaison organisations TSG & SEG members nominated by all member countries and liaison organisations RA SEG Securities SEG Trade Services Where does the ISO platform fit in the ISO structure? ISO is a federation of 163 national standards bodies, ie, the ISO member countries. The standardisation work is spread over various ‘Technical Committees’ (TCs) to which the 163 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 LEI, the IBAN, the ISIN, the CFI, the MIC, ISO 8583, ISO and many others including 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, 76 ISO member countries are involved in the work of TC68 and its Subcommittees, among which 32 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 17 liaison organisations, such as the ECB, EPC, ISDA/FpML, FIX Protocol Ltd (FPL), ISITC, IFX Forum, Mastercard, VISA, Euroclear, Clearstream and SWIFT. ISO 20022, because it covers all financial messages, reports directly to TC68. Other standards generally report to the Subcommittees. As such, the ISO Registration Management Group reports to TC68 and the RMG members can be nominated by the P-member countries and the 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 type of TC68 member countries or liaison organisations. Also reporting directly to TC68 is the Working Group 4 (WG4) which was created in December 2005 and has defined a new edition of the ISO technical specifications that will be implemented in May 2013. SEG Payments SEG FX SEG Cards ISO_20022_LV_v92
21
ISO 20022 Registration Management Group (RMG)
Members - 63 senior managers from: 21 countries: AT, AU, BR, CA, CH, CN, DE, DK, FI, FR, GB, IT, JP, KR, LU, NL, NO, SE, SG, US, ZA. 10 liaison organisations: Clearstream, ECB, EPC, Euroclear, FPL, FpML, IFX, ISITC, SWIFT, 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 five SEGs: Payments and Securities in 2005, Trade Services and Forex in 2006, Cards & Related Retail Financial Services in 2008 Approval of 45 development projects The RMG has been very successful from the start. The number of participating P-member countries and ‘A’ liaison organisations is continuously increasing, demonstrating the interest of the community for ISO The RMG is convened by Gerard Hartsink 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 five Standards Evaluation Groups: Payments and Securities in 2005, Trade Services and FX in 2006, Cards and Related Retail Financial Services in 2008. The approval of a series of Business Justifications for the development of new candidate ISO messages. The list and latest status of all submissions are maintained on ISO_20022_LV_v92
22
ISO 20022 – The Payments SEG (1/3)
Members – 58 experts 16 countries: AT, AU, CH, DE, DK, FI, FR, GB, IT, JP, KR, NL, NO, SE, US, ZA 4 liaison organisations: Euroclear, IFX, ISITC, SWIFT Convener: Thomas Egner, Commerzbank (DE); Vice-convener: Bob Blair, JP Morgan Chase (US); Secretary: Deb Hjortland, FRB (US) Approved: C2B payment initiation (SWIFT/ISTH), Interbank credit transfers and direct debits (SWIFT), Exceptions and investigations (SWIFT), B2C advice & statement (ISTH/ISITC), Mandates (SWIFT) , Change/verify account identification (GUF), Bank account management (SWIFT), Creditor payment activation request (CBI Consortium), Cash account reporting request and notification (SWIFT), Bank Services Billing (TWIST/SWIFT), Authorities Financial Investigations (FFI) Under evaluation: None Next: Cash management (SWIFT), Cash lodgement and withdrawal (NBB), Real time payments & Account switching (Payments Council Ltd - UK), Extended remittance advice (IFX/OAGi) The Payments SEG has attracted industry experts from various countries and liaison organisations. The list of SEG members is kept up-to-date on the ISO website. The Payments SEG works mainly via conference calls. In September 2005, they approved the very first set of ISO 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. In March 2009, the SEG approved a new version of the whole payments message set. In August 2009, it approved 4 Mandate messages submitted by SWIFT. In December 2009, it approved 3 Change/Verify Account Information messages submitted by the French SWIFT Users Group. In March 2010, it approved 15 Bank Account Management messages submitted by SWIFT. In September 2010, it approved 2 Creditor Payment Activation Request messages submitted by the CBI Consortium. In November 2010, it approved 4 Cash Account Reporting Request and Notification messages from SWIFT. In May 2012, it approved a Bank Services Billing message developed by TWIST and SWIFT. On 22 October 2012, it approved 3 Authorities Financial Investigations’ messages developed by the Federation of Finnish Financial Services (FFI). The Payments SEG has approved a new version of 36 of the existing payments messages in the 2012/2013 maintenance cycle. New message versions are expected to be published in May 2013. Next on the SEG plate are: - a whole suite of cash management messages developed by SWIFT. Cash lodgement and withdrawal messages proposed by the National Bank of Belgium on behalf of a series of European central banks. Real time payments proposed by the Payments Council Ltd – UK. Account Switching proposed by the Payments Council Ltd – UK Extended Remittance Advice, proposed by the IFX Forum and OAGi. ISO_20022_LV_v92
23
ISO 20022 – The Payments SEG (2/3)
Covering instruments such as: Payments Credit transfers Covering actors such as: Cheques Financial institutions Direct debits Clearing houses & RTG systems Private & corporate customers 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 ISO_20022_LV_v92
24
ISO 20022 – 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 Communications between the ordering customer and its bank, etc. Payments Cash Management between various actors: 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. … 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 ISO 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 ISO 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. ISO_20022_LV_v92
25
ISO 20022 – The Securities SEG (1/3)
Members – 59 experts 16 countries: AU, BR, DE, DK, FI, FR, GB, IE, JP, LU, NL, NO, SE, SG, US, ZA 7 liaison organisations: Clearstream, ECB, Euroclear, ISDA/FpML, ISITC, FPL, SWIFT Convener: Kevin Wooldridge, Standard Logic (GB); Vice-convener: Amod Dixit, Standard Chartered (SG); Secretary: Mireia Guisado-Parra, SWIFT Approved: Investment funds (SWIFT), Transaction regulatory reporting (SWIFT), Proxy voting (SWIFT), Issuer’s agents communication for CA (Euroclear), FPP report (SWIFT) , Corporate actions (SWIFT), Settlement & reconciliation (SWIFT), Post-trade (SWIFT/Omgeo), Total portfolio valuation report (ISITC/SWIFT) Under evaluation: Pre-trade/trade (SWIFT/FPL) Next: Alternative funds (SWIFT), Target2-Securities (SWIFT/Bundesbank on behalf of 4CB), CCP Clearing (FPL/SWIFT), Collateral Management (FPL, FpML, ISITC, SWIFT), Investment Fund Prospectus (ANBIMA), SSI for Securities, Payments & FX (ISITC, Omgeo, FPL) 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 ISO 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. In November 2008, the SEG approved 22 Issuers’ Agent Communication messages submitted by Euroclear. In January 2009, it approved a new version of the Proxy Voting messages. Two Funds Processing Passport Report messages from SWIFT were approved in November In December 2009, it approved 13 corporate actions and 29 settlement and reconciliation messages developed by SWIFT. It approved a new version of the Proxy Voting messages in February It approved a new version of the Settlement and Reconciliation messages and the Corporate Actions messages in Q It approved an initial set of 5 Post-trade matching messages in August In October 2011, it approved a Total Portfolio Valuation Report developed by SWIFT on behalf of ISITC and 4 complementary Settlement and Reconciliation messages developed by SWIFT, including an Audit Trail message developed for T2S. The Securities SEG has approved a new version of 47 of the existing securities messages in the 2012/2013 maintenance cycle. New message versions are expected to be published in May 2013. A submission of 29 candidate pre-trade and trade message models developed by SWIFT upon a joint submission by SWIFT and FPL is currently on hold. Next on their plate is a series of projects submitted by various organisations. ISO_20022_LV_v92
26
ISO 20022 – The Securities SEG (2/3)
Covering instruments such as: Securities Equities Service bureaux Covering actors such as: Fixed income Investment managers, distributors, transfer agents, fund administrators Broker / dealers Funds Custodians Deriva-tives Regulators CSDs, ICSDs The mission of the Securities SEG covers a wide spectrum of instruments, business actors and…. Stock exchanges, ETC providers Market Data Providers Clearing houses, CCPs ISO_20022_LV_v92
27
ISO 20022 – The Securities SEG (3/3)
Including business areas such as: Clearing & settlement Trade Initiation, pre-trade Trade, post-trade Securities Issuance Securities Custody Income, corporate actions, market data, proxy voting Account opening, standing orders, transaction and account information, advices & statements, queries & investigations Collateral management Collateral, repos, securities lending & borrowing …business areas. The securities industry might take more time to develop and move to ISO 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 ISO 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 ISO 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 ISO messages will initially mirror precisely the equivalent ISO messages to ensure easy translation from one standard to the other. ISO_20022_LV_v92
28
Looking at the advantages 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) ISO 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 ISO registration process strengthens the involvement from the industry: The ISO 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 ISO 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 ISO 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, ISO 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. ISO 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 ISO 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 ISO 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 ISO standard ! ISO_20022_LV_v92
29
ISO 20022 – The FX SEG (1/3) Members – 24 experts
11 countries: AU, CA, CH, CN, FR, GB, NL, NO, SE, US, ZA 3 liaison organisations: FPL, ISITC, SWIFT Convener: Ram Komarraju, CLS (US); Vice-convener: Tony Smith, JP Morgan Chase (GB); Secretary: Steve Gunn, CLS (GB) 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. ISO_20022_LV_v92
30
Foreign eXchange ISO 20022 – 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 Application providers The mission of the FX SEG covers a wide spectrum of currency contracts, business actors and…. CLS and CLS settlement members Industry associations (ISDA) Money brokers ISO_20022_LV_v92
31
Foreign eXchange ISO 20022 – 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 Clearing and Settlement, including netting and related reporting …business areas. Trigger events, option exercises ISO_20022_LV_v92
32
ISO 20022 The Trade Services SEG (1/3)
Members – 32 experts 14 countries: AU, CA, CH, DE, DK, FI, FR, GB, IS, IT, JP, NL, US, ZA 1 liaison organisation: SWIFT Convener: Tapani Turunen, Tieto (FI) Vice-convener: Peter Potgieser, RBS (NL); Secretary: Jim Wills, SWIFT Kick-off meeting: in September 2006 Approved: Invoice Financing Request (CBI Consortium), Trade Services Management (SWIFT), Financial Invoice (UN/CEFACT TBG5), Demand Guarantees and Standby Letters of Credit (SWIFT) Under evaluation: none Next: Factoring Services (ASF), Invoice Tax Report (FFI & Tieto) 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 CBI Consortium in October 2007 50 ‘Trade Services Management’ messages (also known as the ‘TSU’) from SWIFT in April 2008 1 ‘Financial Invoice’ message from UN/CEFACT TBG5 in November 2010. 20 ‘Demand Guarantees and Standby Letters of Credit’ messages developed by SWIFT in December 2012. In October 2011, the RMG approved a business justification from the Association Française des Sociétés Financières (ASF) for the development of Factoring Services messages. In October 2012, the RMG approved a business justification from the Federation of Finnish Financial Services (FFI) & Tieto Corporation for the development of Invoice Tax Report messages. ISO_20022_LV_v92
33
ISO 20022 The Trade Services SEG (2/3)
Covering products… Trade Services Collection …and services such as: Reconciliation (A/R, A/P), remittance data Documentary credit Open Account Trading Letter of credit Guarantee e-Invoicing 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…. Purchase order, transport documents Invoice financing ISO_20022_LV_v92
34
ISO 20022 The Trade Services SEG (3/3)
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 Trade facilitators: chambers of commerce, insurance co, freight forwarders, carriers, customs, factoring co Application providers It covers a wide range of actors… ISO_20022_LV_v92
35
ISO 20022 – The Cards & Related Retail Financial Services SEG (1/3)
Members – 32 experts 14 countries: AT, AU, CA, CH, DE, FI, FR, GB, JP, KR, NL, SE, US, ZA 4 liaison organisations: IFX, Mastercard, SWIFT, VISA Convener: Chris Starr, APACS (GB); Vice-convener: William Vanobberghen, Groupement des Cartes Bancaires (FR); Secretary: Reinhard Herwig, SRC (DE) Kick-off meeting: on October 2008 Approved: CAPE – Acceptor to Acquirer and Terminal Management (EPASOrg) Under evaluation: none Next: Acquirer to Issuer Card Messages (TC68/SC7/TG1), ATM interface for transaction processing and ATM management (IFX Forum/EPASOrg) The Cards and Related Retail Financial Services SEG was created in 2008. In October 2010, they approved 15 Card Payments Exchanges (CAPE) messages developed by EPASOrg to support Acceptor to Acquirer transactions. On 5 April 2011, the SEG approved a second set of 3 messages developed by EPASOrg to cover POI Terminal Management including status report, management plan and acceptor parameters. In January 2013, it approved a fourth Terminal Management message submitted by EPASOrg. EPASOrg will develop additional candidate messages to cover the Sale Management at the retailer (Sale to POI). The Cards SEG has approved a new version of the CAPE messages in the 2012/2013 maintenance cycle. New message versions are expected to be published in May 2013. Two other business justifications are approved for development. ISO_20022_LV_v92
36
ISO 20022 – The Cards & Related Retail Financial Services SEG (2/3)
Covering instruments… Cards and Retail Debit card Charge and credit card …and actors such as: Acceptor (merchant, retailer) Card holder Prepaid card Card issuer Hard- and Software providers Card scheme Acquirer The scope of the Cards and Related Retail Financial Services SEG covers various instruments and actors…. Intermediary agent ISO_20022_LV_v92
37
ISO 20022 – The Cards & Related Retail Financial Services SEG (3/3)
Including business areas such as: Transactions between merchants and acquirers, and cardholders and issuers that support authorization, clearing, reversal, chargeback, dispute processing, etc. Transactions between acquirers and card issuers Similar messages transacted on internet or from mobiles or other personal devices ATM processes such as authorization, processing, ATM management and inventory POI messages for payments, administrative and device related services It covers a wide range of business processes… ISO_20022_LV_v92
38
ISO 20022 – Technical Support Group
Members – 26 experts 10 countries: BR, CN, DE, FI, FR, GB, JP, KR, NL, US 4 liaison organisations: Euroclear, FPL, Mastercard, SWIFT Convener: Paul Hojka, UK Payments Administration (GB); Vice-convener: Anthony Coates, Londata (GB); Secretary: Kris Ketels, SWIFT Kick-off meeting: on October 2008 Mission: help RMG, RA, SEGs and Submitting Organisations with technical matters The TSG was created in 2008. The main purpose of the TSG is to provide technical support to the ISO registration bodies and the submitting organizations or communities of users, upon their request. The TSG advises the Submitting Organisations, the RA and the SEGs on the most appropriate and consistent interpretation of the ISO standard. Any SEG may request the advice of the TSG on technical issues arising from the evaluation of the proposed updates to the Repository or on the technical "implementability" of the proposed updates. As required, the TSG may also be called upon by the RMG, to offer advice on an issue relating to the implementation of the ISO standard, any proposed adoption of new technical specifications or the best way to organize migration to new technical specifications. ISO_20022_LV_v92
39
Continuing with today’s agenda…
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 played a role. ISO_20022_LV_v92
40
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 library 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. UN/CEFACT contributed a technical specification called ‘CCTS’ (Core Component Technical Specification) which is closer to ISO To avoid divergence and facilitate communication between the financial industry – using ISO and other industries – using UN/CEFACT, the financial arms of ISO and UN/CEFACT agreed to work together at ensuring semantic interoperability of their respective dictionaries, thereby ensuring a smooth flow of business information across messages developed under one or the other standard… Goal is to establish interoperability between ISO and UN/CEFACT repositories ISO_20022_LV_v92
41
Harmonisation between ISO and UN/CEFACT
2004: TC68, TBG5 and SWIFT sign a MoU to investigate harmonisation 2005: Trial submission from ISO to UN/CEFACT 2006: ISO TC68/WG4 takes over technological alignment 2007: Official submission from ISO to UN/CEFACT 2008: Customer-to-bank payment components harmonised and accepted in UN/CEFACT core component library 2009: The cooperation is placed under the umbrella of the ‘MoU on e-Business’ 2010: Official submission of a financial e-invoice message from UN/CEFACT to ISO 20022 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). In 2005: SWIFT made a ‘gap analysis’ to describe the differences between ISO and UN/CEFACT’s CCTS and proposed ways to bridge these gaps. The RA made a ‘trial submission’ of some components from the ISO 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. In 2006, the investigation of the alignment of ISO and CCTS methodologies was transferred to the newly created TC68/WG4, in charge of reviewing ISO technical specifications. The trial submission from 2005 was turned into a real submission. UN/CEFACT (TBG17) started processing this submission in 2007 and harmonized and accepted it in early In 2007, UN/CEFACT TBG5, in turn, submitted a business justification for the development of an ISO invoice message based on UN/CEFACT ‘Cross Industry Invoice’ standard. In 2009, the harmonization effort was placed under the more general umbrella of the MoU on e-Business. In 2010, UN/CEFACT TBG5 submitted an ISO compliant Financial e-Invoice to bring into the ISO repository the components used in UN/CEFACT that are needed in ISO messages. ISO_20022_LV_v92
42
A single ISO-UN/CEFACT approach
Registration Management Group ISO users ISO 20022 Registration Authority ISO Standards Evaluation Groups IFX UN / CEFACT (all industries) TBG5 UN/CEFACT Registry/Repository ISO Financial Repository Securities CLS Business models Payments Core Component Library Data Dictionary SWIFT Trade services This slide illustrates the convergence goal between the ISO and UN/CEFACT repositories. Candidate ISO messages Euroclear Forex Common Business Processes Business Process Catalogue EPASOrg Cards ISO_20022_LV_v92
43
Continuing with today’s agenda
ISO 20022 Interoperability within the financial industry The purpose of this last part of the presentation is to illustrate how ISO can help supporting interoperability between different message standards, through its business and message modelling approaches. ISO_20022_LV_v92
44
Using ISO 20022 modelling to reach interoperability
Account Order Date All institutions have their own sets of data objects …and groups them into ‘syntax-neutral’ message models, which... Order Date ISO standardizes common data objects… As explained earlier, the pillar of the ISO methodology is the central dictionary of common business concepts and the modelling methodology used to assemble them in syntax-neutral message models. These message models are the ‘business’ standards approved by the SEGs. Thanks to the central dictionary, all the ISO message models share a common understanding and representation of business concepts which helps the business information to flow smoothly from one message to the other along the transaction life cycles, even if the syntax used to identify and format these concepts in the ‘physical’ messages is different. … can be ‘transformed’ in message formats in the desired syntax ISO 20022 ASN.1 FpML FIX ISO_20022_LV_v92
45
ISO 20022 compliance at model level
Repository ISO Dictionary Dictionary Catalogue ISO message models Card payments Payments clearing & settlement physical message representation In some business areas, the ISO XML syntax may not be the most efficient. For example, in the cards business domain, there may be a need to use a more ‘compact’ syntax than the ISO XML syntax. However, as the data of a card payment will ultimately be processed using the ISO ‘pacs’ - payments clearing and settlement messages, it is key to use the same business concepts in the two sets of messages. The best way to achieve this is by using the ISO recipe to model the card payment transaction messages and transform the resulting message models into the desired syntax. ASN.1 syntax ISO XML syntax ISO_20022_LV_v92
46
ISO 20022 compliance at model level
Repository ISO Dictionary ISO compliant Dictionary Catalogue ISO message models Card payments Payments clearing & settlement physical message representation The resulting message formats are not fully compliant with the current ISO recipe, but they are granted the label of “ISO compliant using a domain specific syntax”. ASN.1 syntax ISO syntax ISO compliant ‘using a domain specific syntax’ ISO compliant ISO_20022_LV_v92
47
“Investment Roadmap” for ISO, FIX, XBRL and FpML syntaxes
The Investment Roadmap is maintained by the Standards Coordination Group including the following organisations: In the securities industry, standards development organisations FPL, ISDA/FpML, SWIFT and ISITC cooperated to issue, in 2008, an ‘Investment Roadmap’ of syntaxes to be used for each business process and asset class. In certain areas, more than one syntax may be required to accommodate the needs of different communities of users. The Investment Roadmap has triggered several ISO development projects targeting the ISO compliance ‘using a domain specific syntax’, such as FIX or FpML. In 2009, SIIA/FISD and XBRL joined the above mentioned organisations to form the ‘Standards Coordination Group’ and expand the Investment Roadmap. Click on the links to download the latest version of the Investment Roadmap and the associated FAQ. Download the Investment Roadmap and related FAQ ISO_20022_LV_v92
48
Interoperability in the customer-to-bank payment domain
Bank A IFX format Proprietary format Bank B Customer A SWIFT MT 101 Let’s look at another example in the customer-to-bank payment domain. 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… Bank C Let us look at a concrete example from payments area: a customer may need to adapt to the format of the banks… ISO_20022_LV_v92
49
Interoperability in the customer-to-bank payment domain
Customer A IFX format Customer B Proprietary format Bank A SWIFT MT 101 Customer C …or it may be the bank that will need to adapt to several formats to please their range of customers. …or banks may need to accept many formats… ISO_20022_LV_v92
50
The reverse engineering produces a canonical ISO 20022 message model
Interoperability in the customer-to-bank payment domain Proprietary TWIST OAGi ISO 20022 Core Payment Kernel model SWIFT MT IFX IFX, OAGi, TWIST and SWIFT formed the ‘IST Harmonisation Team’ to ‘reverse engineer’ existing formats and propose a single ISO message model to cover the customer-to-bank payment initiation. The resulting ISO message, the CustomerCreditTransferInitiation, is also known as the ‘core payment kernel’. It was the first ISO message, approved in September 2005. The single message model can be used to translate each standard into the model and vice versa. The reverse engineering produces a canonical ISO message model ISO_20022_LV_v92
51
Interoperability in the customer-to-bank payment domain
Core Payment Kernel IFX MT 101 MT 101 ISO 20022 Core Payment Kernel IFX Adoption of the ISO 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. Adopting ISO facilitates convergence and co-existence ISO_20022_LV_v92
52
& Answers uestions www.iso20022.org iso20022ra@iso20022.org
We have reached the end of this ISO presentation, and are ready to answer your questions. Remember, a lot of information is available on the ISO website ( which is updated on an ongoing basis. Questions and comments can also be sent to the RA: ISO_20022_LV_v92
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.