Jacobs Edo:  What we do is go around the world giving developmental assistantships and/or grants to public and private organizations. Our activities are quite comparable to those of the World Bank, except of course for the size difference between the two institutions. Depending on what it is—a road, an airport, energy, or something else—the project will involve paying some money to the government or to contractors. Through this year, OFID's 40th anniversary, we have carried out operations in over 134 different countries.

T&R:  If you're making payments in 134 countries, how many different banks do you work with?

JE:  Well, we have four of what we call 'house banks.' These are the banks that we're banking with privately as an institution. But in addition, we have over 30 other counterparty banks, which the treasury team use for everything from deposit management to investments to trading. Payments flow out of all these counterparty banks.  

T&R:  What did your payment process look like in your legacy environment?

JE:  Everything was manual, managed in Excel spreadsheets and faxes—or sometimes using an individual bank's electronic platform.

Generally, if we needed to make a payment, a treasury employee would manually generate a file that they would attach to a memo showing a list of the amounts to be paid, and to whom. This would be physically transmitted to the required approvers, and once they had all approved the payment, a fax would be generated and sent to the bank. The bank would receive the fax, confirm the signatories, and then manually enter the payment into its system. Then, on payment completion, the bank would send a confirmation fax back with the results.

We did have some banks that gave us the opportunity to make payments via their secured Web channel, but someone would have to log in and manually put in the transaction. And then the first approver would have to log in with an approver token, and then a second approver would have to do the same as well. This was the critical challenge of online banking under our old process: The approvers would have to carry a number of tokens for different banks, and most of our approvers travel a lot, so the initiator of a payment would have to make arrangements ahead of time to be sure the approvers would log in at the right time to approve a payment request.

T&R:  What about bank account management activities? How did you handle other banking tasks in the legacy environment?

JE:  As I said before, the process was manual and tedious. Making a deposit deal, for example, was nearly similar to making a payment. A fax would be sent to the right signatories, who would be in various locations. This was a little bit cumbersome. And then after we had all of the necessary approvals, we would release the deposit instructions to the bank on paper. Once the bank received it, someone from the bank would call and complete the deal. We had people who were basically hired just to help treasury carry out these types of tasks.

T&R:  What led you to search for a better banking solution?

JE:  Well, as an institution we were already implementing an SAP ERP [enterprise resource planning] system. We realized that if we deployed SAP Treasury and Risk Management, we could streamline our payment processes. We started to look closely at how we handled payments, and what we could do differently. At the same time, we also looked at how we communicate with our banks. In looking at both of these areas, we realized that it would make sense to use SWIFT with our SAP ERP system.

By using SWIFT together with SAP ERP, we could have one unified platform for all our payments, and we could automate a lot of staff activities around payments and bank account management. This would reduce the manual work involved in making payments, and reduce the opportunities for errors that came with all the faxing and manual data entry processes.

Also, we change banking partners every few years, and by using SWIFT we would avoid having to change the payment platform every time we changed counterparty banks.

T&R:  And why did you decide to use a SWIFT service bureau?

JE:  Once we had decided to go with SWIFT, we had to ask, 'How do we operate and support its hardware infrastructure?' One of the reasons for moving forward with this project was to streamline and, where possible, automate treasury and payment operations, so it wouldn't make sense to add more people to manage the new SWIFT connectivity. But at the same time, we're a small organization, and we didn't have the necessary skills in house to support SWIFT. There are institutions that are similar to ours that may have direct connections to SWIFT, such as the World Bank and the African Development Bank, which have an internal support team. But we completely lack the manpower in house.

T&R:  Were there any activities in particular that you didn't have the internal expertise to handle?

JE:  We're an institution that exists as collaboration among member nations' governments. The first thing our senior management was concerned about when we were considering changing to the SWIFT payment platform was data security. They wanted to make sure that we would not be opening the door to any data security breaches or unwanted legal challenges.

We studied and successfully made the case that if we used a service bureau, we would be handing our payment process to an organization with a lot of expertise around communications and the technical operation and connections to the SWIFT network. Although management had concerns about us giving our payment data to a third party, this approach actually makes our systems more secure, as payment data is completely encrypted and transferred via an IPsec-enabled VPN [virtual private network]. It's removed the need for so many employees to act as middlemen during payment processing, and has automated file transfers, file conversions, and all the other things that need to happen to make our communications straight-through to our counterparty banks. 

