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 language used. Here is a list of common terms you are likely to see in treasury and treasury operations groups

Common Treasury Terms and concepts

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.

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 treasury.

Limits

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 on products (Money market, Foreign Exchange, Equities) as well as counter parties. Some limits are internal (defined by the bank), while others are regulatory (defined by the regulator).

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.

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.

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.

Ticket Approval

Once the deal ticket has been created, it needs to be approved by another user residing in the Front Office. For approval purpose, 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.

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.

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 purpose, 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 be go through the confirmation cycle again, i.e. approval, then verification and finally for authorization.

Confirmation

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.

• Swift
• Manual confirmation
• System generated confirmation
• Others

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.