Like all other fields Treasury systems also have their own language. Before you go ahead and build them or start working with a treasury group you have to get familiar with the treasury management terms & language used. Here is a list of common terms you are likely to see in treasury and treasury operations groups
Common Treasury management terms
i. Deal Ticket
All transactions in a treasury function are recorded through a system that tracks the flow of each transaction through its life cycle. The document that records the transaction is called a deal ticket or ticket for short.
ii. Dealing System
The system that treasury function uses to trade and interact with other treasuries in the market. This is generally different from the treasury system that is used to record, track and manage transaction workflow within the treasury.
Limits are part of the control mechanism to ensure that the treasury does not book un-authorized deals and trades by defining a cap on daily trading done by trader, dealer, desk or group. Limits also apply to products (Money market, Foreign Exchange, Equities) as well as counterparties. Some limits are internal (defined by the bank), while others are regulatory (defined by the regulator).
iv. Treasury Desks
A treasury desk refers to a business line or business group whose performance and profitability is generally tracked separately. For instance, Money market or Fixed Income, Foreign Exchange and Treasury Marketing Unit (TMU), Equities and Margin lending desks each refer to a distinct line that forms the treasury group.
v. Front Office, Middle Office, Back Office
Roles that define segregation of duties and control across a treasury. A front office user is a dealer or trader who books the trades and executes it. A Middle Office user is responsible to enforce and review risk limits and exceptions while a back office function is responsible for settlement, confirmation and accounting. TROPS or Treasury Operations is generally used to refer to the treasury back office group.
vi. Four eyes workflow
The ticket workflow is implemented with the Four Eye Principle. All tickets created need to pass through a confirmation cycle of approval, verification and authorization. The approval is conducted by the Front Office personnel, whereas the remaining two confirmations are performed by the Back Office.
vii. Ticket Approval
Once the deal ticket has been created, it needs to be approved by another user residing in the Front Office. For approval purposes, each user has been provided with a financial limit. If the ticket amount is more than the limit assigned to that user, then the user is not able to approve that ticket.
viii. Ticket Verification
Once the deal ticket has been approved, it needs to be verified by another user. The verification is done by a user residing in the Back Office.
ix. Ticket Authorization
Once the deal ticket has been approved & verified, it needs to be authorized by an independent user, once again, residing in the Back Office. For authorization purposes, each user has been provided with a financial limit. If the ticket amount is more than the limit assigned to that user, then the user is not able to authorize that ticket.
At any stage during the confirmation process, the ticket may be returned to the original dealer who created the ticket either for cancellation or for corrections/ editing. The edited ticket will go through the confirmation cycle again, i.e. approval, then verification and finally for authorization.
Whenever a deal is complete, a Confirmation letter setting forth the terms and conditions of the deal is sent to the counterparty. A confirmation is then required from the counterparty which usually arrives the same day. The confirmation provides a necessary final check against dealing errors. It should be independent of the trading room and be performed entirely by operations. Using the data from the settlements and payments systems, the confirmations provide a check to ensure that the operations areas of each party to the deal have recorded the same details for each of the transactions carried out.
The confirmation should contain (at a minimum) details of the counterparties and location, brokerage, transaction date, value/ settlement date, settlement instructions, currency amounts and exchange rates (for FX deals), etc.
The treasury system tracks the confirmation status of all deals including the monitoring of all unconfirmed transactions. There are 4 ways of receiving a deal confirmation from the counterparty.
- Manual confirmation
- System generated confirmation
In the event that there are delays or where confirmations are not received there should be an established escalation procedure to follow up on missing confirmations. In addition to this management also needs to be informed.
Risk in the confirmation process arises either when discrepancies are missed or when trades are not confirmed. Failure by the counterparty to send confirmations could be the first sign that the counterparty is facing impending financial failure.
Settlement entails carrying out a series of duties in respect of all transactions emanating from the front office effectively leading to making an actual payment.
Settlement risk is the risk that after having sent the payment instructions, there is a delay in receiving the payment or the payment is not made at all, i.e. there is a default.
xii. Price discovery
Price discovery is the process by which buyers and sellers interact to determine the fair market price of an asset. Trading in the financial markets is about obtaining prices. Efficient financial market prices reflect the future risk and return associated with a security. But trading decisions also impact how prices will move and trading activities continuously feed new information into market prices.
xiii. Rate reasonability
A mechanism or process for checking that the rate entered by a dealer is a rate that is likely and reasonable based on the expected daily fluctuations possible in that rate. For example, under normal conditions, interest rates and exchange rates will move within a certain daily range and a rate reasonability check will flag any rates that are outside that boundary.
xiv. Proprietary Trading
Proprietary trading is the means by which the bank trades stocks, bonds, options, commodities, derivatives or other financial instruments for its own account i.e. for its own profit rather than trading on behalf of its customers. It involves active position taking with a view to capital gain. Banks involved in this form of trading believe that they have a competitive advantage that will allow them to earn excess returns. Their aim, therefore, is to directly benefit from the market rather than through the commissions they could earn from processing trades on behalf of their customers. Due to the volatility in the markets, earnings from proprietary trading tend to be more volatile as compared to the bank’s earnings from processing client trades.
Banks engaged in proprietary trading usually have separate desks that are solely devoted to prop trade. These desks work in isolation from those processing trades on behalf of the bank’s clients. The objective of these desks is to earn profits that are above those that could be earned in their normal market-making trades. Another reason why the trading desk is kept separate from the other desks is to avoid conflicts of interest or situations where the prop desk’s trades could harm the bank’s customers’ interests. One such activity is fronting running a customer’s order where the prop desk knowingly purchases shares ahead of the customers’ trades, so as to benefit from the price increases that could result when the customers’ deals are processed. This results in profits for the prop desk at the cost of the bank’s customers who end up paying higher prices on their trades.
xv. Operational Risk
- Transaction risk: Execution error, Product complexity, booking error, settlement error, commodity delivery risk, documentary/ contract risk
- Operational control risk: Exceeding limit, rogue trading, money laundering, security risk, key personnel risk, processing risk
- Systems risk: Programming error, model/ methodology error, IT systems failure, telecommunications failure
- Business events risk: Currency convertibility risk, shift in credit rating, reputation risk, legal risk, taxation risk, disaster risk, wars, collapse/ suspension of market
- Regulatory risk: Breaching capital requirements, regulatory changes