[September 26, 2002] "The SWIFT business standards build on SWIFT's experience in developing FIN messages and take it one step further. They are developed in a more formal approach and take into account the full business domain - including its players, processes and business interactions. The resulting messages fit better into the end-to-end business transaction even though they may focus on only a part of the transaction chain... The new messaging solutions are developed based on:
(1) Business modelling methodology, which starts from a description of the relevant business processes, then focuses on the definition of the communication requirements and finally specifies the required messages. The methodology uses Unified Modeling Language (UML) as a syntax independent notation, making it easier to separate the business standard from its physical representation. This methodology facilitates interoperability between standards in different syntaxes, e.g., between FIN and XML. It also makes the link between the messages and the end-to-end business process more formal and more explicit.
(2) Reusable data elements stored in a central repository: the Financial Dictionary. The Financial Dictionary identifies uniquely all the pieces of information (business elements) that need to be exchanged by business actors. It describes their meaning, the way they have to be expressed in a message and the "synonyms" used in other messaging schemes.
(3) XML (eXtensible Mark-up Language), as syntax, and XML schemas as the formal way to describe the message structure. In order to make the delivery of the physical messages faster and more rigorous, SWIFT has defined formal XML design rules to automate the generation of XML schemas. XML has been adopted by the software industry as the preferred communications syntax. As a result, software providers offer a wide range of standardised, off-the-shelf tools to display and validate messages.
[October 17, 2001] SWIFT is involved in a number of XML-related standards efforts consistent with the goal of moving to a single standard for financial services. SWIFT "fully supports this progression and is involved in a number of initiatives, including industry-led ones, to facilitate the industry-wide adoption of a single standard... The ISO working group was created in September 2000 to co-ordinate and standardize the use of XML for securities messages; the mission of the ISO WG10 is to evolve ISO 15022 to permit migration of the securities industry to a standardised use of XML. The aim is to guarantee interoperability across the industry and with other industry sectors, particularly but not restricted to the financial industry... FIX and SWIFT are seeking convergence of their respective messaging protocols to ISO 15022 XML... In addition to SWIFT's ongoing role as the registration authority for the ISO 15022 series of securities messages, the convergence and interoperability aspects of SWIFTStandards methodology have attracted the interest of major financial standards bodies, institutions and vendors... SWIFTStandards has a new methodology to develop and deliver standards faster for SWIFTNet services and for the industry as a whole. The SWIFTStandards Financial Dictionary provides a database of business elements used within financial industry communications; it is the result of cooperation between SWIFT and major financial industry bodies."
[January 25, 2001] SWIFT is "an industry owned cooperative which provide messaging services to banks, broker-dealers and investment managers, as well as to market infrastructures in payments, treasury, securities and trade. These services help our customers reduce costs, improve automation and manage risk. It supplies secure messaging services and interface software to over 7,000 financial institutions in 192 countries; the average daily value of payment messages on SWIFT is estimated to be above USD 5 trillion. SWIFT has re-engineered the way it develops standards in order to take full advantage of state-of-the-art technology. This has led to the definition of a new standards development methodology, based on the use of modelling techniques. The methodology is called SWIFTStandards Modelling and comprises three layers: (1) The Business layer focuses on understanding the business, independently of the solution used to meet its requirements. (2) The Logical layer based on these models specifies how the business data can be exchanged in a structured way, following a number of rules. (2) The Physical layer delivers the messages and rules in the appropriate syntax; e.g., SWIFT MTs, ISO 15022 or XML..." The SWIFT company web site provides an overview of the main characteristics of SWIFT's adoption of XML in an application called swiftML. "swiftML is not 'just another XML implementation for the financial industry'. The design of swiftML bears in mind the interoperability issue of different financial XML implementations through the use of SWIFTStandards Modelling. This new standardisation approach allows to the separation of the business standard from its physical representation in a specific syntax (in this case XML). All this information is stored in the SWIFTStandards Repository. This allows different syntaxes (even non-XML syntaxes) to interoperate through the use of the common business model. swiftML is in line with major XML standardisation initiatives (e.g., ebXML, a global initiative to achieve a common and predicatable usage of XML cross-industry). swiftML adoption follows a very structured approach. For example, business information is always expressed as XML elements/values; metadata information is expressed as XML attributes. This results in consistent and uniform swiftML messages. swiftML messages are currently described using traditional XML DTDs; swiftML schema rules will be published as soon as W3C (World Wide Web Consortium) adopts XML schema and there is a real business need. swiftML is designed in such a way that the adoption of XML schema will not impact the messages currently described using traditional DTDs. The swiftML XML DTDs are primarily used to provide a link to the SWIFTStandards Repository which contains the complete business standard. swiftML element names are human readable. The XML DTDs can be used to validate messages (though these validation capabilities of DTD are limited). These DTDs are not used to document the message, and swiftML DTDs do not replace the UML business model. swiftML has been designed bearing in mind that it must never constrain the development of the business standard. swiftML will have its first implementations in GSTPA, in interactive messaging for the 'Inquiry Link', and in e-trust." The swiftML design rules Technical Specification documents the set of XML design rules, called swiftML, which define in a very detailed and strict way how the physical XML representation is derived from the business message in the UML class diagram."
From the swiftML design rules Technical Specification: "Last year, the SWIFT Board approved the adoption of XML as the preferred syntax for SWIFTStandards. XML is a technical standard defined by W3C (the World Wode Web Consortium) and leaves a lot of freedom for the exact way it is used in a particular application. Therefore, merely stating that we are going to use XML is not sufficient, we must also explain HOW we will use XML. The use of XML by SWIFT is part of the overall approach for the development of SWIFTStandards. This development focuses on the correct definition of a business standard using modelling techniques. The resulting business standard is captured in UML (Unified Modelling Language) and is stored in an electronic repository, the 'SWIFTStandards Repository'. Business messages are defined in UML class diagrams and XML is then used as a physical representation (i.e., the syntax) of the defined business messages. A set of XML design rules, called swiftML, define in a very detailed and strict way how this physical XML representation is derived from the business message in the UML class diagram. This document explains these XML design rules. Mapping rules from UML to swiftML are governed by the following design choices: (1) swiftML representation to be as structured as possible: a) Business information is expressed as XML elements/values; b) Metadata information is expressed as XML attributes. XML attributes are not to be conveyed on the wire' in the XML instance, unless required to remove ambiguity. (2) Even though we have XML-schemas in mind, the design rules currently focus on the generation of traditional DTDs. (3) swiftML element tag names should be readable. (4) Names in UML should be reused in swiftML as much as possible. (5) swiftML elements are derived from the UML representation of a business message. They can only be derived from UML-classes, UML-roles or UML-attributes. (6) Each swiftML element must be traceable to the corresponding UML model element..."
References:
[November 05, 2002] "Web Services on Wall Street -- Inside STP." By Gunjan Santami. From Integration Developer News (November 04, 2002). Case Study. "Straight-through Processing (STP), a solution that automates the end-to-end processing of transactions for all financial instruments from initiation to resolution, is set to revolutionize the financial industry. STP will streamline back-office activities, leading to reduced failures, lower risks, and significantly lower costs per transaction. It encompasses a set of applications, business processes, and standards that will redefine the settlement and processing paradigm within the capital markets industry... A SOA-based framework is capable of providing support for multiple XML standards, such as ISO 15022 [see ISO Working Group 10 - ISO WG 10] and FpML, at the same time, and adding additional standards support without significant redevelopment effort... With the use of Web Services as an enabling technology, STP-related problems and issues will shift from connectivity among different applications in-house and with trading partner applications to the content and structure of the information that is exchanged. The analogy here will be that Web Services will define the standard postal mechanism along with the envelope and addressing format for exchanging letters. What is inside the envelope (the content of the letter) will be defined by the XML-based business process standard, such as ISO 15022 XML..."
[November 04, 2002] "Microsoft Enables Financial Institutions to Cut Cost Of Straight-Through Processing. Microsoft Works With Key Financial Institutions and Partners to Launch BizTalk Accelerator for Financial Services, an Open and Integrated Financial Messaging Infrastructure." - "Microsoft Corp. has "announced the launch of the BizTalk Accelerator for Financial Services, a software solution that enables financial organizations to rapidly integrate financial messaging with internal business systems, support the Society for Worldwide Interbank Financial Telecommunications (SWIFT) ISO 15022 and new XML-based industry standards, and rapidly manage and repair messaging and trade errors. Working with SWIFT and other key technology partners and customers in the financial services industry, Microsoft aims to lower the cost of entry into the financial middleware market by providing a low-cost, highly scalable infrastructure solution, based on BizTalk Server 2002, that can be implemented quickly and easily to facilitate straight-through processing (STP)... The BizTalk Accelerator for Financial Services will assist financial institutions in deploying STP solutions, thereby reducing the risks and costs associated with errors and failed trades. It provides financial industry-specific messaging capabilities that enable financial institutions to manage exceptions, rationalize reference data, detect and repair faulty messages, and build new SWIFT- and Financial Information eXchange (FIX)-compatible systems. In addition, the Financial Services Accelerator provides integral tools to enable support for further industry-standard advancements, ensuring the system is future-proof. It is the fourth accelerator to be released by Microsoft since 2000; the others are RosettaNet (high-tech supply chain), HIPAA (healthcare) and Suppliers (supplier enablement). The first version of the BizTalk Accelerator for Financial Services focuses on payments processing and capital markets trading, settlement, and delivery processes. Built-in features include more than 90 document specifications, or schemas, which describe SWIFT and International Securities Association for Institutional Trade Communication (ISITC) messages for payments, foreign exchange, securities trading and reporting. Microsoft has joined the SWIFT partner program and is providing an immediate solution for institutions to become ISO 15022 compliant. It also offers support for ISO 7775 messaging standards and the new SWIFT Secure IP Network and Gateway..." See the related Presspass interview with Kenny McBride and Derek LaSalle in "For Financial Services, Goal Is STP, Tool Is XML."
[October 30, 2002] "Microsoft Delivers BizTalk Integration Platform For Financial Services." By Mitch Wagner. In InternetWeek (October 30, 2002). "Microsoft plans next week to introduce BizTalk Accelerator for Financial services, an application designed to help financial services link up for securities trading through the use of Web services protocols. The software is designed to rapidly manage messaging and trades between financial institutions, as well as correcting errors. The software is compliant with key financial industry standards, including SWIFT ISO 15022, a standard for securities trading, along with the older standard it replaces, ISO 7775, and standards from FIX and ISITC, two other organizations setting standards for financial transactions. The first version of the software will focus on payment processing, capital-markets trading, settlement, and delivery processes. It has more than 90 document specifications, or schemas, which describe SWIFT and ISITC messages for payments, foreign exchange, securities trading, and reporting. BizTalk Accelerator for Financial Services is the fourth industry-specific implementation of BizTalk to ship. Previous versions are RosettaNet, for the high-tech and electronics industries; Suppliers for supplier enablement; and HIPAA for healthcare..."
[October 15, 2002] "Cape Clear Announces Web Services Integration for SWIFT Financial Network." - "Cape Clear Software, a leading provider of Web Services technology, today announced a Web Services-based integration solution for the SWIFT network. SWIFT is a messaging platform for over 7,000 financial institutions in 197 countries. Cape Clear will enable SWIFT's Members to bypass the traditional costly and complex integration approach, and instead use Web Services to integrate with the SWIFT network and provide Closed User Groups for their clients. SWIFT is migrating its existing X.25-based network to SWIFTNet, which uses Internet Protocol (IP) network technologies and XML. The first service provided by SWIFT utilizing XML is Cash Reporting. Cape Clear will be demonstrating a number of solutions for implementing Cash Reporting at the SWIFT Sibos conference in Switzerland this week, along with solutions for exposing the SWIFT Service as a Web Service and converting existing FIN messages to XML... Cape Clear will expose SWIFT as a Web Service, making it easy for any participating organization to link its business applications to the network using the Web Services standards (XML, SOAP, WSDL, and UDDI). The result is a significant reduction in the cost of integration for any institution looking to link its applications with the SWIFT network and its clients. Cape Clear supports the creation and integration of Web Services from Java, J2EE, .NET, CORBA, COBOL, and all XML-supported applications. Based on the XML standard, the next generation of SWIFT messages (XML for SWIFT, as described in ISO15022) is planned to be phased into general use. This is a fundamental change to the current SWIFT message standards and signals the move of SWIFT from X.25 to IP network technologies. The new messages are based on business elements relevant to the specific business process. Customers will benefit from these new messages, which will be easier both to update and use. These messages will also better embrace the principles of straight-through processing (STP), providing increased business functionality, along with the capacity for expanded use without any loss of efficiency..."
[July 24, 2002] "EBA and SWIFT announce the adoption of Bulk Payments SWIFTStandards XML for STEP2." - "In response to the payments industry needs, SWIFT has been developing a set of XML standards aimed at facilitating the exchange of bulk payments. As a result of a joint collaboration, SWIFT and the EBA (Euro Banking Association) have defined a STP Bulk Payments message in XML, which will be used primarily, but not exclusively, in the STEP2 system. This message is part of the set of Bulk Payments SWIFTStandards XML messages. The EBA, through STEP2, will provide a pan-European ACH solution for processing bulk payments. The system will offer direct access to a wide banking community, whose payment instructions, routed through to STEP2, will be distributed to any bank operating in the EU. In addition to the MT 103+ based files, the STEP2 core application will also accept, process and deliver XML Bulk Payments files from/to its users. Supporting both FIN and XML-based standards will allow STEP2 to offer a solution that address different banks' needs. We will keep you regularly informed on any progress made on this joint EBA and SWIFT initiative..."
[May 2002] "SWIFTStandards XML for Implementors." May 2002. 42 pages. "This document is the implementation manual for SWIFTStandards XML messages. It is currently aligned with the SWIFTNet V4.0 product line, and it will be updated as such when SWIFTNet will be enhanced. It explains what the various XML components are, how they relate to the SWIFTStandards Financial Dictionary, and how this SWIFStandards Financial Dictionary is organised to promote reusability... Overview of the methodology for SWIFTStandards Message Development The methodology comprises 5 activities: (1) The Business Analysis focuses on getting a good understanding of the business objectives of the considered Business Area. (2) The Requirements Analysis focuses on discovering the communication and interaction requirements related to the Business Processes that are part of the considered Business Area. (3) The Logical Analysis and (4) Logical Design specify the Message Standard that meets the identified communication and interaction requirements. The Message Standard is defined independently of any physical implementation and includes Message Flow Diagrams and Message Definitions. (5) The Technical Design delivers the physical implementation of Message Definitions and Message Rules in their corresponding SWIFTStandards XML Schema2. These five activities are applied in an iterative and incremental way for the SWIFTStandards Message Development..." [cache]
[July 27, 2001] SWIFT-FIX convergence to ISO 15022 XML. "On 5 July 2001, SWIFT and FIX Protocol Limited (FPL) announced that the two organisations will seek convergence of their respective messaging protocols by centring on the development and adoption of ISO 15022 XML as a common industry standard. SWIFT and FPL will actively support the efforts of ISO Working Group 10, the group focused on the migration to XML of ISO 15022, which is the current standard scheme for securities messages. ISO 15022 XML can be viewed as a superset covering the domains of existing protocols, such as the current ISO 15022, FIX, and FpML, developed via the use of business modelling with an XML-based representation. ISO 15022 XML will leverage the expertise of FPL in the pre-trade and trade domain (orders and executions) and SWIFT in the post-trade domain. In addition, there are numerous other firms and standards bodies committed to and involved in the ISO Working Group 10 process. SWIFT Standards serves as the Registration Authority for the current ISO 15022 standard and will expand this role to cover the new XML version of ISO 15022."
ISO Working Group 10 (ISO WG10). "The mission of the ISO WG10 is to evolve ISO 15022 to permit migration of the securities industry to a standardised use of XML. The aim is to guarantee interoperability across the industry and with other industry sectors, particularly but not restricted to the financial industry..."
[July 27, 2001] SWIFT FAQ re: ISO 15022 XML announcement. "SWIFT and FPL believe that ISO 15022 XML will provide the glue between the pre-trade/trade (front office) and post-trade (back office) domains. The effort leverages the experience and expertise of both organisations: FIX in the pre-trade/trade domain and SWIFT in the post-trade domain. Different parts of the trade life cycle are truly coming together to work through issues hindering effective STP and the move to shortened settlement cycles... ISO 15022 and FIX are both "tag"-based syntaxes, where the business elements and their values are identified by a code called a "tag". However, the tags and the way to express values are different in ISO 15022 and in FIX. Most of the business elements used by FIX and ISO 15022 are the same. SWIFT and FIX had already started co-operating to make sure that the new business elements used by FIX (for FIX 4.3 version) have an equivalent in the ISO 15022 Data Field Dictionary. So that further convergence, when we have an ISO 15022 XML version, will be easier..." See also the PDF version. [cache, PDF]
[October 10, 2001] "Pre-trade/trade -- Is Interoperability Achievable?" From SWIFT. "Securities participants left Sibos in San Francisco feeling generally upbeat about the possibilities for closer dialogue between SWIFT and FIX on aligning their respective standards. That feeling was vindicated in July when FIX Protocol Ltd. (FPL) and SWIFT announced an agreement to seek convergence of their respective messaging protocols. The agreement centres on the adoption of ISO 15022 XML as a common industry standard. Under the terms of the agreement, FPL and SWIFT will actively support the efforts of the ISO Working Group 10 (WG10), which aims to evolve the ISO 15022 scheme for securities message types to a single standard, expressed in XML. The agreement leverages the expertise of FPL in the pre-trade/trade domain and SWIFT in the post-trade domain. Both organisations will work to develop mapping documentation to support the industry's migration to ISO 15022 XML and the coex-istence of FIX, ISO 15022 and ISO 15022 XML... Interoperability and convergence are two compatible, though not necessarily linked approaches to that alignment. 'Interoperability would ease convergence but is not necessary to achieve it,' suggests panellist Jean-Marie Eloy , head of standards, SWIFT. 'I would define interoperability as the ability to transfer the technical format or syntax of one standard into the format of another, with defined syntax mapping rules using some kind of middleware. It also has to consider things like business process and work flow,' explains panellist John Goeller, director, CSFBNext, convener of the ISO 15022 XML Working Group and a long-time FIX participant. 'Convergence, on the other hand, means that two standards have combined into one through agreement of a common technical syntax and business process.' While aiming for convergence of standards, it is, says Mr Goeller, 'perfectly logical to start with how those standards will interoperate'..." [From: SWIFT Sibos Issues On-site, 15 - 19 October 2001]
[April 09, 2001] "Rewriting the Standard Approach." From SWIFT. "Straight-through processing (STP) has been the 'Holy Grail' of the securities industry for several years. Numerous industry initiatives have declared the furtherance of STP as their ultimate goal. Yet there is also recognition that without appropriate use of standards, STP can never be fully achieved end-to-end. Two developments in the securities industry are now providing the impetus for a determined effort to bring together the work in standards creation now being undertaken by disparate bodies with an often-overlapping membership. These are the move to a new ISO standard for securities messages (ISO 15022) and the growing acceptance of the potential role of XML in overcoming communication barriers in a TCP/IP environment. Paradoxically, it is the fear that the various XML initiatives in the financial services industry could lead to further divergence that has prompted the current formal co-operation. 'XML is not a syntax per se; it's rather a way of defining your own syntax,' explains Jean-Marie Eloy, head of standards, SWIFT. 'Unless you really agree on the way you will use XML, you risk introducing different flavours or dialects. That's what we want to avoid.' FIX, SWIFT and FpML have all embarked separately on XML projects for their own messages. 'We want to move to one standard,' says Eloy. 'XML is very powerful on a TCP/IP protocol network, but we have to agree on one and only one use of XML. If, for example, we use 'trade date' in a message, we need to agree on the definition and give it a single, unique name in XML.' ISO 15022 ISO 15022 replaces the previous standard for electronic messages exchanged between securities industry players, ISO 7775 (scheme for message types) and ISO 11521 (scheme for interdepository message types). Defined by Technical Committee 68 of the International Organisation for Standardisation (ISO), it sets down the principles necessary to provide the different communities of users with the tools to design message types to support their specific information flows. These tools consist of a set of syntax and message design rules, a dictionary of data fields and a catalogue for present and future messages built by the industry from the defined fields and following agreed rules..."
[July 2001] swiftML design rules Technical Specification - swiftML rules. "Detailed technical specifications on how swiftML is generated from a given UML business model..." 41 pages. [cache]
[January 25, 2001] "A business blueprint for standards. SWIFTStandards: An Update." From SWIFT. "The development of standards is still a highly technical business. But it is also a business issue. That synergy is being embodied in the new SWIFTStandards that are being developed for the XML environment. As Martine de Weirdt, senior manager, standards, at SWIFT, reminded delegates, 'we don't build standards for the sake of doing so, but for your business.' De Weirdt traced the development of the new approach to standards from Sibos at Helsinki and Munich. This has been a response to the emergence of a diverse user community and the fact that proprietary standards are reaching their technical limits. The ultimate goal is still 'one standard' at the end of the day, but the emphasis in the interim will be on interoperability. There was reassurance for all the delegates present from Klaus-Dieter Naujok, senior business developer at NextERA and chair of the ebXML joint initiative of UN/CEFACT and Oasis. 'SWIFT is state-of-the-art and it has always shared our vision of the future,' said Naujok. 'What it is doing is not exotic and CEFACT would not have been possible without SWIFT.' Naujok pointed out that the telecoms, automobile and retail industries, for example, are all moving in the same direction. And, he said, 'if you're part of it now, the cost may not be so great as it would be if you had to bear the costs of migration in the future.' With so many industries and standards bodies working together 'there is no danger of being isolated.' ebXML aims to create a framework for different industries to work with an interoperable form of XML. Its 10 project teams are working within an 18-month timeframe to establish requirements, broaden awareness, and develop architecture, core competencies, registries and a business process. Microsoft - one of the few big technology players not involved in ebXML - is now talking to the organisation. Business information modelling lies at the heart of the development of SWIFTStandards. In the case of the GSTPA, for instance, business information modelling is being used to develop a model for the post-trade, pre-settlement environment. In the e-trust area, an interactive message is being developed to query trust certificates. Frank Vandamme from SWIFT standards reiterated the point that 'you don't need to be a modelling expert to work on standards development. We need to capture the information from your business experience.' Unified Modelling Language (UML) is then used to produce a model which is put to the users. The other crucial ingredient in future standards will be XML. Naujok emphasised that XML is not a universal panacea to all syntax problems. What it does offer is the ability to create flexible document structures. Vandamme described in more detail how swiftML is evolving - along with a number of other XML formats, such as FIXML, FpML, Bolero XML and STPML. The important point is that SWIFT will not replace all FIX syntax messages with XML syntax - especially not, as in the payments area, where FIN works very well. swiftML does have all the benefits of XML and it will be possible to create a lot of tools around it, especially as XML is becoming the standard in e-business..."
[January 26, 2001] "XML: The Search For Standards." By Clive Davidson. In Risk Magazine. August 2000. "Extensible Markup Language (XML) can offer the best route to the consistent data formatting standards desperately needed for straight-through processing and enterprise-wide risk management. But the industry still lacks a comprehensive and compatible set of specifications. There is currently a proliferation of initiatives to create subsets of XML standards for things such as over-the-counter derivatives and risk data. At the same time, various organisations, including Microsoft and the United Nations, are attempting to establish frameworks for co-ordinating standards across industry sectors. So while on one level progress towards XML-based standards for straight-through processing (STP) and risk appear slow, there is considerable activity towards establishing the groundwork on which these standards must be based... while several institutions and their software suppliers have seen the potential of XML to solve internal problems and have already deployed it in proprietary ways within their technology infrastructures, they are also supporting initiatives to create industry-wide standards. Among the first to seize upon XML for their internal use were software suppliers California-based Integral Development, and New York-based SunGard Trading and Risk Systems and JP Morgan. Integral and SunGard created sets of XML specifications for their own systems, called FinXML and Network Trade Model respectively, while JP Morgan got together with PricewaterhouseCoopers to sketch out XML specifications for OTC derivatives, which they called FpML. Integral made FinXML freely available, and has used it in building its CFOweb.com financial portal, while SunGard has contributed NTM to Microsoft's DNAfs architecture for financial services (Risk August 1999, page S19). Meanwhile, other XML initiatives have appeared. The consortium of broker-dealers and investment firms developing the FIX protocol for sharing pre-deal information has been working to incorporate XML into a new version of its protocol called FIXML. New York-based data and technology supplier Bridge Information Systems created MDML, a market data specification for XML, while Toronto-based risk management systems supplier Algorithmics has begun working on an XML specification for risk data, called RDML...But while the industry generally recognises the need for diverse and complementary efforts at this early stage of the standards-making process, some people in the industry felt there was a need to pull the various strands of activity together. In February, representatives from the FIX organisation, the Industry Standardisation for Institutional Trade Communication-International Operations Association (ISITC-IOA) and the American National Standards Institute hosted a meeting that included representatives from all the vertical and horizontal XML initiatives, as well as many from traditional standards-making bodies such as the International Organisation of Standardisation (ISO), the World-Wide Web Consortium (W3C -- the originator of XML), and financial industry service providers and consortia such as the communications network and messaging organisation Swift, and the Global Straight-Through Processing Association (GSTPA). The purpose of the meeting was 'to share information and identify commonality in terms of approach, framework and agreed principles, as well as potential points of convergence', with the overall aim of promoting 'interoperability' between the emerging XML specifications. Following presentations on ebXML, FpML, FIX, the GSTPA, the ISO and the ISITC-IOA, the meeting identified three areas that required co-ordinated attention -- modelling (of the business requirements to be captured in the standards), semantics and schemas (the syntax of the individual standards), and interoperability (the ability of the standards to work together). There was a further meeting in June, where the participants established the ISO XML Advisory Group. The participants chose ISO as the umbrella organisation because of its long experience in international standardisation efforts, and its established role in the financial industry -- the securities industry has adopted its ISO 15022 data dictionary as the standard for messaging in confirmation, clearing and settlement. John Goeller, director at Salomon Smith Barney and chair of the new group, says its aims are to 'serve as the co-ordination point for XML initiatives, provide a framework for standardised use of XML in the securities industry, provide XML recommendations for the ISO 15022 data dictionary, and co-ordinate with ebXML'." [This article originally appeared in the Technology Risk supplement to the August 2000 issue of Risk magazine published by Risk Waters Group Ltd.]
Related XML standards activity for securities and financial markets:
- Financial Information Exchange Protocol (FIX)
- Interactive Financial Exchange (IFX)
- FinXML - 'The Digital Language for Capital Markets'
- Investment Research Markup Language (IRML)
- Extensible Financial Reporting Markup Language (XFRML)
- Extensible Business Reporting Language (XBRL)
- XMLPay Specification
- Financial Products Markup Language (FpML)
- Market Data Markup Language (MDML)
- Weather Markup Language (WeatherML)
- MarketsML Initiative
- Research Information Exchange Markup Language (RIXML)
- Data Link for Intermediaries Markup Language (daliML)
- Straight Through Processing Markup Language (STPML)
- FAML DTD for Financial Research Documents
- Open Financial Exchange (OFX/OFE)
