The following case study was excerpted from the latest Treasury in Practice Guide, Selecting the Right Treasury Management System, underwritten by Kyriba.
About three years ago, the treasury department at New York University decided to move from Excel to a TMS, explained Tim Hesler, CTP, assistant treasurer, global banking, cash management and treasury operations. “We were all Excel, and for us, the business case was to reduce key person operational risk,” he said. “We also saw finance running a bunch of great systems, and we didn’t want treasury to still be running spreadsheets.”
Hesler’s treasury team knew going into it what they needed—cash flow forecasting, core cash management, automated bank communications, and bank account administration. Heavy investment and debt functionality weren’t really needed at this point, and neither was foreign exchange, as NYU’s hedging program is completed once a year. Treasury also did not need a general ledger interface module since it had already automated that with its ERP provider, and it also did not need payments, since this was automated between its ERP accounts payable sub-ledger and a bank.
“In finance in general, people make mistakes in Excel spreadsheets all the time, public companies have had hits to their earnings, people getting fired, etc.,” Hesler said. “Even now, when you read the Wall Street Journal, there are huge issues just because people didn’t run their Excel spreadsheet correctly. So we wanted to prevent that in our organization.”
Because treasury had a clear idea of its technical and functional requirements, it was able to narrow the choices down to five vendors. From there, NYU was able to begin its formal RFP process. “I wrote it, but it was supplemented by our PMO group, who helped to keep it even more objective so it wasn’t all treasury doing it,” Hesler said.
NYU’s treasury department ruled out four of the candidates for a variety of different reasons, including: vendors with questionable viability in the near term; a lack of ERP treasury consultants; poor customer service, and high prices with no value proposition. As Hesler put it, one vendor’s reputation can be summed up like so: “They sell you the system, and then they leave.”
Hesler’s team ultimately settled on a solution that fits NYU’s specific functionality requirements. It took the treasury team some time to sign the contract because they wanted to ensure that what was promised to them was absolutely going to be delivered, so they interviewed the proposed implementers of the system to make sure there was a ‘fit’. “We were just being really cautious,” Hesler said.
Since the implementation, the improvements at NYU have been dramatic. Treasury used to download a plethora of reports off of bank systems and manually email them out to users, payroll, AP, accounting, etc. Now, that’s all automated. “We needed that automation because we don’t have a huge team and we have a lot of complex transactions,” Hesler said. “For our size university—which is huge—we’re executing transactions in the financial markets that may be more rigorous than some large corporates. We’re issuing tax-exempt debt, we are managing billions of dollars in investments, we’ve got a hedging program—but we’ve also got all the strict internal requirements of compliance for a nonprofit.”
Treasury also has much tighter controls; NYU uses multifactor authentication to access the system, as well as IP filtering and a jump host server. “So when we enter the TMS or a banking portal, we are actually entering a virtual server in the middle of our secure IT data center,” Hesler said. “We’ve made it extremely difficult to actually get into it. Because if a desktop machine is compromised, we have all the added protections of the entry points being in that secure data center. We wanted that incremental amount of security, because fraudsters have broken into other company’s networks or network drives.”