Limits-R12.01

T3TLI - Limits - R10.1

1

Limit module monitors availability and utilisation of Limit. Limit can be sanctioned at an individual Customer Custom er level or at a group level. Customer Cu stomer limits are monitored on a real-time basis whereas other limits against Currencies, Commodities and Countries are updated during du ring Close Of Business. Limit is a risk perception and the Bank can classify its risk products as per its requirements. This course covers the dependencies, parameters and Features of Limit module. Important Important features of Limits Limits including revolving, non revolving, secured and un-secured, individual and group limits and product and sub products are touched upon. Enquiries and reports related to Limits are given towards the end.


2

Limit module monitors availability and utilisation of Limit. Limit can be sanctioned at an individual Customer Custom er level or at a group level. Customer Cu stomer limits are monitored on a real-time basis whereas other limits against Currencies, Commodities and Countries are updated during du ring Close Of Business. Limit is a risk perception and the Bank can classify its risk products as per its requirements. This course covers the dependencies, parameters and Features of Limit module. Important Important features of Limits Limits including revolving, non revolving, secured and un-secured, individual and group limits and product and sub products are touched upon. Enquiries and reports related to Limits are given towards the end.


2

When a Bank does a transaction with a Customer, it is exposed to different different types of risks – Risk Risk towards an individual or groups of customers; Countries or groups of countries; Currencies and Commodities. Setting a limit for a client allows the lender to control exposure to that client and to monitor its own overall position. positi on. For example, before a loan is made available to a customer, a limit must be set up specifying the maximum amount that the Bank considers it prudent to lend to that customer. customer. This will enable the client’s client’s transactions to be processed without override, provided the transaction falls within the agreed limit. LIMIT application will also allow clients to draw facilities in different currencies and will re-calculate outstanding amounts into the currency of limit. Setting up limits also allows a Bank to monitor its exposure to its clients by product, e.g. Forex and by sub-product, e.g. a limit for spot. The lender can also monitor its exposure by commodity (Industry), country and currency. A reducing or non-revolving limit does not have its value restored when a transaction is repaid. A Non-reducing Non-reducing or revolving limit is maintained at the sanctioned levels on repayment. In a Limit hierarchy, hierarchy, all levels should have certain similar attributes, one of them being that of the Limit being Reducing or Non-reducing. For instance, if the Product level is Revolving, all the sub products under it should also be Revolving. Customer limits for product and sub products are monitored in real time during on-line processing. Country, Country, Currency and Commodity limits are monitored and reported during close of business batch.


3

A limit may be fixed or variable depending upon it being allowed to change in line with changes in collateral value.


3

A Limit may be sanctioned at an individual customer level or to a liability group level which is then made available to the customers of that group. If Walls Ltd is a stand alone company, a limit of USD 5 million may be sanctioned to it. If it belongs to a group called Walls group in which there are three companies including Walls Ltd., then a limit of USD 10 million may be sanctioned to Walls group and USD 5 million to Walls Ltd. At any point, the individual limit of Walls Ltd as well as the group limit of Walls group will be checked for availability. Limits are also sanctioned for specific products. This could optionally be at a Global level, and mandatorily at a Product level and under a product, optionally at ten further sub product levels, thus adding up to totally twelve levels. A limit is a perception of risk and hence limit products could be grouped differently from business products of a Bank. Every business product may be associated with a unique risk perception, or a single risk perception may be common to many business products, or a single business product may be associated with different risk perceptions. It is possible to accommodate all these situations suitably.


4

Limits are set for specific amount of a currency. Limits in one currency may be allowed to be used for utilising in other currencies also. CURRENCY table provides exchange rate for updating the utilisation amounts of Limits when they are used for transactions in other currencies. Currency wise, Industry wise and Country wise exposure are updated during close of business as when a Limit is sanctioned, it also stores details of exposure in a specific currency, given to a customer engaged in a pre-defined industry and defaults country of exposure from the country of residence of customer. Further, value from CUSTOMER.STATUS indicated in the Customer record helps decide the limit grade. Thus the static tables CURRENCY, INDUSTRY, COUNTRY and CUSTOMER.STATUS are used while inputting limits. When we want to collect interest and / or charges on the unutilised or utilised portion of a limit, then that should be set to be transferred on a daily basis to a contingent account. Interest and charges of this contingent account should be liquidated from another non contingent account of the customer. For this purpose, customer type contingent accounts should be opened using category codes indicated in ACCOUNT.PARAMETER. Further, internal contingent account for contra purpose also needs to be opened. Category codes for such internal account should conform to setting in ACCOUNT.CLASS with record Ids of OFFLIMIT, UTILLIMIT and OFFSPINT .


5


6


7


8

There are only two Parameter tables required to be set up for Unsecured limits – LIMIT.REFERENCE and LIMIT.PARAMETER. However, for every risk perception, viz Limit product, a separate record is required to be set up detailing all its nature in LIMIT.REFERENCE. Later, all the limit products are linked to business products as one to one or one to many or many to one associations in LIMIT.PARAMETER. For secured limits, parameter tables for COLLATERAL application are also required to be set up as they are used to indicate how the limit is secured.


9

This table is used to define the types of Limit to be processed by T24 Limits. A Limit product or risk perception is also known as a Limit Reference within T24. This can be defined as being part of a hierarchy, made up of a GLOBAL Limit, PRODUCT Limit and SUB PRODUCT Limits under a Product. Products falling under a hierarchy have to have some common attributes – all of them will be either reducing or non reducing. This table is also used to define whether the Limit product is one that requires availability checking each time, or whether it is updated only for information. It is possible to indicate a product as only for information purpose, or a deposit product which does not require updating or a typical exposure product that needs checking availability etc.


10

A Global limit, Product limit and a Sub product limit together is considered as a Standard level. The next stage of sub product is considered as first level of sub product. Limit structure can be created with or without a Global level. Hence, Global level may be considered as an optional part of the Standard level. However Product Level is mandatory. Sub product levels are also optional. In LIMIT.REFERENCE table, we should start defining the lowest multi level sub product first and then move up the chain till we reach the top most level – Product or Global as the case may be. It is advisable to understand the multi-level risk hierarchy first following top to down approach and then define products in LIMIT.REFERENCE from bottom to top approach. The limit would be setup in the following order 1. Global level 2. Product level 3. Sub product level. This is the inter-relationship between these levels which is also in Loan the order of risk hierarchy.

Secured

Land and Building


Unsecur ed

Stock

11

Id for a Global limit product should be between five and seven digits of which last four digits should be Zeros. Id for a Product limit should be three or four digits with last two digits as Zeros. A sub product shall not have more than 1 zero as last two digits. It should also be noted that the first 2 digits in case of a four digit identifier and the first 1 digit in the case of three digit identifier of each sub-product should be same as that of product under which it falls. With this structure, we can define up to 999 Global limit products, 99 types of Products and 99 Sub-products under each product. The lowest level sub product is defined first and then its parent and so on. At each stage, child products under a parent have to be indicated. Thus the relationship is hierarchical, Global being the highest level and sub-product of level 9 lowest. ID

Use

10000

Global

1000

Product

1011

Sub-Product

1

1012

Sub-Product

2


Level

12

1013

Sub-Product


3 etc

12

