r08-loans and deposits.pdf

TEMENOS T24

Loans and Deposits

User Guide

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Loans and Deposits

Table of Contents

Introduction.............................................................................................................................................. 3 Application Overview ........................................................................................................................... 3 Setting up the System.......................................................................................................................... 3

Interest Payment Methods ............................................................................................................... 3 Interest Basis.................................................................................................................................... 5 Interest Types................................................................................................................................... 5 Charges, Fees, Commission and Tax.............................................................................................. 7

Application Design ............................................................................................................................. 15 Parameter Files .............................................................................................................................. 15

Overview of Input and Processing ..................................................................................................... 29 Interest Accruals............................................................................................................................. 29 Sundry Deposit............................................................................................................................... 30 Account Receivable........................................................................................................................ 31 Deposits ......................................................................................................................................... 32 Commitment ................................................................................................................................... 34 Loans.............................................................................................................................................. 36 Leases............................................................................................................................................ 40 Bills Discounted and Rediscounted................................................................................................ 42 Schedules....................................................................................................................................... 52 Accounting...................................................................................................................................... 58 Limits .............................................................................................................................................. 60 Third Party Limit ............................................................................................................................. 60 Reports........................................................................................................................................... 61 Enquiries ........................................................................................................................................ 62 Delivery .......................................................................................................................................... 69 Rolling LD contracts ....................................................................................................................... 76 Early Maturing / Partial Repayment of LD contracts ...................................................................... 78 Primary Market Bonds Processing................................................................................................. 83 Bond Cancellation and Repurchase of Accrued Interest ............................................................... 90 PM.LD.PARAM............................................................................................................................... 91 SPF settings ................................................................................................................................... 91 Loan Transfer in Multi-Book environment ..................................................................................... 92 Non-Stop Processing ..................................................................................................................... 99

TEMENOS T24 User Guide of 99

Loans and Deposits

Introduction

Application Overview The Loans and Deposits module (LD) covers the standard product types used in the commercial loans sector. These are:

• Commitment

• Loan

• Deposit

• Account Receivable

• Sundry Deposit

• Leasing and Annuities

Setting up the System

Interest Payment Methods There are two interest methods as discussed earlier, the arrears type and the discount type.

Arrears Type Interest This is a standard method of interest payment, where interest is payable/receivable at the end of an interest period.

Discounted Interest Discounted interest is interest paid at the start of the interest period. The interest calculation is the same as for an arrears interest type, and is not calculated using yield style calculation.

Discounted To Yield By flagging the YIELD.METHOD to YES, the interest may be calculated using the 'yield method' in place of a straight discount. The amortisation of such discount is done based on an effective rate for the respective period over the life of the deal, and also taking into account the Grace Period.

Grace Period If the GRACE.PERIOD is set, the interest or discounted interest will be based on the number of days for the interest period plus the number of days of grace.


Loans and Deposits

Negative Interest Rates For both loans and deposits, if the field NEGATIVE.RATES is flagged to YES, a negative rate can be input in the INTEREST.RATE field. It accepts values ‘YES’, ‘NO’ or Null and will not be an input field after first authorisation. The default value is Null (with the same meaning as ‘NO’). ‘YES’ is not permitted in the following cases:

a) Discounted contract (INT.PAYMT.METHOD set to ‘2’)

b) INTEREST.BASIS set to ‘S’ (special) i.e. direct input of interest amounts

c) Annuity type contracts

d) Capitalisation set to ‘YES’

e) Contract with a value in ‘TAX.INTEREST.KEY’ field i.e. contracts with interest tax

f) Rediscount contracts

g) Commitment contracts (category range 21095-21099)

If set to ‘YES’, input of positive, zero and negative rates with the following restrictions -

Negative interest rates can be input in the following fields:

INTEREST.RATE

MIS.INTEREST.RATE

NEW.INTEREST.RATE (during amendments)

Negative interest rates can be input in the following fields of LD.TXN.TYPE.CONDITION

INTEREST.RATE

Negative interest rates can be input when defining type ‘R’ schedules.

During amendments, field NEW.SPREAD would accept a negative value even if the resulting interest rate were negative.

Note that for floating rate contracts, where the rate from PERIODIC.INTEREST or BASIC.INTEREST plus the value input in INTEREST.SPREAD gives a negative rate, would result in an error where NEGATIVE.RATES is set to ‘NO’.

PERIODIC.INTEREST and BASIC.INTEREST will not allow the direct input of negative rates, but negative contract rates can occur as the result of adding a negative spread.

For the ‘YES’ option, field LIQUIDATION.MODE can only be set to ‘AUTOMATIC’.


Loans and Deposits

Interest Basis There are several Interest Basis types used by LD these are:

Type Days Description

A 360/360 Each month is considered to have 30 days

A1 Similar to A above but with special conditions – see HELPTEXT

A2 Similar to A above but with special conditions – see HELPTEXT

B 366/360 The exact number of days will be considered in respect of the numerator.

C 366/366 The exact number of days will be considered in respect of the numerator.

D 360/366 Each month is considered to have 30 days.

E 366/365 The exact number of days will be considered in respect of the numerator.

F 360/365 Each month is considered to have 30 days.

F1 Similar to F above but with special conditions – see HELPTEXT

F2 Similar to F above but with special conditions – see HELPTEXT

S Special (Special interest basis).

Figure 1 - Interest basis

Interest Types Further clarification of the interest types is required. These can be categorised as follows:

Fixed The interest rate is a ‘fixed’ rate, usually for the life of the loan/deposit. T24 does allow the user to change the rate since market demands require the bank to have a flexible approach. The rate is entered on each individual contract and is maintained manually (if necessary).

It is also possible to change a 'fixed' rate contract type into a 'periodic' type.

Using this type of interest it is possible to enter an interest amount rather than let the system calculate the amount, using an INTEREST.BASIS of S. Furthermore the following functionalities are possible

Ability to define Principal Schedule

Discounted contract

Ability to change Interest Rate & Interest Amount

Ability to change Maturity Date of the contract

Base Rate Where there is an agreement to pay or charge interest at an agreed spread under/over the banks published base rate, the individual contracts are tied to the base rate via a key. When the base rate changes, the interest amounts due are re-calculated automatically.


Loans and Deposits

Periodic Manual This is probably the most used by the Commercial Loan area, as it controls the loans which are tied to LIBOR type rates where the rate is agreed for a fixed period usually of 1 to 6 months. The option to add/subtract a spread is also catered for. As in its name the maintenance is manual, but this normally only involves setting the new rate on the contract. The term of the rate is defined by the ‘R’ type schedules, which are discussed later. This type of contract permits interest bearing and discounted payment methods.

It is also possible to change a 'periodic' rate contract type into a 'fixed' type.

Periodic Automatic Similar to the Periodic Manual, the Periodic Automatic is designed for banks that operate a large number of deposits that clients have given standing instructions to be rolled every few months at a LIBOR type rate. The benefit to the bank is that the dealer maintains the PERIODIC.INTEREST table and the deposits pick up the new rate automatically and generate the necessary accounting entries and advices. Even after a particular rate has been picked up from the PERIODIC.INTEREST table and processed by the contract, it is possible to revisit the table and make changes to rates in the past. The contracts will then recalculate interest based on the changed rates. It is also possible to define an overriding rate for a Periodic Automatic contract if required, by entry of the rate with the ‘R’ type schedules.

It is enabled for Discounted contracts as well. The only constraints being Rate Change Schedule (R schedule) can only be defined on Interest schedule date. Also Principal/Spread changes are allowed only within the current Interest periods. All other features of Fixed rate Discounted contract apply for Periodic Interest as well. Discounted contracts are still prohibited for Floating rate/Periodic Manual types.

Periodic Straight This option is a cross between the Fixed rate type and the Periodic Manual. The user is given the flexibility to add a spread and to change the rate when required manually. This type of contract permits interest bearing and discounted payment methods.

Interest rate type is enabled for ‘S’ basis contracts as well.

Interest on Repaid Amount in Loans The field INT.COLL.METHOD is used for collection of interest only on principal instalments which are being repaid. If this field is set to REPAY.AMT, whenever a principal amount is being repaid, interest will be collected concurrently only on that portion of the principal which is being repaid. Such interest is collected for scheduled repayments or ad-hoc repayments.

Note that this field cannot be used for Deposit, Call/Notice, Annuity or Commitment type of contract, and no I or combination of I schedules are allowed on LD.SCHEDULE.DEFINE. Also S basis interest is not allowed as well as the interest payment method cannot be discounted.


Loans and Deposits

Charges, Fees, Commission and Tax The Loans and Deposits applications allow a wide variety of charges, fees and commissions to be taken during the life of the contract.

Charges Charges are received from the client. Charge types are defined in the application LMM.CHARGE.CONDITIONS, and should be specified with the PAY.RECEIVE flag set to RECEIVE to indicate that the bank receives the charge. The record can be linked to the standard charge and commission tables, FT.CHARGE.TYPE and FT.COMMISSION.TYPE if required, so that charge amounts can be defaulted.

Charges can be taken on-line or as scheduled events, see the section ‘Early Maturity Penalties’ for further details.

Fees Fees are paid to the client of the contract. Fee types are defined in the application LMM.CHARGE.CONDITIONS and should be specified with the PAY.RECEIVE field set to PAY, to indicate that the bank pays the fee. The record can be linked to the standard charge and commission tables, FT.CHARGE.TYPE and FT.COMMISSION.TYPE if required, so that fee amounts can be defaulted.

For drawdown issue fees the FT.CHARGE.TYPE / FT.COMMISSION.TYPE key may be specified directly in the field DD.FEE.CODE.

Fees can be taken on-line, or as scheduled events, see the sections ‘Drawdown Issue Fees’, ‘Paying Fees To Agents’ and ‘Multiple Charge Schedules’ for further details.

Commissions Commission may be taken on loan contracts (CATEGORY 21050 - 21089), in a similar method to interest. A commission rate is specified in the field COMM.RATE together with the day basis in the field COMM.CALC.METHOD. The commission is calculated based on the Outstanding Principal or on the highest balance for the period using the specified rate, and is payable at maturity by default, or on specified dates defined in the LD.SCHEDULE.DEFINE screen using a ‘C’ type schedule. The calculation of commission on highest balance basis is performed if the setting in the field CSN.CALC.TYPE is HB.

The commission may be paid by the customer, or paid by the bank. This is identified by the field COMM.PAYMT.METHOD which can have three values:


Loans and Deposits

Interest Bearing

This is commission paid by the customer at the end of the commission period and will be debited from the COM.LIQ.ACCT.

