In 2006, we presented a case study of Microsoft Corporation and how the company started its implementation of SWIFT. Two years later, we talk to Ed Barrie, Group Manager for Treasury, Microsoft Corporation, to look at how Microsoft’s use of SWIFT has developed.
2006
Microsoft Treasury, based in Redmond, Washington is a centralised operation responsible for all elements of cash management, FX, corporate finance, risk management and credit and collections. The company has around 100 banking partners and 1,000 accounts of which 400 are managed by treasury. Seven staff manage the Treasury Operations and four manage the subsidiary Cash Planning function. Microsoft started a project in 2003 to consolidate and streamline its back office cash management operations using SAP, which is used throughout Microsoft. This included bank communication, payments, bank account reconciliation, FX transactions and creating an in-house cash centre to manage intercompany transactions and subsidiary funding.
We implemented a connection to SWIFT because we wanted to spend less time managing transactions and more time managing our assets.
The global SAP cash management implementation was the starting point for a project to implement direct SWIFT connectivity through MA-CUGs, which is achieved using Microsoft’s own BizTalk Server and BizTalk Accelerator for SWIFT. Six pilot MA-CUGs, covering 100 bank accounts are going live this October and the company intends to connect with nearly 30 banking partners covering close to 90% of its bank accounts via SWIFTNet by June 2007. Prior to this, Microsoft Treasury did not have daily electronic visibility over these accounts and had hundreds of users across the company accessing numerous third party banking applications with their associated direct and indirect costs. There were also problems with consistency of security across the various banking systems across a widely disbursed organisation.
The key project objective was to retrieve bank statement information (MT940) from their partner banks, which will ultimately be extended to include intra-day statements (MT942) for the relevant bank accounts and also payment messages (MT 101). Microsoft sees significant value in the emerging XML messaging for bank statement retrieval, not necessarily from a cash position and balance perspective, but for detailed bank reconciliation purposes as data can be more effectively mapped to the business application.
As Ed Barrie, Group Manager for Treasury, Microsoft Corporation explains,
“We implemented a connection to SWIFT because we wanted to spend less time managing transactions and more time managing our assets. This is a paradigm you can extend across the business. You can’t view SWIFT in a vacuum, nor is the SWIFT project restricted to treasury. It has to involve all the stakeholders who interact with the banks and the banking data. For us, as well as the benefit of replacing some of our banking workstations, the value of SWIFT has been in the context of a wider re-engineering project and the added value we can gain from the network in the future.”
2008
Two years on, we asked Ed Barrie about the progress which Microsoft Treasury has made:
“We have made significant progress in our use of SWIFTNet over the past two years, and it is now our primary communication channel with our banks. Only two of our primary banking partners have not yet migrated to SWIFT services, but we are now connected to 20 banking partners for prior day statement reporting and four banking partners for intraday statement reporting via SWIFTNet. We are in the process of on-boarding five more partners and expect to on-board an additional 15+ partners through the remainder of this year.
“Two years ago, XML messages via SWIFT were barely a twinkle in the eye, but today, we are piloting XML ISO 20022 messages with two of our primary banks (Bank of America and Citi) which will involve receiving statement information via FileAct using the new CAMT XML format. As part of this process, we are comparing the data we are receiving via SWIFT with MT940 and 942 messages, and the data presented through the banks’ proprietary channels, to ensure that we are capturing all the information which is available on a transaction. We are also looking at the mapping of the statement data into SAP using Microsoft BizTalk Server and the BizTalk Accelerator for SWIFT. We are also reaching out to our other primary banking partners to determine their readiness for ISO 20022 messaging support. [[[PAGE]]]
“Although this project is progressing well, we have an SAP upgrade scheduled for February 2009, so we will delay live operation of XML until the spring of 2009.
The goal for the next year is to on-board a further 30 partner banks and to both pilot and put into production XML statements with three or four banks.
“The primary benefit which we have gained through SWIFT connectivity is having a single communication channel leveraging industry standard data formats that can be used to communicate with new and existing banking partners. This greatly simplifies our ability to establish electronic communications. The benefits that we anticipate by supporting ISO 20022 messaging for statement reporting is that transaction-level data is potentially greatly enriched and presented in a structured, defined way. This permits higher levels of straight-through-processing and greater granularity of information for automatically posting transactions to the general ledger and automatically applying those transactions to open items. By improving the quality of data which comes into the organisation, SAP can be used more widely as the ‘source of truth’ for account statement information as opposed to relying on multiple electronic banking systems. While there is nothing wrong with these systems, in some instances the banks charge for their use, which creates external costs. More significant are the ‘soft’, internal costs. When you have over 1,000 users accessing these systems, there are considerable hidden costs of compliance, user training, user administration, IT support, etc. In reality, the large majority of these users access these systems for bank statement information so using SAP provides a more convenient way of achieving this.
“We have also started using FileAct to receive EDI 822 (billing analysis files) from some of our US partner banks, and BSB files (TWIST format for bank services billing) from some of our international banking partners. We are asking our international banking partners to support the TWIST BSB format and to deliver those files to us on a monthly basis via FileAct so that we have greater transparency and understanding of the fees that we pay for banking services.”
Have you been surprised at the way in which SWIFT access amongst corporates has evolved in recent years?
“I have been surprised that quite a few smaller companies (i.e. those outside the Global 500) have either started implementing or are considering SWIFT, whereas there are fewer companies amongst the Global 500 which have done so than I would have expected. However, the interest amongst corporates has been significant, a trend which I expect to continue. I was pleasantly surprised by the number of corporates which attended Sibos last year and corporate attendance at this year’s event promises to be higher again.
“What is interesting is that the business case for almost all corporates is the same, even though the priorities between organisations may differ. Firms are looking for a single ‘pipe’ through which to channel information with their banks with a view to increasing visibility and standardisation. This in turn allows a greater concentration of IT resources and better automation of reconciliation and G/L posting.
“One issue in which I see corporates taking a great deal of interest is exceptions and investigations, which had not emerged when we first implemented SWIFTNet. This is an area of considerable interest to us, as exceptions and investigations currently take place using unencrypted emails and faxes, so there are certainly improvements we can make in this area.”
What challenges do you see in corporate adoption of SWIFT?
“In some cases, adoption by corporates is hindered as very few banks have a clearly articulated project map for SWIFT implementation, which can create a disconnection between corporates, banks and SWIFT over who should take responsibility for each element of the project.
“Another issue which the banking community needs to address is the question of consistent documentation. Each bank has its own agreement for SWIFT services which is a big sticking point for us. For example, when signing up to receive bank statements through SWIFT, some banks present a simple two-page agreement which can be turned around quickly, whereas others use an extensive legal contract in which we need to involve our external counsel. This is inevitably costly and time-consuming, and in one case it took over a year to conclude an agreement.
“In the early days, many banks were concerned about disintermediation and the risk of corporates transferring their business as a result of gaining greater bank independence. These fears have not been realised and I do not see this situation changing. We have terminated banking services if a bank is a member of SWIFT but refuses to communicate with us through SWIFT, but not in situations where the bank is not a member of SWIFT, nor have we transferred our business from a bank simply because we had the capability to do so. [[[PAGE]]]
“XML is a significant opportunity for standardisation, with considerable benefits for corporates. However, this will only be the case if banks adopt the standards consistently. There are already some hints of banks interpreting the standards in a different way which cannot continue if ISO 20022 is to achieve its objective.”
How do you see Microsoft’s use of SWIFTNet developing in the future?
“The goal for the next year is to on-board a further 30 partner banks and to both pilot and put into production XML statements with three or four banks. Our intention is to migrate to XML from the existing MT940 and MT942 messages as soon as each bank supports it.
“We also envisage that we will extend our use of BSB messages via FileAct with our top 20 banking partners. Currently we have little visibility over charges, so a big focus is to improve in this area. Furthermore, we are also looking to pilot and put into production SWIFT Enl messaging for exceptions and investigations to replace the existing emails and faxes we use for this.
“While we have ambitious objectives with SWIFT, the benefits are considerable and facilitate high quality information and straight-through-processing.”