It is possible to denote a risk perception as FX. This facility will be allowed in FOREX application and enables considering an additional risk element called clean risk, which is also known as delivery risk. The clean risk limit is the maximum allowable value of foreign exchange transactions from the same counterparty to mature on any single day. For example, the Bank may be prepared to have an Overall Foreign Exchange limit of USD 20 million with a given Counterparty, but may want to limit the delivery risk on any one day to USD 5 million. When a limit product is designed as “FX” by using this field, it enables us to indicate the clean risk amount also in a Limit, in addition to overall exposure under the product. It is also possible to denote a risk perception as TB – Time banded. Time banding facility enables different amounts of a limit to be applied to different maturity dates. Limits can be set for time periods to control the exposure by period. This is based on the concept that the further forward the maturity date of a transaction, the greater the associated risk. The full amount of a Limit is therefore available for the most immediate time slice and the amount decreases as the maturity increases. An overall Limit of USD 3 million can be additionally set as USD 1.5 million of that limit is meant for loans of duration upto 6 months, USD 1 million for duration upto 12 months and the rest for periods upto 24 months. This facility is applicable for contract applications involving duration like LD, MM, SC etc.


13

A Money Market line of $300 million may be sub-divided into $150 million for maturity within 3 months, $100 million within 6 months and the remaining $50 million within 12 months. To enter the above into the LIMIT application, the overall $300 million should be entered with a 'blank' time code. The associated multi-valued fields should be expanded to enter the sub-division as follows: TIME CODE

COMMITTED.AMOUNT

3M

150M

6M

100M

12M

50M

If a transaction exceeds the specified period (in this case 12 months) and the referral message is overridden, the T24 will reduce the amount available in the latest band specified (12 months). It should be noted that when a band is not fully utilised it becomes available for use at lower levels. In the example, if the limit for up to 12 months is not used, $150 million (100 + 50) would be available for 6 month contracts. Time bands can be entered in LIMIT application only if its product has the appropriate specification of TB in FX.OR.TIME.BAND Field in LIMIT.REFERENCE parameter table.


14

Risk perception for Deposits should be set with option DP. This is used in LD and MM applications. It is not possible to set a limit for a customer for accepting deposits. Limit is not checked for deposits. T24, by default creates a Limit on its own when a deposit is accepted. Instead, exposure on contracts covered under a DP type of risk is for information purpose only and can be viewed using Enquiry LIAB. Option IN is to indicate that the risk perception is for information purpose only and will not check availability. It will not trigger any override unless CHECK.LIMIT Field in the respective record in LIMIT application is set as Yes. NULL option is used for ACCOUNT and Global products. Input in FX.OR.TIME. BAND Field is allowed only for Products and sub products and not for Global products. While setting records in LIMIT.REFERENCE, the lowest level of sub product is defined first and then its parent and so on. The choice defined for the lowest level should be maintained for all higher products in its hierarchy so that all Products and sub products maintain the same basic attribute.


15

Indicates whether, or not, a type of Limit regains its original value on liquidation or repayment of a utilisation. Let us assume that a Customer is sanctioned a limit of USD 500,000 and avails assistance of USD 400,000 against this limit. The unutilised portion of the limit is USD 100,000. When the customer pays back the assistance, what should be the limit available to him for further assistance? A reducing Limit would permit the customer to draw only USD 100,000 being the un-availed portion. A non reducing limit would however permit him to use USD 500,000 as the limit gets restored by repayments. A reducing limit is also termed as non revolving limit and a non reducing limit is termed as revolving limit. Limit for Overdraft account can be reducing or non-reducing. The entire hierarchy of risk perception, from Global through Product to Sub products should all have the same value – either Reducing or Non reducing.


16

This field allows control over risk involved with Sub-allocation from a Limit product of one type to another. Let us assume that there are three Limit products set in LIMIT.REFERENCE:300 Overdraft 400 L/C s 500 Loans A Bank may perceive that the risk involved in these Limit products runs from Loans (highest) to L/Cs (lowest). So the T24 can be set to allow sub allocation from a high-risk to a lower risk product and not the other way around. The table below shows an example scenario. LIMIT.REFERENCE

GET.SUB.ALLOC

300 Overdrafts

500

400 L/C's

300 and 500

500 Loans

none

This will allow sub allocation from a Loans limit to either LCs or overdrafts and from an overdraft limit to LCs, but not from a limit for LCs to Loans or overdrafts. When a sub allocation is made from one limit product to another, but not


17

defined here, then an override is generated to this effect.


17

When a customer is sanctioned limits for a particular assistance, and the assistance is availed, T24 checks availability of suitable limits and then permits the transaction. When a limit is not sanctioned but an assistance is availed, then T24 generates override to this effect and if duly approved, creates a limit by default. There could be limits meant only for information purpose and not for availability checking. For such limit products, DEFAULT.CHECK Field should be set as 'NO' to prevent overrides being generated. When a default limit is to be created by T24, then is it required to be done at Global or Product level? This choice is relevant for the lowest level of sub product, and where there is no sub product defined, then could be set for a product. LIMIT.KEY.TYPE Field allows values of GLOBAL and PRODUCT for this purpose.


18

It is possible to have a risk perception as a percentage value of the transaction amount to enable Limit to be affected only to this extent of the transaction value. In some business transactions, the risk involved may not be the same as the transaction value. For example, in the case of Derivative products like Swaps, the underlying risk is only a part of the contract value as the downside risk is limited. In a Swap transaction, currencies are exchanged on spot date which have to be re-exchanged on a future date. Even if they are not re-exchanged, risk for a Bank is limited to the difference in prices of currencies and not the entire value. If a Bank feels that risk in such transactions are only 10% of the transaction value, then 10 could be indicated in LIMIT.PERCENTAGE Field. Then, for a contract value of 100,000, limit of only 10,000 will be updated. This field should be used to define the percentage only at the lowest level and hence input will not be allowed for Global products and for Products / Sub products with a reference child. It is always taken as 100% for overdrafts in accounts. For the overdraft, line percentage value other than 100% is ignored and 100% is always used. A percentage value indicated in LIMIT.REFERENCE can be subsequently changed only through LIMIT.CHANGE application.


19


20

Instead of using one fixed percentage of limit calculation for contracts of any duration, it is also possible to have different percentages for different residual maturities. As the residual maturity changes, the limit utilisation will also be updated during Close of business. The multi valued MATURITY.PERIOD Field could be used in an ascending order to define different residual periods needing different Limit Percentages. For example 10% could be set for 1 month, 15% for 2 months and 20% for rest of the period. MAT.PERIOD.PERC Field is used to specify the percentage amount of each period. Residual maturity period can be indicated as Days, Weeks, Months and Years. These should not be mixed together like nnD for the first period and nnW for the second period in the same record. The final value should be indicated as R to cover undefined Rest of the period. If a fixed percentage has also been indicated in LIMIT.PERCENTAGE Field and different percentages are indicated for different maturity periods, these values are added together for calculating utilisation.


21

Choice in LIMIT.BAND.LEVEL Field controls method used to derive limit utilisation. This could be set as Level or Band. Accordingly, either a single relevant percentage from a series of percentage values is chosen under Level option or different percentages are chosen according to different periods and then added up under Band option. Let us assume that 10% is required for residual maturity of 1 month, 15% for 2 months and 20% for the rest of the period and duly defined in LIMIT.REFERENCE for a risk perception product. A 3 month contract under Level option will use 20% at the time of input and 15% after 1 month. The same 3 month contract will use 45% at the time of input and 25% after 1 month under Band option.


22

PERC.CALC.BASIS Field is used to determine how the percentage amount should be derived from MATURITY.PERIOD and MAT.PERIOD.PERC Fields. Choices available here are FIXED, PRORATA and PERIOD. Defaulted value is FIXED. Under this option, the percentage will be a direct percentage of the deal amount. Calculation will be % x Deal amount. PRORATA option indicates that the calculation will be pro rata according to the time remaining to maturity in the case of LEVEL and prorata according to the length of the period in band in the case of BAND choices. Percentage is regarded as % p.a. and year is 365 days. Calculation will be % x Deal amount x days to maturity or days in the band / 365. Calculation for PERIOD setting will be % x Period to maturity / Period, where period is set according to the Maturity period definition, in Days (D) Weeks (W) Months(M) or Years (Y). Where a period is a fraction of a band this will be rounded up.