Discounted

This is commission paid by the customer at the start of the commission period and will be debited from the COM.LIQ.ACCT.

Payable

This is commission paid by the bank at the end of the commission period and will be credited to the COM.LIQ.ACCT.

Tax Tax can be deducted or added if required on the interest amount, commission amount and principal at contract initiation and subsequent principal increase. The tax rates are defined in the TAX application, the keys used should be defined in the fields TAX.PRINCIPAL.KEY, TAX.INTEREST.KEY and TAX.COMMISSION.KEY respectively, and the amount of tax to be taken is held in the fields TOT.INT.TAX, TOT.COM.TAX and TOT.PRINC.TAX.

Figure 2 - Tax details of loan record


Loans and Deposits

The system table APPL.GEN.CONDITION can be used to define a series of conditions and calls to locally developed subroutines which can be used to determine a contract group code which will automatically update the CONTRACT.GRP field whenever the contract is changed.

The section ‘APPL.GEN.CONDTION’ in the chapter ‘System Tables’ has a fuller explanation of the use of the contract group code.

It is possible to define a generic tax type in TAX.PRINCIPAL.TYPE, TAX.INTEREST.TYPE and TAX.COMISSION.TYPE as opposed to the specific tax keys described above.

The system table TAX.TYPE.CONDITION allows contract group codes to be defined in relation to tax types and specific tax codes.

The tax type together with the contract group code will be used to determine a specific interest tax code for the contract. If changes to the contract result in a different contract group code being generated then a new tax code could be generated.

Suspension of Income It is possible to suspend income on the LD deal when the underlying Past Due contract changes status to NAB. In order to invoke this functionality, the SUSPEND.INCOME field in the relevant PD.PARAMETER record may have to be flagged.

If REV.PL.AT.NAB is flagged to YES in the relevant PD.PARAMETER record, interest due and remaining uncollected (IN portion in PD) as well as interest accrued and not due on the LD would be reversed along with penalty income and spread.


Loans and Deposits

Accrual and Amortisation of Charges, Fees and Commission The field MTHLY.AMORTISATION in the LMM.CHARGE.CONDITIONS record indicates that Fees and Charges may be amortised during the life of the contract. When set to Y to indicate amortisation is required, the period for amortisation must be defined in the field AMORTISN.PERIOD. This can be set to indicate that the amount is to be amortised over a fixed period (either months or years), up to the next rate change, or over the remaining term of the contract.

Charges/Fees can be accrued or amortised by setting the below fields in FT.COMMISSION.TYPE and linking the same to LMM.CHARGE.CONDITIONS.

ACCRUE.AMORT

A – to accrue

M – to amortise

ACCRUAL.FQU

D – for daily accrual / amortisation

M – for monthly accrual / amortisation

AMORTISN.PERIOD defines the START.DATE and END.DATE in EB.ACCRUAL record created for accrual / amortisation.

The values in the field AMORTISN.PERIOD can be:

C - until end of contract

nM – for n number of months

nA – for n number of years

R – until next schedule


Loans and Deposits

For charges defined as schedules in LD.SCHEDULE.DEFINE, the start and end dates are as below: AMORTISN.PERIOD

ACC/AMORT START DATE END DATE

R Accrue If previous schedule of same type exists, then schedule date is the start date. Otherwise it is contract value date.

Schedule date

R Amort Schedule date Next schedule date of similar type. If there is no similar schedule, then end date is maturity date of contract.

C Accrue Value date of contract Schedule date

C Amort Schedule date Maturity date of contract

nM Accrue ‘n’ number of months before schedule date. If it is earlier than value date, then start date is the value date of contract.

Schedule date

nM Amort Schedule date ‘n’ number of months after schedule date. If it goes beyond maturity date, end date is maturity date of contract.

nA Accrue ‘n’ number of years before schedule date. If it is earlier than value date, then start date is the value date of contract.

Schedule date

nA Amort Schedule date ‘n’ number of years after schedule date. If it goes beyond maturity date, end date is maturity date of contract.

If there are 2 schedules with same charge code on same day, system will generate EB.ACCRUAL only for one charge and the other one will be taken straight to P&L.

It is also possible to reverse the earlier accruals / amortisation and rebook them daily by setting up ACCR.REV.PARAM. For more details, please refer to “INTEREST AND CHARGES” user guide.

Commissions are accrued in a similar manner to contract interest; the categories used are defined in the LMM.INSTALL.CONDS record. The frequency for accrual is the same as the relevant interest accrual frequency.

Note that there is no facility to accrue or amortise tax amounts.


Loans and Deposits

Multiple Charge Schedules

Multiple charges and fees can be associated with schedule types. The calculation amount can be specified in the CHG.BASE.AMT field as shown above.

Valid input to this field may be as follows:

Figure 3 Valid input to the CHG.BASE.AMT field

Fees and commissions can be defined linked to a schedule type by specifying the correct LMM.CHARGE.CONDITIONS code in the CHRG field together with the associated CHG.BASE.AMT. Separate Fee and Commission schedules may also be defined using a type “F” schedule with the associated LMM.CHARGE.CONDITIONS code.

The CHG.BASE.TYPE used will determine the account, which is to be used to pay/receive fees and charges as follows:

Figure 4 - CHG.BASE.TYPE

Charge and fee codes may be linked to FT.CHARGE.TYPE or FT.COMMISSION.TYPE.

Charges and fee amounts may be amortised over the lease contract life if required. It is therefore a straightforward process to set-up various charging mechanisms to cover such items as insurance which are to be borne by the customer and as a consequence can be added into the lease.

The following screen illustrates how a charge can be added into a lease agreement by updating the schedule. In this instance the charge is linked to a flat amount (insurance to be charged monthly, for example), which is defined on the FT.COMMISSION.TYPE file.


Loans and Deposits

Figure 5 - Add a charge into a lease agreement by updating the schedule

Enquiry indicates the result of the addition of the monthly charge as follows:

Figure 6 – Enquiry : LD.BALANCES.SUM

Interest Tax Relief There is the facility within the LD module to apply tax relief to interest payments for certain types of loan contracts.

Tax relief does not use the TAX.INTEREST.KEY or TAX.INTEREST.TYPE fields on an LD contract as interest tax does; instead interest tax relief can be set up by using the CHARGE.CODE field on LD.SCHEDULE.DEFINE, containing the ID of a record in LMM.CHARGE.CONDITIONS. The LMM.CHARGE.CONDITIONS record should be set up with the PAY.RECEIVE field set to PAY and the TAX.RELIEF.FLG set to Y.

It is not possible to set up tax relief without defining schedules, so the DEFINE.SCHEDS field on the LD contract must be set to YES.


Loans and Deposits

Figure 7 – LMM.CHARGE.CONDITIONS for Tax Relief


Loans and Deposits

Application Design

Parameter Files

LMM.INSTALL.CONDS This table holds the accrual dates/cycles for both the LD and MM (Money Market) modules together with the P/L accounts that will be used. The modules allow for the definition of separate accrual cycles for local and foreign currencies. It is also possible to set complex P/L account structures, which will provide improved audit information for the bank’s accountants.

Figure 8 - LMM.INSTALL.CONDS record


Loans and Deposits

Figure 9 - LMM.INSTALL.CONDS record (cont.)


Loans and Deposits

LMM.ADVICES This table controls, for each LD category, the advices that are to be produced and the format to use. This allows the bank to define its own categories of LD contracts and the format of advices to be used.

Advices are linked to ‘activities’ in LD. Activities are defined on the LMM.ACTIVITY application. Example activities are ‘contract initiation’ and ‘change of interest rate’. The LMM.ADVICES record can specify whether or not advices are to be generated and sent to the counterparty for NONE, ALL, or SOME of the activities that may occur during a contract’s life.

The field FORMAT.CATEGORY enables each LD category to produce, if required, specialised advices and confirmations through the Delivery module. If this field is left blank then T24 will produce a default format advice. However, input in this field can enable special formatting records in Delivery (DE.FORMAT.PRINT) to be used. For further details see the section on Delivery later in this chapter.

Figure 10 - LMM.ADVICES


Loans and Deposits

LMM.ACTION.CODES The action codes are pre-supplied and are used in the accounting and delivery advices produced by the LD module.

Figure 11 - LMM.ACTION.CODES

Example action codes are as follows.

Figure 12 – Enquiry : LMM.ACTION.CODES


Loans and Deposits

LMM.TEXT

Defined in ACCOUNT.CLASS is a debit and credit suspense account to be used by the LD module. By using LMM.TEXT there are 18 texts (9 credit and 9 debit) that can be printed on advices whenever a suspense account is used. By typing ‘1’ in the drawdown account field on a loan, the credit suspense account is used for the credit, and the first text string is displayed. If the ‘1’ is input in the drawdown of a deposit, the debit suspense account will be used together with the debit text string.

Figure 13 - Example of LMM.TEXT usage in LD input


Loans and Deposits

LMM.CHARGE.CONDITIONS

This table specifies the charges and fees that can be applied by the system.

Charges paid by the customer can be defined by setting the PAY.RECEIVE field to RECEIVE.

Fees paid by the bank can be defined by setting the PAY.RECEIVE field to PAY.

Fees and Charges may be amortised if required; this is indicated by setting the field MTHLY.AMORTISATION to YES. The period over which the amortisation takes place may be one of the following defined in AMORTISN.PERIOD:

Figure 14 - Values of period over which amortisation takes place

If the fee or charge is to be calculated automatically, the record should be linked to the FT.COMMISSION.TYPE or FT.CHARGE.TYPE applications by specifying the key in the field CHARGE.CODE.KEY. If the record is not linked to these applications, the fee or charge amount must be entered in LD.LOANS.AND.DEPOSITS or LD.SCHEDULE.DEFINE applications.

Figure 15 - LMM.CHARGE.CONDITIONS record


Loans and Deposits

LMM.ACTIVITY The activity codes are used in the accounting and delivery advices produced by the LD module. They are pre-defined by T24.

Figure 16 - LMM.ACTIVITY

The following list shows some typical LMM.ACTIVITY codes supplied and used by T24.

Figure 17 - LMM.ACTIVITY Codes supplied by T24


Loans and Deposits

LD.GROUP.CONDITION The LD.GROUP.CONDITION application defines special conditions applicable to specific groups of customers or an individual customer. The @ID of LD.GROUP.CONDITION must be a group defined in the APPL.GEN.CONDITION record of LD.LOANS.AND DEPOSITS.

This table may also be used to define conditions applicable for a specific customer. In such case, the @ID of the file should be C-Customer reference (E.g. If the customer number in T24 were 100112, the ID would be C-100112).

