Getting Started with UNIFI (ISO 20022)

Transcription

1 SDN Contribution Getting Started with UNIFI (ISO 20022) Summary This article provides an explanation of the ISO UNIversal Financial Industry message scheme (UNIFI). Created on: 24 May 2006 Author Bios David Frankel is Lead Standards Architect for Model-Driven Systems at SAP Labs. His career in the software industry spans over 25 years, during which he has had experience as a software developer, architect, and technical strategist. He is the author of many published articles and sole author of the book Model-Driven Architecture : Applying MDA to Enterprise Computing, published by John Wiley & Sons in He also is lead editor of the book The MDA Journal: Model Driven Architecture Straight from the Masters, published by Meghan-Kiffer Press in He served several terms as an elected member of the OMG Architecture Board, and was intimately involved in the OMG's launch of Model Driven Architecture. He is the co-author of several industry standards, including COM-CORBA Interworking, the UML Profile for CORBA, and the UML Profile for EJB. Juergen Weiss is SAP s Director of Product Management for Application Solution Management ERP (Enterprise Resource Planning) in the Financial and Public Services Business Solution Group. He joined SAP in 1997 after a previous position as PR Manager in a large German bank. He has held various positions within SAP and since 2000 has been globally responsible for the Financial Supply Chain Management applications including Electronic Bill Presentment and Payment, Dispute Management, Collections Management, Credit Management and In-House Cash as well as Accounts Payable and Receivable. Among his tasks, Juergen manages the roll-in of customer requirements and the roll-out of the solution. Juergen has degrees in Economics and Business Administration from the Universities of Heidelberg and Hagen SAP AG 1

2 Table of Contents Getting Started with UNIFI (ISO 20022)...1 Summary... 1 Author Bios... 1 Table of Contents... 2 Why UNIFI is Important to SAP and SAP Customers... 2 The Need to Simplify Electronic Payments... 2 The Need for Straight-Through Processing... 2 What is UNIFI?... 3 UNIFI Electronic Finance Messages Being Implemented by SAP... 3 How UNIFI Helps... 3 A Closer Look at the UNIFI Standard... 4 UNIFI s Model-Driven, Component-Based Message Definition Process... 4 The Business Process Catalogue and the Data Dictionary... 4 Why is UNIFI Component-Based?... 5 Why is UNFI Model-Driven?... 5 UNIFI Roles and Responsibilities... 5 ISO Technical Committee Standards Evaluation Groups... 5 The Registration Authority... 5 The Repository Management Group... 5 Membership... 5 Why UNIFI is Important to SAP and SAP Customers SAP is committed to streamlining communication between banks and their corporate customers and to realizing straight through processing of electronic payments. The UNIFI standards are critical to achieving these objectives, and SAP is implementing the standards in mysap ERP. The Need to Simplify Electronic Payments A Global 1000 company typically has between eight and 15 relationships with various banking institutions. Large organizations have to work with 100+ banks, 100+ message formats and more than 50 internal proprietary systems. Multiple message formats, data structures, interfaces, and proprietary tools make electronic information exchange between banks and their corporate customers extraordinarily complex and costly. Corporate IT departments administering electronic payments via their ERP systems handle payment orders for each bank separately, collect statements from each bank separately and manage complex routing requirements. Each interface costs an estimated EUR 20K 50K per year to maintain. The existence of multiple bank communication channels complicates security issues. Banking institutions have similar challenges, with inefficient client access through multiple, costly delivery channels, and the banks spread themselves thin trying to manage security over each channel. Banking institutions also have to maintain proprietary interfaces and communication software. The Need for Straight-Through Processing Furthermore, the cacophony of formats and protocols is impeding the implementation of straight through processing. There is a lack of agreed-upon status and notification messages, which results in poor visibility of the financial supply chain and little or no opportunity to reduce the requirements for working capital SAP AG 2

3 What is UNIFI? The ISO UNIversal Financial Industry (UNIFI) message scheme describes a process for defining electronic finance messages. UNIFI also provisions a repository where messages conforming to the process can be registered. Various communities of interest have formed to leverage the UNIFI process to define and register messages. The first to do so was the IST Harmonization (ISTH) group, a consortium of standards bodies and banks that enlisted the assistance of additional companies including SAP. ISTH initiated the World Wide Payment Harmonization Project, which defined a set of electronic payment messages called the payment kernel that SAP is implementing. ISTH is working on some new messages as well. The standards bodies that are members of the ISTH consortium are: IFX Forum: International Financial exchange Forum SWIFT: Society for Worldwide Interbank Financial Telecommunication OAGi: The Open Applications Group TWIST: Transaction Workflow Innovation Standards Team UNIFI Electronic Finance Messages Being Implemented by SAP The UNIFI messages that SAP is implementing in mysap ERP include: Credit transfer initiation Debit transfer initiation Payment initiation status Payment initiation cancellation request Payment initiation cancellation status Cash management advice Cash management statement The most critical messages credit transfer initiation, debit transfer initiation, and cash management statement are expected to be released earlier than mysap ERP. Support for the remaining messages will be released exclusively in mysap ERP. It should be noted that payment initiation cancellation request and status messages will be implemented later than the others. Direct bank communication via mysap ERP will use SWIFTNet to send and receive UNIFI messages to and from banks. SWIFTNet is the private network operated by SWIFT that ensures higher levels of security, reliability, and data integrity than are available over the public Internet. SWIFTNet offers two different mediums for transmitting UNIFI messages. One is FileAct, which transmits messages as files. The other is InterAct, which is a more interactive mode required for certain kinds of financial transactions. SAP will use FileAct for transmitting UNIFI messages. How UNIFI Helps Standardization that results in one set of electronic payment and funds transfer messages (UNIFI) on one secure message delivery channel (SWIFTNet) should significantly streamline and simplify electronic finance for users of mysap ERP. Standardized payment and funds transfer initiation messages, status messages, and advice and statement messages enable banks and their corporate customers to close the loop and achieve straight through processing. Adoption of the new messages across industry will take some time, but the path has been defined and the way money moves is fundamentally changing SAP AG 3