23

For FIXED calculation, the percentage will be a direct percentage of the deal amount. Calculation will be % x Deal amount. The amount of limit to be affected will be changing in line with the residual maturity period. The amounts will also be different in line with the choice made as LEVEL or BAND calculation.


24

PRORATA option indicates that the calculation will be pro rata according to the time remaining to maturity in the case of LEVEL and prorata according to the length of the period in band in the case of BAND choices. Percentage is regarded as % p.a. and year is 365 days. Calculation will be % x Deal amount x days to maturity or days in the band / 365. The amount of limit to be affected will be changing in line with the residual maturity period. The amounts will also be different in line with the choice made as LEVEL or BAND calculation.


25

Calculation for PERIOD setting setting will be % x Period to maturity / Period, where period is set according to the Maturity period definition, in Days (D) Weeks (W) Months(M) or Years (Y). The amount of limit to be affected affected will be b e changing in line with the residual maturity period. Where a period is a fraction of a band this will be rounded up. In the above example, the amount will not undergo daily changes, but only when the period in months changes. The amounts will also be different in line with the choice made as LEVEL or BAND calculation.


26

It is also possible to derive the limit utilisation from an external routine. The Th e name of this subroutine should be entered in LIMIT.SUBROUTINE LIMIT.SUBROUTINE Field. Whatever be the final limit update calculation, it is possible to indicate floor and cap rates to control these values. When floor and cap rates are mentioned, T24 calculates these amounts as a fixed percentage of the transaction amount. It also does an actual calculation according to choices made in other allocation schedule related fields. It then compares these with the floor and cap amounts, and uses the appropriate amounts.


27


28


29

When the limit and transaction currencies are different, it is possible to use Buy or Sell rates for different legs instead of a uniform middle rate. If BUY – SEL option has been chosen, then rates will be applied as follows: CASE - 1: Limit XXXXXX.400.01 is in Local currency, say USD. A contract for USD100,000 is put through to hit the limit. In this case since both limit and the transactions are in local currency LCY there is no conversion involved and therefore the limit outstanding will be updated with -100,000. CASE – 2: A contract for GBP100,000 is put through to hit the limit given in case1. Here the transaction in GBP will be converted to Local currency which is also the limit currency, using the first component of CONVERT. RATE specified in LIMIT.REFERENCE table for product 400 which in this case is the BUY rate of the transaction currency. If the Buy rate for GBP is 2 then the limit outstanding will be up dated by -200,000 (100,000*2) and the total outstanding in the limit after this transaction will be -300,000. CASE – 3: Limit YYYYYY.400.01 is in EUR. A contract for GBP100,000 is put through to hit this limit. Buy rate of GBP = 2. Sell rate of EUR = 1.4. In this case the transaction in GBP will be converted to USD by using the first component of the CONVERT. RATE which is BUY. This amount will be converted to EUR which is the limit currency, using the second component of the CONVERT. RATE which is SEL. So the limit outstanding will be calculated using the formula 100,000*2 / 1.4 = 142,857.1 EUR.


30


31


32


33


34

While risk perception products are defined as Limit products in LIMIT.REFERENCE with underlying rules for calculating risk, they have to be associated with business products of T24. Business products are defined using five digit codes in CATEGORY table. These business products are handled through several Contract applications and ACCOUNT application. LIMIT.PARAMETER application is used to link the limit products to T24 business products. Fields to be used for linking these two elements have multivalue / subvalue facility and due to this, one to one, one to many and many to one relationships can be easily established. A risk product is associated to a business product by referencing the Application name, business product reference, usually through Category code but not necessarily restricted. Applications may appear on multiple occasions where there is more than one limit product associated with it. It is advisable to define default products to take care of situations when the other product conditions are not met. When market conditions change or the Bank's management decides to reorganise their limit control, due changes in this table will automatically allow and take care of such changes in the limit verification process.


35


36


37

It is possible to produce reports prior to expiry and review dates of Limits to enable taking suitable action. A Bank can choose how many days before these events would the reports be needed. They can be produced upto 99 days prior to these events. This number can be indicated in EXPIRIES.REPORTING and REVIEWS.REPORTING Fields. Country, Commodity and Currency reports are produced by way of batch reports at pre-defined frequency. These reports can be designed to give details of all risk products or only a select few, by naming groups of products and defining which limit products are to be covered under that group. These groups and limit products to be covered there under are mentioned in COM.PRODUCT.GRP , COU.PRODUCT.GRP and CCY.PRODUCT.GRP multi value fields. Product and sub products would however not be allowed to be mixed. For example, it is possible to produce commodity group comprising only of products 100, 200 etc or group of sub products 101,102,201etc. We cannot produce a report comprising 100, 101, 200 etc. Country, Commodity and Currency limits are updated only during close of business and serve as information purpose. It is possible to indicate the upper limit upto which these are supposed to be used. This will help in reports to see how much could still be used under these limits. While defining LIMIT.COMMODITY, it is possible to set for individual products or group of products as defined in COM.PRODUCT.GRP. Similar facility is available for


38

LIMIT.COUNTRY and LIMIT.CURRENCY also.


38

Limits are generally sanctioned by the credit committee and sometimes dates of committee meetings may be such that some of the limits might be expiring before the next meeting. In such situations, it would be required to internally extend the expiry of the limit by a few days so that the limits could still be internally treated as operational but with a suitable message. This is achieved by inputting Administrative Extension Date to be greater than the Expiry date of a Limit. When a limit is administratively extended, number of days defined in ADM.EXTENSION.DAYS Field in LIMIT.PARAMETER will be used by LIMIT application to check that the extension date mentioned in ADM.EXTENSION.DATE is within the stipulated period. Any value between 1 – 360 days can be specified in this field. Default value is None indicating no extension is intended in the Bank. The date input in this field will be used at the time of checking limit as follows: 1. When the Administrative Extension date has been reached, a corresponding override message will be issued online to the user. 2. When the expiry date has been reached but not the Administrative Extension date, then this date will be included as information in the override message presented to the user.


39

Limits are revalued on the date and frequency set up in the REVALUATION.TIME Field. Here a date and cycle to indicate when the first revaluation will occur and at what frequency thereafter is specified. If a date is not input, it is calculated depending on the current date and with the specified frequency. UPDATE.RATE Field specifies whether the user wants rates specified in the CONVERT. RATE Field in limit references to be effective in the revaluation of limit outstanding when the limit and transaction are in different currencies. A value of 'Yes' in this field will mean that the limit outstanding will be revalued online and in batch processing using the rate type specified in the CONVERT. RATE Field in LIMIT. REFERENCE. When the value is 'No' the limit outstanding will be revalued at mid rate irrespective of any rate type specified in the CONVERT. RATE Field in LIMIT. REFERENCE.


40

