It has been a year since Ed Barrie, senior product manager for Treasury at Microsoft Corporation, stood with SWIFT CEO Leonard Schrank at SIBOS in Copenhagen to announce that Microsoft would be using SWIFT for financial messaging with its banking partners. Since then, progress has been a little slower that he had anticipated while the potential impact looks to be much broader. Speaking to WFS over the summer, Barrie discussed what has happened since that announcement and how he has become an internal ambassador, explaining to groups across Microsoft how they can benefit from the company’s use of SWIFTNet.

Are you using SWIFT now?

We will go live the first week of October with six pilot banks located in Europe, South Africa, Australia and North America covering 150 bank accounts. It has been slower than I initially thought, mostly because Microsoft is such a big organization and it takes time to get everybody on board. But without a doubt, everyone across the organization has endorsed the project. They appreciate the vision of having all Microsoft-to-bank communications flow over one secure channel. Ultimately it is a lower cost solution that is easily repeatable and provides increased security, resiliency and reliability.

How are you implementing it?

We have scaled back and broken SWIFTNet into multiple phases and smaller chunks than we had originally anticipated. We spent a lot of time analyzing the enterprise architecture needs and leveraging BizTalk Server and the BizTalk Accelerator for SWIFT so we can build a robust solution internally that can be maximized across the enterprise. Phase 1 is predominately focused on the MT940 bank statement message that covers the opening balance, closing balance, and all the transactions in the bank account for each business day. We will feed those messages into our SAP ERP system. Our plans are to onboard between five and fifteen banks for MT940 reporting through the end of June.

What’s next after bank statement messages?

Starting later in the fall we will begin Phase 2 of Project Fort Knox, which will cover intraday statement reporting where needed in the form of the MT942 message, as well as Treasury initiated payment messages in the form of the MT101 and MT103+ messages, and preferably the XML Core Payment Kernel message, although we are finding support of XML messages over SWIFTNet by banking partners to be somewhat uneven. Initiatives are ongoing to foster adoption in this area.

What does Microsoft gain from intraday reporting through SWIFT?

For a number of our accounts, especially those used for collections and cash concentration, we would like to have intraday reporting where our influx of money is coming in as well as exposing that intraday statement data to the Cash Application team within our Worldwide Credit & Collections group so that they can apply customer payments same day thereby improving their business process. Prior day and intraday statement reporting into SAP will allow us to have one ‘source of truth’ for banking data across the company and will also allow us to remove our reliance on third party banking applications which are a high-cost and high-overhead solution for us.

Will that save Microsoft money?

In some cases those third party banking applications may have a direct cost to us, but the bigger cost is in the compliance process and IT support around the third party applications. To comply with our internal Sarbanes-Oxley requirements we have to review each of those applications on a quarterly basis. We have to know who the users are, show which users have been added, what permissions they have, and which users have been decommissioned. We have to know the level of permissions for each user, and in some cases the permission capabilities within the applications are not granular enough to prohibit a person from doing a transaction that they don’t have authority to perform. Keeping that updated requires a lot of administration and IT support, which is expensive. Plus we have to train the users in each proprietary bank system. In the case of one banking application, we have more than 600 users looking at data that is already streaming in through SAP. We can reduce our overall total cost of ownership by removing some of those proprietary applications as well as reduce overall risk to Microsoft from a compliance, security and control standpoint.

How much are you automating?

SWIFTNet brings efficiency and scalability to our existing process. Across a large organization you have to manage change very carefully. Our only major change initially is receiving reporting on bank accounts that Treasury currently does not have electronic visibility in. We will also configure a number of these bank accounts for auto posting and reconciliation within SAP. We can get our bank account statements to report in via SWIFTNet and leverage the capabilities within SAP to post the transactions directly to the general ledger (G/L) automatically, so we don’t have to have users gathering the banking data on their own and in turn uploading the transactions into the G/L. We have reporting capabilities that notify us if there is a difference between the closing balance of the bank statement and the closing balance of the G/L. So, if a transaction post isn’t correct we can see that daily instead of at the end of the month. 