The following special conditions may be defined in this table:

Interest Spread - Loans

This would define the additional spread that will be added to derive the interest rate for a loan contract of this group / customer. This might be input as a positive or negative absolute value.

Example - Rate in BASIC.INTEREST table for ID 1 = 10%. Spread defined in LD.TXN.TYPE.CONDITION table for 21050 = 2% and for 21051 = 1%.

Supposing the value mentioned in this field for this Group is “-0.50”, then the derived rate for a loan under the category 21050 for this customer would be 10 + 2 – 0.50 = 11.5% and for loans under category 21051, it would be 10+1-0.5 = 10.5%.

Along with this field the user would be able to define the effective date for such change. Such effective date may be forward, backward * or equal to process date.

Interest Spread - Deposits

This would define the additional spread in case of deposits for this customer/group. Separate fields are specified for loans and deposits, as the spread might be positive for deposits and negative for loans for favoured customers.

Along with this field the user would be able to define the effective date for such change. Such effective date may be forward, backward * or equal to process date.

* When the effective date is back-valued, the rate change is applicable only for the current interest period, in the same lines as BASIC.INTEREST change.

Change of spread either for loans or deposits would update all existing contracts for the customer / group during the COB process. Such revised value will be used for defaulting the spread for any fresh deal


Loans and Deposits

Apply.Curr.Deals

With options of YES and NO. If YES is chosen, revised interest is applicable for existing as well as new deals input. If NO is chosen, such change is applicable only for fresh deals input in the system. This field is only input if new rates are defined in INTEREST.SPREAD.LOANS or INTEREST.SPREAD.DEPOSITS.

Charges and Commissions

The extent of charges and commissions (as defined in LD.TXN.TYPE.CONDITION) that is to be taken. Similar to exchange spread this is an associated multi-value field with the CHARGE/COMMN.TYPE, and for each charge or commission, the extent to which the customer is to be charged is mentioned.

Example - CHARGE.CODE in TXN table is CACT01 with a flat charge of 1,000. Definition in the group condition table is as follows:

CHARGE/COMMN.TYPE - CACT01 CHARGE/COMMN.PERC - 50%

In this case the charge amount defaulted in the deal for the customer would be 500 (50% of 1,000).

Figure 18 - APPL.GEN.CONDITION


Loans and Deposits

Figure 19 - LD.GROUP.CONDITION

Figure 20 - LD.TXN.TYPE.CONDITION


Loans and Deposits

Figure 21 - LD CONTRACT

Figure 22 - LD CONTRACT-1


Loans and Deposits



From the above screenshot, the CONTRACT.GRP has defaulted to ‘1’ to which the customer belongs. For the product category of 21051 LD.TXN.TYPE.CONDITION an interest rate of 10% was defined. A preferential spread of –1 was defined for this group in LD.GROUP.CONDITION. At the deal level a rate of 9% is applied for this customer. Similarly the appropriate charges have also been defaulted.


Loans and Deposits

LD.TXN.TYPE.CONDITION The set of rules governing the specific category of the deal may be defined in this table. Here the user may define the minimum and maximum values for the term of the contract, the drawdown amount, and the default interest rate (or key plus spread), accrual rule, commission, charges etc for each currency within a specific product category. The default value for the start of day maturity may also be input here. These values would be defaulted on to the LD deal and are changeable at the deal level. The contracts initial draw down amount and term are validated against the inputs in the TXN table and appropriate overrides are generated at the deal, if exceeded.

Figure 25 - LD.TXN.TYPE.CONDITION record for Customer Loan

For liquidations in a currency other than deal currency, the default CONVERSION.TYPE and SETTLEMENT.MARKET may also be defined in this table.

Figure 26 - LD.TXN.TYPE.CONDITION


Loans and Deposits

It would be possible to define tolerances for the user-input amount in the case of Certificate of Deposit (CD) type of products. For CD's the user may input a value in MAT.AMOUNT and let the SYSTEM default the AMOUNT based on the term and interest rate. If a card rate were available, the AMOUNT as well as the MAT.AMOUNT may be input. In order to protect typographical errors in input, tolerances on the SYSTEM calculated amount could be defined either in terms of absolute values or percentage formats. Should the user input value in the AMOUNT field exceed the tolerances, an error message is shown at the deal.


Loans and Deposits

Overview of Input and Processing

Interest Accruals Interest on an LD deal is calculated for the period of the deal, from value date to maturity date.

Normal interest calculation includes the first but not the last date. However the normal Interest calculation and accruals can be overridden by the settings in the field ACCRUAL.PARAM. This field is available in the LD.TXN.TYPE.CONDITION table as well as on the LD transaction in order to define different rules for loans and deposits (if so desired), which will be defaulted on to the deal. The value is defaulted to changeable, at the deal level and an override is produced when changed.

The accepted values in the field should be a valid value from the EB.ACCRUAL.PARAM table which is defined below.

Figure 27 – EB.ACCRUAL.PARAM

The above example shows the interest accrual rules for the Japanese RYOHA style of interest. This particular parameter defines that the number of days of interest should include both the first and the last day, and if any repayment is done, the next interest period starts from Repayment Date + 1.

The use of the EB.ACCRUAL.PARAM table allows the user to define whether a routine is to be used, Include Start Date or not, Include Last Day or not. Furthermore, + or - adjustment of no days can be specified for Principal Increase or Decrease.

The ROUNDING.RULE at contract level allows the User to define the rule which is used for rounding underwriting fee, facility fee, interest and charge amounts calculations apart from rounding rules specified at currency level. This can be defaulted from the LD.TXN.TYPE.CONDITION for the category. However if no rounding rule is specified by the user or defaulted, then the rounding rule given at EB.ACCRUAL.PARAM if exists, is used, else the rules at currency level takes precedence.


Loans and Deposits

Sundry Deposit As previously stated these are ‘interest free’ deposits either for a fixed duration or at call. The numbers of fields from the LD main file that are required are minimal; therefore VERSION records are used for the input of Sundry Deposits.

Input To record a Sundry Deposit is very simple; the only values required are the customer, currency, amount, accounts and the duration. If the maturity date is unknown the contract can be input as ‘call’, however since there is no interest element there can be no definition of ‘notice’ contracts.

In our working example we will work through the following scenario:

As a result of an incoming transfer the bank has received USD 3,000 for our client William Gates, unfortunately he has no USD accounts and is known to be on vacation for the next three weeks.

Figure 28 - LD Sundry Deposit

The contract debits the Nostro account, and pending receipt of where the customer wants the money, it will be repaid through the internal suspense account. The contract will remain on the system until the maturity date is changed.

Changes Using the example Sundry Deposit from the previous section we have now received notification that the customer wants the money credited to his newly opened USD Savings account. So we need to change the repayment account and mature the contract. The same input VERSION can be used since the only changes required are to the maturity date field and the repayment account field. The limitations for these changes are that the maturity date must be equal to or greater than today. Since there is no interest element, the effect of the maturity date on the contract is not important. If the bank considers that the credit to the clients account is important, either the FT or DC module should be used to correct the value date for interest purposes on the newly opened savings account. This is of course subject to the banks discretion.


Loans and Deposits

Account Receivable These are ‘interest free’ loans either for a fixed duration or at call. The numbers of fields from the LD main file that are required are minimal; therefore we have supplied VERSION records that can be used for the input of Account Receivables.

Input Recording an Account Receivable is just as simple as the Sundry Deposit, with the main values that are required being, the customer, currency, amount, accounts and the duration. If the maturity date is unknown the contract can be input as ‘call’, however since there is no interest element there can be no definition of ‘notice’ contracts.

In our next working example we will work through the following scenario:

As a result of a charge incurred by our client William Gates, we have to cover a shortfall on his savings account for one week.

Figure 29 - Account Receivable input

Change A typical change here could be that the client requires a further extension and the user need only amend the maturity date field.


Loans and Deposits

Deposits Deposits are normally of a fixed period with the interest and principal being paid at maturity. However, the user has the option to create call or notice contracts and additionally set payment dates for the settlement of interest and/or principal at dates other than maturity.

Input

Figure 30 - Example of Deposit input

The typical changes that users wish to make on deposit contracts can be accommodated very easily in the LD module. Breaking of contracts may require the change of the interest rate as well as the maturity date itself. Contracts can be extended or amended from call/notice to fixed or from fixed to call/notice. A number of VERSION records exist to assist the user when making simple or specific changes to their contracts, like amending the settlement accounts.


Loans and Deposits

Figure 31 - Using a Version for amending a Deposit input


Loans and Deposits

Commitment The commitment product can have many forms; the commitment can be revolving or non-revolving. Fee calculation can be based on the original or the unused amount of the commitment amount. There can be a grace period at the start and end of the commitment and drawdown amounts against the commitment can be specified.

We show a simple commitment contract below and a drawdown against it as an example loan contract.

Input The example below shows a straightforward commitment contract. Note the start and end dates for fee calculations differ from the contract start and end dates.

Figure 32 - Inputting a Commitment using Version LD.LOANS.AND.DEPOSITS,Com LCU.CALC.BASE accepts new values TO (Tranche Original),TU (Tranche Unused), O (Original) and U (Unused). If value TO or TU is input in this field, D.D.START.DATE and D.D.END.DATE can be multi-valued and individual tranche amount and its validity may be defined. TRANCHE.AMT defines the amount of each tranche, which is associated to the start and end date fields.

Values NC and RC are allowed in L.C.U.TYPE. These determine whether the residual balance that has not been drawn, is allowed to be carried forward or not after the expiry of the D.D.END.DATE.

If LCU.CALC.BASE is set to TO, COMMT.AVAIL.AMT is updated only on the first D.D.START.DATE and not on VALUE.DATE. Loan withdrawal before this date is not possible under the commitment (unless the dates are re-defined in the commitment record). Fee on commitment will be based on the value in COMMT.AVAIL.AMT.

If LCU.CALC.BASE is set to 'T' and L.C.U.TYPE has a value of either 'R' or 'N', withdrawal of loan after the expiry of the last D.D.END.DATE in the commitment record is not permitted.


Loans and Deposits

Changes Though changes to commitment contracts are possible, they are not normal. However, T24 does not restrict the user from changing fee rates, maturity dates or amounts. The only exceptions are where drawdowns have been made. In these circumstances the commitment amount and period cannot be less than the current drawdown amounts and dates.

Schedules If the commitment contract will not be drawn against, it is possible to define a series of ‘P’ schedules using the LD.SCHEDULE.DEFINE screen,

a. to reduce the notional principal amount

b. to repay capitalised interest