NET.OUTSTANDING Field is used to define whether, or not, FX contracts are netted before comparison with the respective limit. If No netting is chosen, the full value of the transaction is compared with the limit to ensure that the transaction will not cause an excess. If netting is chosen, T24 will net transactions in opposite sense which involve the same two currencies, which are for the same liability number and which mature on the same date. For example, suppose the following two transactions are in the T24:Buy USD 100,000 Sell GBP 70,000 Value 31/12/08 Buy GBP 35,000 Sell USD 50,000 Value 31/12/08 If Netting is not requested and the limit is 150,000 US Dollars, after the first transaction, 50,000 US Dollars is available. After the second transaction, the Limit is reduced by the US Dollar equivalent of 35,000 GBP. If this gives a figure of 50,000 US Dollars, the Limit availability is reduced to zero. If Netting is desired, the second transaction is subtracted from the first transaction in the middle rate equivalent of 35,000 GB Pounds, giving a net equivalent value of 50,000 USD. This is then subtracted from the Limit to give an available figure of 100,000 USD. It should be noted that the Limit T24 always uses the same bought side of Foreign Exchange transactions for all calculations. Apart from the currency, the sold side is always ignored.


41

When a limit has not been sanctioned to a Customer but transaction is duly accepted with override indicating there is no limit, T24 creates a limit by default. Irrespective of transaction currency, this limit will always be created by T24 in the Currency indicated in DEFAULT.CURRENCY Field. It is not mandatory to indicate risk perception product for deposits. T24 will automatically use the product defined in DEFAULT.DEPOSIT Field for deposit contracts in MM and LD applications in case where specific limit products have not been associated with a deposit business product. This limit product should have been defined in LIMIT.REFERENCE with a value of DP in FX.OR.TIME.BAND Field. T24 will use this only for information. Customer wise limits cannot be created for deposit products manually but T24 uses default product to create a limit. If no specific information product is defined for Money Market Fiduciary Placements, limit product defined in DEFAULT.INFO Field will be used as default. This limit product should have been defined as Information product. If no specific limit product is defined for Money Market Fiduciary deposits, limit product indicated in DEF.FID.DEPOSIT Field will be used as default. This product should have been defined in LIMIT.REFERENCE with a value of DP in FX.OR.TIME.BAND Field. For country, commodity and currency reports, limit products for overdrafts and


42

Nostro balances are identified by limit products defined in DEFAULT.ACCT.LIMIT Field and DEFLT.NOSTRO.LIMIT Field.


42

It is possible to advise an amount as limit allowed to a Customer and record a higher value as internally approved amount for limit processing, which could be used in exceptional cases or as a routine case by the local authorities. It is also possible to indicate maximum secured, maximum unsecured and maximum total limit amounts for limit operations. Choices are available for defaulting values as Advised amount and setting conditions for the amount to be checked – only Advised amount or Advised as well as Internal amount. DEFAULT.ADVISED Field has Null, Internal and Maximum as choices. If set to Null, there is no automatic default. Useful when the Advised amount is going to be different from Internal amount. If set to Internal, always the Internal amount is defaulted as Advised amount also. If Maximum is set, then the Advised amount takes the value of MAXIMUM.TOTAL field in a Limit, which is the overall maximum allowed amount. ADDITIONAL.VAL Field indicates if checking is required in addition to the Maximum total amount of a Limit. If ADVISED is set, the checking will be against the Advised limit also. The advised limit is the one which is communicated and agreed with the customer who has availed for the product.


43

If INTERNAL is set, the amount will be checked against the Internal limits. The internal limit is the one which the bank internally decides that the customer is eligible for (based on the credit worthiness of the customer). If BOTH is set, the amount will be checked against both the advised and the internal limits.


43

When REPORT.MULTIPLE Field is set to YES, then at the time of inputting a contract for the customer, T24 would check for all the possible matches, find whether there are any Limit records in existence. If only one is available then it will be defaulted as the Limit product of the contract. If there are more than one, the user is shown the choices thorough a drop-down list attached to the field LIMIT.REFERENCE in respective transaction. When more than one limit is available to the customer, then it is possible to filter out the limits that can be used based on certain conditions. There are some hard coded filter conditions such as: CHECK.EXPIRED: This can be used to filter out the expired limits CHECK.AVAILABLE.MARKER: Can be used to filter out limits that are not made available, viz the limits whose AVAILABLE.MARKER Field is set as NO. CHECK.DRAW.DATE: Can be used to filter out limits that had crossed their last date for drawing. Last date for drawing can be set earlier to Limit expiry date. Other hard coded filters are : CHECK.CUST.RESTRICT, CHECK.CURRENCY.RESTRICT, CHECK.COMPANY.RESTRICT. Apart from the above hard coded filter fields, we can use any of the fields in LIMIT application in this field for filtering out the LIMIT record of the customer that we wish to use for the transaction.


44

Unutilised portion of a limit could be transferred on a daily basis to a Contingent account of the Customer . This account would then show a negative balance to the extent of unutilised amount to enable collection of charges and / or interest on the negative balance. The Category codes to be used for such contingent accounts is defined in ACCOUNT.PARAMETER. The Customer type of contingent account is to be opened with these category codes and the contingent interest field should be set as non-contingent (B) type indicating interest is collectible. In the Customer’s Limit, the Account number of such account is to be indicated to enable sweeping of unutilised portion of a limit on a daily basis during COB. The negative balance in the Contingent account indicates the unutilised portion of a limit. When a limit is allowed to be exceeded, then there is an excess utilisation instead of non utilisation. A Bank may like to record these also and penalise a customer by way of charges or opting for negative interest for credit balances. If ALLOW.UNUTIL.CR Field is set to Y then overall balance of contingent account may become credit. This could also be held for information. If a Bank decides not to go for such charges, but to record only if there is less utilisation, then the field could be set to N. When limit is fully utilised contingent account balance reaches zero. If limit is exceeded


45

contingent account balance continues to be Zero.


45

Though Limits are generally established for our customers, it is possible to set them for correspondents also. Establishing Limits for guarantees issued on behalf of our Customer is normal. We can also establish limits for guarantees issued in favour of a Correspondent by using a routine. Sample routine MD.CB.LIMIT.UPDATE is available in Model Bank for this purpose which is used for MD.DEAL application. EXT.LIMIT.APP Field should indicate the application, EXT.LIMIT.RTN Field should be used to indicate the routine for calculation and EXT.LIMIT.NO Field should indicate a unique limit reference for the correspondent Bank. For each T24 application, limit entries may be configured to pass to external correspondent limit. Other suitable routines will be needed to be built in the secondary build for this purpose. Though Limits are generally calculated by simple percentage formulas, Forex limits can be calculated or netted by desired complex formula by using routines. For example we may like to have a limit impact equal to 10% of contract value after netting + Customer’s Profit / Loss on outstanding position. A pre-defined routine may be assigned for each FX risk product using LIMIT.REFERENCE and FX ROUTINE Fields. Core routines CALC.FX.PROFIT.LOSS and FX.LIMIT.NETTING.I are available. Other desired routines could be built in secondary build.


46

The order in which these parameter tables should be created is stored within the automated tool for this purpose. For easy reference, reference, the order sequence in the ascending build reference reference order is given in the left. The values required for population of the tables will be obtained from information analysed in TAABS. The mandatory and optional files are shown by red star and blue colour codes. Wherever there are dependencies for filling up values in the parameter tables in build sequence, the dependencies are shown on the right.


47


48

LIMIT LIMIT application is used for creating limits for customers. These limits are created by products. First customer is given limit for loans and the next customer is given limit for forex. In the simplest case a limit is held for one product for an individual customer. customer. A simple limit consists of three components, being Id of the Customer to whom the credit line is made available, the limit product and a serial number. number. This enables more than one limit product for the same customer and more than one limit for the same product. Upto 99 limits could be given to the same customer for the same limit product. For example, we wish to restrict our lending exposure to M/s. Smith and Co. to the extent of USD 30 million. If Customer Id of Smith and Co is 100082 and lending product limit Id is 4000, then, we would input Id as 100082.4000. T24 maintains this Id as 100082.0004000.01. T24 will check this limit whenever a loan is input for Smith and Co to ensure that the loan is within the sanctioned limit amount. Though this limit is not fully utilised, Smith and Co cannot avail assistance under another risk product under this limit. Smith and Co can use this limit only for loans and not forex assistance. Further, Further, if loan assistance is going to exceed the sanctioned limit amount of USD 30 million, override is generated in T24 which should be duly approved. Excess utilisation is suitably shown in the record in LIMIT application.