How does this change the work at Treasury?

It leverages the system functionality and gets users away from managing transactions and lets them focus on managing assets. Instead of spending a lot of time and effort getting the bank transactions entered into SAP, that gets done automatically. They can spend their time managing exceptions. This allows people to focus on more value-added processes.

Where do you see your use of SWIFT going in the future?

We are beginning to do the research into the new SWIFT XML cash management, cash reporting and payment standards based on XML to see how we can leverage these emerging standards. Our goal overall would be communication with all our banking partners over one secure channel using XML-based industry data formats that provide the maximum amount of data richness and transaction status all through a single, repeatable low cost process.
We are also exploring the potential to leverage SWIFTNet across our capital markets operations. It would be great if we could get all of our trading confirmations to come in electronically via SWIFTNet from our counterparties and feed that data into our systems in order to automatically confirm matching trades while providing a workflow and messaging capability on trade discrepancies. We are also looking into the possibility of using SWIFTNet to communicate OTC derivative transactions with industry utilities such as DTCC using the FpML format.
Clearly, there is the potential to make SWIFTNet the centralized portal for the majority of Microsoft’s financial messaging needs.

Are you using Citi’s TreasuryVision?

Not yet. We have looked at TreasuryVision and are considering it. Citibank is a primary partner of ours and we have leveraged them already because we have a number of banking partners where we just have one or two accounts, or the bank doesn’t support SWIFTNet for corporate-to-bank communications. In those cases we have asked them to transmit their statement to Citibank’s InfoPool server and then Citi forwards the statements on to us. We are doing that with seven of our partner banks.

Any useful lessons you have learned over the past year?

A corporation needs to understand its needs end-to-end and build an enterprise financial messaging strategy. It needs to work with its banks early on in the process to help implement that strategy. You can’t look at getting on SWIFT purely from a treasury perspective; you need to take a view of what is going on across your enterprise. Look at what services and capabilities are available via SWIFT and supported by your banks that you can use in your enterprise. For example, at Microsoft, accounts payable and payroll are in Corporate Services while accounts receivable is part of Treasury. Accounts payable is sending huge volumes of low value payments. For those you need statement reporting, exception handling and reconciliation. How can you leverage SWIFTNet to extend those capabilities to AP or payroll or other functions like employee stock services or 401(k) administration?  What does accounts receivable need in order to apply payments to the correct customer account and the correct invoice? How can we leverage the same information for our cash operations?

Where does SAP play here?

SAP is the ERP system used across Microsoft as well as our Treasury workstation for cash management, foreign exchange and In House Cash Center. Feeding all bank statement data into SAP allows us to have ‘one source of truth’ around banking data and to leverage the posting and reconciliation capability. Leveraging both SWIFTNet and SAP will allow Microsoft to standardize a multitude of separate and decentralized processes into a few global processes which will allow the company to more efficiently and effectively manage its assets.
SWIFT and the banks have a great opportunity to provide a higher degree of value using XML, which provides more data richness and allows corporations to map that enriched data in a logical manner into a corporate treasury workstation or an ERP system. We are trying to leverage SWIFT to solve a business problem.

Biggest issue – what is the cost of getting users trained in those apps – the proprietary systems the banks have?

Unknown.  Microsoft has over 1000 bank accounts held across 95+ banking partners around the world.  I’m sure the cost of our SWIFTNet initiative is more than offset by the potential savings in decreased usage of these applications.  We want to note that we are not trying to exclude any of our banking partners or the value-added services that they provide. We are trying to rationalize how we manage this end-to-end, especially given the changes in the regulatory environment and our need to have tight controls and visibility into our financial supply chain. At the end of the day it’s about reducing risk and managing our assets more efficiently.