A commitment can be flagged as a non-drawable commitment by setting the field COMMIT.DRAWING to NO. This can be used where the commitment is updated manually to mirror the effect of contracts, which are associated with the commitment, though are not linked through the LD.LOANS.AND.DEPOSITS application.


Loans and Deposits

Loans The major part of the LD module is to cater for the many different types of loans that each user bank may offer. Use of alternative VERSION records and advices allows the user to set specific loan types using the category codes on the system to reflect the different products. These can then be reported by the category code in the banks General Ledger.

Input Using a drawdown against a commitment the example below illustrates a simple loan contract. The LD module allows for much more complex stand-alone loans which can have payment schedules, interest settlement frequencies, rate change frequencies, LIBOR or Base rate options as well as discounted product types.

Figure 33 - Drawing under a Commitment using Version LD.LOANS.AND.DEPOSITS,Drw


Loans and Deposits

Figure 34 - Discounted Loan input using Version LD.LOANS.AND.DEPOSITS,ADL

with Yield Method as NO


Loans and Deposits

Figure 35 - Discounted Loan input using Version LD.LOANS.AND.DEPOSITS,ADL

with Yield Method as YES Examples of a discounted loan with different Yield.Method are also shown here to highlight how the different VERSION records accommodate the banks differing requirements.

Note the different calculation of the interest. This is due to the Grace Period being taken into the Yield computation.

When YIELD.METHOD is set to YES, the value in the AMOUNT field is taken as the repayment amount (or the bill face value, if a bill is discounted). The amount to be disbursed to the customer (net amount) is arrived at using the following formula

Net Amount = Repayment Amount / (1+ (I * N)/(X * 100))

I = rate entered in the INTEREST.RATE field

N = number of days between the VALUE.DATE and the FIN.MATE.DATE (grace period does not

form part of this period)

X = the denominator of the interest basis used


Loans and Deposits

Consider above example

Amount = 1,000,000

Value date = June1st, 2003

Final maturity date = July 1st, 2003

Interest rate = 10%

Interest basis = B (366/360)

Grace period = 5 days

Yield method = YES

N = 30 days (exclusive of grace period) but 35 with grace period

Using the formula given above, the net amount (inclusive of grace amount) is

=1,000,000 / (1+ (10 * 35)/(360 * 100)) = 990, 371.39

The total interest amount is 1,000,000 less 990,371.39 = 9628.61 (inclusive of grace period interest)

The effective rate is calculated using 35 days =

9628.61 * 360 * 100 / 1000000 * 35 * 10 = 9.90371%

The grace period interest is therefore = 1,000,000 * 9.90371 * 5 / 360 = 1,375.52

Therefore the total interest (TOT.INTEREST.AMT field) after factoring in the grace period works

out to 8264.46 + 1377.41, which is 9,641.87

Changes The typical changes that users wish to make on loan contracts can be accommodated very easily in the LD module. Breaking of contracts may require the change of the interest rate as well as the maturity date itself. Contracts can be extended or amended from call/notice to fixed or from fixed to call/notice. A number of VERSION records exist to assist the user when making simple or specific changes to a contract, like amending the settlement accounts. The user is given the flexibility to make changes to accommodate the banks needs, so for example, the fact that a rate was supposedly ‘fixed’ does not prevent the user changing the rate.


Loans and Deposits

Leases

Fields for Leasing There are three fields introduced in the main LD contract which support the Leasing functionality:

Figure 36 - Fields in LD contract used for Leasing

The following extract illustrates how a typical LD version can be written to enable the input and recording of a 12-month automobile lease having no residual value at the end of the lease term.

Figure 37 - Inputting a Lease contract


Loans and Deposits

Leasing schedule types A schedule type “A” indicates that the underlying transaction is an annuity type agreement in the schedule definition screen - LD.SCHEDULE.DEFINE.

The “A” schedule defines the regular annuity repayment amount. The associated amount may be entered or calculated using the standard annuity repayment calculation if entered. The amount of principal and interest to be repaid for each monthly repayment will be calculated by T24. Only one “A” schedule may be specified. For a “begin” type lease contract, the first repayment must be the same as the contract value (start) date.

Figure 38 - Inputting Lease schedules

The schedule definition screen enables the recording of any associated charges or insurance leasing. Please refer to the section detailing charges and fees for details. Once the lease details have been entered into T24, you can use the supplied ENQUIRY LD.BALANCES.SUM to see the amounts that have been calculated, whether the underlying transaction has been authorised or not.

Figure 39 - LD.BALANCES.SUM screen


Loans and Deposits

Bills Discounted and Rediscounted The LD.LOANS.AND.DEPOSITS application now enables you to set-up bills, which your Organisation has discounted or passed on to a third party for rediscounting.

On the LD transaction there is a multi-value field - BILL.NUMBER in which you may record one or more bills, which have been accepted for discounting or offered for rediscounting. Before you can use this facility, a bill or bills must exist on the BILL.REGISTER file.

Bill Register Before you can record a bill with the LD application, basic details of the bill must exist within the BILL.REGISTER. The following extract illustrates how a bill may be recorded:

Figure 40 - Recording a Bill in BILL.REGISTER

The above extract indicates that “Keizo Saji” expects to receive a sum of USD 1,000,000 from “Hiroshi Yamauchi” on 16th August 2004.

Once the bill has been entered and authorised, it becomes eligible for acceptance by either a third party or your particular Organisation. Entering a valid CUSTOMER id into the ACCEPTOR field indicates acceptance by a third party. Leaving that field blank indicates that the bill is eligible for acceptance by your Organisation.

For details as to how to “accept” a bill, please refer to the MISCELLANEOUS.DEALS application User Guide.


Loans and Deposits

Bills – Use in Loans and Deposits Discounting and Rediscounting of bills is performed in the LD.LOANS.AND.DEPOSITS application. Before transactions involving bills can be entered, two LMM.CHARGE.CONDITIONS codes should be defined for the booking of profit and loss from rediscounting.

Figure 41 - LMM.CHARGE.CONDITIONS record for Bill Rediscounting

These codes must be added to the LMM.INSTALL.CONDS record in the field BILL.CHG.CODE. The profit code must be value 1 and the loss code must be value 2.

Figure 42 - Adding code to LMM.INSTALL.CONDS record


Loans and Deposits

Bills – Discounting The LD.LOANS.AND.DEPOSITS application enables you to record details of bills, which your Organisation has agreed to discount on behalf of a customer. This option is available whether or not your Organisation or a third party has accepted a bill. However the bill must exist on the BILL.REGISTER.

A VERSION LD,DISCBILL is provided to enable the setting-up of a bill which has been accepted for discount.

Figure 43 - Discounting a Bill using LD.LOANS.AND.DEPOSITS,DISCBILL Version

The above screenshot illustrates the means by which the LD.LOANS.AND.DEPOSITS application records the details of bills, which have been accepted for discount.

The BILL.NUMBER field is used to record the id of a bill, which must exist on the BILL.REGISTER file. You may enter the id directly into that field or you may invoke the drop-down list facility while in the BILL.NUMBER field of the version. Select the bill, which is to be discounted, complete the LD and enter it into the System in the normal way.

However, the process of selecting bills for discount has been designed to run from an ENQUIRY. The ENQUIRY is used to obtain a selection of like bills, which can be bundled together for discounting collectively. Once the selection is on view, the bills can be selected and loaded into an appropriate LD contract for you.

This is achieved by first invoking the ENQUIRY BILLS.DISCOUNT. When the required selection criteria has been made, running the enquiry will present you with a list of those bills which are recorded on the BILL.REGISTER file and are available for discount by your Organisation. A bill must first be flagged “Y” in the DISCOUNT field before it can be selected for discounting.


Loans and Deposits

The BILLS.DISCOUNT ENQUIRY checks for these values and only displays those bills which meet the correct criteria as illustrated in the extract below:

Figure 44 - Enquiry BILLS.DISCOUNT Having obtained the list of those bills, which are available for discounting, you will then need to select the particular record for which you wish to view or record the discount rate within the LD application.

Select the particular bill for Viewing, which has been accepted for discounting. Do this by Clicking the

button over the particular item on the list.

Figure 45 – Viewing a record within BILLS.DISCOUNT Enquiry


Loans and Deposits

However if this particular bill is to be discounted, then Clicking the button will automatically invoke the LD.LOANS.AND.DEPOSITS application and add the bill to the BILL.NUMBER field.

Figure 46 - Discounting Bill

The ENQUIRY then populates the LD transaction with the BILL.REGISTER details, leaving you to complete the transaction. How much you need to complete here depends upon whether you have tailored the VERSION shown above to default such information as CATEGORY, INTEREST RATE (i.e. the discount rate) and GRACE.PERIOD.

A bill discounting transaction is recorded in the same way as a discounted loan; the amount paid for the discount is the sum of the bill amount less a discount amount. The discount amount is the sum of the bills multiplied by the discount rate for the remaining term of the Bill.

The discount amount will be amortised over the remaining term of the Bill.


Loans and Deposits

The LD module is also able to provide “bill bundling” facilities so you can select a parcel of bills all having the same currency and the same liability customer so that they can be discounted collectively under one single LD contract. A batch of bills can be assigned a batch number through input of the field BATCH.NO. If "NEW" is entered into this field a batch number will be automatically assigned.

The following extract illustrates how a typical “bundle” of bills are recorded within the LD application:

Figure 47 - Example of Bill ‘bundling’

These particular bills all share the same maturity date, currency and customer and therefore may be “bundled” into a single LD contract so that they are discounted collectively.

A bill discounting transaction may be terminated prematurely by changing the maturity date of the loan transaction. The maturity date of the bill will be updated in the BILL.REGISTER by the system.


Loans and Deposits

Bills Rediscounting The LD.LOANS.AND.DEPOSITS module is also able to process bills which, having already been accepted for discounting, and then offered to another third party for rediscounting.

A VERSION LD.LOANS.AND.DEPOSITS,REDISC is provided for processing the rediscount of a bill, or bundles of bills.

The various steps you should perform are exactly the same as those you must carry out in order to record a bill accepted for discount. The only exception being that you must use the ENQUIRY BILLS.REDISCOUNT.

Figure 48 – Enquiry : BILLS.REDISCOUNT

This ENQUIRY will locate those bills that have already been discounted and are therefore available for rediscounting.

These too may be selected and placed into an LD contract in the normal way, thereby creating a deposit taken as the rediscount proceeds are received.


Loans and Deposits

Figure 49 - Rediscounting Bill using Version LD.LOANS.AND.DEPOSITS,REDISC