49

Limits can be sanctioned in one currency and utilised in same or any other currency. For example we may set a loan limit as USD 30 million. This limit could be used to avail loans in USD or even in GBP, EUR, CHF etc. The utilisation amount will be converted at the prevailing middle exchange rate. If a loan of GBP 10 million is availed, and if the exchange rate is 2, the utilisation of limit will be marked as USD 20 million. Normally a limit may be utilised in any currency. However this may be restricted using the ALLOWED.CCY and ALLOWED.AMT Fields or RESTRICTED.CCY Field. Thus, the above limit may be made available to select currencies like USD, GBP and EUR with a further facility of indicating extent of usage in those currencies. Alternately, it is possible to restrict usage of the above limit in JPY and SGD currencies thereby allowing full usage in all other currencies. A limit is only available from the date indicated in ONLINE.LIMIT.DATE Field and is available till the date indicated in EXPIRY.DATE Field. If a limit has crossed the expiry date, but if there are contracts against this limit, then the limit will move to history only after the contracts mature. Warning of approach of expiry date is provided through suitable reports. Through LIMIT.PARAMETER we can indicate the number of days prior to expiry such warning to be included. Temporary extensions are allowed through ADM.EXTENSION.DATE Field provided this is within the setting in


50

ADM.EXTENSION.DAYS Field in LIMIT.PARAMETER .


50

The Bank can initially input a limit even before its client has accepted the facility. In this case a suitable date before which the client should accept is indicated through OFFERED.UNTIL Field. As the client is yet to accept the offer, the Bank may indicate that this limit is not yet available for use by setting AVAILABLE.MARKER Field as N. This is a mandatory field and could be set as N or Y depending on the Bank’s decision to allow usage of limit. It is possible to subsequently change it from N to Y or vice versa. If an Application attempts to make use of a limit when it is not available, suitable override will be generated. If the override is approved, it will still be reported in an exception list produced overnight. This facility can also be used when a Bank wants to temporarily suspend further usage of a limit by its customer. A limit should be available till the last expiry date of any contract using it. But it is possible to put a last date for allowing any contract to draw from the limit. LAST.DRAW.DATE Field is used to indicate a date before which any contract using the limit should be value dated. Then, value date of each transaction/ hitting the limit will be compared with this date. An override will be generated if the transaction date is beyond this date. If the T24 date is beyond this date, but the contract is back valued and is within the last draw date, then override will not be generated.


51


52


53


54


55

At times a Bank may like to sanction a limit amount and advise a lower amount to its customer. A customer might have wanted a lower amount, but the Bank might have carefully analysed the repayment capacity and internally approved the customer for a higher amount. It could still communicate what the customer wanted and allow its branches to top this up as and when the customer needs more limits without coming back to the approving authority. The exposure that the Bank is willing to take is indicated as its internal amount and the amount communicated is indicated as advised amount. If the Bank does not want to follow this, then both these amounts would be the same. It is possible to get values defaulted in ADVISED.AMOUNT Field by suitably setting LIMIT.PARAMETER. This could be the internal amount or the maximum value of secured and unsecured amounts of limit. Further, it is also possible for limit availability to be checked against the advised amount or internal as well as advised amount. This is useful for Banks who would like to maintain different amounts as Internal and Advised. The T24 can then check whether the transaction is allowed under Advised amount itself or if not available under Advised amount it is atleast available under Internal amount.


56

Limit has a review date for first review and frequency set for further reviews. REVIEW. FREQUENCY Field is used for this purpose. In LIMIT.PARAMETER we set the number of days before which a limit due for review is to be reported. Thus, limits are automatically included on the limits due for review reports on the specified dates. A limit sanctioned to a customer in a Company can be used in any other company also. This enables a customer to use his limits anywhere in the Bank instead of getting tied to a particular branch where the limit was sanctioned. However, it is possible to restrict usage by using ALLOWED.COMP or RESTRICTED.COMP Fields. These fields can be multi valued to allow input of more than one company. COB reports are produced to indicate exposure to Currencies, Countries and Commodities. When a limit is sanctioned to a Customer, it is automatically presumed that the exposure is for the residence country of the Customer and to the industry in which the Customer is engaged in and the grade of the limit is equal to the status of Customer. It is possible to change or include more than one value for these and also allocate weightage by means of a percentage. If a Customer is engaged primarily in Agriculture industry, this would be indicated in Customer record and defaulted into limit with 100%. This can be modified or another industry like Dairy could be included and percentage allocations could be specified for these industries. Industry exposure would then be


57

suitably modified and reflected.


57


58


59

The theory behind time banding of limits is that longer the duration, greater would be the associated risk. This type of Limit is therefore approved on the basis that the whole Limit is available for the most immediate time band. The amount available then decreases as the maturity time band increases. Example: A Money Market line for a total amount of USD 100 million may be subdivided into USD 60 million meant for maturity within 30 days, USD 30 million for maturity within 90 days, and the remaining $10 million within 180 days. If this customer wants to avail USD 40 million for maturity of 80 days, it is possible to accommodate as long as the amount under latter time band of 180 days is available. When a band is not fully utilised it becomes available for use at lower levels. To enter the above limit, the overall $100 million should be entered with a 'blank' time code. The associated multi-valued fields should be expanded to enter the sub-division as follows: TIME.CODE field 30 LIMIT.BAND field 60 million TIME.CODE field 90 LIMIT.BAND field 30 million TIME.CODE field 180 LIMIT.BAND field 10 million The example above shows that the bands must be entered in ascending order and the period is always taken as days.


60


61


62


63

A group of companies can have one limit which is split within member companies. A corporate body can have one limit which is split within its branches or departments. Each entity requiring a limit will need to have an individual record in CUSTOMER application. The top of the group is considered as Liability customer for limit grouping purposes and is marked so in its CUSTOMER record. It is also marked as Liability customer for other members of the group. Limits can be held at Group level only or at Group as well as individual levels. The sum of individual limits can be greater than the group limit but the total outstanding of all individual limits is always limited to that of the group limit. Where limits are held at group as well as individual levels, T24 will check that the outstanding is not allowed to overdraw at the individual as well as Parent levels. In the above case, If Company A draws 3 million and Company B draws 4 million, Company C will be allowed to draw only 1 million so that the group limit of 8 million is not breached. The linkage between group and individual limit is the usage of Liability customer. Id for group limit, which is the liability customer would be Liability customer Id + Limit product Id + Serial number. For any member of this group, Id for individual limit will have the Individual customer Id also at the end of the above Id.


64

Where limits are held at group as well as individual levels, T24 will check that a business transaction does not overdraw limits at individual as well as group level. Both the limits will be duly updated. When limit is held only at a group level and not at individual level, group limit is used for individual level transactions also. In this case, it is presumed that all members can avail upto the entire amount meant for the group. As only group level limit is available, T24 updates this limit and also maintains a limit record at the individual customer limit level recording this utilisation. It will however not validate contracts against this limit as it is maintained only to enable setting up a limit at this level at a later date. Only outstanding amount will be updated from time to time here. Advised, Internal and on line limit amounts are kept blank. When Limit is held only at the liability group level, it is available to any customer who is part of the group. ALLOWED.CUST and RESTRICTED.CUST Fields help regulate availability. Limit cannot be created for restricted customers or those not included as allowed customers. If these fields are left blank, then it could be created for any customer in the group. If restriction is at the lowest stage like the lowest sub product or product, business transaction will not be allowed. If the restriction is indicated only at a higher stage, then override is generated at transaction input stage. If override is approved, T24 creates limits by default.. If a value of *ALL is specified in RESTRICTED.CUST Field, then limit


