Chapter Four
,
Importance of Operations and Control Efficiency
PROCESSES FORM THE CORE of the Treasury function, with systems and technology being enablers to implement and achieve efficient processing. Unfortunately, processes are also some of the most ignored aspects of many a Treasury, relegated to the shadows away from the glamour and spotlight of investor relations, mergers and acquisitions, capital planning, exotic concentration solutions, and risk management.
This chapter highlights the importance of processes—their operations and control—and some of the tools required to put processes in place. The Toolkit in Part Five discusses some of these tools in detail.
TOOLS
There are many tools available in the Treasurer’s armoury. The following tools (Figure 4.1) are especially critical from an operations and control standpoint.
Policy
A Treasury policy, a sample of which is provided in Part Five, is a starting point in the Treasury operations and control journey. Key elements, activities, risks, and mitigants are identified; roles and responsibilities are allocated; and limits and functioning parameters are defined. Processes and procedures have to work in tandem with the policy.
Process Mapping
Process maps lay a strong foundation for watertight process notes. There are different styles and standards of process mapping. I favour maps where the process is mapped out by role and each handoff point from one role to the other is clearly demarcated. A separate role for system inputs and handoffs and the activity performed by the system segregates the human element from the technological one. The handoffs are one of the key differentiators that maps bring to the table. Opportunities for errors creep in when there are handoffs. It is important to document handoffs appropriately and try to minimise their frequency and number. Figure 4.1 shows an illustrative process map for Treasury risk management.
Process Notes
Process notes, which are referred to by many other names, such as standard operating procedures, are detailed documentation, by activity and role, of each Treasury process. Some of the advantages of standardised process notes in uniform formats are that they:
- Improve efficiency and effectiveness of operations.
- Provide a ready reference tool for new employees to start performing their roles immediately and a refresher for existing employees backing up or ascertaining process-related aspects in situations of ambiguity.
- Enable auditors, reviewers, and regulators to understand the process end to end and hence lower the opportunities for miscommunication.
- With greater transparency, show up opportunities for error and improvement, thereby increasing control and process watertightness.
- Improve employee motivation, awareness, and morale.
- Reduce cost.
- Provide a pan-company, cross-location standard for cutting-edge Treasury Design.
Systems and Technology
The advent of systems and technology across the spectrum has vastly increased the efficiency of Treasury processes. Irrespective of the nature of the business and industry, and for a business in any stage of maturity, size, and growth, Treasury is one unit that certainly benefits from automation and systems. Increasingly proactive banking systems, payment gateways, and vendor automation have greatly added to the bulwark of a robust Treasury process. Two key questions arise, which are addressed below. We subsequently revisit the Systems discussion in Part Five.
1. Is it better to align processes around a good system or to align systems around existing efficient processes?
One of the reasons for procuring a new system is to improve processes. With the assumption that a robust system that has been tried and tested will make the whole process more efficient, it is more practical to use the opportunity to enhance existing processes with the system as enablers, without having to change the system and retain existing processes.
2. Is it better to have good use of excellent technology or excellent use of good technology?
It is said that a system is only as good as its usage. It is always better to use a system in an excellent manner to extract the most from its capabilities than to invest in a state-of-the-art system but use it only partially and not leverage its complete capability. Of course, any system must fulfil the criteria for which it has been procured and must have the desired capabilities.
Integration
Integration of systems, processes, accounting, and control with the entire firm’s architecture increases process coordination and reduces the need for duplication and rework.
Reporting
A good reporting mechanism utilises little human time and effort, is timely and appropriate, and optimises level of detail for each level of management. Overreporting can waste time and lower the perceived level of importance of information or require more effort to identify the meaningful and necessary information from an ocean of data. Under- or inadequate reporting has its own obvious consequences.
Control
Regular review and control of processes ensures that there are few surprises and operating or other losses incurred as a result of inadequate or inadequately followed procedures. A detailed overview of the control process is given in Part Five.
DIFFERENT OFFICES: FRONT, MIDDLE, AND BACK
The delineation of duties across the front, middle, and back offices is increasingly gaining popularity. Of the many innovations and thought processes that the banking sector has lent to the world, one of the most crucial is the middle-office function. This function monitors and works closely with both the front and back offices, reporting independently and ensuring that management receives regular updates regarding activities of the two other cogs in the Treasury wheel.
- Front office. Focuses on planning, transacting or dealing, funding, investment, risk management, interacting with banks, and owning the accounts. This is the front end with the key decision making and transacting. This function reports directly to the Treasurer.
- Back office. Focuses on confirmation, settlement, processing the transactions, basic reconciliation, and passing the entries into the enterprise resource planning (ERP) or general ledger (GL) accounting system. This is the back end with key execution and operations responsibilities. If the Treasurer is also a transactor or dealer who regularly executes transactions, the back-office reporting should be independent, preferably the responsibility of the controller.
- Middle office. Focuses on control, valuation, reconciliation between front and back offices, performance evaluation, model validations, risk reporting, and limit monitoring. This area is appropriately called the middle office because its function has oversight of both front and back ends, with key control and reporting responsibility. The middle office always reports independently of front and back offices, either to the controller (if the Treasurer does not have a transactional role) or to the chief financial officer (CFO) or risk head (if the controller has oversight of the back office).
Figure 4.2 provides a snapshot of the various responsibilities across these three arms of Treasury activities.
In many situations, the lack of role clarity could result in items falling in between tables and having no ownership. The case study below illustrates such a situation.
CASE STUDY: WHICH DESK SHOULD LOOK AFTER THIS ISSUE?
The CFO of a European technology company was in a quandary. The books in the control system and the Treasury system were showing different numbers. The Treasurer, who had claimed a massive savings as a result of his hedges, had resigned when the controller reported that the hedging process over the past two years had actually lost the firm a lot of money and that the objectives of achieving stability and visibility of financials were not being met. The week after the Treasurer had quit, one of the dealers came to the CFO with a problem: A hedge transaction that the Treasurer had done earlier in the month as part of the hedging programme that had also been reported in the GL system (ERP) had come up for maturity, but the bank had no records of the supposed transaction. Similarly, a payment that was supposed to have gone for an earlier hedge settlement through the electronic system had shown a confirmation, while the bank was still asking for the payment to be made.
The Treasury team was responsible for the transactions and interface with banks and for accounts and liquidity management. Any entries to be passed were done so by the controller’s team based on reports issued by Treasury. The control team members were not experts on Treasury decisions and products; they left decisions to the expertise of the Treasury team, agreeing in the spirit of teamwork to help pass the entries in the back end. Implementation of a state-of-the-art Treasury system had assisted the process. Entries were now mostly automated except for a few processes, where the front end or dealers still handed over reports and the transaction entries in the ERP were then be passed by control based on these inputs.
The CFO immediately requested an independent review, and after two weeks, he received the report. Sifting through the points, there was one thread that was common: the differences between the various elements, systems, or desks on their evaluations, numbers, and balances. The reconciliation process had gone awry. The ERP (GL system) and the state-of-the-art Treasury system that the company had invested in on the treasurer’s recommendation were showing completely different numbers on account balances and hedging transactions. Transactions reported on the Treasury system and whose mark-to-markets were being correctly reflected in the accounting books were not present in the banks’ reports. Limit excesses by traders had been checked (the checklists had been ticked) but not reported, since the checks had been done by the traders themselves—system and banking reports would come in to the dealers who would perform the verification to the best of their ability.
The CFO called the controller and the senior members of the Treasury team. All of them had done their day-to-day operational jobs to the best of their abilities, but when the time came to discuss reconciliation, the answers were ambiguous. Owing to direct system handoffs between the Treasury system and the ERP, no one had felt that there was a need for reconciliation. The banks’ offer to integrate their systems with the Treasury system had been rejected owing to incremental implementation costs. Hence the activity had remained with the Treasurer and his team. Limit checks were designated a noncritical activity by the dealers and hence were not factored into reviews on automated system reports—where they had been built, the recipient e-mail addresses listed the dealers themselves, and post-migration, the addresses had not been changed. The inbox of the Treasury team members was thus flooded with over 100 reports that kept being flushed to the “Unread reports” folder and purged whenever the mailbox exceeded its limit.
The solution again was simple: The reconciliation process had to be done, regularly. The question was, by whom?
Would it be done by the front office, giving it access to the back-end systems as well? Or was it a back-end task, reconciling tasks after the entries had been passed? Or was it worthwhile to invest in a middle office, which would be responsible for all the reporting and the reconciliation, independent of the activities of deal origination, decision making, and booking in the firm’s ledgers?
The next case discusses a real-life case of the National Aeronautical and Space Administration (NASA) and shows how a situation for a control and information security risk was resolved.
CASE STUDY: IMPORTANCE OF MANAGING INFORMATION TECHNOLOGY SECURITY RISK IN OUTSOURCING CONTRACTS
Information technology (IT) security has become a main area of focus with increasing interconnectivity of systems and networks around the world and scattered information and data storage through the use of various service providers. When activities are outsourced, the criticality of building in adequate measure of information security (IS), especially sensitive financial and balance sheet information that Treasury possesses and uses, is escalated. This case study explores how NASA builds in IS risk into its outsourcing contracts and how it addressed and resolved a situation of noncompliance.
Background: Importance of IS
IT security and safety of information and details are critical for any firm. When your firm runs the largest and most advanced space programme in the world, the risk is possible at the highest level, which could result in human fatalities.
Incomplete IS aspects and classification for any project could lead to a number of potential issues. NASA takes its IS risks very seriously, especially in the background of the consequences shown in
Figure 4.3.
Information classification must be unambiguous and easy to interpret, since the use of the classification and the data protection around each classification or category of information will be different. Each data item must be identified and classified beforehand to avoid rework and reduce chances of error and risk. NASA uses the classification provided in
Figure 4.4.
Situation: Contract Built In But No Compliance with IT Security
The Orion project is an advanced spacecraft programme in the implementation stage. Also known as the Multi-Purpose Crew Vehicle (MPCV), it is being built to explore farther into our solar system, including potentially returning to the moon, visiting an asteroid, and/or mounting a hugely complex and risky mission to Mars. The first manned mission is expected to take place after 2020. Each Orion spacecraft is projected to carry a crew of four astronauts. Most of the Orion project activities have been outsourced to selected prime contractors.
During a review, NASA discovered that appropriate security clauses around sensitive but unclassified (SBU) information had not been incorporated appropriately into the vendor contract.
NASA had redefined the responsibilities for information as part of establishing its security protocols (see
Figure 4.5). However, the details of the requirements were not established until after contract award.
When the vendor was requested to assess the contract cost impacts of incorporating the new security protocols, the cost was more than NASA could bear. NASA now had two options:
1. Seek a waiver from NASA headquarters (HQ) and governing security agencies regarding levying the new security protocols on the Orion contract.
2. Negotiate between the Orion prime contractor and the owner of the security requirements (NASA HQ) to meet the intent of the levied security protocols to ensure the protection of sensitive information while maintaining the cost impacts within budgetary constraints.
On examination, it was evident that a waiver would have an irreparable impact and leave much sensitive information vulnerable to theft or misuse. The vendor was a long-standing partner of NASA; hence from a relationship perspective, it should be possible to work with it to find a solution.
It was decided to renegotiate the requirements with the prime contractor and HQ. However, there would be a price to pay, and the team at NASA recognised that. The way forward was to work closely to identify the security requirements and reduce risk to the largest extent, and also identify how these requirements could be levied on the prime contractor with minimal cost impact from wording or process changes (see
Figure 4.6).
One of the key elements was training the team at the vendor side, so that they could fully understand and implement the new security protocols. The training would involve:
- Proper identification and categorisation of information (in this case, sensitive but unclassified)
- Proper marking of information
- Proper handling of sensitive but unclassified information
- Storage requirements
- Transmission requirements
- Decontrolling information
The consequences of noncompliance or failure to identify information as such could result in:
- Increased risk to programmes or operations essential to the mission
- Damage to a person’s privacy interests or economic or physical welfare
- Possible administrative action and criminal prosecution
- Competition having access to the information
Once the vendor came back with estimates and the plan, the team at NASA worked with the vendor team to finalise the revisions and negotiate on the cost, for a win-win situation in the context of the information security gap.
Contributed by Jeevan Perera, PhD, JD, Johnson Space Center, NASA
Learnings
IT security is critical to the organisation, especially information on bank accounts, financials, risk management, and investments that Treasury is privy to and owns. IT security needs to be built in to outsourcing contracts to reduce operational risks.
If such clauses have not been factored into existing contracts, it would be worthwhile, as we saw in the case of NASA, to subsequently incorporate these clauses into the contracts and rationalise the incremental cost structure by working with the vendor or outsourcing partner.
SUMMARY
In this chapter, we looked at some of the important elements of Treasury processes, operations, and control. The importance of process mapping and other tools were highlighted. Finally, the delineation of Treasury activities and responsibilities across front, middle, and back offices and the growing importance and context of the middle office were discussed.
