Microsoft BizTalk Accelerator for SWIFT: Harnessing the Power of SWIFT for Enterprise Financial Messaging

Technical Solution Brief

Published: April 3, 2007

Microsoft has close to 100 banking partners, with more than 1,000 individual accounts worldwide. The Microsoft Treasury group requires daily communication with many of these banks through a variety of mechanisms. Microsoft has implemented Microsoft® BizTalk® Server 2006 and the Microsoft BizTalk Accelerator for SWIFT to standardize this communication through a security-enhanced IP financial network.

Today, the role of a corporate treasury is far beyond historical cash management responsibilities. In many corporations like Microsoft, the treasury plays a more strategic, advisory role in overseeing the entire organization's financial supply chain.

The increasing globalization of business has created a demand for the reduction of cost and improved efficiency in business transactions across borders. The global payment environment is complex and fragmented, making efficient processing difficult to achieve. To solve these challenges, the Microsoft Treasury group teamed with the Microsoft Information Technology (Microsoft IT) team to design and implement a communication solution based on BizTalk Server 2006.

This technical solution brief contains information for IT decision makers who want to achieve the benefits of adopting a single standard method for financial communication. This paper assumes that the audience is already familiar with the basic concepts of business-to-business enterprise application integration (EAI).

Treasury Group Operations

The Microsoft Treasury group's responsibilities include allocating resources to subsidiaries for monthly funding, reconciling transactions, making money transfers, and most importantly, investing excess cash resources in investment markets to generate revenue.

Microsoft has more than 1,000 bank accounts spread among approximately 95 banks located around the world. To manage each of these accounts accurately, the Microsoft Treasury group receives and processes a statement at the end of each business day. The statement contains the beginning and ending balance for the account and a record of each transaction for that day. Awareness of available assets in an account is key: The Treasury group monitors accounts and makes investment decisions to generate additional revenue. The difference between minutes and hours can translate to millions of dollars.

Business Challenges

Multiple Custom Connections

Each bank that the Microsoft Treasury group works with uses different processes and systems to communicate with customers and banking partners. Previously, the Treasury group developed and maintained multiple custom point-to-point connections to communicate with its banks. As with all point-to-point solutions, this approach had inherent challenges.

Figure 1 shows an example of the point-to-point connections between four different banks to a single corporate client. The example highlights connecting a back-end system (mainframe or host) from a corporate client to a bank's host by using a Value Add Network (VAN). The "X" or "Y" after each connection name is a variable that implies that multiple connections of each type may exist. For example, the e-banking Y system connects with bank Y, and e-banking system Z connects to bank Z.

Figure 1. Example of a financial communication design that uses multiple point-to-point connections

Aside from the cost and complexity of developing and managing several separate systems, implementing point-to-point connections provides unique challenges when the connections are mission critical, as they are for the Microsoft Treasury group. Characteristics like redundancy, reliability, and guaranteed delivery can be difficult to develop even within a single connection. Developing these characteristics as part of dozens—perhaps even hundreds—of custom connections is especially time-consuming and expensive.

New Banking Relationships

As new markets emerge, Microsoft establishes new banking relationships. Developing a new custom line of communication between Microsoft and a banking partner can be a major obstacle. The custom point-to-point connections that Microsoft IT has developed for communication with banking partners can be costly and can take several months to develop. This investment of time and money may deter Microsoft from ending a relationship with one banking partner in order to partner with another bank that offers better services or rates.

System Reliability and Timeliness of Data

Some banks do not have a system in place to provide the required daily statements. The only way for these banks to transmit the required information is through an intermediary, such as another bank, or through a message broker, as shown in Figure 2.

Figure 2. Example of a solution where the partner bank communicates with Microsoft through several intermediaries

In one example, the statement data that a particular bank sends to Microsoft each day is processed through nine other systems, each owned and operated by a different intermediary, before the statement data reaches Microsoft. This solution presents the following challenges to Microsoft IT:

• The number of potential points of failure increases substantially.
• Microsoft has no control over most of the systems that process the data. If a problem exists with the connection between these systems or if the systems are malfunctioning, Microsoft cannot diagnose, troubleshoot, or solve the problem.
• The end-of-day statement can take up to 18 hours to reach Microsoft. This latency can result in high costs in terms of lost opportunities.