65

would be restricted to all customers.


65


66


67


68


69


70


71

In line with multi level products set up through LIMIT.REFERECE, it is possible to set Global, Product and Sub product level limits for an individual customer or at liability group and group member levels. It is mandatory to indicate products allowed at the Global level and the sub products allowed at the Product level. Only the products / sub products that are indicated as allowed at a group head level can be made available to individual member level. Id structure for the parent and child levels is: Liability Customer Number.Global Reference.Serial Number, 1111.10000.01 Liability Customer Number.Product Reference.Serial Number, 1111.1700.01 Liability Customer Number.Sub Product Reference.Serial Number, 1111.1710.01 Liability Customer Number.Global Reference.Serial Number.Customer Number, 1111.10000.01.1112 Liability Customer Number.Product Reference.Serial Number.Customer Number, 1111.1700.01.1112 Liability Customer Number.Sub Product Reference.Serial Number.Customer Number, 1111.1710.01.1112 Out of these, Liability Customer level Product is mandatory.


72

Multi Level Sub products can be created one below the other. T24 will update the limits from downwards. An unsecured short term loan will go check and update Unsecured short term limit at Sub product level 1, and then Unsecured loans at Sub product level 0 and then Loans limit at product level and finally Global level. At all these levels, limit should be adequately available to allow the transaction to pass through. In case limit is not available at one or more levels, T24 generates suitable overrides to this effect.


73

It is possible for the sum of sanctioned limits of individual companies at each level to be higher than the Parent level – at Global, Product and Sub-products levels. But, at every stage, the outstanding will not be allowed to exceed the individual level for a sub-product, product or Global. Also, at every level, the sum total of outstanding of all the companies will not be allowed to exceed the sanctioned level for the Parent. For example, outstanding of Secured loan for Company A will never exceed 1.5 million, and B 3.5 million and C 1 million. At any stage, the sum total of outstanding under Secured loan from A, B and C will not exceed 6 million. If Company A has already availed 1.5 million, B and C together can avail only 4.5 million, though their individual limits may allow them to avail more. In the case of Unsecured loan, if individual company limits have not been created for Short term and Long term loans, then Companies A and B can avail the same to the extent of 2million and 1 million respectively. Company C can avail Short term loan to a maximum extent of 1.5 million being the maximum fixed for Loan for C and 1 million for Long term loan. This is however subject to the total unsecured limit for the group at any point of time, not being used beyond 2 million and the total loan not beyond 3 million and the individual company limits are also not breached.


74


75


76


77


78


79


80

When a transaction requiring limit is input and if a limit has not been created, override message will be generated stating that this is an unauthorised overdraft. Upon due authorisation, T24 will generate a limit record but without any amount as Internal, Advised or Online limit. Outstanding amount will be shown. Such T24 created Limits will be reported in Limits General Errors Report generated during COB. When a customer belongs to a liability group, and if no limit has been sanctioned either for the group head or for group head and customer, T24 will create this default limit for both levels. Likewise, when limit has not been created for a sub product but created for a product, then the default limit will be created at sub product level. When limit has not been created for sub product as well as a product, then the default limit will be created for sub product as well as product levels. However, the override in all these instances will only indicate non availability of limit at the highest level – product for liability customer in this case.


81

It is possible to schedule increases and decreases to a limit. A Limit of USD 3 million expiring after 3 years could be gradually reduced instead of allowing to expire abruptly. Likewise, where a customer’s needs are envisaged to increase over a period of time, it is possible to allow him lower utilisation initially and scheduled to increase over a period. These increases and decreases could be set to take effect periodically till the end of a stated period or for a indicated number of times. When an increase or decrease is scheduled, it could be set for a particular sub product alone, in which case, while the overall product limit remains unchanged, a sub product alone is affected by increase or decrease. Alternately, this increase or decrease could be set to effect the entire line. If entire line is to be effected, then it could be indicated only at the lower level and not at top level limits. Example : For limit record 100069.0000415.01 with an online limit of USD 1 million, let the parent record be 100069.0000400.01 with an online limit of USD 2 million. If 100069.0000415.01 limit is set to increase every 2 weeks by USD 0.5 million and is also set to increase the full line, then on the increase date, the product line is first increased to become USD 2.5 million and then the sub product line is increased to become USD 1.5 million. This increase will continue every 2 weeks till increase end date is reached. While increase could be set to happen only in limit currency, decrease could be effected as equivalent of any currency.


82


83


84

Sub allocation is temporary transfer of an amount between two limits and is done through LIMIT.SUB.ALLOC application . A transfer from a limit reduces its available value and is called sub allocation given. A transfer to another limit increases its available value and is called sub allocation received. Id of LIMIT.SUB.ALLOC application is SA followed by two digits to represent the year and 6 digits for serial Number of sub allocation of the given year. Example is SA08000001 where SA stands for Sub Allocation, 08 for year 2008 and 000001 is the serial number of sub allocation in the year 2008. It would suffice if a serial number is input as Id. T24 defaults SA and the year. Sub allocations could be effected between limits in the same Company (Accounting unit) or from any other Company of the Bank. SUB.ALLOCATE.FROM Field is used to define the credit line, or sub limit or Company giving sub allocation and SUB.ALLOCATE.TO Field is for receiving the sub allocation . It is possible to do sub allocations between limit lines or limit line and customer. It would suffice if either transferor or transferee is a credit line. In LIMIT.REFERENCE, it is possible to indicate from which limit product sub allocation could be done for another limit product. If transfers are not between allowed products as defined in LIMIT.REFERENCE, T24 will generate override message to this effect.


85

Sub allocation is always for a specific period. On expiry of this period or on expiry of limit, which ever is earlier, the sub allocation is over and the original line gets back the value. What happens when a sub allocation is over, but the transferee line would be over drawn if the sub allocation is reversed as the contracts under that have not been completed or the existing limit of the transferee line is not adequate now? A limit is sub-allocated from Limit line A to Limit line B for a specific period. On the expiry date, T24 follows these rules: 1. If Automatic restoration of sub allocation is opted, then even if Line B would face an excess drawn situation, sub allocation is reversed and restored to Line A. 2. If Automatic restoration of sub allocation is not opted, then on the expiry date, T24 will check whether on restoring the sub-allocation, limit line B would result in excess utilisation. If there is no excess drawing, then the sub allocation would be restored in full. If the restoration causes an excess in Credit line B, then sub-allocation will partially take place to the extent so as not to cause an excess in Credit line B. In this case, the amount will be reduced in LIMIT.SUB.ALLOC file and the expiry date will be revised to next working day to remains the sub-allocation in force. Thus the expiry date is moved by one day and the checks are repeated


86

until the sub-allocation is returned in full.


86


87


88


89

Amendments to basic Limit information may create extensive adjustments and re calculations. Hence, these changes are made to be effected through a separate application - LIMIT.CHANGE. This application could be used to add or change the liability customer of a Customer. Though the field LIABILITY.CUSTOMER is in CUSTOMER application, its value can be changed only through LIMIT.CHANGE application. If a limit has already been used, then its currency could be changed only through LIMIT.CHANGE. When the currency of limit is changed, T24 automatically changes the value of limit into the new currency, by retaining the overall exposure amount. If the currency of a limit of USD 50,000 is changed as GBP and if the exchange rate is 2, then the limit value is changed as GBP 25,000. All amounts like Internal amount, advised amount, outstanding and availed amounts will be suitably changed. Percentage allocation specified in LIMIT.REFERENCE for any limit product can also be changed only through LIMIT.CHANGE application. All these changes can be effected on line by using Function Verify. LIMIT.CHANGE record gets cleared during Close of Business process and