4 A Closer Look at the UNIFI Standard This section provides an overview of the architecture of the UNIFI standard. UNIFI s Model-Driven, Component-Based Message Definition Process The UNIFI standard does not define electronic financial messages. Instead, UNIFI codifies a process for defining such messages. Any community of interest can use the process to define messages for the electronic exchange of data and can apply to the UNIFI Registration Authority to have the messages registered in the UNIFI Repository. The IST Harmonization (ISTH) group, described above, is an example of such a community of interest. The payment kernel that ISTH defined is the first set of messages to be admitted to the repository. The UNIFI process is model-driven and component-based. Although XML-structured data is what flows when a UNIFI message moves from point A to point B in the financial value chain, defining a message is not simply a matter of specifying an XML schema. An XML schema must be generated from an abstract UML model of a message. The model of the message is a composition of message components. Message components are also UML models. The model of each message component can be traced back to a component within a model of the business transaction under consideration. Business Process Catalog Business Transactions Data Dictionary Business Components Message Components Messages (Composed of Message Components) Schemas (Generated automatically from Messages) A B Means B traces back to A UML XML Figure 1: Contents of the UNIFI Repository The Business Process Catalogue and the Data Dictionary The UNIFI Repository includes (see Figure 1) a Business Process Catalog, which contains models of business transactions. The Repository also has a Data Dictionary, which includes models of the entities that are dealt with by business transactions. These entities are called business components. The Data Dictionary also contains message components, which are models of the recurring sets of data that are exchanged in the course of executing business transactions. Messages are modeled as combinations of message components. XML schemas are generated from the message models according to a UML-to-XML mapping defined in the UNIFI standard. Hence, any element in an XML schema can ultimately be traced back to a business component used in a business transaction. The UNIFI standard specifies that organizations that contribute message definitions to the repository must follow the model-driven, component-based process. That means that a message definition must always be 2006 SAP AG 4

5 constructed as an assembly of message component definitions. Whenever possible, message components already defined in the Data Dictionary should be used to define a new message. If it is not possible use existing message components, then and only then the contributor must define and register new message components. Finally, the XML schema for the message must be generated from the UML-based message model as defined by the UNIFI XML schema production rules. The generated schemas define the format of the XML that flows at run-time when a UNIFI message is exchanged between two or more constituents. Why is UNIFI Component-Based? The component-based aspects of the UNIFI process are designed to avoid duplication of effort and promote synergies in the work of the various contributors to the Repository. Why is UNFI Model-Driven? The model-driven aspects of the process are designed to ensure that each part of a message can be definitively traced back to a model that provides a semantic context. This minimizes the interoperability errors that usually occur when a common understanding of data semantics is lacking. The model-driven approach also results in consistently structured XML that is derived from UML according to published rules. Furthermore, separating the model of the business information from the physical XML representation means that changes to XML, or the replacement of XML by something else in the future, will not make it necessary to rebuild the message definitions from scratch. UNIFI Roles and Responsibilities This section provides an overview of the various groups that are responsible for the UNIFI standard and for the contents of the UNIFI Repository (see Figure 2). ISO Technical Committee 68 The UNIFI standard was promulgated by ISO Technical Committee 68, which is ISO s financial services committee. TC68 Working Group 4 (WG4) is responsible for maintaining and upgrading the standard. This means that WG4 is responsible for defining the process for creating, approving, and registering content for the UNIFI Repository, but has no role in creating, approving, or screening specific content to be registered in the Repository. Standards Evaluation Groups Standards Evaluation Groups (SEGs) are responsible for evaluating the business case for proposed contributions of new content to the UNIFI Repository. There are multiple SEGs, each addressing a different area of the financial services industry. The Registration Authority The Registration Authority is the organization that maintains the UNIFI Repository. It is responsible for maintaining consistency of content across the different business areas, and for the integrity of the information in the Repository. The Registration Authority makes the decision whether to accept or reject proposed contributions to the Repository, based on its evaluation of the effect contributions would have on the consistency and integrity of the Repository contents. ISO designated SWIFT to fulfill the Registration Authority function. The Repository Management Group The Repository Management Group (RMG) oversees the Registration Authority. The purpose of the RMG is to ensure that the Registration Authority performs in accordance with its contractual obligations. The RMG manages an appeal process that advocates of a rejected contribution to the Repository can use to challenge such decisions. The RMG also charters and defines the scope of Standards Evaluation Groups. Membership TC68 Working Group 4, Standards Evaluation Groups, and the Repository Management Group are composed of qualified representatives of various companies, organizations, and countries as defined by ISO 2006 SAP AG 5

6 rules. The Registration Authority is a pre-existing organization that hires and fires employees according to its own policies. ISO TC68 WG4 Repository Management Group Standards Evaluation Groups Registration Authority Figure 2: UNIFI Organization Chart Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document SAP AG 6