Employee Productivity

The disparate connections and systems for cash management and account management created an issue with transaction reconciliation for the Microsoft Treasury group. Because each bank used a different method of communication, each statement came in a different format, and the data was spread across multiple systems. Microsoft employees had to collect data from the multiple systems to determine the available assets. These highly skilled employees spent much of their time tracking money, when they could have provided better value to Microsoft by analyzing the best ways to invest the money.

Solution Requirements

When choosing an integration solution, the Microsoft Treasury group reviewed its business process to identify solution requirements. Initially, the group determined that the solution must meet the following requirements:

• Reliability
• Scalability
• Reduced latency
• Loosely coupled design
• Centralized management
• Standard user interface (UI)
• Centralized tracking and auditing
• Single method for connectivity to multiple banking partners
• Familiar system for creating messages that are sent to banks

About SWIFT

Founded in 1973, the Society for Worldwide Interbank Financial Telecommunication (SWIFT) is an industry cooperative that provides a standard format and method for transmitting payments, stock transactions, letters of credit, and other financial messages among nearly 8,100 member banks, broker-dealers, and investment organizations around the world. SWIFT processes millions of transactions worth several trillions of dollars each day, with an average transit time of 20 seconds.

SWIFTNet is a highly secure and reliable IP network that SWIFT members can use to communicate with one another by using standard message formats and protocols. Most financial institutions around the world already use SWIFTNet for communication. SWIFTNet guarantees delivery of messages by using a store-and-forward mechanism. The guarantee of reliability (99.999 percent uptime) is based on a high level of hardware and software redundancy.

In late 2004, SWIFT expanded SWIFTNet beyond banks to include corporate entities. Companies can now use SWIFTNet to communicate with their banks by using the same standards and protocols that the banks have been using for years.

Technological Solution

Working together, the Treasury group and Microsoft IT decided that the best way to standardize the communication process was to integrate directly with SWIFT. After evaluating the requirements, Microsoft IT chose BizTalk Server to meet the Treasury group's needs.

The solution also takes advantage of the existing enterprise resource planning (ERP) system that Microsoft uses. Enabling connectivity between the ERP system and SWIFTNet required a workflow engine that provides message translation and rule-based decision making. Microsoft IT implemented BizTalk Server 2006 as a message broker between SWIFTNet and the ERP system to manage the required message formatting and content enrichment.

End-User Experience

Several years ago, Microsoft implemented SAP as the company's ERP system. In 2004, the Microsoft Treasury group implemented SAP as a line-of-business application for cash management and foreign exchange management, and as an in-house cash center. Because SAP is the established standard within Microsoft, the Treasury group decided that the end-of-day statements that it receives from the banks through SWIFTNet would be transformed and stored in SAP. After the data is in the SAP system, the Treasury group can view the data by using a single interface with which it is already familiar. Additionally, the Treasury group wanted to use a Microsoft Office SharePoint® Server 2007 Web site as a central location for creating messages to send to banking partners.

Access to SWIFTNet

SWIFTNet makes a claim that few large networks can make—that the security of the network has never been compromised and that the network cannot be accessed from the Internet. Members can access SWIFTNet only by using a dedicated line (for example, a T1 line or a modem) and by using SWIFT interface products, such as SWIFTAlliance Access and SWIFTAlliance Gateway.

SWIFTNet Advantages

Integration with SWIFTNet enabled the Microsoft Treasury group to use a single method of communication for all of its banking partners who are members of SWIFT. The integration also provides standardized message formats that Microsoft can use with a number of banking partners. This standardization means that, regardless of the bank, the process of receiving daily statements is the same. Figure 3 shows an example of communicating with several partner banks through SWIFTNet.

Figure 3. Example of communication through SWIFTNet

Connectivity Through BizTalk Server

BizTalk Server is an integration and business-process management server that provides powerful messaging and orchestration services. These services include:

• Application integration services. Include adapters that are used to connect to and communicate with various disparate systems, including SAP, Oracle databases, and mainframe systems.
• Data normalization. As the adapter sends or receives messages, a pipeline processes the messages. The receive pipeline normalizes the message data into XML, and the send pipeline serializes the XML data to another format. The pipelines can also be used for message validation, data encryption and decryption, and party resolution. The messaging services also provide mechanisms known as maps to transform messages from one schema format to another.
• Orchestration services. Automate the processing of messages. Orchestrations are typically used to coordinate the communication between systems by controlling the timing, order, and logic of the business process.
• Business Rule Engine (BRE). Enables dynamic business policies and logic to be integrated within a business process. The logic of the business rule policy can be changed at run time, thus enabling greater flexibility in BizTalk Server applications.
• Business Activity Monitoring (BAM). Enables the tracking of data about a business process. This tracking can be used to monitor real-time statistical data for end-to-end visibility into business processes.

BizTalk Accelerator for SWIFT

For Microsoft, BizTalk Server was the obvious choice as the underlying messaging platform for integrating SAP with SWIFTNet. The reason is that BizTalk Server offers an add-in product—the Microsoft BizTalk Accelerator for SWIFT (A4SWIFT)—that includes tools and components that enable integration of enterprise applications with SWIFTNet.

A4SWIFT provides the following tools and software components that enable this integration with SWIFTNet:

• XML Schema Definition (XSD) schemas for FIN messages. SWIFT determines the structure of all messages that are allowed on SWIFTNet. BizTalk Server must have a schema that defines the structure of every message that it processes. A4SWIFT provides schemas for all FIN messages so that BizTalk Server can send, receive, and process FIN messages.
• BRE policy for FIN messages. The format requirements for FIN messages go beyond the structure of the data. Strict data validation requirements exist for all messages that are transmitted on SWIFTNet. A4SWIFT includes a set of business rules that can be used to validate FIN messages.
• Receive pipeline disassembler component. FIN messages are in a complex Electronic Data Interchange (EDI) structure natively. For BizTalk Server to process data, the data must be in an XML format. BizTalk Server uses pipelines to normalize data into an XML format as the data is received. The A4SWIFT disassembler also provides a special mechanism for splitting batched FIN messages. The disassembler component validates incoming messages against SWIFT standards by calling the BRE policy for SWIFT messages.
• Send pipeline assembler component. Before outgoing messages can be sent to a bank through SWIFTNet, the message must be serialized to the EDI flat-file format. Because the SWIFTAlliance Access device would reject invalid or malformed messages, the messages must be validated during the send process. Similar to the disassembler component, the assembler component calls the BRE policy to validate outgoing messages.
• Orchestrations for repairing invalid messages. If, for any reason, the pipeline determines that the message is invalid, BizTalk Server initializes orchestrations to repair the message.
• Microsoft Office InfoPath® 2007 form templates for FIN messages. Microsoft foresaw the need for users to interact with some of the FIN messages directly. A4SWIFT has Office InfoPath form templates that users can use to create new XML versions of any FIN message. BizTalk Server then processes the templates and eventually sends them to a bank via SWIFTNet.

Enriched Content Through BizTalk Server

Because of the many components that A4SWIFT provides, Microsoft IT required a minimal amount of custom coding for the SWIFTNet integration project. The team responsible for the SAP implementation at Microsoft defined the data structure for the SAP system. Microsoft IT worked closely with the SAP team to create a BizTalk Server schema that represented that structure. Nearly any EAI solution requires this process.

The FIN messages did not contain all of the data that the SAP system required. To enrich the messages with additional data before transforming it into the SAP format, Microsoft IT created a canonical schema that is used exclusively during BizTalk Server processing. Incoming FIN messages are mapped to a message of the canonical structure. This message structure is used during the data enrichment process. After all of the data is collected, the messages are mapped to the SAP Intermediate Document (IDoc) Financial Statement (FINSTA) format.

Automation of Financial Calculations

After Microsoft IT defined the source and destination structures, the team created BizTalk Server maps to define how to transform the data from one structure to another. The maps copy values from the source message and create a new message based on the destination schema.

The maps enable the processing of complex logic through the use of functoids. A functoid is a BizTalk Server mechanism that manipulates data as it is processed through a map. The functoids perform calculations on the data, run custom C# scripts, and perform lookups in a computer database running Microsoft SQL Server 2005, to enrich and manipulate the data as required.