90

LIMIT.CHANGE.HIST record is created with the data from LIMIT.CHANGE.


90

When the liability customer is changed, then existing limits of the customer are deleted if there are no underlying transactions. Fresh limits have then to be accordingly created. If there are any underlying transactions, existing limits are deleted and new limits are created at new liability customer and customer levels. Customer liability change is not allowed for customers having pending sub allocations. The sub allocations should first be brought to a close and then the customer liability changes should be effected.


91

It is possible to reverse a limit only if there is no transaction linked to it. Any utilisation of the limit would be detailed on the contract and recorded under field name LIMIT LIMIT.REFRE .REFRENCE. NCE. Reversal of a Limit is possible only when there are no contracts or accounts utilising the limit. Limits that are no longer required can be cancelled by setting expiry date to current date and marking that they are no more available. If these limits are attempted to be used, T24 will generate suitable override messages.


92

We have so far seen features of unsecured limits. limi ts. All these are applicable for partly secured or fully secured limits. When a collateral is linked to a limit and if the limit is marked as Fixed or Variable, it becomes a secured limit. If no collateral coverage is available, then the Limit is said to be Unsecured or Clean. At times, the value of collaterals collaterals may not cover the limit amount. amount. In this situation, the limit is partly secured. secured. We can indicate the maximum amount upto which the limit could be considered as unsecured. When a limit is marked as Fixed, then limit availability is not directly related related to changing values of collateral. If a limit is marked as Variable, then Online limit availability changes according to changes in collateral value. When collateral value decreases, limit availability decreases and when collateral value increases, limit also increases, but upto the maximum sanctioned amount. More on this are explained in training program on Collateral.


93


94

This table is used to define ranges or lists of Currency or Company codes for allowing or restricting usage in LIMIT application. Records can be defined for either COMPANY or CURRENCY, and may be specified as a list of values, or a series of ranges. These records can be utilised in LIMIT application in ALLOWED.CCY, RESTRICTED.CCY, ALLOWED.COMP, RESTRICTED.COMP Fields. This helps as a short cut in limit definition process. For example, certain limits may be valid only for currencies used in Europe. In such a case, the currencies involved could be grouped here. Id of this record should be used with an asterisk when used in LIMIT application.


95

LIMIT.COUNTRY.GRP table allows definition of Country Groupings. LIMIT.COUNTRY table can then be used to define Limits for Country Groups as well as for individual Countries. For instance if it is required to keep track of outstanding for Commonwealth countries, LIMIT.COUNTRY.GRP table can be used to define 'South America' by linking together the Country Codes which make up that group. Having defined South America, an upper limit amount can then be entered in LIMIT.COUNTRY table for South America. T24 will then keep track of outstanding for this grouping, by means of overnight reports. It is possible to define any group of countries as a country group. Even if South Africa, for instance, is defined as part of America, T24 will not apply any geographical checking or validation. It will only ensure that if a Group name is defined once, it cannot be used again with the same underlying countries in another record. A Country may be included in more than one group as long as the Group name is not defined in the field Group. LIMIT.COMMODITY .GRP table is used to define Industry groupings. LIMIT.COMMODITY table can then be used to define limits for Commodity groups as well as for individual industries.


96

Country limits are limits on total outstanding business that can be conducted with a country. It is a secondary LIMIT based upon the same update mechanisms as client limits. LIMIT.COUNTRY table is used to define Limits by Country or Group of Countries. Groups created through LIMIT.COUNTRY.GRP could be used for this purpose. T24 does not provide real-time information about Country limit utilisation. Instead, a report which shows the country limits and utilisation is produced at the frequency defined in LIMIT.PARAMETER. Country limits can be set against groups of products. For example we can define a group of products called ‘OVERDRAFTS’ and state that the maximum exposure to overdrafts in France is to be 1 billion Euro. Each Limit record is assigned to a country through COUNTRY.OF.RISK Field. It is possible to multi value this field and allot a percentage allocation for each country. If no country is entered, then the residence of customer is defaulted in Limit record.


97

Limits can be monitored against commodities. Thus total exposure to oil industry can be monitored. Limits for commodities are defined in LIMIT.COMMODITY table. Commodities can be grouped in the same way as countries by using LIMIT.COMMODITY.GRP table. For example, if oil extraction and oil refining had been defined as separate industries, they could be grouped together in LIMIT.COMMODITY.GRP as Oil and a single limit to indicate maximum exposure against both these industries could be set up in LIMIT.COMMODITY table. Id of LIMIT.COMMODITY.GRP table could be used as Id of LIMIT.COMMODITY table also. T24 does not provide real-time information about commodity limit utilisation. Instead, a report which shows the commodity limits and their utilisation is produced at the frequency defined in LIMIT.PARAMETER.


98

Limits may be monitored at close of business against individual currencies also. LIMIT.CURRENCY table is used to define limits by Currency. Although this file is maintained on-line, T24 does not provide real-time information about currency Limit utilisation. Instead, a report which shows currency limits and their utilisation is produced at the frequency defined in LIMIT.PARAMETER.


99

T24 has set of standard enquiries on limits. Such enquiries can be viewed for any desired Customer liability number. LIAB enquiry displays summary of limits like details of limit amount, outstanding amount, available amount and expiry date. It is possible to drill down right up to the contract/transaction level using appropriate links.


100

From LIAB enquiry, it is possible to drill down to LIM.TRADE enquiry. This enquiry shows sub product wise break down of top level credit line. From this enquiry, we can further drill down to LIM.TXN enquiry which shows details of contract and accounts covered by a limit.


101

A summary of liability under a Forex Limit for the clean risk exposure is generated in enquiry LIM.FX1. A further drill down of LIM.FX1 will generate LIM.FXTXN schedule containing details of transaction under the clean risk transaction.


102

Reports can be printed at pre defined frequency during COB or on ad-hoc basis. T24 reports on limits include reports on General Errors, Full Liability, expired limits and advance intimation for limits to be reviewed. General error report contains details of limits for which there have been errors, like absence of limit arrangement and limit not available for use. Central liability ledger is a customer-wise report with product-wise and currency-wise liability. Credit lines expired report provides limits that have expired with details of limit currency, amount and balance outstanding and expiry date. Credit lines to be reviewed report is an advance information on limits to be reviewed. Details furnished include limit reference, customer, limit currency, amount, excess amount and excess date.


103

When a transaction requiring limits is input, T24 compares it with the settings in LIMIT.PARAMETER like the Application, Category code, other choices etc and identifies the associated risk product required for the situation. This risk product is pre defined in LIMIT.REFERENCE and may get some basic attributes from the settings there. This includes the percentage calculation, time banding etc. On the other hand, it simultaneously checks the customer and the liability customer. It then checks whether for the liability customer and the customer, limits have been set up for the risk product in LIMIT application. If a limit has been created, it then checks its availability to cover the business transaction. If it is available, it updates the Limit record suitably. In case of absence of suitable limit or inadequacy of limit, T24 generates suitable overrides. If the overrides are duly approved, it creates default limits or allows excess in existing limits.


104

