In 1977, I worked as a summer intern at a major New York bank. My job was to phone corporate customers daily with their account balances. Late morning, I would start taking calls from customers wanting to initiate wires; I would complete a paper wire ticket with all the details, which my supervisor would sign and hand to a person who would walk it to the wire room. I was part of the first generation of corporate cash management. By 1979, most banks offered simplistic TTY cash management services directly to their clients but it wasn't until the introduction of the IBM XT, in 1983, when things started to get intresting.
At that time, most major banks began developing or buying treasury workstations, which remain the foundation of corporate cash management functionality today. Almost 30 years later, the functionality we see in Web-based applications is shockingly similar to what we had in 1983. The reason for this is pretty simple-in the 1980s the PC with a hard drive enabled these applications for the first time. In response to the new technology, banks and their vendors learned how treasury professionals did their job, and designed systems to meet their requirements. That's application development 101. Since then, however, similar applications have just been re-deployed on different technologies-DOS to Windows, Windows to Web, and so on. My belief is that since then, few banks/vendors have re-examined what new opportunities have become available with the new channels that have emerged. A parallel set of applications for ACH and bulk payment applications took a similar route as the treasury applications, but were designed for the payroll and accounts payable departments. These applications were then glued together under one menu, adding to the current situation of diverse user experiences.
When redesign is contemplated the unique needs of corporate customers can't be underestimated. Corporate applications must cater to the needs of the bank's largest clients that maintain very complex entitlements and approval workflows, single and batch payments, comprehensive transaction validation rules, dynamic reporting, and file-import functionality. They must also be easy to learn, use, and self-administer for second and third tier clients. Finally, corporate banking systems must cope with many security concerns including dual factor authentication, transaction signing for non-repudiation, single sign-on, role-based dashboards, and even safeguards that prevent one authenticated user from trying to get to another user's privileges within same organization.
After sorting out all these requirements and understanding the diversity of users, there isn't much room left to create a brand-new user experience. More importantly, much larger, often strategic, opportunities are missed as a result of not examining the capabilities of new user experience (UE) approaches. The changes in Web applications allow much broader access than the earlier workstation-based products. Another constraint is that UE specialists are not experts in highly specialized corporate cash management applications.
For example, when banks first developed cash management workstations, they built wire screens to include all of the fields necessary to create a valid wire from a bank perspective; the transaction could not be saved until those mandatory fields were entered. One of the mandatory fields is the wire's debit account. In some organizations, treasury may want regional entities to enter and approve the wire, but when it's ready to go, have treasury assign the debit account.
The result: regional offices print a wire request which is manually routed, signed, and faxed to treasury for bank application key entry. Same manual process as deployed in 1983. By allowing "personalization" at the organizational level, this model could be easily changed, transforming the corporate banking user experience. The customer determines which critical settlement and user defined fields are required for the wire originator, such as "Beneficiary Account," "G/L Number" and "Vendor ID." The customer defines what constitutes an originated wire request to support organizational requirements.
The customer configures their summary views to include the "G/L Number" and "Vendor ID" fields as well as the other payment fields deemed critical for the transaction workflow to eliminate the need to "drill down" to the detail wherever possible. The customer then adds a workflow step requiring a treasury user to enter the appropriate debit accounts on approved wires. This would be a customer-defined user experience that met organizational goals. The system would ensure bank transaction integrity by forcing the user to enter all the required fields, but within a customer-defined workflow.
In sum, corporate cash management is ripe for re-invention. Assigning consumer banking teams to create corporate banking applications is not the answer; the applications are architecturally and functionally very different. Banks need to talk to their customers and study how their products are being used to determine the existing constraints that could be lifted with a re-engineered process. Legacy user requirements should be re-examined to truly understand what new opportunities exist with the newer, rich Internet application technology. Every institution should strive to build a team of state-of-the-art user experience experts and corporate cash management business specialists to collaboratively create this next generation of product.
Eric Campbell is the CTO of Bottomline Technologies.
