Published: October 01, 2009
Since 2006, we have been pleased to present an evolving case study of Microsoft Corporation illustrating how the implementation of SWIFT has developed. In this feature, we take a snapshot of progress at three points: 2006, 2008 and 2009, and we are delighted to talk once again with Ed Barrie, Group Manager for Treasury, Microsoft Corporation.
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 2005 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.
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 Microsoft BizTalk Accelerator for SWIFT. Six pilot MA-CUGs covering 100 bank accounts went live initially in October 2006, with the aim of connecting 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 in a widely disbursed organisation.
Six pilot MA-CUGs covering 100 bank accounts went live initially in October 2006, with the aim of connecting with nearly 30 banking partners covering close to 90% of its bank accounts via SWIFTNet by June 2007.
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 (MT101). Microsoft also recognised at an early stage the 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.”
2008We 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 2009.
By having an insight into accounts globally, we can reduce the cash levels in subsidiary accounts and centralise cash flow in treasury.
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.
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 e-mails and faxes, so there are certainly improvements we can make in this area.
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. [[[PAGE]]]
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.
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.
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 ENI 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.
We now receive bank statements from over 40 banks through SWIFTNet into our ERP system, SAP. This gives us visibility over more than 99% of our global cash assets. Although we do not have direct connectivity with every bank, achieving this degree of cash visibility has been very positive. By having an insight into accounts globally, we can reduce the cash levels in subsidiary accounts and centralise cash flow in treasury. We have also automated transaction posting in our general ledger, and achieved over 80% STP (straight-through processing) rates, including booking transactions into bank accounts and posting into SAP automatically.
We have not yet migrated to ISO 20022, although this is still an objective. We are still actively testing with four banks, and analysing statements transmitted in ISO 20022 format to check that the data presented is equivalent to our existing statement formats. This is not yet the case, so our view is that ISO 20022 will be an evolving development over several years. The first phase of our XML implementation will be to receive statements in XML format with equivalent data to our legacy formats. In the second phase, our ultimate objective is to import an enriched data set to enhance STP rates and reconciliation even further. As with all new initiatives, the speed of XML development will be driven by demand, as only then can banks, vendors and other parties justify the necessary investment. [[[PAGE]]]
Of all the post-ISO 20022 SWIFT initiatives, eBAM perhaps offers the greatest potential for corporate users of SWIFT beyond payments and statements.
This is certainly something in which we have an interest, although we are not fully active at this stage, and we are waiting for SWIFT and the banks to agree the necessary formats and business process rules, at which point we will be able to make the necessary decisions internally. eBAM is certainly an initiative with direct, tangible benefit both for corporates and their banking partners. For example, Microsoft has two people dedicated to managing bank accounts and the associated mandates, and other large corporates will have equivalent or greater resource dedicated to the function. Similarly, from a banking point of view, there must be a huge cost in managing the paperwork surrounding the bank account opening, closing and mandate processes. Consequently, of all the post-ISO 20022 SWIFT initiatives, eBAM perhaps offers the greatest potential for corporate users of SWIFT beyond payments and statements. There are other important areas of course, such as Exceptions & Investigations, which SWIFT is promoting actively, but it would seem to us that eBAM brings even greater opportunity.
To some extent, yes. We are certainly starting to see demand ramping up, not so much driven by the appeal of banking communication through a single ‘pipe’ and leveraging standards, but as corporates are seeking to consolidate their banking activity as far as possible. While in the past, the ‘silver bullet’ for many treasurers was to work with a single bank, this is less the case today, with most preferring to implement a regional or federated structure; leveraging SWIFT is an important means of achieving this.
While this demand is driving uptake, it is still an effort to implement SWIFT, and there is not yet a big ecosystem supporting it.
Firstly, we will continue to on-board banking partners for statement reporting. Although we have already achieved over 99% visibility of cash assets, we are aiming to reach 100%. As part of this process, we are also refining the automation of our transaction flow, accounting and reconciliation process to maximise STP.
Secondly, we are working on building support amongst our banking partners for integration of ISO 20022 bank statements into SAP, at least amongst our top four banks. This will primarily be through FileAct, but we are also talking to some banks about using XML through InterAct. There is a challenge with XML through FileAct, however, in that there is no validation of file formats transmitted through FileAct, so as a channel, it effectively represents FTP over SWIFT. This is where InterAct presents an opportunity, as not only can large files be transmitted, but they are also validated, which bring huge benefit.
A third initiative is to standardise currently non-standard date feeds to FileAct so that these can be managed through a single process.
Over time, we need a broader, more standard ecosystem that takes into account the full transaction lifecycle, whereas at the moment, SWIFT’s influence stops at the end of the SWIFT infrastructure. In addition, there needs to be greater focus on the tangible value that XML adds to the transaction process and what enriched data will mean in practice. This will help to create demand and therefore fuel development.
How Thought Leadership Can Reduce the Cost of Sales by Patrik Havander, Havander & Partners A focused attention on the costs incurred by the global sales and marketing processes is becoming increasingly important for corporate banks and their transaction banking departments. While the client/bank relationship remains vital, research has shown that in fact relationship selling […]
