Introduction to Collateral

This is a company level application, which sets out high-level parameters that control the Collateral module. The parameters include:

• Maintaining the number of changes to collateral revaluation in the COLLATERAL application
• Considering account balance when deposit account is given as collateral
• Online update of cash collaterals (if required)
• Online collateral valuation (if required)
• Defining the currency and forex risk margin to cover the currency conversion risk factor
• Contract sequence routine defined in EB.API can be attached in the Contract Seq Rtn field.

The contract sequence routine instructs the system to apply a different collateral allocation order for the contracts returned, compared to the standard pro-rata allocation.

Example – Running contract sequence routine

In this example, a contract sequence routine has been set up in COLLATERAL.PARAMETER, which returns the contracts in the order in which the transactions take place. The collateral amount is not allocated based on pro-rata allocation; instead, it is allocated based on the execution value for each Limit. This means that when more than one Limit is linked to the same Collateral Right, the amount assigned to each Limit is used by contracts. One Limit is not borrowed from another Limit’s assigned collateral amount. The following Limit structure has been created:

• Validation Limit LI0000101030 with Internal Amount = 50,000.

• Utilisation Limit LI0000101031 with Internal Amount = 30,000, but with an Online Limit = 22,500 based on the Execution Value of the collateral linked to the Limit.

• Utilisation Limit LI0000101032 with Internal Amount = 20,000, and an Online Limit equal to the Internal Amount; both this and the previous Limit are linked to the same Collateral Right.

• Collateral Right COR09362S124H showing the two Utilisation Limits linked to it and the collateral to which they pertain.

• Collateral CO09362G674G showing the total Execution Value of the two Utilisation Limits and the Collateral Right Id to which they are linked:

• Collateral Allocation showing the allocated amount (that is, Execution Value) for each of the Utilisation Limits:

• The two records in the LIMIT.TXNS application showing the contracts that utilised each Limit:
• For Limit LI0000101031, contracts 10017194202 and 10017194203.

• For Limit LI0000101032, contract 10017194204.

By disbursing the above contracts and running LI.CONTRACT.ALLOCATION.SERVICE, ECB displays the following details for each contract:

• Contract 10017194202 is disbursed for 6,000 by utilising Limit LI0000101031; given that Online Limit = 22,500, the system allocates the full amount for the transaction:

• Contract 10017194203 is disbursed for 15,000 by utilising Limit LI0000101031; given that Online Limit = 16,500, the system allocates the full amount for the transaction:

• Contract 10017194204 is disbursed for 25,000 by utilising Limit LI0000101032; given that Online Limit = 20,000, the system could have allocated a total of 21,500 for the transaction since there are still 1,500 not utilised for Limit LI0000101031; however, because of the contract sequence routine that has been initiated, the system allocates only the 20,000 assigned for this Limit:

This application is used to define classes (or types) of collateral such as:

• Cash
• Buildings
• Guarantees
• Stocks (or sub-divisions thereof)

Information from this application is used to determine (for each type) how the collateral value is established, re-valued and linked to other applications. 

The key to this application is numeric and it is entered in the COLLATERAL.CODE application.

In the below screenshot, the Application field is set to mandatory using the Application Input field. This is a multi-value field and allows different types to be accepted under this class of collateral. 

Temenos Transact provides the following values for contracts and accounts:

• Nominal Value – Face value or current market value of the collateral.
• Execution Value – Expected value, which realises on sale. This can be expressed as a percentage of nominal value if required or value of the underlying MM, LD contract and so on.
• Third Party Value – Displays how much value of the collateral is used outside Temenos Transact, the prior right of another lender.  This amount is deducted from execution value to determine the net execution value of collateral.
• General Ledger Value – Amount recorded for general ledger purposes.
• Central Bank Value – Specific limitation on values set by the Central Bank, if any.

Input choices for the value fields are given below:

• Mandatory (M) – User must input the value of collateral
• Optional (O) – An optional input field
• None (N) – Value is not entered by the user
• n%N – Nominal Value percentage
• n%E – Execution Value percentage
• Fed (F) – The nominal value of the collateral is automatically fed from the main application, belonging to the collateral
• Fed/Margin (FM) – The nominal value of the collateral is automatically fed from the main application belonging to the collateral, using the margin value calculated by the application.

The Cash Collateral field in COLLATERAL.TYPE indicates if the collateral is a cash collateral. The options are Y or N or Null, where N or Null means the same.

This application is used whenever the Execution Value field (if defined as a percentage of Nominal Value field in the COLLATERAL.TYPE application) is different for specific customers. To input a record in this application, the Execution Value field in the main COLLATERAL.TYPE application must be defined in the %N format. The record ID format of this application is <CustomerID> -< Collateral Type ID>.

This application allows further sub-classification of the collateral objects such as:

• Credit balances in account
• Land
• Buildings
• Bronze sculpture
• Stone cravings

Each of these sub-classifications can be recorded in COLLATERAL.CODE application.

The collateral codes are linked to COLLATERAL.RIGHT application. These collateral rights can be recalculated and the rights can also be reviewed at periodic intervals. This is achieved by using the following fields:

• Percent Date Fqu field is a combined date and frequency field. It determines if and when the system has to automatically recalculate the value of the Percentage Cover field in the COLLATERAL.RIGHT main application records, belonging to this code.
• Review Fqu field is used to generate a default value for the Review Date Fqu field in the COLLATERAL.RIGHT main application, belonging to this code.

Also, collateral code is used in determining how the collateral values are reallocated across central bank reporting lines.

Using a structured record set-up helps in entering and understanding the links between COLLATERAL.TYPE and COLLATERAL.CODE applications.