Limits are set for Customers for a particular value in a currency. Hence CUSTOMER and CURRENCY are central to usage of Limits. Limits can be used in any permitted currency. At that time, T24 looks at the mid rate for exchange calculations and converts the usage amount into limit amount for due updating. Country of residence of Customer, his industry and status are used to update information in LIMIT application. Static table of COUNTRY, INDUSTRY and CUSTOMER.STATUS provide these values to a customer record to default into LIMIT application. Risk products are pre-defined in LIMIT.REFERENCE and duly parameterised in LIMIT.PARAMETER to link to business products. All T24 applications make use of limits. In addition to updating utilisation of limits in LIMIT application, T24 also maintains internal files LIMIT.COUNTRY, LIMIT.CURRENCY and LIMIT.COMMODITY . These are used to monitor Country, Currency and Industry exposure by way of close of business reports.


105


106

In Normal limits, if there are two limits 1840.01 and 1840.02 required for a customer, then there would be two distinct Limit hierarchies – (1) 600101.1800.01 with sub product limit 600101.1840.01 and (2) 600101.1800.02 with sub product limit 600101.1840.02. It would not be possible to link the Limits 600101.1840.02 under the same product limit of 600101.1800.01. A hierarchy of multi-level limit products could be specified by defining the sub product levels in LIMIT.REFERENCE and attaching the sub product limit references in the Parent limit references. This Limit structure would apply to all customers, and it would not be possible to modify this structure for a particular customer. Further, it is not possible to input a sub-product Limit without first inputting its parent. These are standard features of a normal limit. It is possible to overcome these by using Cross limit features.


107

Cross Limits provide a flexible structure with consolidation of limits at multiple levels. A Cross limit structure would have three levels only – Top product level, Cross level and another single level for products. There will not be a global line. Under a Top product, there can be several products, but all at the same level. There can be a cross level with different ways of consolidation. These could change from customer to customer also. In the above example, for Top product Loan, there are four different products – Long term secured, Short term secured, Long term unsecured and Short term unsecured. In the normal structure, at installation stage itself, it should be pre-decided whether the Loan product is to be sub-divided as Secured and Unsecured or Short term and Long term. This had to be designed as Sub product Level 0 and accordingly, under the two sub-products, there used to be further sub product levels. Once decided, this structure is uniform for all customers. Under Cross limits, there is no concept of sub-product of different levels. Instead there is a concept of Cross Limit product. The four sub-products under Loan is shown to be consolidated in two different ways – one as Secured and Unsecured and the other one as Short term and long term. For different customers, different consolidations are possible.


108


108

Cross limits provide a flexible limit structure with consolidation of limits at multiple levels, with the hierarchy of limits linked through RECORD.PARENT field. It would be possible to create more than one limit for a product with different sequence numbers and attach them to the same Top product or Cross Limit. This is not possible in case of normal limits. This facility could be also used to define separate limits for a product based on Currency or Company restrictions. For example, to limit the exposure in two different companies, the following limits could be input: 500101.1870.01 with restriction for use in first company and 500101.1870.02 with restriction for use in second company, both with the same record parent of 500101.1800.01.


109

Since processing and validations related to cross limits are different from those of normal Limits, it would be necessary to distinguish at LIMIT.REFERENCE level, whether the Top product and products defined are for normal limit or cross limit. We cannot define a Global product for cross limits. Top products, Cross and product ranges to be used are first defined in LIMIT.CROSS.PARAM suitably. In the next step, they should be individually defined in LIMIT.REFERENCE. As the ranges have been pre defined in LIMIT.CROSS.PARAM, T24 will default the values of TOP, CROSS or PRODUCT while defining them in LIMIT.REFERENCE field.


110

For each Top product in a cross limit, a record should be created with 3 or 4 digit Id in LIMIT.CROSS.PARAM table. This Id should atleast have two zeros at the end. If we want to use 1800 as a Top product in Cross limits, a record with Id 1800 should be created in LIMIT.CROSS.PARAM. It is essential to ensure that that there is no record in LIMIT.REFERENCE with Id in the range of 1800-1899. In LIMIT.CROSS.PARAM, the field TOP.CROSS.REF indicates the last Id usable as a CROSS product. Rest are meant to be used as products only. Thus, for every top product, there can be 99 cross and products under that. We can define a range for cross products and the balance are to be used as products. If the Field Id is 1800, then that is the Top product. If 1840 is defined as TOP.CROSS.REF, then 1801 to 1840 can be used as Cross products. That leaves 1841 to 1899 to be used as sub products.


111

In LIMIT.CROSS.PARAM, when 1900 is indicated in LINKED.REF field with Id 1800, then the range of 1900 to 1999 is considered as linked to corresponding range of 1800 to 1899. There should not have been records in LIMIT.REFERENCE for 1900 to 1999. When a record is created in LIMIT.REFERENCE with Id 1850, it will also create a record with Id 1950 automatically. Extending this functionality, when a value is indicated in LINKED.REF field of an already existing LIMIT.CROSS.PARAM record, T24 would automatically create all the corresponding records in LIMIT.REFERENCE corresponding to the already existing primary records in LIMIT.REFERENCE. If 1950 is linked to 1850, then it is possible to create 198 limits for the same customer for the same risk product, which in this case is 1850 as primary and 1950 as the linked secondary. Ids in LIMIT would be like CCCC.1850.01 to CCCC.1850.99 and continuing thereafter as CCCC.1950.01 as the 100 th limit and going up to CCCC.1950.99. Only 1850 needs to be defined in LIMIT.PARAMETER. It will not be possible to define 1950 as it behaves only as a linked product.


112


113


114


115


116


117


118

If Cross limits is also proposed to be used, then the above build sequence is required in addition to the previous build sequence. If Cross limits only are proposed and not normal limits, then this build sequence will replace the earlier build sequence. The mandatory files are shown by red star. Wherever there are dependencies for filling up values in the parameter tables in build sequence, the dependencies are shown on the right.


119


120


121

It is possible to create cross limits by defining the products and then Top product later or by the opposite way of defining Top product first and then the products. When inputting Limits from top-down, order of input would be Top product limit followed by Cross limits. When a Top product is defined and allowed products indicated, T24 would automatically create records for products with value of Zero. T24 created records would be in INAU status. User can delete or authorise or suitably modify the T24 generated records. It is also possible to input a product limit without inputting the Top product limits first under bottom up approach. T24 will automatically create the Top product limits. Where there are multiple products under a Top product, it is advisable to follow top – down approach.


122

Here TEMGVA represents Temenos Geneva, TEMLON represents Temenos London, TEMNY represents Temenos New York of the illustration; ST, MT and LT represent risk sub products of Short term, Medium term and Long term respectively.


123

Here TEMGVA represents Temenos Geneva, TEMLON represents Temenos London, TEMNY represents Temenos New York of the illustration; ST, MT and LT represent risk sub products of Short term, Medium term and Long term respectively.


124


125


126


127


128


129


130


131


132


133


134

LIMIT.CROSS.USAGE table is internally maintained. It is updated for each Top Product Limit input for a Liability customer in the case of cross limits. It can be used for creating / modifying new limit records. For each Top Top product limit, this table records the sequence number, the cross limits and product limits used and the next cross limit that would be allowed. It also holds the next allowed product limit sequence number. Its Id is Liability Customer ID.Top Product Limit reference Id.


135

We have seen the parameter tables connected with Limits. We have seen major features of Limits like setting limits for customer and customer groups and setting limits at product and sub product levels. We have seen different types of limits like revolving and non revolving, secured, unsecured and partly secured limits. We have seen the difference between fixed and variable limits. We have had hands on experience in sanctioning unsecured limits and viewing various enquiries and reports. We shall look at secured limits in the session on Collateral.


136

Limits-R12.01

Recommend Documents