Limit

The conditions for the Limit are defined at product level and can be negotiated at arrangement level except the Limit Serial field.

If the owner of the arrangement has a credit limit covering this account, the reference to that Limit is specified in the Limit Reference field. The reference must be a valid record in LIMIT.REFERENCE.

If no limit reference is specified and the working balance goes into debit, a message stating 'Unauthorized Overdraft' appears and an override is required before the transaction gets accepted. If a reference is specified, the corresponding Limit record gets checked. If it covers the new working balance, the transaction gets accepted. Else, an override is required before the transaction gets accepted.

The Limit Id can be of the format: Application Code-Julian Date-Sequence of number. (Example - LI20108K5PKF). The features of this limit key type are:

• The limit ID is auto-generated by the system.
• Any number of limits can be created for a customer.
• Supports both shared and non-shared limit structures.
• Supports multi-customer limits.

In a shared limit structure consisting of global, product and sub-product, the child always shares the parent amount, that is, each child limit amount is less than or equal to its parent limit amount. Limit utilisation is on a first-come first-serve basis.

In a non-shared hybrid limit structure consisting of reporting, validation and utilisation, each child limit has its own portion from its parent limit, that is, sum of all utilisation limits is equal to or less than the validation limit.

Refer to the Limits module for additional information.

Multi Party Limit – Jointly Severally Liability

The JS Liable field in the Customer Property Class indicates if the customers are jointly and severally liable when there is more than one customer associated with the sanctioned limit. If this field is enabled, it denotes that the customers are jointly liable.

Read Joint Owned Limits-Limit Structure and Update Approved Advised Limit Umbrella Structure. for more information.

The following section explains the steps to configure a multi-party limit with joint liability.

1. To create a multi-party limit with joint liability, the user must create the underlying product limit references. For a new limit key (Key Type is Txn Ref in LIMIT.PARAMETER), it is possible to create alphanumeric limit reference IDs not exceeding 12 characters.

   

2. The utilisation limits are created first and then they are linked under the validation limits. When multiple products are involved, the limit reference for the child products is created and then linked under the limit reference record for the parent product.
3. The LIMIT.PARAMETER table is updated with the required set of products under the application to which these products belong. When the products are added, only the LIMIT.REFERENCE record IDs of the utilisation limits are added. For the multi-party limits with joint liability, the Key Type is set as Txn Ref in the parameter table. With that setup, it is possible to have the Limit Reference in an alphanumeric format.
4. As a next step, the limit records have to be created with the approved limit amount and all associated customers (multi-party) must be included within the limit to track the joint liability.
5. When the validation limits are created, the system automatically creates the reporting limits for all the associated customers. The reporting limits are created for consolidation of Risk & Exposure Overview reports. These reports show the utilisation at the group level for all the customers included in the validation limits. The group level information is derived based on the relation defined in CUSTOMER.GROUP application.

   

6. Further to the validation limits, the utilisation limits must be defined with the approved amount for the same set of customers. In case of multiple products, utilisation limits must be created for each product individually with the applicable amount.
7. In order to track the joint liability, the Joint Liability must be set as Yes while creating the validation and utilisation limits.
8. When the utilisation limits are non-reducing / revolving in nature, the underlying product conditions must be in sync with the defined limit structure. This is achieved by setting the Revolving attribute to Payment in the Term Amount product condition.

Limit References for LI Limit Keys

In Limit Parameter, the Limit key can be used to indicate the Limit Key structure that is used by the system.

The options are:

• Limit Key - Old Limit key composed of Customer/Liability Id, Product and Serial Number.
• Txn Ref - Both Old and New Limit key structure.

For a Limit Id that follows the LI structure Txn Key can have the Limit Reference values that are either numeric or alphanumeric. Both numerical and alphanumerical IDs co-exist in parallel, but only within separate Limit Product structures.

Single Limit

If an account requires exclusive use of a Limit, this can be defined at the product level in the Single Limit field and negotiated at arrangement level if necessary.

Limit Serial

This can be set to either a valid limit reference serial number or NEW. When NEW is given, system creates a default system maintained limit record for Retail Accounts. Read Retail Account User Guide for more information. At arrangement level, when a serial number is given, there should be a valid underlying limit record with the given limit reference and serial number in the system, else validation error appears.

Limits with Time Bands

The users can link a Time Band Limit Reference to a Limit Product Condition for Account and Lending products. For Lending products, the system passes the maturity date of the arrangement to the limit checking mechanism and checks limit availability and utilisation against the appropriate time bucket. As per standard Time Band processing, arrangements automatically moves between time bands based on where they are in their lifecycle. For Account and Call products, where a maturity date is not present, the system checks limit availability against the first time band of the underlying limit record.

The below attributes are used in Retail Accounts when limit is managed by AA. The Limit Property Class is used to define the suspension (debit balance) criteria for an Overdraft Account. The Overdraft Status, Days and the Suspend attributes are used to define suspension. For example, a bank can decide to suspend all overdraft accounts that are in overdraft status for 90+ days.

Overdraft Status

The status of the overdraft is selected from the drop down. The drop down value cannot contain any duplicate value.

Limit Amount

It specifies the limit amount for limits which are managed from AA. This amount would be mapped to the limit's ‘Internal Amount’ field. The user is allowed to input this field only when Manage Limit is set to YES or Limit Serial is set to NEW.

Maintain Limit Balance

This field indicates if we need to maintain limit balance. If Maintain limit balance is set, Charge Account is not allowed. To know more refer to Limit balances section of Retail accounts userguide.In case of single limit definition, there is no necessity to include a charge account. It can be configured by setting Maintain Limit Balance to YES. For such cases, the limit balances cannot be maintained on a separate account.

