Technology Support for Treasury Dealing and Hedging, Part I
The dealing operations in most corporate treasury departments focus on risk mitigation through hedging financial exposures and investing surplus cash to reflect treasury policy as regards the permitted instruments, maturity profile and counterparty or issuer creditworthiness and dealing limit availability.
Corporate TMSs – as distinct from banking systems – initially functioned as deal database maintenance and reporting systems. Their central role was to track basic foreign exchange (FX) and the simplest interest rate transactions, namely short term loans and deposits. They developed to provide control and report generation appropriate to support high-value financial transactions, strengthening audit quality and treasury transparency. Such systems would support functions such as printing deal confirmations and producing treasury accounting reports.
The value added by TMSs increased significantly when the specifics of corporate treasury risk management were addressed through incorporating exposures (such as future commercial commitments to buy/sell a foreign currency on a particular date/date range) so the TMS could identify hedging requirements, process hedge transactions, and analyse the effectiveness of hedging operations transacted.
Further technology advances were driven by TMS vendors’ product managers taking advantage of the increasingly fast and broad connectivity made available in large organisations. This enabled exposures, deals and deal requests to be channelled promptly and accurately to a central or regional treasury for analysis and action.
This facilitated the development of powerful in-house banks (IHBs). Technology provided treasury with the means to expand the scope and value of its services, through secure and transparent dealing workflows, enabling professional risk management and market execution to be performed, based on enhanced visibility for exposures and deals.
TMS Dealing Workflows – Static Data Management
A key value adding-feature of today’s TMSs, compared with spreadsheet solutions, is their powerful functionality to capture, store and deploy the ‘static’ or standing data needed to serve the efficient and accurate processing of treasury deals.
The static data initially used by a TMS often originates from a legacy system or database. Such a resource is a valuable aid to an accelerated and accurate TMS implementation, provided that the information quality is high. TMSs generally have an automated static data upload function, which validates the importing legacy information, generates error reporting to facilitate correction, and uploads accepted data into the new database.
The new TMS typically includes much additional functionality compared with the legacy system, making it necessary to validate and enrich the uploaded static data so that the TMS can function as automatically and effectively as possible. This implies that an important pre-requisite to uploading static data is a thorough review of the quality and completeness of existing data, which often involves unanticipated and perhaps substantial effort, best performed by appropriately qualified treasury team members. The eventual benefit will be efficient implementation, but there is an unavoidable need for often substantial research, data creation and validation to achieve maximum benefit.
Often much of the information demand of the TMS is based on data that has not been systematically captured before, adding to the initial implementation burden. The TMS vendor should provide sufficient training, documentation and support to facilitate the necessary work.
A substantial amount of information falls in the general category of static and other data that supports a smoothly-functioning treasury dealing workflow. It includes bank and dealer counterparty names; contact information and authorised dealing and back office personnel; standard settlement instructions for all deal types; debt (including borrowing facility) and investment instrument definitions – including settlement and calculation parameters such as day counting conventions for interest accruals and payments; counterparty confirmation formats and instructions for all deal types. Static data extends to both external dealing, and also, where applicable, to IHB internal dealing.
In addition to this complex data web, further information is needed if the deal workflow is to be fully automated. Examples include the definition of the sources of market rate and price information, counterparty (and perhaps other) dealing limit values and credit rating, chart of accounts and accounting rule definitions.
The above examples underline the scope and value of a comprehensive static data collection and validation exercise, as an essential element in planning and executing a high-quality TMS implementation that adds real value to treasury dealing operations. The detailed requirement should be fully researched and planned with the vendor and key project team members, who may include executives from outside the treasury department, such as accountants, auditors, and IT. Sometimes a new effort to set up a high-quality static database from scratch results in a more efficient and dependable process than working with old data that it is significantly inaccurate or incomplete.
Treasury Dealing Workflows – Deal Management
Having addressed the static data environment, the automated deal workflow itself may now be analysed, with the following points applicable equally to FX, interest rate and commodity dealing.
Today’s TMS’s offer transparent and secure straight-through processing (STP) workflows for standard treasury deal management. Effectively there is no substantial functional differentiation between the various systems’ deal management offerings for most corporate treasuries.
Instrument coverage will be examined in Part II; meanwhile the generic workflow elements comprising treasury deal management will be analysed.
For those engaged in a system selection exercise, the differences between the offerings are evident in the user friendliness, look-and-feel, efficiency and transparency of competing offerings. This includes how well they integrate or interface with existing bank reporting and payment solutions, enterprise resource planning (ERP) and other complementary third party and in-house applications.
The value of implemented a highly automated STP solution is that it should minimise error frequency, and provide high levels of dependability and efficiency to treasury operations and the dealing workflow components of deal entry, confirmation, settlement and accounting
Deal Entry
The original entry process for treasury deals into a modern TMS uses information stored in the static database described above. The process may be set-up so the specifics of treasury policy are enforced, for example with respect to restrictions on counterparties and instruments.
The value-added facilities extend to the pre-deal process phase, so the dealer has access to a dashboard or report clearly defining the exposures or positions that require hedging or investment dealing in the marketplace. The TMS may have integral decision support functionality to propose specific deals and to show what the impact of the deal would be if executed. The TMS may also show available headroom versus dealing limits and facility headroom, to help with selecting available bank counterparties and lending facilities.
Once the deal has been executed, the data entry process draws down all relevant static data relating to the counterparty and instrument, so pre-validated information is automatically drawn into the deal record; an efficient process that minimises data keying, and so helps to eliminate errors. The process often includes short-cut input options, such as entering ‘M’ to signify millions, and supplying standard dates such as the FX spot date and normal maturity date for, say, a three-month time deposit in a particular currency. The workflow will attach the standard settlement instructions for the instrument and counterparty, securing this critical part of the process. Any potential breach of counterparty limits will be highlighted, reported and followed-up according to pre-defined rules.
The format of all data is validated by the TMS, and deal rates entered may be subjected to reasonability tests against the current market to help eliminate gross errors.
Once the deal has been entered, the TMS database will automatically update in real time, so the dealer can see the current risk position on a dashboard or report. The relevant limit or facility utilisation will also be updated, facilitating accurate further usage if needed by the organisation.
A long-standing TMS feature is the maintenance of ‘competitive bid’ information, which enables the dealer to record a selection of losing counterparties’ submitted rates. This data may be used for subsequent bank performance analysis and relationship meetings with bankers.
The process is also applied with minimal modification to inter-company or IHB deals. An added automation function often found is that a series of subsidiary deal requests – for example for identical time deposits – may be amalgamated for one deal at the best available price in the market; the deposit is then allocated in the original proportions to the internal counterparties, in a series of back-to-back inter-company deals. The workflow continues through to completion for all these deals in a controlled, efficient process. In many operations, deal requests are submitted and subsequently reported over the web.
Electronic Dealing
Automated dealing services are increasingly popular with corporate treasuries. Implementation of such solutions usually involves tight integration with the TMSs dealing workflow. Typically the TMS submits deal requests to the dealing service, which holds up-to-date approved counterparty and available limit information. The service executes the order and returns the relevant information to the TMS, where its arrival triggers continuation of the dealing workflow.
Electronic corporate dealing of this kind has proved to efficient and accurate in accommodating many aspects of the entire treasury dealing requirement.
Deal Import
A further origination point for treasury deals in more decentralised organisations is subsidiaries’ local finance operations. Again, the web is usually employed for 24/7 information exchange. According to policy, group treasury may have an approval role in the workflow or the information may simply be used for central financial risk visibility purposes. The import process will include validation of the deals by the TMS, with error and other reporting returned to the originators.
Automated deal import is often used in implementation to load historic deals – sometimes in high volumes – into a new TMS’s database, to facilitate comparative analysis and benchmarking, and for research purposes. The same points concerning legacy data verification and enrichment made for static data management apply equally to historic deals.
Control and Audit Features
To summarise, a contemporary TMS adds value and quality to the entry of all kinds of treasury deals. Following the original entry or import operation, companies’ treasury policy require some level of human intervention to validate the accuracy and authority of new deals before the automated workflow can proceed.
In larger treasuries, the TMS will manage the segregation of duties between originators, authorisers and processors of deals. The required logic can consist of quite complex sets of rules, which are securely locked into place and administered by the TMS. The rules may also limit individuals, and perhaps groups, within defined boundaries such as their maximum permitted size of deal. In smaller operations, executives from outside the treasury function may be required to approve and authorise treasury deals, to implement a suitable segregation of duties environment.
A further control function provided by all TMSs is the maintenance of an indelible and complete audit trail, including all deals and static data operations. Every event – add, change, read and delete – is immediately recorded in the audit trail. The information captured includes identification of the person who performed each action, together with a data and time stamp, and full details of any changes made. All this information is available in TMS audit reporting.