As the world’s leading software company, Microsoft needs no introduction. This month we talk to Ed Barrie about the challenges and benefits brought by the SWIFTNet solution which Microsoft recently implemented in order to streamline communications with its banks.
Ed Barrie
Group Manager, Treasury
Ed Barrie is a Group Manager in Microsoft Corporation’s Treasury Department, responsible for the Treasury Operations and Services Group. Ed and his team are responsible for all cash and investment operations as well as managing and enhancing all of the information systems in the Worldwide Credit & Collections, Capital Markets and Global Cash Management groups within Microsoft.
Ed’s team figures out how to maximise the use of systems and data so that Microsoft’s Treasury Department can operate efficiently and effectively under the increasing complexity of Microsoft’s worldwide business needs, Treasury’s changing needs and the overall changes resulting from the increased regulatory environment.
Prior to joining Microsoft in October 2002, Ed spent ten years at a regional investment firm where he was Vice President of Trading and Information Systems. Ed holds a Bachelor of Arts in Economics.
What is the structure of Microsoft’s treasury?
Microsoft’s treasury is composed of around 130 people. It is predominantly a centralised treasury, with the exception of the credit collections function, which is spread out globally. The rest of the treasury is located in Redmond, Washington.
The treasury is composed of five groups:
- Worldwide Credit and Collections Organisation is essentially our accounts receivable organisation group. We have large pockets of credit collections people in Dublin, Singapore and Reno Nevada, as well as individuals in other locations around the world.
- Global Cash Management and Treasury Operations is responsible for moving all of our funds around all our bank accounts globally, as well as being responsible for our subsidiary funding and for setting up our banking structure.
- Capital Markets is responsible for all investment management, our foreign exchange programme, our strategic investment programme and any other type of investments where we’re using financial assets.
- Corporate Finance is responsible for Microsoft Corporation’s capital structure, the Microsoft common stock buyback programme and other corporate finance related issues.
- Risk is actually composed of two sub groups: our Business Risk group and the Financial Risk group. Business Risk is primarily responsible for insurance coverage and Financial Risk monitors the Capital Markets group.
What is your role and what are your major responsibilities?
As Group Manager I am primarily responsible for two things: our Treasury Operations team – which comprises both our Cash Operations group and our Investment Operations group – and Business Insight and Reporting.
Cash Operations is responsible for actually moving the cash between all of Microsoft’s bank accounts. Microsoft has over 1,000 bank accounts globally, spread across 100 banking partners. Cash Operations interactively manages over 400 of those accounts on a daily basis, so it is responsible for sweeping all the cash that comes into our various collection accounts up to our concentration accounts. It disburses cash to our operating accounts, as directed by our Cash Planning team. The goal is to keep all the cash that is not used for operating expenses and to get that into our capital markets portfolio for investment.
Our Investment Operations group supports our Capital Markets group. They are responsible for all trade confirmation, trade processing including managing the post trade lifecycle of OTC derivatives, interfacing with our custodian banks and settlement issues. Investment Operations essentially performs the middle and back office functions that an investment firm would have.
Business Insight and Reporting is essentially the systems and technology component of Microsoft Treasury. They are responsible for the definition and development of all the tools and technologies used across the Microsoft treasury across all the groups listed above which includes both internal and external customer facing applications, so I’m involved in both the operational aspect and the systems/IT aspect of Microsoft Treasury.
How do the challenges you face differ from the challenges encountered by smaller treasuries?
There is a lot of dispersion and autonomy – both at the business group level and at the subsidiary levels – so just the sheer size of the company and the number of activities going on at any point in time are challenging. Life is never still in treasury or at Microsoft: things are always changing and it’s a challenge just getting your arms around that sheer vastness and complexity.
If you distil that down to what it means for treasury, it comes down to how to manage all the cash across all those bank accounts. How do we optimise the use of that cash and how do we manage the risk around that? How do we leverage our technology so that our people spend less time managing transactions and more time managing assets? Those are the big challenges. We frame this under a paradigm called the Lifecycle of the Dollar which is focused on improving the visibility and velocity of cash within our systems.
Why did you decide to implement the SWIFT solution?
It started with the implementation of the treasury module of our SAP ERP system. Before we implemented SAP we had direct connectivity with three of our banking partners. However, they only fed us daily current bank statements for the bank accounts that the treasury directly managed, so we couldn’t really view the bank accounts that were managed by our subsidiaries.
Then we implemented SAP: we re-built those three data feeds and told those banking partners to turn on data statement feeds for all of the accounts that we held with them. We went from having daily visibility of between 125 and 150 bank accounts to having daily visibility of about 300 bank accounts.
The next stage was to get all of our bank accounts reporting electronically. We reached out to our internal product group that is responsible for the Microsoft BizTalk Server, which is our middleware application that we use for data transformation and translation. They actually had a product called the BizTalk Accelerator for SWIFT and it was targeted at financial institutions. They suggested that we speak to SWIFT because they might be a solution that would work for treasury.
About three years ago we started discussions with SWIFT. We met with representatives from SWIFT and started developing a vision of making SWIFTNet the centralised portal for communicating with a significant number, if not all, of our banking partners. We made a decision to become a direct participant on SWIFT and built out connectivity initially for statement reporting into our SAP system.
Some of our banks actually tried to dissuade us. I think the banking community was really worried about being disintermediated, but we do not view this as a way to disintermediate our banks. All we see is a way for us to gain visibility over all of our cash and transactions in a single, secure, scalable and cost effective manner. All corporates want the same thing: a similar way to talk to all their banks.
We ultimately implemented the solution in October 2006 and we have seen a lot of press coverage, not only about Microsoft Corporation being on SWIFT and using it, but also about how other corporates (and now many of those banks) are using us as a reference for other customers who want to connect via SWIFT.
What challenges did you come across?
The biggest project challenges for us were just developing expertise in understanding the SWIFT messages and market practices around those messages. We also had to understand some nuances about how SWIFT works, especially in the fall when they go through their standards release upgrade for the messages. The main challenges were understanding those messages; how we take that data in; and how we can leverage it within the ERP system.
What benefits did you have as a result of this solution?
We’ve seen around a 326% ROI on this project over a five year period, so that has positive benefits for Microsoft financially. Operationally, we are receiving end of day statement reporting for over 350 bank accounts from 20 banking partners and intraday statement reporting for over 400 accounts from three banking partners via SWIFTNet. We now have daily visibility to bank account cash balances and transactions that has never existed before for us. Strategically, this project has helped support our sales, marketing and product groups by demonstrating the use of our BizTalk Server technology to help manage our financial messaging needs by creating solutions in the market that other organisations can in turn leverage for their own SWIFTNet and financial messaging needs.
The next thing that we’ll be working on is the velocity component, and that’s when we start supporting our high value wire payments over SWIFT. Currently, we’re still sending those through the proprietary banking channels, but the next major project will be actually moving these payments via SWIFTNet.
This also has benefits for Microsoft because it extends our domestic wire cut-off time by 30 minutes. If you look at the payments landscape and the way payments move through the systems, there’s a big bubble of payments that move and get processed late in the day. Because our cut-off is 30 minutes before the Fed cut-off, we’re missing out on the opportunity to use the cash that comes in as a result of those late credited payments.
If we’re able to move those funds for an additional 30 minutes, then we can use them the same day and move the cash to a more optimised overnight vehicle. We’re also getting requests from our internal customers to do wire payments later in the day, so if we can add another 30 minutes, we’re able to provide a better service for our internal customer base.
Did you consider any other options when you were looking for a solution?
The only other option was leveraging a banking statement aggregation service through some of our primary banking partners, which we currently do with one of them. We leverage this service when third party banking partners of Microsoft’s do not have the ability to transmit statements directly to us via SWIFTNet. In these cases we have these banking partners transmit the statements to our aggregation partner, who in turn forwards the statements to us for loading into our ERP system.
This process works well; however, given the number of banking partners that we have and the other management challenges presented by having more ‘links in the data delivery chain’ when leveraging an aggregation service, we ultimately made the strategic decision to be on SWIFT.
We are also leveraging SWIFT beyond statements and payments. We are receiving billing analysis files via the FileAct service and are looking to receive next generation XML statements via InterAct and FileAct.
One of the other drivers was showcasing the use of our own technology, specifically the Microsoft BizTalk Server and the BizTalk Accelerator for SWIFT, in managing the translation and transformation of SWIFT messages into and out of our ERP system.
How does this fit into the solution?
At Microsoft we have direct connectivity to the SWIFT network, and we have the SWIFT software and servers receiving and sending messages. Then we have our SAP ERP system, and in between the SWIFT infrastructure and SAP we have a BizTalk Server environment running the BizTalk Accelerator for SWIFT and the BizTalk Adapter for SAP. All those messages – the statement messages, the end-of-day MT940s and the intraday MT942s – come through the SWIFT infrastructure.
They get passed to our BizTalk Server environment and run through the BizTalk Accelerator for SWIFT which parses those FIN messages and presents them as an XML document, which we then map to the FINSTA IDOC format for importing directly into SAP. BizTalk Server also allows us to perform additional data calculations, validations and enrichment using the source statement data and store that data in SAP. It’s a very seamless process.
Are you using a combination of MA-CUGs and SCORE at the moment?
Yes, we use both. There’s not much of a difference from our perspective. I know a lot of people have said SCORE is better, but some banks have not yet signed up for the SCORE user group. I think the complexity of MA-CUGs versus SCORE has really been blown out of proportion in the press. We never had a problem joining different MA-CUGs because you do it all through the SWIFT website. It’s very straightforward.
The big challenge that really does not get a lot of press coverage is the individual service agreements with your banking partners for statement reporting. That is the real challenge in communicating, whether you’re doing it through a point-to-point connection or whether you’re doing it through SWIFT.
We’ve had some banks where we’ve just emailed them and said, “We want to communicate with you via SCORE, can you entitle these accounts for MT940 reporting to this BIC?” and they turn it on. In a couple of days, the statements are flowing through.
However, we’ve had another bank that said, “Sure, we’re happy to do that, however, we need to send you a service agreement.” We had a 46 page service agreement in two point text, that was heavy on the legal language, and we can’t just blindly sign those; we have to take them to our internal legal group, which then sends them out to external counsel for review. External counsel is not doing their job unless they send it back and try to negotiate terms, and then it increases your cycle time. With some banks it has taken us six months or longer to come to an agreement for statement reporting.
“External counsel is not doing their job unless they send it back and try to negotiate terms, and then it increases your cycle time. With some banks it has taken us six months or longer to come to an agreement for statement reporting.”
SWIFT has produced a template which the banks can use as the basis of their service agreement with their corporate customers. We are starting to see some banks support or use that template as the basis of their service agreement, but it still turns out to be a 28-30 page document.
I think everybody misses that point. I think they’re trying to blame SWIFT or look to SWIFT to make this process really easy, when SWIFT has done as much as it can do. It’s the banking community that really needs to get pragmatic about this, especially if they are sending statements over SWIFTNet to a known end point (BIC).
More generally, how do you see treasury technology evolving in the next few years?
I don’t think the debate is settled yet on using the treasury functionality of an ERP system versus a dedicated workstation. I think that is still somewhat open, so I’m interested to see where that goes.
Ultimately, I think we are hopefully going to see more standardisation in the payments, statements and exceptions and investigations space – especially as the ISO 20022 message set starts to become widely supported. Essentially what this means is that you get a much more enriched information payload moving along with the transaction, so that you can increase your own straight through processing. Ultimately this will enable us to provide better services for our customers along with increasing our own internal efficiencies and improving the Lifecycle of the Dollar.