When Bills are rediscounted the transaction is booked as a deposit with a zero interest rate. A rediscount rate must be supplied, which is used to calculate the amount to receive for the discount. The amount to receive is calculated as the sum of bills less the sum of the bills multiplied by the rediscount rate for the remaining life of the bills.

The action of rediscounting a bill will result in a profit or loss on the original discount, this is calculated as the sum of the bill multiplied by the difference between the discount rate and the rediscount rate for the remaining period of the bill. This amount is taken as a charge or fee in the CHRG.AMOUNT fields, together with a CHRG.CODE identified in LMM.INSTALL.CONDS in the field BILL.CHG.CODE.

Even after the bill is rediscounted and profit/loss crystallized, both the loan (discount) and the deposit (rediscount) transactions continue to be accounted for until the maturity of the bill. However, there may be cases where the rediscounting is done on a “without recourse” basis, i.e. the bank may want the loan and the deposit transactions to be removed from its books on the date of rediscount. For this purpose, the field RED.RECOURSE may be set to YES or NO. If flagged to YES, the rediscount transaction would be treated as “with recourse” and both the loan and deposit would continue in the books of the bank till maturity of the bill. Should this field be flagged to NO on the value date of rediscounting, both the asset and liability contracts are matured.


Loans and Deposits

Impact of Limits by Rediscounting a Bill

When a Bill is rediscounted, there is no longer any risk to the bank. In order to reflect this, the limit updated by the original discount of the Bill(s) should be backed out. A subroutine, BILL.LIMIT.AMOUNT, has been provided which will recalculate the exposure for a bundle of discounted bills so that only those, which have NOT been re-discounted, are included.

This routine should be added to the LIMIT.REFERENCE record as the reference of discounted bills in the field LIMIT.SUBROUTINE.

Figure 50 - LIMIT.REFERENCE for Discounted Bills


Loans and Deposits

Bill History The results of discounting and rediscounting a bill can be seen in the BILL.REGISTER record.

Figure 51 - BILL.REGISTER


Loans and Deposits

Schedules

