WHITEPAPER SWIFT MESSAGING The testing journey LIAM SHERLOCK Principal Consultant liam.sherlock@sqs.com Liam Sherlock holds a degree in Applied Computing and has been with SQS since 2005. His key responsibilities are test management, consultant coaching, and programme / project management. Programme / project delivery is backed up with the certifications PRINCE 2® and PMI PMP®, as well as test management. His experience spans 14 years of professional testing across a wide range of industry sectors, managing geographically dispersed test and vendor teams. SWIFT Messaging Page 2 1 MANAGEMENT SUMMARY The Society for Worldwide Interbank Financial Telecommunication (SWIFT) was founded in 1973, with the mission of creating a shared worldwide data processing and communications link and a common language for international financial transactions. Starting with the support of a modest 239 banks in 15 countries, SWIFT now boasts 8,468 live users across 208 countries. (') sure. As volumes of traffic increase, there will be a greater need for performance testing of processing platforms and trade life-cycle management applications. Another area of growth is XML messaging (i.e. ISO 20022 or MX format). This message format was published for the first time in 2004 and therefore still is in its infancy. Traffic for this format over In recent years, there has been an increase in the last five years (as published by SWIFT) has alinterest in Straight-Through Processing (STP, most doubled. This traffic increase along with the (()) with withregard regardtotofinancial financialservice servicetransactransac- support of major clearing houses in Europe and tions. SWIFT messaging can help facilitate STP. pending restrictions being placed on its predecesThis offers financial service organisations the op- sor standard (ISO 15022) means that the growth portunity to reduce costs and increase volumes of this message format looks set to continue at of financial transactions. This area has huge some pace. growth potential as it is easy to demonstrate the return on investment to potential clients. With This paper aims to advise on what contributes to STP, manual intervention and paper processing making SWIFT messaging a success, especially are removed thereby reducing costs but increas- with regard to message flows and straight-through ing the risk of financial transactions being com- processing. It looks at the interaction between the pleted with inaccurate or out-of-date information. messages, how they are linked, and gives examTherefore, it is vital that the messaging solution ples of the testing challenges that organisations is tested thoroughly in order to reduce risk expo- working with SWIFT messaging have to face. 2 INTRODUCTION 2.1 SETTING THE SCENE ISO (International Organization for Standardization) is the world’s largest developer and publisher of international standards, a network of the national standards institutes of 162 countries. This network makes it possible to reach a consensus on solutions that meet both the requirements of business and the broader needs of society. (3) The standards for electronic messaging in the financial industry have been developed by ISO. However, while ISO has defined the standards, a dictionary of data fields and a catalogue for messages have been kept outside these standards. They are made available by the Registration Authority (RA). SWIFT is the RA for the following ISO standards that will be mentioned: ISO 15022 Securities – This standard’s message scheme includes a set of syntax and message design rules, a dictionary of data fields, and a catalogue for securities (i.e. MT) messages. ISO 20022 Financial Services – This standard includes a universal financial industry message scheme. It is a repository contain- SWIFT Messaging ing descriptions of messages (i.e. MX) and business processes for the financial industry, and a maintenance process for the repository content. The messages themselves are an XML-based syntax and are the successor to the ISO 15022 standard. In addition to the above standards containing the two main message suites, SWIFT users will also come across other standards to use within the messages themselves: ISO 9362 – This is also known as the BIC (Business Identifier Code). This code unambiguously identifies both financial and non-financial institutions. It is used primarily for international wire transfers and the exchange of other messages between banks. The BIC can have either eight or eleven characters. ISO 13616 – IBAN stands for International Bank Account Number. It is the international standard for numbering bank accounts. It allows exchanging account identification details in a machine-readable form. The IBAN structure is defined in ISO 13616-1 and consists of a two-letter ISO 3166-1 country code, followed by two check digits and up to thirty alphanumeric characters for a BBAN (Basic Bank Account Number). (4) ISO 6166 – This standard provides a uniform structure for a number known as the International Securities Identification Number (ISIN), which uniquely identifies securities. (+) The ISIN consists of a total of twelve characters. Page 3 2.2 THE CHALLENGE With SWIFT message testing, the challenges are many, but understanding how to interpret the SWIFT standards and understanding the flexibility within these standards is key. The need to understand how the messages are linked to form message flows is imperative to reaching straightthrough processing. Finally, SWIFT makes regular updates to its message formats, and any user of SWIFT messaging needs to keep informed of these changes. An assessment of the updates is required to see whether any changes to message configurations have become necessary. 2.3 GETTING STARTED In order to get started with SWIFT messaging, there are a number of prerequisites that need to be in place before you can send and receive messages. A quick overview of the following terms used when talking about SWIFT messaging will be helpful: Message service(s) Message format(s) Message types Knowing these prerequisites is vital to the success of any SWIFT messaging project, so they should be known and agreed before delving into any details of the messages themselves. 2.3.1 MESSAGE SERVICE(S) SWIFT provides an Internet protocol-based messaging platform called SWIFTNet, which offers four messaging services to SWIFT Note: There are other, alternative numbers that customers (-): can be used to identify a security, e.g. CUSIP® 1 FIN – This service enables the exchange of messages formatted with the traditional (used in the US and Canada, cf. (,)) or SEDOL SEDOL SWIFT MT (message type) or ISO 15022 stand(used by securities registered with the London ards. It works in store-and-forward mode and Stock Exchange). SWIFT Messaging Page 4 functionality (see Figure 1), such as message copy, broadcasts, and online retrieval of previously exchanged messages. This standard of messaging currently is by far the most used. 2 InterAct – This service enables the exchange of messages formatted with the new XML-based SWIFT MX or ISO 20022 standards. As well as offering store-and-forward messaging, it also supports real-time messaging and real-time query-and-response messaging (see Figure 2). 3 FileAct – This service enables the transfer of files. It can be used for the transfer of large batches of messages, such as bulk payment files, very large reports, or operational data. 4 Browse – This service allows users to browse securely on financial websites available on SWIFTNet using standard Internet technologies and protocols such as HTTP-S and HTML. SWIFTNet Message Institution A Message Ack Ack CENTRAL STORAGE Institution B STORE-AND-FORWARD MESSAGING Figure 1: Store-and-forward messaging SWIFTNet Institution A SWIFTNet Message Query Acknowledgement Response REAL-TIME MESSAGING Institution B Institution A Institution B REAL-TIME QUERY-AND-RESPONSE MESSAGING Figure 2: Real-time messaging and real-time query-and-response messaging SWIFT Messaging It is important to note that a mix of services can coexist in the overall SWIFT messaging solution. This is especially true if there are a number of communicating parties involved. For example, communication between client and transfer agent could be done using InterAct while the communication between transfer agent and custody could be FIN. This means that the transfer agent must be able to send and receive both the MT and MX message formats. The service choices available may be impacted by the age of the systems being interfaced. In our experience, the older and more established legacy custody systems are almost always FIN-enabled and do not yet support InterAct. Migration to the InterAct service and the new XML-based MX message format is gaining speed, especially as the time when restrictions will apply to FIN Fund Templates draws nearer. The other advantage of InterAct is real-time messaging. Delays in the settlement of financial transactions are no longer acceptable. Speed of processing and therefore automation of the messaging process becomes increasingly important. 2.3.2 MESSAGE FORMAT(S) The choice of a messaging service directly impacts the message format to be used. As with the choice of service, facts suggest that the more established MT format (ISO 15022) is more popular and used most frequently. For someone unaccustomed to the format, it is more difficult to understand, but because of its popularity, many people within the financial services industry refer to this format as SWIFT and are unaware that another format even exists. The MT format uses a series of tags followed by the actual information. The following subset of an ‘MT502 Order to Buy or Sell’ message shows the order details section of the message: Page 5 :16R:ORDRDET :22H::BUSE//SUBS :22F::TOOR//MAKT :22H::CAOP//CASH :22F::TILI//GTCA :22H::PAYM//APMT :98A::EXPI//21001231 :16R:TRADPRTY :95R::BUYR/CLIENT1234 :70E::DECL///CERT/Y/BYOO/1234 :16S:TRADPRTY :16R:TRADPRTY :95Q::INVE//BANK1 :16S:TRADPRTY :19A::ORDR//EUR/50000 :35B:ISIN GB0123456789 :16S:ORDRDET This will be explained further below. A user unfamiliar with the MT format will find it difficult to know what this subset is talking about. The format of an MX message sample (ISO 20022) is more familiar to people accustomed to XML: <IndvOrdrDtls> <OrdrRef>ORDERREF001</OrdrRef> <FinInstrmDtls> <Id> <ISIN>GB0123456789</ISIN> </Id> </FinInstrmDtls> <GrssAmt>50000</GrssAmt> <SttlmMtd>APMT</SttlmMtd> <PhysDlvryInd>false</PhysDlvryInd> <ReqdSttlmCcy>EUR</ReqdSttlmCcy> <ReqdNAVCcy>EUR</ReqdNAVCcy> </IndvOrdrDtls> SWIFT Messaging 2.3.3 MESSAGE TYPES Within each message format, there is a suite of message types. For ISO 15022, these are broken into categories: Category 1 – Customer Payments Category 2 – Financial Institution Transfers Category 3 – Treasury Markets, Foreign Exchange Category 4 – Collections and Cash Letters Category 5 – Securities Market Category 6 – Treasury Markets, Precious Metals Category 7 – Treasury Markets, Syndication Category 8 – Traveller’s Cheques Category 9 – Cash Management and Customer Status Each message type is given its own unique ID, e.g. MT502, MT509 or MT515. The first digit after the ‘MT’ indicates the category that the message type belongs to. Each message type will have its own Page 6 definition as detailed by SWIFT. This message definition will have a number of optional, mandatory and conditional elements to it. It is important to understand what message types are going to be tested, before going into the more detailed definition piece. For ISO 20022, the message types are broken down into five business domains: Payments FX Securities Trade Services Cards and Related Retail Financial Services It should be noted that the suite of supported message types needs to be agreed between the sender (financial institution or bank) and the receiver (financial institution or bank) prior to going into a lower level of detail with regard to message definition and testing. 3 MARKET – CURRENT STATUS AND OUTLOOK According to the article ‘IT Spend by Industry Worldwide’ by Jeff Roster, the ‘Financial services industry spent $ 558.4 billion worldwide in 2008 on IT (hardware, software, IT services, internal services and telecommunications)’. (.) that Current forecasts from Gartner (/) predict predict that IT spending will remain around the $ 500 billion mark into 2015 and have a CAGR (Compound Annual Growth Rate) in excess of 5 % over the fiveyear period from 2009 to 2015. SWIFT messaging enables more than 9,000 financial service organisations in 209 countries (according to SWIFT, July 2011) to exchange millions of standardised messages daily. ('&) SWIFT makes annual updates to its standard message formats and this, together with changes in how SWIFT messaging is being used, means that there is constant change and growth in the area of testing. Figure 3 shows the average daily volumes of traffic (messages and files) over the last five years (YTD). SWIFT Messaging 20,000,000 Page 7 FIN (15022 messages) File Act (files) InterAct (20022 messages) 15,000,000 10,000,000 5,000,000 0 2007 2008 2009 2010 2011 July 2007 July 2008 July 2009 July 2010 July 2011 13,408,802 15,207,924 14,789,382 15,933,049 17,428,600 10,669 22,366 27,825 39,383 50,907 675,583 924,243 981,183 1,169,999 1,229,840 Figure 3: SWIFT Messaging – Average Daily Traffic YTD (Information obtained from www.swift.com) As can be seen from the figures above, there has been a steady growth in the SWIFT message traffic across the three services over the last five years, and all indications are that this is set to continue. With the increase in SWIFT traffic and continued investment in IT in the financial services sector, it is logical to conclude that the need for people with SWIFT messaging knowledge will be in greater demand than ever. 4 UNLOCKING THE MYSTERY OF SWIFT MESSAGING There are a number of challenges in getting messages from source (financial institution or bank) to destination (financial institution or bank), but by meeting these challenges and testing accordingly, we can overcome them. The key considerations in this context are the following: Understanding the MT message structure Understanding the MX message structure Sequencing the messages and linking them in the quest for STP SWIFT compliance with published standards Migration from MT to MX SWIFT Messaging 4.1 UNDERSTANDING THE MT MESSAGE STRUCTURE The message structures for MT and MX are very different. With this in mind, they need to be treated separately here. For MT, the messages are broken down into four or five blocks (block 3 is optional). The header block tells us where the message is coming from (sender BIC) but the majority of the information is contained in block 4, i.e. the text block or body. {1: Basic Header Block} – Contains the sender’s BIC address {2: Application Header Block} – There are two options here, input or output {3: User Header Block} – Optional block {4: Text Block or Body} – Contains main body of information for the message type (specified in the application header) and must obey the rules outlined in the SWIFT standards governing this type {5: Trailer Block} – Contains Message Authentication Code (MAC) and Checksum (CHK), and indicates whether the message is a duplicate of a previously sent message As previously mentioned, the main body or block 4 of the message is where all the message information is contained. There are a number of key points to understand about the message type definition: It is broken into sequences and subsequences, some of them mandatory (e.g. Sequence A – General Information) and some optional (e.g. Sequence C – Additional Information). Each sequence and subsequence is broken further into line items with tags. Again, some are mandatory (M) and some optional (O). It is important to note that mandatory tags are only mandatory if the sequence or subsequence that contains them is included; i.e. if an Page 8 optional sequence or subsequence is included in the message, then the mandatory tags associated with that sequence must also be included. Each sequence and subsequence has a beginning tag (16R) and an end tag (16S). Each line item in the definition has an allowed format. The usual pattern is: <Tag><Qualifier><Content>, e.g. :20C::SEME//12345 Each tag may have an option / letter, e.g. 16 can have R or S. R means start and S means end. After the tag, the item may or may not have a qualifier. There may even be multiple qualifiers: it is possible to recognise these instances by a lower-case letter, e.g. 22a. In this case, 22 can have the options F or H, as mentioned in the ‘Content / Options’ column. The ‘Detailed Field Name’ column sometimes gives a description of the line item, and sometimes it will include a hyperlink to further rules or options: · 16R – Shows a description ‘Start of Block’; whereas · 23G – has a hyperlink to further options for the ‘Function of the Message’. If we go to the page, we see that there are three options: CAST, INST or REST. In addition, there are a further three optional sub-functions that this item could have: CODU, COPY or DUPL. · The ‘Content / Options’ column shows the format displayed as a series of symbols (like BNF), with each symbol given rules for what this symbol can be replaced with, e.g. ! = Fixed length, a = Upper case, or n = Numeric (0-9). The use of optional tags in mandatory sequences / subsequences and the use of optional sequences / subsequences should be agreed between the message sender and receiver. It is recommended that a template message is agreed upon by both parties prior to commencement of SWIFT Messaging testing. The sender and receiver should try to limit the options within tags. For example, in an MT509 message type, the status of order (IPRC) can have all the following codes: CAN1, CAN2, CAN3, CAND, CANO, COSE, DONE, DONF, EXCH, EXSE, INTE, NOTC, OPOD, OVER, PACK, PAFI, PART, REJT, REPR, SESE, or SUSP. The receiver may not be interested in receiving all of these status updates and therefore can agree with the sender a subset of codes, thus reducing the number of messages to be sent over and back during testing. Some of the other nuances and behaviours within the MT standard are discussed in another whitepaper, ‘Transformer and SWIFT MT Messages’ by Trace Financial Limited. ('') The next step is to ensure that the message template is SWIFT-compliant. By sending a sample message across the SWIFT network, the sender will quickly know whether the message meets the SWIFT definition guidelines. If the message is not compliant, a NACK (Negative Acknowledgement Message) is returned. SWIFT applies charges for messages that are not SWIFT-compliant. There- Page 9 fore, this approach of defining message templates and proving their compliance prior to testing variations of the template will save on cost (by avoiding charges) and testing effort (reduced rejection messages). 4.2 UNDERSTANDING THE MX MESSAGE STRUCTURE The MX structure is very different from the MT structure. In MX (ISO 20022), the structure is XMLbased. However, the MX standard also has a header record and then the main body of the message. The header will include the Distinguished Name (DN) of the sender and the receiver, a unique message ID and the service being used. The DN is used in the same way as a BIC in ISO 15022. An example is: ou=abc, o=bankbebb, o=swift, in which bankbebb is the eight-character BIC, and the other elements form the optional extension. This extension allows a detailed identification by department, geographical location, application, or individual. The following is a sample header: <Header> <Message> <MessageIdentifier>MESSAGE ID</MessageIdentifier> <Format>MX</Format> <Sender> <DN>ou=example,o=aibkie2d,o=swift</DN> </Sender> <Receiver> <DN>ou=funds,o=deutdeff,o=swift</DN> </Receiver> <NetworkInfo> <Service>swift.if.ia!p</Service> </NetworkInfo> </Message> </Header> [Message ID: Sample MX setr.010.001.03] [MX is used for 20022 messages] [Sender of message details] [Receiver of message details] [This is the Test Service] SWIFT Messaging Page 10 Note: In ISO 20022, there are separate services for live and test messages. ‘swift.if.ia’ for product network messages and ‘swift.if.ia!p’ for test and training messages. Note: SWIFT provides a free tool called ‘Simulation Testing and Qualification Service (STaQS) – Message Validation’ for verifying that MX messages are compliant. (')) For each message type in MX, there is a defined XML schema and Message Definition Report (MDR) available from ISO. ('() The TheMDR MDRcontains contains the following information for each message type: Message Functionality Message Rules and Guidelines Structure Message Items Description Business Example 4.3 SEQUENCING MESSAGES AND LINKING As with the MT standard, some information in each MX message type is mandatory and some is optional. Where the MT standard had sequences / subsequences, the MX standard has what it refers to as ‘building blocks’. In the MDR, the ‘Outline’ subsection under the ‘Message Functionality’ section mentions which blocks are mandatory and which are optional. The ‘Structure’ section of the MDR provides further detail on the available tags within each block. As with XML, the MX standard uses the slash ‘/’ to signify the closing of a tag. For example, <MsgId> opens the Message Identification tag and </MsgId> closes it. The same lessons learned when testing the MT standard should be applied when examining the MX standard. The sender and receiver should: Agree on the use of optional blocks and on optional tags within mandatory blocks for each message type under test; Limit the scenarios for testing by agreeing on a subset of the available options within the tags; Remove the risk of sending multiple noncompliant messages by defining a template for each message used and testing this template before extending the test to all variations of the template. Once the message service(s), format(s) and types have been agreed and the message templates defined, the next key step to achieving STP is to identify the message sequencing. The latter should be aligned with the business scenarios / processes the messaging is aiming to support. Business analysts, or better still, members of the current business-as-usual team(s) (e.g. operations or product) should be closely involved in deciding on message sequencing. Thought should be given to each business scenario and the sequence of events. The tester can be useful in these discussions to ensure that even ‘non-happy day’ scenarios are thought of: What happens when an order is cancelled? How does the messaging for a cancellation work, i.e. are there additional messages? What happens when an order is late or received after the cut-off time? What happens when an order incurs a commission charge? What happens when the order is for an asset / fund not supported by the transfer agent it is submitted to? What happens when a payment has been made for an order that is subsequently cancelled? It is OK to begin with the common ‘happy day’ scenarios and start building from there, as long as the other scenarios are not forgotten. Model diagrams, like those in the documentation for ISO 20022, can be very useful for this purpose (see Figure 4). SWIFT Messaging Instructing Party 1: Financial Inst. Application Page 11 Instructing Party 2: Financial Inst. Application Intermediary Party: Financial Inst. Application Executing Party: Financial Inst. Application Subscription Order Subscription Order Subscription Bulk Order Request for Order Status Report Request for Order Status Report Order Instruction Status Report Order Instruction Status Report Figure 4: The use case ‘Manage Order Status’ In order to facilitate sequencing of messages, it is necessary to understand how SWIFT messages are linked. In ISO 15022/MT, this is done using the 20C::SEME from the original message in the 20C::PREV or 20C::RELA fields (within the optional linkage sequence) in follow-on messages. Figure 5 shows the interaction between a client placing an order for a trade, and the transfer agent responding to the order in the form of a status update (MT509) and then an order confirmation (MT515). This example can become even more complicated when further interaction points are added. SWIFT Messaging Page 12 In ISO 20022/MX, a similar approach can be adopted using <MsgId> from the original message and linking to this using the <OthrRef> or <RltdRef> tags in follow-on messages. one who is developing new capabilities around ISO 20022 messaging but has not yet signed up a potential client. However, testing would still have to be repeated when on-boarding new clients. The sequencing of messages becomes extremely important when implementing STP (StraightThrough Processing). The ability to sequence the messages in alignment with the agreed business flows is critical to the success of any STP implementation. 4.4 STAYING SWIFT-COMPLIANT Once all the hard work is done and an organisation achieves SWIFT compliance for its message set, the next challenge is to stay compliant. SWIFT makes annual updates to the MT standard, and next year they are planning two updates to the MX standard. Any organisation that adopts SWIFT messaging should have a process in place to assess SWIFT updates and be in a position to test any changes as they occur. In some cases, no updates are needed, but the assessment has to be done every time an update to the message standard is released. The STaQS tool from SWIFT can be used to test message sequencing for ISO 20022 messages, using its Business Order Flow Validation service. This service does incur a charge. It allows users to test the flow of messages over and back across the SWIFT network simulating how it will happen in the real world. This is a useful service for any- 1 MT502 20C::SEME//CL-01 TRANSFER AGENT 2 MT509 20C::SEME//TA-01 20C::RELA//CL-01 3 CLIENT Figure 5: Message sequencing example for MT MT515 20C::SEME//TA-02 20C::RELA//CL-01 SWIFT Messaging Page 13 4.5 MIGRATION FROM MT TO MX SWIFT will begin to apply restrictions on the use of MT fund templates. The next big challenge facing the financial services industry is the quest to achieve straightthrough processing and a fully automated solution to messaging. The need to migrate is real and approaching fast. SWIFT is offering incentives to users who migrate early, as well as disincentives to users who are slow to migrate. The growth in ISO 20022 fund traffic has already begun (see Figure 6). In 2001, the funds industry mandated SWIFT to develop a set of message templates to be used for the subscription / redemption process, leveraging the existing MT messages used for securities transactions (MT502, MT509 and MT515). With an eye on the future, in 2003 the funds industry and SWIFT collaborated to develop a full set of messages using the ISO 20022 standard. The aim was to go beyond the order process and enable the industry to automate and standardise the entire funds transaction flow – including transfers, statements, account management, price reports and cash forecasts. ('*) SWIFT provides documentation and support for this process. While the mapping from an old MT message type to a new MX message type helps, it does not fully explain the nuances and differences between the two catalogues of messages. For example, in the MT standard there is one message type (MT502) for placing an order whether it is a subscription, redemption or switch trade type. In the MX standard, there are three separate message types (MX setr.010.001.03, setr.004.001.03 and setr.013.001.03), i.e. one for each trade type. The migration to funds‘ ISO 20022 has already begun with the first ‘wave’ to be completed by the end of 2012, when existing ISO 20022 fund users must use MX messages with counterparties that are ISO 20022 ready. The real deadline comes with the second ‘wave’ from January 2013, when With regard to testing, the same rules apply for the MX standard as for the MT standard. The format of the message templates should be agreed between the sender and receiver. The options within the message templates should also be agreed, and limited where possible. 5.4 % 13.3 % 21 % 25 % 2008 2009 2010 YTD 2011 (May) Figure 6: ISO 20022 volume versus total fund traffic volume on SWIFT ('+) SWIFT Messaging Page 14 5 CONCLUSION AND OUTLOOK There is no doubting that SWIFT messaging is very popular in the world of electronic messaging. All signs are that its use will grow with the financial service institutions and banks striving to reduce operational costs by increasing automation in their communication with each other. Efforts to achieve STP mean that there will be lots of testing opportunities over the coming years. The key testing messages in this paper hopefully will help understand some of the potential pitfalls and how to avoid them: Familiarise yourself with the message standard being tested and ensure you are aware of the nuances in the message definition. Agree on the use of the optional items (sequences, blocks, tags) within the standard and document these in templates for each message type used. Know the sequence of messages and link messages in a way that supports the business and operational processes. Stay SWIFT-compliant by keeping informed of the changes to the message definitions, and assess these updates against the message set in use. Update respective templates and test as required. Organisations messaging in the funds industry should act now and begin migration to the MX standard. Seek help and assistance from industry experts and test professionals to de-risk the introduction of messaging and achieve the ROI that successful implementation can bring. SQS has been working with many of the major banks and financial services institutions across Europe to assist them with their SWIFT messaging projects. The software specialist’s experience in software testing and quality assurance for the entire range from simple messaging projects through to the more complicated ones means that SQS is ideally positioned to help organisations with the next challenges of messaging with their clients. Bibliographical References ' SWIFT. About SWIFT – History. SWIFT. [Online] 2011. http://www.swift.com/ about_swift/company_information/swift_history.page?lang=en. ( Kjell Nordgard. Straight-Through-Processing: Profit through efficiency. Jour nal of Financial Services Technology. [Online] 2007. http://www.jfst.com.au/ author/10656209. ) ISO. About ISO. International Organization for Standardization. [Online] 2011. http://www.iso.org/iso/about.htm. 4 SWIFT. IBAN Registry. SWIFT. [Online] 2011. http://www.swift.com/dsp/re sources/documents/IBAN_Registry.pdf. + ANNA. ANNA.ISINs ISINs&&ISO ISO6166. 6166.ANNA ANNA(Association (Associationof ofNational NationalNumbering NumberingAgenAgencies). [Online] 2011. http://www.anna-web.com/index.php/home/isinsaiso6166. , Investopedia. CUSIP Number. Investopedia. [Online] 2011. http://www.investopedia.com/terms/c/cusipnumber.asp. - SWIFT. Messaging Services. SWIFT. [Online] 2011. http://www.swift.com/dsp/ resources/documents/factsheet_messaging_services.pdf. . Jeff Roster. IT Spend by Industry Worldwide. Gartner Blogs. [Online] 2009. http://blogs.gartner.com/jeff_roster/2009/02/11/it-spend-by-industry-worldwide/. / Gartner. Enterprise IT Spending by Vertical Industry Market, Worldwide, 2009 – 2015, 3Q11 Update. Gartner. [Online] 2011. http://www.gartner.com/ technology/research/it-spending-forecast/. '& SWIFT. SWIFT.About AboutSWIFT SWIFT– –Company CompanyInformation. Information.SWIFT. SWIFT.[Online] [Online]2011. 2011.http:// http:// www.swift.com/about_swift/company_information/index.page?lang=en. '' Trace Financial Limited. Transformer and SWIFT MT Messages. Trace Financial Limited. [Online] 2011. http://www.tracefinancial.com/hres/transformer%20and%20swift%20mt%20messages.pdf. '( ISO. Catalogue of ISO 20022 Messages. ISO 20022. [Online] 2011. http:// www.iso20022.org/catalogue_of_unifi_messages.page. ') SWIFT. SWIFT – STaQS for Funds. SWIFT. [Online] 2011. www.swift.com/solutions/solutions/funds/SWIFT_STaQSforFunds.pdf. Page 15 Bibliographical References '* Funds ISO 20022 Migration: The industry moves towards a full messaging solution. SWIFT. [Online] 2011. http://www.swift.com/solutions/funds/documents/SWIFT_InfoPaper_Funds_Migration.pdf. '+ Migration to ISO 20022. SWIFT. [Online] 2011. http://www.swift.com/solutions/funds/migration.page. Page 16 SQS Software Quality Systems AG Phone: +49 (0)2203 9154-0 Stollwerckstrasse 11 51149 Cologne / Germany www.sqs.com