T&R:  So, how does your payment process now work?

JE:  Now all transactions are managed from within the ERP system, regardless of the payment method or where it's originating. They are initiated in our SAP ERP system, then they go out via our service bureau, which is Global Transaction Banking Solutions Business of D+H [formerly known as Fundtech]. D+H delivers the payment instructions to the bank via the SWIFT network, and then it's implemented.

Someone in treasury might initiate a treasury payment within the enterprise. The ERP platform will automatically route the payment internally for approvals. The initiators and approvers are all authorized users of the system, and which is also mobile-enabled, so approving a transaction is simple. Approvers don't have to carry around a bunch of different approver tokens anymore. Once the transaction has internal approval, the system will send it on to D+H, and from D+H it will automatically be sent to the counterparty bank via SWIFT. Then the bank will automatically acknowledge receipt of the SWIFT MT message by sending a separate SWIFT message when the transaction is complete. This is all straight-through communication, not requiring people to be involved in sending the messages, and it all takes place within seconds.

T&R:  What are the biggest benefits you've achieved through this transformation of your payment processes?

JE:  One big benefit is that we're able to monitor our financials online in real time. Here's one example: We want to be able to operate from any country; we need the freedom to go into any country at any time to tackle poverty and developmental challenges. But there are banks in the U.S. that cannot deliver cash to certain countries because of international restrictions, sanctions, etc.

Before, our treasurer would sometimes initiate a payment and assume the transaction had succeeded, but it wouldn't go through because of blacklisting or other issues. We wouldn't find out for days that there was a problem. Now, with our new platform, we can immediately see whether or not a payment will go through.

And now we have a bank communication dashboard that gives us dynamic liquidity reporting and shows the status of all payments. In some countries—especially those in Africa, for example—when you make a payment transfer, it may have to go through different corresponding banks before it gets to the direct beneficiary. Our new system enables us to track this, and to understand why a payment initiated on Monday might take four or five working days to get to the beneficiary. Before now, we would wait for the instructing bank to deliver a banking report, which normally would take weeks. Now we have instant visibility, transparency, and auditability.

Our digital treasury transformation has been quite challenging as well as rewarding. It's been a great leap for the institution.

T&R:  How have your treasury operations changed as a result of having this information at your fingertips?

JE:  Treasury practices will change. For one thing, our cash position report is now dynamic. Before, it was basically a forecast. Now it is quite accurate. Everything is now dynamic and updated in real time. In fact, reporting across the board is now providing a lot more visibility end-to-end. The whole lifecycle of treasury operations is now visible not just to the analysts, but also to management.

So, for example, operational disbursements are done from a different organizational unit. Before now, they would have to send physical memos around, just to find out the status of a particular payment or disbursement request. With the new enterprise platform, they don't have to do that. There's visibility throughout, and no more questions of who is doing what, and when.

T&R:  Would you say you have any lessons learned from the selection and implementation of this new treasury management solution?

JE:  Yes, several. One is that a project of this nature requires strong management commitment and support, because the change is quite huge and people don't tend to like change a lot. Once we announced these changes at OFID, some people became upset, thinking they were going to lose their job. You have to have good communication and solid support from senior management to keep the momentum and get the buy-in at lower levels of the organization. We had that, all thanks to our indefatigable director general, Suleiman J. Al-Herbish, who provided strong support and commitment.

Another lesson is that the applied project-implementation methodology and approaches have to be very, very strong and sound. What we are doing here is administering and orchestrating a lot of people, materials, technology, and all of that. If things don't go smoothly, that could cause major disruptions for the institution. The project team must have a great depth of technical and practical business-transformation knowledge. They also need to be able to marry the functional requirements to available technical capabilities in a practical way.

Our mandate was to automate treasury processes, but in doing that we came across a number of obstacles that we didn't foresee at the start of the project. I think this was the first time that an international organization with as much breadth as OFID had undertaken SWIFT connectivity through a service bureau globally. We had to deal with sensitive issues around security, data, privacy, and all the other things that worry commercial organizations.

But even for companies that aren't trying something completely new, you never know what will come up during a project. There is no one-size-fits-all solution. So technical skills are key to success with this type of endeavor.