Description Contracts which have all scheduled events occurring at maturity, can be set to request the system to raise the scheduled events automatically (referred to as a BULLET contract). However, where a contract needs multiple interest, principal, rate change dates these require the user to input the events in the define schedule screen (referred to as an AMORTISING (contract).

The define schedule screen is automatically displayed whenever the user selects the define schedule flag on a VERSION. It is a tool to assist the user in creating the schedules by use of frequencies based on dates, amounts and number of events required.

The number of forward STMT.ENTRY to be generated and LMM.SCHEDULES update, can be dictated either at LD input or using the default set at LMM.INSTALL.CONDS by field FWD.PROJ.

For example if the user enters value 3 in field FWD.PROJ in LD Contract, system will generate only 3 Forward STMT.ENTRY and LMM.SCHEDULES will be updated with the same number of schedules. But if FWD.PROJ is not specified STMT.ENTRY and LMM.SCHEDULES will be updated using that of LMM.INSTALL.CONDS till the Maturity Date of the Contract. During COB when a schedule is processed system will generate the Forward STMT.ENTRY and update LMM.SCHEDULES so that number of entries matches the value in FWD.PROJ.

User can change this value any time at Contract Level and Parameter Level. If the user amends a contract and increases this value then Forward STMT.ENTRY and LMM.SCHEDULES will updated as the per the new value and vice versa.

This field can accept a value in the range 1-99.

Defining Schedules The screen has some header fields and space for the user to specify the schedule information.

These contain the following data:

Figure 52 - Options in FORWARD.BACKWARD.KEY field


Loans and Deposits

Figure 53 - Options in BASE.DATE.KEY field

Figure 54 - Field descriptions

The following example shows how the system can calculate the repayments of principal for a 12-month loan based on the user’s input of the first amount and date. On the example the user has requested 11 further payments to be made monthly (note the last payment will be adjusted and the user given an override with the amount calculated by the system).

A diary schedule has been defined to remind the user to telephone the customer ahead of the interest repayment and rate reset. An annual fee is charged at the end of the year.


Loans and Deposits

Valid schedule types are:

Figure 55 - Valid schedule types

Figure 56 - Authorising Schedule input

Once the transaction is authorised, the schedules are created and the define screen information is written away for future reference. If the user wishes to amend the schedules after they have been authorised, the existing schedule define screen is retrieved ready for amendment as required. As schedules are processed throughout the life of the contract, the define screen information is updated. When the schedules are modified, the system will ensure that the schedules defined are still consistent with the current status of the contract, e.g. the principal schedules match the current contract balance and the interest is paid on the maturity date.

A contract with a schedule definition can be identified by the value AMORT in the field CONTRACT.TYPE. A contract with only the default schedules at maturity will contain the value BULLET.


Loans and Deposits

Repayment of Capitalised Interest using ‘P’ Schedule The capitalised interest amounts can be included for repayment (on or after the actual capitalisation date), by flagging the field REPAY.CAP to YES. The system then allows the capitalised amount to be repaid through “P” schedules.

Any interest schedule with the field CAP.INT set to YES in LD.SCHEDULE.DEFINE, is capitalised.

Throughout the life of the contract, the deal amount with any increase and capitalised amount can be repaid, subject to the principal amount does not become zero before maturity date.

On rate changes when REPAY.CAP is set to YES and if CAP.INT is set to YES in any one of the schedule, an exception file LD.SCHEDULE.EXCEPTION is updated. This can be used by the user to define the schedule, else by default the system redefines the schedule so that the final repayment will include the adjustment. If the rate is decreased, then the schedule is shortened and the maturity date is updated accordingly.

Note: The 'B' schedules can be used to enter forward or backward dated Principal increases and are taken into account when validating any repayment schedules. They cannot be used if the AMOUNT.INCREASE field has been used on the main LD.LOANS.AND.DEPOSITS file.

It is possible to input B type schedule (Principal Increase) in a drawing contract. Tranche availability and commitment availability will be checked online. Limit and Commitment available amounts will be updated online in LIMIT and LD applications respectively.

It is possible to have overlapping repayment schedule dates and frequencies for capital payments, but only Principal Schedules (“P” and “B”) are allowed to overlap on the LD.SCHEDULE.DEFINE record. This can come from frequency definition or ad-hoc multiple repayments on the same schedule date.

If multiple repayments are defined, the PRIN.AMOUNT.DUE field on the LMM.SCHEDULE file contains the positive or negative consolidated repayment amount, while the multi-value field PRIN.AMT.SPLIT reflects the repayment breakdown for the schedule date.

For fixed maturity contracts it would be possible to define I (interest) schedules in the LD deal itself, provided Principal is payable Bullet. This is achieved by defining the interest payment frequency in INT.DUE.DATE field. If capitalisation were flagged to YES, interest would be capitalised based on the cycled dates as per frequency defined in this field. For these types of deals, the LD.SCHEDULE.DEFINE input is not allowed.

For Call Notice contracts, it would be possible to take both interest and principal amount on maturity and definition of INT.DUE.DATE and COMM.DUE.DATE are not mandatory. However, if a date is input in these fields, the scheduled event would be processed and the dates cycled according to frequency set. If interest / commission are payable on maturity only, then no input is made in these fields. An override "Schedule for interest not defined" is given in this case. Should there be a commission defined in the contract an additional override "Schedule for commission not defined" is given.

TOT.INTEREST.AMT is not updated if interest or commission schedules are not defined.


Loans and Deposits

When the deal is to be matured, the appropriate date is fed in FIN.MAT.DATE field. TOT.INTEREST.AMT & TOTAL.COMM.AMOUNT are populated with interest/commission for the period of the deal.

If the date entered in FIN.MAT.DATE were equal to process date, maturity entries would be raised online. If a future date is entered, maturity would be processed during end of day of the date entered (or start of day if the deal is so flagged)


Loans and Deposits

Customising the Schedule Screen The schedule definition screen is a standard application, LD.SCHEDULE.DEFINE that can be customised using the VERSION utility in the same way as with any other application.

In order to provide the flexibility of having an input VERSION that is unique or specially suited to a particular contract type, it is possible to create matching VERSION records for the main input LD.LOANS.AND.DEPOSITS and LD.SCHEDULE.DEFINE. This depends on what may be called the VERSION extension; the part of the id after the application name starting with and including the comma (i.e.,COMM).

For example a commitment contract that needs no P schedules could be simplified and use a VERSION contract LD.LOANS.AND.DEPOSITS,COMM. A schedule input VERSION called LD.SCHEDULE.DEFINE,COMM would be invoked automatically as the VERSION part of the application is the same.

The rules for use are:

• If a VERSION extension for LD.LOANS.AND.DEPOSITS exists on file for LD.SCHEDULE.DEFINE, then those VERSIONS are used.

• If a VERSION extension for LD.LOANS.AND.DEPOSITS does not exist on file for LD.SCHEDULE.DEFINE or no VERSION is used then:

o LD.SCHEDULE.DEFINE,STD is used for Input function

o LD.SCHEDULE.DEFINE,STDAUTH is used for authorisation function.

These VERSION records are released as standard and should not be modified.


Loans and Deposits

Accounting Accounting takes place in the LD module in accordance with the system standards. The accounting stages can be broken into:

• On-line

• Close of Business

• Forward Accounting

On-Line Where contracts have a start date that is equal or less than today the drawdown accounting will take place at authorisation. The accounting details are actually created on completion of the validation by the user and are used to update working balances to avoid overpayments caused by entries being raised elsewhere in T24. Once the contract is authorised these entries are passed over the accounts and the account record is updated. Amendments such as principal increase will also take effect on-line if the effective date is today or earlier.

Close of Business During the Close of Business routines there are several accounting events to be processed, these are:

Start events

Any contract that was input with a forward start date will be processed during the Close of Business when the contract starts, or earlier if the start date in a non-working day.

Interim events

During the life of a contract there will be many interim events such as interest payments, principal settlements and charges that will need to be processed. These are made during the Close of Business process.

Maturity events

Where contract reaches maturity all the accounting will take place in the Close of Business processing.

Forward Accounting The system raises forward accounting entries for all future events in the life of the contract; these are raised at authorisation but are actually created at input time in the same way as on-line accounting entries, and are used to check the account cash flow. Each time a contract is amended or an event is processed, all the forward entries are regenerated.


Loans and Deposits

Forward Interest Projection

The future interest, commission, charge and fee amounts are projected each time the entries are generated.

In the case of Periodic Automatic contracts, the user has the option to project the interest calculations using either:

• The current system rate.

• Extracting the relevant rate from the current settings of the PERIODIC.INTEREST table, which can be recalculated on a specified frequency.

The application LMM.INSTALL.CONDS contains the setting of these options in the fields PROJECT.R.TYPE and FWD.R.TYPE.FQU.

Figure 57 - LMM.INSTALL.CONDS


Loans and Deposits

Limits The LD module uses standard calls to the LIMIT module. There are special limit situations, which are unique to the LD module; these are due to the special products that only the LD module can handle.

Whenever a simple loan contract is input, the LD module after all validation checks have been performed, will check with the LIMIT module to see if an approved limit is in place for that product type. If none exists, a default one will be created. Checks will be made against the expiry date, last drawing date, available amounts, global or sub-product limits according to the unique limit structure of the bank.

However, when commitment contracts are input the user is given an option to reduce the limit by the full commitment amount immediately, whereby any future drawdown will be noted against that limit. Alternatively, the limit can be updated as and when the drawdown is made.

The LIMIT module also caters for revolving and non-revolving commitment contracts. Of course the system will not permit a revolving commitment to utilise a non-revolving limit record.

Third Party Limit A bank which makes advances to customers on the basis of instruments like bills, cheques etc issued by a third party, may want to exercise limit controls over the presenter of the instrument as well as the issuer of the instrument. The fields THIRD.PARTY.ID and THIRD.LIM.REF can be used for this purpose, whereby the user can input the ID of the third party whose limit should be hit and also the corresponding limit reference that needs to be hit.


Loans and Deposits

Reports The following reports are supplied as standard with the LD module:

LD0100 Imminent maturities report Details the contracts, which are due to mature in the next few days. The user in LMM.INSTALL.CONDS sets the number of days.

LD0110 Maturing events report Similar to the maturity report, this report will advise the user of interim events, which are due in the next few days. Items such as interest due dates, principal repayments and fees due are shown.

LD0200 Contracts accruals report This report will provide information on the accruals on each contract as at the close of the previous day’s business.

LD0300 Rate revisions report Loans administration staff use the rate revisions report to assist in rate settings. As it is common banking practise for rates to be set on or before the rate change date, this report will advise of forthcoming contracts that need rates to be set in the next few days.

LD0500 Missing payment instructions Where the settlement instructions were unknown for a client and the option to post accounting entries through the standard LMM suspense accounts was taken, it is important to inform the user of any contracts where future accounting will take place through these suspense accounts. In effect this report advises the user which contracts are still awaiting the clients settlement details to be corrected.

LD1100 Payments effected (since last Close of Business) For information only a report is produced of the payments that have been effected over Nostro accounts by the system.


Loans and Deposits

Enquiries

LD.CURR.INT.BR This ENQUIRY will allow the user to analyse the accrued interest for the current and previous interest periods on a contract. It will show the rates, principal amounts and days, which comprise the interest amounts calculated.

Selection is by

CONTRACT.NO

Figure 58 - Enquiry LD.CURR.INT.BR


Loans and Deposits

LD.BALANCES.FULL.BR An ENQUIRY to list details of all past schedules processed and the projected future schedules. The enquiry shows all future principal, interest, commission, charge, fee and diary events throughout the life of the contract. Multiple repayments for the same date are displayed on different lines.

It may be run to show details for a certain period only if required, by entry of a START.DATE and END.DATE in the selection criteria.

This enquiry may be run on unauthorised and authorised contracts to show the future details. Where a Loan has a MANUAL LIQUIDATION.MODE, any linked PD.PAYMENT.DUE details can be shown too by setting the selection field SHOW.PD.INFO to YES or MERGE. A value of MERGE will incorporate the overdue information into an existing line of repayment details where the date matches, a value of YES will show the details on a separate line.

Selection criteria are:

CONTRACT.ID

START.DATE

END.DATE

SHOW.PD.INFO

Figure 59 - Enquiry LD.BALANCES.FULL.BR


Loans and Deposits

LD.BALANCES.SUM.BR

This is a summary version of the LD.BALANCES.FULL.BR ENQUIRY showing only, principal, interest, and charge events.

The selection criteria are identical.

Figure 60 - LD.BALANCES.SUM.BR


Loans and Deposits

LD.HIST.INT.BR Similar to the LD.CURR.INT.BR ENQUIRY this allows the user to analyse the accrued interest for the previous interest periods on a matured contract. It will show the rates, principal amounts and days, which comprise the interest amounts calculated.


CUSTOMER

CONTRACT.NO

Figure 61 - Enquiry LD.HIST.INT.BR


Loans and Deposits

LD.MONITOR.BR As part of the schedules allowed in the LD module it is permitted to enter a diary schedule that can be used by the loans administration staff to record any event as text for specific contracts. This ENQUIRY allows the user to find any diary notes for today by contract or customer.


CUSTOMER

CONTRACT.NO

Figure 62 - Enquiry LD.MONITOR.BR


Loans and Deposits

LD.RPM.HIST.BR LD.RPM.HIST is an ENQUIRY used to provide more concise information about the payments effected on a contract. Such payments include principal and interest.


@ID

CUSTOMER

CONTRACT.NO

Figure 63 - Enquiry LD.RPM.HIST.BR


Loans and Deposits

LD.COMMITMENT.DRAWING.BR An ENQUIRY to allow the user to see which drawings have been made under a commitment. The commitment may be an asset with Loans and as drawings, or a liability with Deposits as drawings.

Selection is by

COMMITMENT.NO

Figure 64 - LD.COMMITMENT.DRAWING.BR


Loans and Deposits

Delivery The LD module provides advices through the standard delivery interface in T24 and accommodates the following message/advices:

Payment Messages The majority of payments can be effected directly through the LD module, however the number of parties involved in the transfer are limited. More complex deliveries require the use of the FT module.

MT103

A payment advice that can be sent by mail, telex or SWIFT. The advice is sent only to the user’s correspondent who will affect the delivery on the user’s behalf. The MT100 is normally used where the beneficiary is not a bank. The delivery reference for the MT103 message generated is written to an internal file LD.PAYMENT.ENTRY

MT202

A payment advice that can be sent by mail, telex or SWIFT. The advice is sent only to the users correspondent, who will affect the delivery on the users behalf. The MT202 is normally used where the beneficiary is a bank. The delivery reference for the MT202 message generated is written to an internal file LD.PAYMENT.ENTRY.

Production and Suppression of Payment Messages A payment message will generally be produced whenever a Nostro account is credited with a Principal or Interest Payment amount. Where these payments fall on the same value date, and use the same Nostro and settlement details, one net payment will be produced. Any fees or charges falling on the same date through the Nostro will also be added / subtracted from the payment amount.

The system will always produce a payment message in the above circumstances unless:

• The customer of the Nostro Account is the same as the CUSTOMER.ID of the deal or the PAYING AGENT if specified, and SEND PAYMENT is not set to Y.

• The field SEND PAYMENT is set to NO.

The field SEND PAYMENT can be used to suppress or force payments on an individual contract basis if required. Suppression of a payment that would normally be sent will require an override.


Loans and Deposits

Figure 65 - Override stating non-production of payment advice

Advices and Confirmations Each event in the Loans and Deposits application can be configured to produce an advice or confirmation. The SWIFT standard message types have been used, although such confirmations and advices need not be directed through SWIFT using the flexibility of the DELIVERY system. Production of advices at product level is controlled by the application LMM.ADVICES.

MT320

The SWIFT advices for new and amended deals are fully supported. However, the user has the ability to send mail advices for which many options not supported by SWIFT can be catered for. These advices are listed in LMM.ACTIVITY and cover the typical Loans department work.

MT324

This advice type is to communicate the maturity information on contracts to the counterparties.

MT330

Advices based on this SWIFT message type are used for call/notice contracts; again more extensive mail advices are catered for.

MT350

Settlement of interest at dates other than the maturity will trigger these advices. The mail advices also include the ability to send reminders to the counterparty about when interest payments are due.

MT900

Debit advices are sent to the account owner detailing the nature of the debit and the transaction that instigated it.


Loans and Deposits

MT910

Credit advices are sent to the account owner detailing the nature of the credit and the transaction that instigated it.

Suppression of Advices and Confirmations It is possible to suppress confirmations and advices for an individual contract by setting the field SEND.CONFIRMATION to NO.

Interest rate change advices The LD.LOANS.AND.DEPOSITS application will, if required, advise customers of changes to the interest rate on a contract.

The interest rate change advice is sent via the DELIVERY application and consequently may be sent via SWIFT, printed, or sent by any other route available through the application.

Rate change advices may be produced either when the interest rate fields on the contract are modified or the interest rate on a contract changes as a result of the underlying base rate being amended.

Activating rate change advices

A number of parameters need to be reviewed and established to control the production of interest rate change advices. Separate sets of parameters control the production of advices when contract details are changed and when base rates are changed.

For changes to contract details, the field LD.RATE.CHANGE.ADV on LMM.INSTALL.CONDS indicates whether rate change advices are to be produced. This includes changing the interest rate on a contract not linked to a base rate. If this field is set to N then replacement confirmations will be produced.

For changes to base rates, the field BASIC.RATE.CNG.ADV on the application BASIC.RATE.TEXT indicates whether rate change advices are to be produced for changes to this base rate.

Also for changes to base rates, the LMM.ADVICES records may require modification. These records indicate which advices are to be generated for each CATEGORY of contracts. To enable interest rate change advices, the LMM.ACTIVITY codes 1080, 1081, 2080, and 2081 should be specified where advices are required.

Finally the printed output parameters should be reviewed. Example parameters (DE.FORMAT.PRINT records) are provided with a key as follows:

335.LD1401.1.GB

935.LD1401.1.GB


Loans and Deposits

These should be amended to suit local requirements. Additional records may be created to print specialised advices. See the Delivery section of this user guide for further details.

Example interest rate change advices The following example has been formatted using the facilities available in the GLOBUS DELIVERY module (specifically the application DE.FORMAT.PRINT). The supplied formats can be easily customised using this application or used as a base for other, specialised, interest rate change advices.

Figure 66 - Example of printed Rate Amendment Advice produced by T24


Loans and Deposits

If the counterparty to the loan or deposit is on the SWIFT network then DELIVERY may send the rate change advice as a SWIFT message if required. If the loan is a fixed rate then a message type 935 will be generated, if call or notice then message type 335.

Figure 67 - Example of SWIFT MT935 message

Figure 68 - Example of SWIFT MT335 message

LD activities & advices - tables and keys The following table links activities in the LD application with the advices generated in the DELIVERY application and the parameter records that are used in DELIVERY.

The first column contains the activity (from LMM.ACTIVITY). The second column shows the DELIVERY DE.MAPPING record that will be used to map from the activity details to the message details. The third column shows the DE.FORMAT.PRINT records that will be used to create the printed advice.


Loans and Deposits

Figure 69 - LMM.ACTIVITY records and their relative mapping and print records

Abbreviations

nn = last 2 digits of formatted CATEGORY (see below for full explanation).

For more information on DE.MAPPING and DE.FORMAT.PRINT see the DELIVERY chapter of this user guide.


Loans and Deposits

Formatting of CATEGORY code for DELIVERY keys The DELIVERY formatting record used to print Loans and Deposit advices may be selected on the basis of, among other things, the type of contract generating the advice. The type of contract is determined by the category code, however in order to make the system as flexible as possible, two elements of translation are performed.

Firstly in order to minimise the number of records required in DELIVERY (DE.FORMAT.PRINT records) the LD CATEGORY codes are divided into ranges with all categories in the range producing the same style advices.

Secondly, in order to enable the production of specialist advices for particular types of Loans and Deposits when required, a field called FORMAT.CATEGORY is provided on the table LMM.ADVICES. This field is optional, but when present for a particular LD category, will overwrite the range causing a special format advice record to be produced.

Thus the translation logic is:

The LMM.ADVICES record is read for the category on the LD contract. If there is a record and the field FORMAT.CATEGORY is present then the FORMAT.CATEGORY will be used.

Otherwise the following codes will be assigned:

Figure 70 - Default Categories used by LMM.ADVICES

For example the interest payment for a deposit with CATEGORY 21035 will use the format record 320.LD2801.1.GB. This will be the same record used for all LD contracts with a CATEGORY code in the range 21001-21039. However if a special advice is required then the FORMAT.CATEGORY field could be set to 21035 in which case the format record 320.LD2835.1.GB would be used.

Setting prior days for events The LD module has the facility for setting the number of days prior to an event that an Advice (E.g., Maturity reminder) will be sent to the customer. Usually this will be set at the advice level through the LMM.ADVICES application. Entering a numeric in the field DAYS.PRIOR.POST will determine how many days before the event that the physical advice will be sent to the customer. It is also possible to set the number of days at the contract level. If a numeric is entered into the field DAYS.PRE.ADVICE when creating or amending a contract then this number will be the pre-defined number of days and will supersede the LMM.ADVICES information. This option is only available for an advice that allows the DAYS.PRIOR.POST to be used. These are listed on the system help text for LMM.ADVICES.


Loans and Deposits

Rolling LD contracts The LD module can be used to effect simple one-shot contracts for clients with settlement of principal and interest being made at maturity. However, these types of contracts often require rolling over for further periods, inclusive or exclusive of the interest amount. It is normally recommended that this type of deal is made through the MM module, since this module has features which automate rollovers. Below is an alternative method of effecting the rollover using the LD module.

Settling Interest A one-month contract is due to mature in 3 days time and the client wishes to extend it for a further month.

The bank will provide a new rate for the extension; settle the interest from the clients’ account and advise the client of the rollover.

In order to adjust the contract to meet this criteria we will need to use the amendment fields on the LD contract to set the new rate; change the maturity date to the new date, and on the schedule define screen, specify the settlement of interest on the old maturity date as well as on the new maturity.

Note: If the contract is extended without defining an interest schedule for the old maturity date you will find the committed interest has changed and is only settled on the new maturity date.

Capitalising Interest To capitalise the interest at rollover is quite simple. You must effect a principal increase of the same amount as the interest due (and for the same value date). This will in effect charge the interest to the client and credit P/L; then re-credit the amount as an increase. The increase amount and value date are entered on the main part of the contract in the amendment fields.

If interest is to be capitalised for all future interest settlements (apart from at Maturity) the field CAPITALISATION can be set to Y. In this case there is no need to effect a principal increase for the interest amount.

The CAPITALISATION field can be modified at a later stage following initial input. This allows you greater flexibility in the case of any necessary future amendments to the contract, or in the case of any mistakes on input to this field, when the LD contract was first entered.

Draw down in a Currency other than Deal Currency Draw down may be made from/to an account denominated in a currency other than the deal currency. While inputting a discounted LD deal, interest or commission may be collected/paid upfront in a currency other than the deal currency. Similarly charges may be collected in any currency.


Loans and Deposits

Liquidation in a Currency other than Deal Currency Proceeds of liquidation may flow from/to an account denominated in a currency other than the deal currency. A facility is also provided in the SETTLEMENT.RATES table for the user to define an exchange rate that is to be used for conversion while handling liquidation in a different currency.

Increasing/Decreasing the Principal As previously described in the 'Capitalising Interest' section, it is possible to affect an increase in conjunction with the rollover. It is also possible to affect a decrease instead of an increase if the client only wished to roll part of the outstanding principal. It should be noted however, that the decrease must be entered as a repayment schedule on the schedule define screen.

Figure 71 - Increasing principal using Version LD.LOANS.AND.DEPOSITS,Cemarl


Loans and Deposits

Early Maturing / Partial Repayment of LD contracts It is a privileged bank that never has to break a fixed contract at the request of a client, those that do need to break the contract may require a breakage charge to be applied.

Entry of Early Maturity A contract can be early matured by simply amending the maturity date (FIN.MAT.DATE) to the required maturity date. Where schedules have been defined for the contract, these must either be redefined or set to auto schedules. In case of discounted contracts, when the contract is set to mature early there is an option to return interest and commission to the customer if the interest/commission taken upfront is more than the amount as per the calculations for new maturity date. The settings in the RET.INT(Return Interest) and RET.COM (Return Commission) fields govern this functionality. If these fields are set to YES, then interest and commission are returned to the customer or else they are booked as profit.

Figure 72 - Early maturing a contract


Loans and Deposits

A contract can be matured with a back valued date. If a contract is flagged to mature with a date less than or equal to the process date, accounting entries are raised ONLINE.

Fully back valued contracts can also be processed, in such cases the VALUE.DATE and the FIN.MAT.DATE are both backdated. Necessary accounting entries for creation and liquidation of the deal with appropriate value dates are raised ONLINE. The contract is assigned a CONSOL.KEY based on the current definition on the CONSOLIDATE.COND. If such a backdated transaction results in a PAYMENT.DUE, a PD record is created ONLINE and the LD record is written to live files. Else, the records are written to history files based on number of days input in DAYS.POST.MATURITY in LMM.INSTALL.CONDS. There is no update to LIMIT except for creation of PD records for a fully back valued contract. There is no update to CRB or RE.STAT.LINE.BAL also for such contracts. Fully back valued contracts may only have one single interest period and repayment of principal is only bullet.

Start of Day Maturity An LD contract (both loan and deposit types) can be flagged to mature during the START.OF.DAY process. This is achieved by inputting YES in MATURE.AT.SOD in the deal or in the LD.TXN.TYPE.CONDITION table for the respective category type. The value in the TXN table is only a default value, which may be changed at the deal level.


Loans and Deposits

Entry of Partial Repayment A contract can be partially repaid either by entering a principal decrease in the AMOUNT.INCREASE field, which must be back valued, or value today in the field AMT.V.DATE. This decrease is effected immediately on-line; the principal is reimbursed through the DRAWDOWN ACCOUNT.

If the principal reimbursement is required in the future, define an additional P schedule, or amend an existing P schedule for the required repayment amount in the LD.SCHEDULE.DEFINE screen.

Either method can be combined with an amendment to the maturity date (FIN.MAT.DATE) if required.

Figure 73 - Entry of partial repayment


Loans and Deposits

Early Maturity Penalties There are charge fields (CHRG.CODE, CHRG.AMOUNT, CHRG.CAPITALISE) on the main LD contract which allow the deduction of a user input charge which can be deducted from a deposit repayment or added to a loan repayment. Where sufficient notice has been given it is also possible to add a schedule type that will come into effect, usually at next repayment time on the schedule define screen.

Penalty on Overdue The field PENALTY.RATE can be used to stipulate the penalty rate on the contract when it becomes past due. It is also used for calculating penalty spread on the overdue amount when the period in PE.SWITCH.PERIOD in the relevant PD.PARAMETER record has been crossed. For more details please refer to the user guide on PD.PAYMENT.DUE module.

Immediate Charge An immediate charge can be taken by entry in the fields CHRG.CODE and CHRG.AMOUNT, the amount will be debited from the CHRG.LIQ.ACCT when the contract change is authorised.

Figure 74 - Taking immediate charges


Loans and Deposits

The charge can be deducted individually or using a capitalisation flag (the field CHRG.CAPITALISE set to Y) or be added/deducted (according to contract type) from the current contract principal, in the same way as a principal increase (for a loan) or a principal decrease (for a deposit).

Charge Schedules

A charge can be taken as a scheduled event using the LD.SCHEDULE.DEFINE application. A charge to be debited to the CHRG.LIQ.ACCT is defined as an ‘F’ type schedule, a fixed amount can be entered, in the case of a CHRG.CODE linked to either FT.COMMISSION.TYPE or FT.CHARGE.TYPE, the amount can be left empty and the charge will be defaulted based on the existing principal on the charge date.

A charge may also be taken from the contract principal as a future event, by entry of an ‘N’ type schedule. A charge amount must always be entered with an ‘N’ type schedule. On the schedule date the charge will be treated as a principal increase for a loan, or as a principal decrease for a deposit.

Figure 75 - Defining a charging schedule


Loans and Deposits

Primary Market Bonds Processing The booking of bonds issued and purchased by the bank are handled by the Loans and Deposits module (the trading of bonds is handled by the Securities module). Loans and Deposits have several features which are used specifically in the processing of Bonds. The bond created, is defined in the application SECURITY.MASTER so that it can be traded by the SECURITIES system.

Creating a Bond Issue Program A bank may plan to issue a series of bonds, where the total issue takes place over a period of time, possibly in different currencies. The total value of the issue program can be recorded by entering a liability commitment contract.

Entry of such a contract allows the bank to track the amount of the program already issued and that available for further issue. The liability commitment is reported as an off balance sheet item and earns no income.

The issue program contract is entered with CATEGORY 21101 - 21105, with a start date (VALUE.DATE) and end date (FIN.MAT.DATE), the total value of the program (AMOUNT) together with the program CURRENCY. The program may be defined as either REVOLVING or NON-REVOLVING (field L.C.U.TYPE), meaning that when a drawing issue matures, the available amount increases (REVOLVING) or remains the same (NON-REVOLVING).

The start and end date (D.D.START.DATE and D.D.END.DATE) from which drawings can be made from the issue program can be defined if required, as can possible multiples of drawing amounts (D.D.MULT.AMT).


Loans and Deposits

Figure 76 - Version LD.LOANS.AND.DEPOSITS,Cecenv

Creating an Individual Bond Issue When bonds are actually issued they are sold to the bank or customer, or often to an appointed paying agent, who is responsible for handling all payments connected with the issue. The issue is entered in the same way as a standard deposit contract (i.e. CATEGORY 21001 - 21039), although additional options detailed in this section may be required.

Linking to an Issue Program

If the issue forms part of an issue program, the issue number (i.e. the number of the liability commitment contract) is entered in the field COMMITMENT.NO, when the issue is first entered.

Where the issue is in a different currency to the issue program, a conversion rate may be specified in the field L.C.U.CONVERSION, this is used to convert the issue amount into the program currency so that the available amount can be reduced.


Loans and Deposits

Paying Agent

The handling of all payments for a given issue may be appointed to an agent, who will usually receive a fee for performing this service. The PAYING.AGENT field contains the customer number of the agent in these cases. If entered, all payment messages are sent to the paying agent, all settlement information, including accounts are defaulted based on the paying agent rather than the CUSTOMER.ID. The CUSTOMER.ID contains the customer number of the bondholder.

Figure 77 - PAYING.AGENT in LD contract

Note Denominations

A bond issue may consist of a quantity of physical notes of specific denominations. Any re-purchase or partial redemption of the bond must be in accordance with the notes issued. Note denominations may be recorded in the field NOTE.DENOM together with the quantity in the associated field NOTE.QUANTITY. The total value of notes defined must equal the current nominal value (AMOUNT) plus any pending AMOUNT.INCREASE.

When a ‘P’ schedule is defined for a contract with notes defined, the note definitions for the repayment amount must be entered in the LD.SCHEDULE.DEFINE screen in the fields NOTE.DENOM and NOTE.QUANT. If there is only one ‘P’ schedule defined the note values will be defaulted.


Loans and Deposits

Figure 78 - Logging note denominations

Issue Price

The nominal value of the issue is entered in the AMOUNT field, this is used as the base amount for calculation of interest and fees. A bond may not always be issued at the face value, and instead may be issued at a price expressed as a percentage of the nominal value. This may be less than or greater than 100% and is entered in the field ISSUE.PRICE.

The amount to be paid as a result of the issue price at drawdown is stored in the field DRAWDOWN.ISSUE.PRC, which can also be entered if required. The resulting discount (i.e. the issue price is less than 100) or premium (price is greater than 100) is posted to profit and loss.

Drawdown Issue Fees

In addition to the issue price, there may also be fees payable to the paying agent when the bonds are issued, which are deducted from the amount to be paid at drawdown. Such fees are entered in the fields DD.FEE.CODE and DD.FEE.AMT. DD.FEE.CODE may contain any valid FT.COMMISSION.TYPE, FT.CHARGE.TYPE or LMM.CHARGE.CONDITIONS record where the PAY.RECEIVE indicator is set to PAY.

The fee amount may be entered as an amount, or as a percentage of the nominal (any input less than 500 is assumed to be a percentage). Fees may be amortised if specified in the associated LMM.CHARGE.CONDITIONS record field MTHLY.AMORTISATION.

This is accomplished by the usage of fields that will adjust the payment due at drawdown i.e.:


Loans and Deposits

Figure 79 - Example of amounts after fees taken

Adjusting Value date of entries

A standard bond has coupon (interest) periods of equal length, which means that some of the periods end dates may fall on non-working days. In many cases the business practice is not to post any entries to accounts with the value date of a non-working day. The field VD.DATE.ADJUSTMENT provides the option to adjust the value date of accounting entries in this situation.

When determining whether a date is a working day, the HOLIDAY table of each BUS.DAY.DEFN and the local country is checked, the date must be a working day in each country.

The options to amend this value date are set in the field VD.DATE.ADJUSTMENT and are:

Figure 80 - VD.DATE.ADJUSTMENT field options

With contracts, a few special cases may require the value date to be adjusted by a number of working or calendar days prior to the event date. Such an adjustment is specified in the field VD.PRIOR.ADJUST, which can be combined with a VD.DATE.ADJUSTMENT setting if required.


Loans and Deposits


Figure 81 - Date adjustment fields in LD record

Reimbursement Price

In the same way as the issue price determines the amount to be paid for an issue, it is possible to specify a reimbursement price, which determines the actual amount of principal to be repaid at maturity. This price, expressed as a percentage of the nominal, is entered in the field REIMBURSE.PRICE. The entered price is used to calculate the REIMBURSE.AMOUNT, the actual amount to be repaid at maturity. If required the REIMBURSE.AMOUNT may be entered.

Figure 82 - Reimbursement price field in LD record

hen a partial reimbursement or repayment is made, the repayment amount is always the full amount. W

The REIMBURSE.AMOUNT will be recalculated from the REIMBURSE.PRICE based on the outstanding principal.

Loans and Deposits

Interest Effective Date / Payment Date

The VALUE.DATE is treated as the interest effective date for the start of the first coupon (interest) period. Bonds can be issued after the start of the coupon period, in this case the VALUE.DATE is entered back valued to reflect the correct start of the coupon period. In order to ensure that drawdown entry is correctly valued, (i.e. to today’s date), the field DRAWDOWN.ENT.DATE allows the value date for the drawdown entry to be specified, which by default is equal to the VALUE.DATE.

Figure 83 - Back valuing in VALUE.DATE field

Payment of Fees to Agents

A fee can be paid to the customer / paying agent to whom the bonds are issued. There are several different methods of taking the fees.

At drawdown, fees can be taken as described in the section ‘Drawdown Issue Fees’.

Scheduled fees are taken by definition of schedules in the LD.SCHEDULE.DEFINE screen using a type F schedule. The fee amount is entered, or may be left to default where linked to FT.CHARGE.TYPE or FT.COMMISSION.TYPE. When left to default, the fee is based on the outstanding principal on the schedule date. The PAY.RECEIVE indicator in the associated LMM.CHARGE.CONDITIONS record is set to PAY. The fee is credited to the FEE.PAY.ACCOUNT specified in the main contract in this case.

Additionally a fee may be linked to a scheduled interest payment or principal repayment event in the LD.SCHEDULE.DEFINE screen. The CHARGE.CODE associated with the ‘P’ or ‘I’ schedule should be defined; the fee amount is calculated based on the schedule amount using the linked FT.CHARGE.TYPE / FT.COMMISSION.TYPE definition. The fee is credited to the respective PRIN.LIQ.ACCT or INT.LIQ.ACCT depending on the schedule type.


Loans and Deposits

Figure 84 - Defining charges in LD.SCHEDULE.DEFINE

Bond Cancellation and Repurchase of Accrued Interest When part of a bond issue is to be cancelled, bonds must first be repurchased (using the SECURITIES system), then the cancellation of both principal and accrued interest will need to be reflected in the issue contract.

The cancelled principal and interest should be booked to a suspense account, leaving the remaining principal and interest to be settled to the correct accounts at maturity and or end of coupon period. To achieve this, the CANCELLATION.DATE should be entered with the date of cancellation, the start of the coupon period should be entered in the field AMT.V.DATE and the amount of nominal cancelled should be entered as a principal decrease in the field AMOUNT.INCREASE.

The system will then calculate the amount of interest cancelled between the AMT.V.DATE and the CANCELLATION.DATE, storing the calculated amount in the field TOT.CANCEL.INT.AMT. The cancelled principal and interest amounts are debited from a suspense account whose category is defined in the ACCOUNT.CLASS record LDCANCEL. Cancelled interest is credited to the profit and loss categories used for accrued interest.

Figure 85 - LD contract showing cancelled interest amounts

The field ASSET.CLASS in the LD template is used to input the classification of the contract (e.g) standard, sub-standard etc. The classification is user defined and user input. The field PROVISION is meant to input the percentage provision made on the LD. The values held in these two fields are meant for information purposes only.


Loans and Deposits

PM.LD.PARAM This affects what PM updates are created by the LD module. The field PM.MAX.PERIOD allows the user to limit the number of months for which LD will pass PM updates. It is unlikely that the PM data for a 25-year term loan needs to be created so far in advance. There is an overhead in creating this data at input time that can be reduced by using a reasonable setting in this field.

Figure 86 - PM.LD.PARAM record

SPF settings Due to the many accounting and PM updates that can be required when using very long term loans in the LD module, it is possible to exceed the default CACHE.SIZE which is set in the SPF SYSTEM record.

The default is 500 but a more realistic figure for a 25-year loan with monthly payments of principal and interest could require a setting of 1800-2000 depending on the types of deal commonly entered.


Loans and Deposits

Loan Transfer in Multi-Book environment In a multi book environment, a loan contract belonging to one branch can be transferred to another branch using the application EB.COMPANY.CHANGE. The static changes take place accordingly and the company code of the related files is changed to the new company code.

Example of Transferring Loan contract in two branches

1. Loan contract in BK1

Figure 87 - Loan Contract in Company BK1


Loans and Deposits


2. Loan contract in BK2

Figure 88 - Loan Contract in Company BK2

Loans and Deposits

3. LMM.ACCOUNT.BALANCES in BK1

Figure 89 - LMM.ACCOUNT BALANCES in Company BK1

4. LMM.ACCOUNT.BALANCES in BK2

Figure 90 - LMM.ACCOUNT BALANCES in Company BK2


Loans and Deposits

5. EB.COMPANY.CHANGE

Figure 91 - Transferring Contract LD033500001 to Company BNK

Figure 92 - Transferring Contract LD033500002 to Company BNK


Loans and Deposits

6. Loan contracts in BNK after transfer

Figure 93 - Loan Contract after transfer to BNK


Loans and Deposits

Figure 94 - Loan Contract after transfer to BNK


Loans and Deposits

7. LMM.ACCOUNT.BALANCES after transfer

Figure 95 - LMM.ACCOUNT BALANCES after Transfers


Loans and Deposits


Non-Stop Processing

If the Non-Stop Processing Facility is installed on your System, the LD Batch Jobs process transactions that were input prior to COB. Transactions Input during COB will be processed only in the next COB.

As a result the following actions during the Close of Business (COB) are or are not possible

1. User can input a new transaction.

2. System will not allow the user to amend a previous day’s transaction

3. User can amend a contract that was input during COB .

4. System will not allow the user to input back dated transaction

5. Allows the user to input Commitment contract and drawdown against the same.

6. User cannot input drawdown against the Commitment contract that was input prior to COB

7. LD Reports reflects only transactions that were input prior to COB

8. User cannot amend the Contracts that were input prior to COB.

r08-loans and deposits.pdf

Documents