Expiry Date

It specifies the expiry date of the limit, which is managed from within AA. The user is allowed to input this attribute only when Manage Limit is set to YES or Limit Serial is set to NEW. It should be a valid date and cannot be less than today.

Review Frequency

It specifies the next date on which the limit is to be reviewed. This field is mapped to LIMIT record linked to the arrangement. The first review date must be earlier than the Limit Expiry Date.

Netting the Limit

If an account does not exclusively use a Limit, the user can specify that any credit balance of the account can be added to the overall overdraft limit available to other accounts with the same limit reference. This is specified in field ALLOW.NETTING where the options are ‘YES’ or ‘NO’.

Tolerance Currency

It specifies the currency in which tolerance amount to be checked. If not specified, then the system uses the local currency to check tolerance.

Tolerance Amount

When the overdue amount is less than or equal to this amount, aging processing will not be done for the arrangement.

Customer OD Status

 This field is used to trigger the overdraft processing if the activity that has made the account go into overdraft has been initiated by the either:

• CUSTOMER - Aging status to be evaluated only for customer initiated transactions
• ALL - Aging status to be evaluated for all transactions
• NULL - No aging will be triggered

Charge Account

Limit Account stores the limit balances. This Account is indicated in the Arrangement using the Charge Account (CHARGE.DEBIT.ACCOUNT)

Days

It specifies the OD period on which the corresponding status in Overdraft Status applies. The overdue range can be defined as number of days, for example, 1 to 30 days, 31 to 60 days, etc. The value defined here is considered as the TO value of the overdue range, the value defined in the previous overdraft status is considered as the FROM value. The values should be defined in ascending order, the values cannot overlap.

Notice Frequency

It specifies the frequency to send chaser notices to customers in a specific ageing status.

Suspend

It indicates if the account has to be suspended upon reaching specific ageing status. It is a flag attribute with Yes or No value. Yes refers that Accounts falling under the overdraft status should be suspended. When the suspension flag is raised for an overdraft status, the flag should be set as Yes for the subsequent statuses as well.

Posting Restrict

The system applies this posting restriction on the account upon reaching specific ageing status. It should be a valid record in POSTING.RESTRICT table. It must be defined for current ageing status if it is defined for previous status.

In bilateral loans, the own bank exposure and the borrower's exposure are the same. However, in case of club loans, where more than one lenders are involved, it is different. So, the own bank exposure is captured in credit limit and borrower's overall exposure is captured in admin limit.

It is necessary for the bank to record the borrower’s commitment exposure for purposes like Sub-limits check, and the cash flow check of the facility and the loans under it. The admin limits are created automatically by the system. It cannot be created manually. The admin limit is a non-reporting limit.

• Admin Limit Ref- Defines the limit reference being used under which the admin limit should be created.
• Admin Limit Serial – Defined the limit reference serial number. The user can only enter the option New. When New input is given, system would create a default system maintained admin limit record, and the limit’s serial number is updated in this field.
• Admin Limit- To capture the Admin Limit ID. The field a no input field. The admin limit is used to capture the borrower's overall exposure. Admin limit is applicable only to Facility product line.
• Cash Flow Check- This field is used to check if the cash flow check is needed or not, at arrangement level. The cash flow check is done based on the borrower’s exposure. Cash flow check is performed based on the future disbursements and repayments scheduled, of the lending arrangements created under that facility, to find the commitment available for the borrower to with draw at any point of time.

Ageing for the overdrawn accounts can be continued into Temenos Transact post migration by capturing the following attributes from the legacy system. When these attributes are captured, the ACCOUNT.OVERDRAWN record gets updated automatically on authorisation of the takeover activity.

Account Overdrawn ID

This is an optional field. When the account is attached to a limit or if the limit is managed by AA, then a record in ACCOUNT.OVERDRAWN is created with the limit as the record ID, else the account reference number is the record ID.

Act Bal Tot Out

It specifies the actual outstanding balance in the account as of previous day prior to takeover.

Clrd Bal Limit

It specifies the online limit amount of the exceeded limit . However for an account without a limit, this field holds the overdrawn balance as on the previous day of the takeover.

Date First Od

It specifies the date on which the first overdraw occurred in the legacy.

Date Last Move

It specifies the date on which the last movement occurred in the overdrawn account or the limit.

Curr Od Start Date

It specifies the date on which the account balance fell below the tolerance amount defined in the limit condition of the arrangement account

Curr Od Days

It specifies the number of days the account is continuously in overdraft below the tolerance amount setup in the limit condition of the arrangement account

Last Od Fee Date

It specifies the date on which the overdraft fee was collected in the legacy.

The Use Secondary Limit and Secondary Limit Amount attributes are reused in two places namely:

• To allow or restrict an account from utilising a Shared Limit: In this context, they could be seen as “Utilise Limit” and “Utilise Limit Amount”.
• To specify Internal Limit in the case of Memo Accounts: In this context, they could be seen as “Internal Limit” and “Internal Limit Amount”.

Secondary Limit Amount

It can be used to specify a restriction on the maximum debit balance that the account can have.If this field is set to ‘0’, this account cannot be overdrawn.

In the case of a shared limit, this would translate into a restriction on this Account’s utilisation of the available balance of the shared limit.

A special Limit Override is raised whenever a Transaction forces the account to breach this Secondary Limit Amount.

Use Secondary Limit 

It is used for better usability of this feature.

• Setting the Use Secondary Limit to No, results in Secondary Limit Amount being defaulted to 0.
• Setting the Use Secondary Limit to Yes, allows the user to capture a value in the Secondary Limit amount field.

Read Working with Credit Checking for more information on secondary limit usage.