For example, each end-of-day bank account statement message contains the sum of the debit and credit transactions. This calculation enables the Treasury group to easily run cash churn analytics at the statement header level rather than at the transaction detail level, automating the statement reconciliation that an employee previously did manually.

Custom Business Processes

Microsoft IT used BizTalk Server to process the following four specific FIN messages:

• MT940. Represents an end-of-day statement for a single bank account.
• MT995. Represents an inquiry request message that is sent to a financial institution.
• MT996. Represents an inquiry response message to an MT995 request.
• MT999. Represents a security-enhanced communication message (e-mail).

Microsoft IT needed to build the appropriate business process for managing each of the FIN message types. The most important orchestration is the one that the team created to process the MT940 messages. This orchestration performs the following steps:

1. Receives the MT940 message.
2. Maps the MT940 message to the canonical schema.
3. Calls a custom BRE policy that performs a lookup against a computer database running SQL Server 2005 to retrieve additional account information.
4. Maps the previous messages into the FINSTA format.
5. Sends the message to SAP.

Figure 4 illustrates these steps.

Figure 4. Diagram of the orchestration that processes the MT940 messages

Additional Orchestrations

Microsoft IT created two other orchestrations for the MT995 and MT996 message types, respectively. These orchestrations perform data validation on the messages that are being sent or received, and they archive copies of the messages. Another orchestration similarly archives the MT999 messages.

A SharePoint library that uses the Office InfoPath 2007 form templates that A4SWIFT provides is the storage location and UI for the MT995, MT996, and MT999 messages.

Microsoft IT chose to use an orchestration for these processes because of the exception handling that the BizTalk orchestration engine provides. If any one of these processes throws an exception (most commonly, an invalid message), the message is sent to the Operational Framework Process, a custom exception handling process that Microsoft IT uses to resolve all issues with BizTalk Server applications.

Integration with SWIFTNet

The SWIFTAlliance Access device that provides access to SWIFTNet runs IBM MQSeries; SAP is the end point for the MT940 prior-day bank statement data; and Office SharePoint Server 2007 stores the inquiry requests, responses, and security-enhanced e-mail messages. The role of BizTalk Server in the SWIFTNet integration project is to coordinate and facilitate communication among the three systems.

To configure the connection to each of these systems, Microsoft IT used out-of-the-box BizTalk Server adapters for the systems. The configuration for the SAP and Office SharePoint Server connections was a standard configuration.

At the time of deployment, the MQSeries adapter for BizTalk did not support direct connections between BizTalk Server and the MQSeries hardware. To solve this problem, Microsoft IT deployed a computer running Microsoft Windows Server® 2003 and MQSeries for Windows®. This computer communicates with the SWIFT device by using MQSeries, and the computer running BizTalk Server communicates with the computer running MQSeries for Windows.

Physical Design Topology

The physical topology of the solution included a deployment of the following products and technologies:

• SWIFTAlliance Access
• Computer running Windows Server 2003 and MQSeries for Windows
• BizTalk Server 2006
• SQL Server 2005 cluster
• SAP ERP system
• Office SharePoint Server 2007
• Client computer running Office InfoPath 2007

Figure 5 illustrates these products and technologies in the topology.

Figure 5. Diagram showing the physical design topology

Best Practices and Lessons Learned

Considerations that helped to ensure the success of the project include the following:

• Holistic approach. To begin the project, Microsoft IT and the Microsoft Treasury group did not focus on specific technologies, or on design practices and methodologies. Instead, they focused on the business process, from end to end, and determined the requirements of a viable solution. After they agreed upon the design requirements, they evaluated the technologies that could be used to meet the requirements.
• Reusability. Code reuse can be a major time saver during the development phase; this is especially true of a project that uses A4SWIFT. Microsoft IT found that the accelerator provided many code components that Microsoft IT could reuse in many places.
• Business value of components. In keeping with the holistic approach, a strong design consideration for Microsoft IT was the business value of implementing any feature that A4SWIFT provided. The accelerator provided many components that Microsoft IT did not use in this implementation. Microsoft IT decided against some components because they did not add to the business value of the project, and the team wanted to avoid implementing additional technology needlessly.
• Design considerations. Microsoft IT spent the majority of the development time and effort not in creating components for the solution, but in determining how the components could work together to create a complete solution. Microsoft IT also considered how the implementation of a particular component would affect operations. For example, a decision to implement Office SharePoint Server 2007 and Office InfoPath 2007 as the UI for the MT995, MT996, and MT999 messages meant that the six team members responsible for cash management in the Microsoft Treasury group would need to install Office InfoPath 2007 on their computers. Fortunately, the Treasury group members already had Office InfoPath 2007 installed, and Microsoft IT was already familiar with supporting SharePoint sites.
• Understanding of SWIFT. Although SWIFT determines the format of the messages that are transmitted across its network, each bank has some flexibility in how it implements the standard. Microsoft IT had to learn the nuances of working with banking partners over SWIFTNet. For example, some banks require certain fields, whereas other banks do not. One bank may require "field G" to be populated with data if "field D" is empty, but "field G" to be empty if "field C" has data. Another bank may have no preference.

