Sie sind auf Seite 1von 150

T3TLI - Limits - R10.

Limit module monitors availability and utilisation of Limit. Limit can be


sanctioned at an individual Customer level or at a group level. Customer limits
are monitored on a real-time basis whereas other limits against Currencies,
Commodities and Countries are updated during 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 features of 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.

T3TLI - Limits - R10.1

When a Bank does a transaction with a Customer, it is exposed to different


types of risks 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. 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. This will
enable the clients 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 or revolving limit is maintained at the
sanctioned levels on repayment. In a Limit 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 subproducts under it should also be Revolving.
Customer limits for product and sub products are monitored in real time during
on-line processing. Country, Currency and Commodity limits are monitored
and reported during close of business batch.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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 .

T3TLI - Limits - R10.1

T3TLI - Limits - R10.1

T3TLI - Limits - R10.1

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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
T3TLI - Limits - R10.1

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

1012

Sub-Product

T3TLI - Limits - R10.1

Level

12

1013

Sub-Product

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

17

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

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

19

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

25

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

The amount of limit to be affected will be 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.

T3TLI - Limits - R10.1

26

It is also possible to derive the limit utilisation from an external routine. The
name of this subroutine should be entered in 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.

T3TLI - Limits - R10.1

27

T3TLI - Limits - R10.1

28

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

30

T3TLI - Limits - R10.1

31

T3TLI - Limits - R10.1

32

T3TLI - Limits - R10.1

33

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

35

T3TLI - Limits - R10.1

36

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

38

LIMIT.COUNTRY and LIMIT.CURRENCY also.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

42

Nostro balances are identified by limit products defined in DEFAULT.ACCT.LIMIT


Field and DEFLT.NOSTRO.LIMIT Field.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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
Customers 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

T3TLI - Limits - R10.1

45

contingent account balance continues to be Zero.

T3TLI - Limits - R10.1

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 + Customers 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.

T3TLI - Limits - R10.1

46

The order in which these parameter tables should be created is stored within
the automated tool for this purpose.
For easy reference, the order sequence in the ascending build 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.

T3TLI - Limits - R10.1

47

T3TLI - Limits - R10.1

48

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

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

50

ADM.EXTENSION.DAYS Field in LIMIT.PARAMETER .

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

51

T3TLI - Limits - R10.1

52

T3TLI - Limits - R10.1

53

T3TLI - Limits - R10.1

54

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

57

suitably modified and reflected.

T3TLI - Limits - R10.1

57

T3TLI - Limits - R10.1

58

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

60

T3TLI - Limits - R10.1

61

T3TLI - Limits - R10.1

62

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

65

would be restricted to all customers.

T3TLI - Limits - R10.1

65

T3TLI - Limits - R10.1

66

T3TLI - Limits - R10.1

67

T3TLI - Limits - R10.1

68

T3TLI - Limits - R10.1

69

T3TLI - Limits - R10.1

70

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

74

T3TLI - Limits - R10.1

75

T3TLI - Limits - R10.1

76

T3TLI - Limits - R10.1

77

T3TLI - Limits - R10.1

78

T3TLI - Limits - R10.1

79

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

82

T3TLI - Limits - R10.1

83

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

86

until the sub-allocation is returned in full.

T3TLI - Limits - R10.1

86

T3TLI - Limits - R10.1

87

T3TLI - Limits - R10.1

88

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

90

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

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

92

We have so far seen features of unsecured limits. 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 may not cover the limit amount. In this
situation, the limit is partly 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
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.

T3TLI - Limits - R10.1

93

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

105

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

108

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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 100th 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.

T3TLI - Limits - R10.1

112

T3TLI - Limits - R10.1

113

T3TLI - Limits - R10.1

114

T3TLI - Limits - R10.1

115

T3TLI - Limits - R10.1

116

T3TLI - Limits - R10.1

117

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

119

T3TLI - Limits - R10.1

120

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

124

T3TLI - Limits - R10.1

125

T3TLI - Limits - R10.1

126

T3TLI - Limits - R10.1

127

T3TLI - Limits - R10.1

128

T3TLI - Limits - R10.1

129

T3TLI - Limits - R10.1

130

T3TLI - Limits - R10.1

131

T3TLI - Limits - R10.1

132

T3TLI - Limits - R10.1

133

T3TLI - Limits - R10.1

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

T3TLI - Limits - R10.1

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.

T3TLI - Limits - R10.1

136

T3TLI - Limits - R10.1

137