Benefits Gained

Both the Microsoft Treasury group and Microsoft IT have realized benefits by implementing BizTalk Server 2006 and A4SWIFT:

• Single view of enterprise assets. Having a single view of the enterprise's cash assets has given the Microsoft Treasury group increased agility in the investment of those assets.
• Standardization of business processes. The implementation provides standard business processes that Microsoft can use to communicate with all banking partners. As a result, the Microsoft Treasury group and Microsoft IT are now migrating the custom point-to-point banking connectivity to SWIFTNet and expect that all banking connectivity and communication will occur over SWIFTNet by the end of 2007.
• Simplification of connectivity. A single gateway to all banking partners has eliminated many of the specialized skills that users and administrators formerly required to enable, manage, and use the point-to-point connections.
• Reduced cost and time associated with creating new connections. With previous designs, establishing a new line of communication with a banking partner could take months and cost between $50,000 and $150,000 U.S. Standardizing the business process and communication method has reduced the time from months to days and has reduced the cost to significantly less than $50,000.
• Guaranteed delivery. SWIFTNet provides a highly secure and reliable environment. It has virtually eliminated worries about lost messages or unauthorized connections.
• Increased scalability. Adding new banks no longer requires custom-built applications. Establishing a connection with a new banking partner requires updates to the SQL Server database that stores the bank account information, as well as additional configuration in SAP to support the new bank. The development time to add a new bank has been reduced from months to days. Unlike previous point-to-point applications, this solution is built on BizTalk Server, which provides a highly scalable platform. In the future, as the message load increases, adding more processing resources to the BizTalk Server environment will be relatively easy.
• Reduced latency. The number of intermediaries between Microsoft and its banking partners has decreased. Essentially, Microsoft can communicate directly with its banking partners' back-end systems. The reduced latency enables the Microsoft Treasury group to have faster and more complete visibility of its cash assets, which allows for better decision making regarding the investment of its assets.
• Regulatory compliance. The Sarbanes-Oxley Act of 2002 requires companies to provide documentation to the U.S. government of permission levels and access rights for all user accounts that have access to financial data. In the past, these permissions were spread across many different systems with different reporting capabilities at Microsoft. In the current implementation, the user permissions are assigned and maintained in SAP and Office SharePoint Server. This consolidation has greatly reduced the amount of time that is required to generate the documentation.

Planned Processes

This implementation serves as a foundation for additional processes that the Microsoft Treasury group wants to implement in the future to provide greater business value. These processes include:

• Intraday statement processing (MT942 messages).
• Wire transfers (MT101 messages).
• Additional message types (MT192, MT195, MT196, and MT199).
• Management of investments in capital markets.
• Potential to move accounts-payable payments by using SWIFTNet FileAct.
• XML-based real-time cash reporting by using SWIFTNet InterAct.

Conclusion

By implementing a BizTalk Server 2006 solution that includes the BizTalk Accelerator for SWIFT, Microsoft IT and the Microsoft Treasury group overcame problems caused by previous methods that Microsoft used for daily communication with dozens of banks.

By enabling a direct, standardized line of communication with all of its banking partners, Microsoft has reduced operating costs, improved its ability to partner with new banks, and opened future possibilities in terms of how companies interact with financial partners.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

© 2007 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, BizTalk, InfoPath, SharePoint, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.