Introduction to Loans and Deposits

This table displays the accrual dates or cycles for both the LD and MM (Money Market) modules together with the Profit / Loss (P/L) accounts that are used. The modules allow for the definition of separate accrual cycles for contracts designated in local and foreign currencies. It is also possible to set complex P/L account structures, which provides improved audit information for the bank’s accountants.To enable the processing of Risk-Free Rates (RFRs), the bank can configure the RFR related fields for rate calculation.

The screenshot below displays the LMM.INSTALL.CONDS record.

This table controls, for each LD category, the advices that are to be produced and the format to be used. 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. For example, Contract Initiation and Change of Interest Rate activities are a few. The LMM.ADVICES record can specify whether advices can be generated and sent to the counterparty for NONE, ALL, or SOME of the activities that may occur during a contract’s life.

The Format Category field enables each LD category to produce specialised advices and confirmations through the Delivery module. If this field is left blank then Temenos Transact produces a default format advice. However, input in this field can enable special formatting records in Delivery (DE.FORMAT.PRINT) to be used. Read the Delivery section for more information.

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

Example action codes are as follows.

Defined in ACCOUNT.CLASS is a debit and credit suspense account 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 1 is entered in the drawdown of a deposit, the debit suspense account can be used together with the debit text string.

An example of LMM.TEXT usage LD input is given below.

The LMM.CHARGE.CONDITIONS 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 and is indicated by setting the Monthly Amortisation field to YES. The period over which the amortisation takes place may be one of the following defined in Amortisation Period.

If the fee or charge has 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 Charge Code Key field. 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.

The above screenshot displays the LMM.CHARGE.CONDITIONS record.

The Activity codes are used in the accounting and delivery advices produced by the LD module. They are pre-defined in Temenos Transact .

The following list displays some LMM.ACTIVITY codes supplied and used by Temenos Transact.

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 is also used to define conditions applicable for a specific customer. In such case, the ID of the file should be C-Customer reference (For example: If the customer number in Temenos Transact were 100112, then the ID is C-100112).

The following conditions can be defined in this table:

Interest Spread – Loans

The Interest Spread For Loans field defines the additional spread that is added to derive the interest rate for a loan contract of this group or customer. This is input as a positive or negative absolute value.

Rate in BASIC.INTEREST table for ID 1 = 10%. Spread defined in LD.TXN.TYPE.CONDITION table (explained later in this section) 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 is 10 + 2 – 0.50 = 11.5% and for loans under category 21051, it is 10+1-0.5 = 10.5%.

Along with this field the user can define the effective date for such change.

Such effective date may be forward, backward or equal to process date.

Interest Spread - Deposits

The Interest Spread For Deposits field defines the additional spread in case of deposits for this customer or 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 can define the effective date for such change.

The 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 for either loans or deposits updates all existing contracts for the customer or group during the COB process. Such revised value can be used as default for the spread for any fresh deal.

Apply Cur Loans

This field accepts the below values:

• YES - The revised interest is applicable for existing as well as new deals input
• NO - The change is applicable only for fresh deals input in the system

The user can input this field, only if new rates are defined in the Interest Spread For Loan or Interest Spread For Deposits fields in LD.GROUP.CONDITION.

Charges and Commissions

The extent of charges and commissions (as defined in LD.TXN.TYPE.CONDITION) is similar to the exchange spread, which is an associated multi-value field with the Charge or Commn Type fields, and for each charge or commission, the extent to which the customer is to be charged is mentioned.

Charge Code in LD.TXN.TYPE.CONDITION table is CACT01 with a flat charge of 1,000. Definition in the group condition table is as follows:

Charge Type - CACT01

Charge Percentage - 50%

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

From the above screen shot, the Contract Grp field has 1, as default, 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 system defaults the appropriate charges.

LD.TXN.TYPE.CONDITION

The set of rules governing the specific category of the deal can be defined in this table. Here the user can 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 system defaults value for the start of day maturity. It defaults the values on to the LD deal and can be negotiated at the deal level. The initial draw down amount and term of the contracts are validated against the inputs in the LD.TXN.TYPE.CONDITION table and appropriate overrides are generated at the deal, if exceeded.

The above screen shot indicates the LD.TXN.TYPE.CONDITION record from a customer loan.

For liquidations in a currency other than deal currency, the default Conversion Type and Settlement Market fields can also be defined in this table.

It is used to define tolerances for the user-input amount in the case of Certificate of Deposit (CD) type of products. For CDs the user may input a value in Mat Amount field and let the system default the original deposit amount based on the term and interest rate. If a card rate was available, the values in Amount field as well as Mat Amount field can be input. In order to protect typographical errors in input, tolerances on the system calculated amount can be defined either in terms of absolute values or percentage formats. If the user input value in the Amount field exceed the tolerances, an error message is displayed at the deal.

PM.LD.PARAM

This affects the PM updates that are created by the LD module. The Pm Max Period field allows the user to limit the number of months for which LD passes 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 while creating this data that can be reduced by using a reasonable setting in this field.

SPF Settings

Due to multiple accounting and PM updates 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.

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

For both loans and deposits, if the Negative Rates field is selected to YES, a negative rate can be input in the Interest Rate field. It accepts the YES, NO or Null values and the user cannot modify this field after first authorisation. The default value is Null (with the same meaning as NO). YES is not permitted in the following cases:

• Discounted contract (Int Paymt Method set to 2)
• The Interest Basis field is set to S (special) that is, direct input of interest amounts
• Annuity type contracts
• The Capitalisation field is set to YES
• Contract with a value in Tax Int Key field, that is, contracts with interest tax
• Re-discount contracts
• Commitment contracts (category range 21095-21099)

If set to YES, the 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, the New Spread field accepts a negative value even if the resulting interest rate are negative.

S basis functionality in LD supports both the conventional and Islamic lending Business.

• When the bank sells an asset to customer with purchase price + mark-up amount (interest portion), the mark-up amount is agreed with the customer and it is calculated by using the interest rate. The agreed interest amount of the LD contract is stored as part of balances. This agreed interest amount is not changed due to any changes to the repayment amount or repayment dates or partial payment.
• The limit can be updated either for the principal portion alone or for the (principal + total agreed interest amount) portion of the LD contract. As per the parameterisation, the limit is updated for each contract.
• Partial payment can be made online for the principal amount and the accrued interest amount. Based on the parameter setup it is possible to do online repayment of interest, which is yet to be accrued.
• When the interest amount, which is yet to be accrued, is repaid then the subsequent interest payment schedules, depending upon the number of payments paid is removed from schedule definition or the maturity date should be adjusted to the number of payments paid.
• For the Live Interest field, if accounting entries are required for the interest portion of the contract,
  • Input in this field is allowed only for the LD contracts booked with interest basis as S Type and interest payment method as 1 – Interest bearing
  • Input is allowed only for Fixed rate and Periodic straight interest rate types.
  • Input is not allowed for drawdown from commitment contracts.
  • Input is not allowed when Capitalisation of interest is set as Yes.

    

• For the Update Limit Int field, if Limit has to be updated for the interest portion also of the LD contract,
  • Input in this field is allowed only for the LD contracts booked with interest basis as S-Type and interest payment method as 1 – Interest bearing.
  • Input is allowed only for Fixed rate and Periodic straight interest rate types.
  • Input is not allowed for drawdown from commitment contracts.
  • Input is not allowed when Capitalisation of interest is set as Yes.
• If the Live Interest field is set to YES, then it is mandatory to input the interest amount in the I-Type schedule (LD.SCHEDULE.DEFINE).

  

  The Tot Live Interest field in LMM.ACCOUNT.BALANCES stores the total interest amount (mark- up) of the LD contract.

  The Outs Live Interest field in LMM.ACCOUNT.BALANCES stores the outstanding interest amount of the LD contract, which gets updated after repayment.

  

• If the Live Interest field is set to Yes, then it generates the below accounting entries after LD authorisation.
  • DR LIVEDB (Principal Amount)
  • CR Drawdown Account (Principal Amount)
  • DR LIVEIN (Interest Amount) SPEC.ENTRY
  • CR LD Cap A/c (Interest Amount) SPEC.ENTRY

    

• Based upon the Accrual frequency set in LMM.INSTALL.CONDS, it raises the below accrual accounting entries.
  • DR LD Cap A/c SPEC.ENTRY
  • CR PL Category CATEG.ENTRY
• On the date of repayment, it generates the below accounting entries based upon the liquidation mode and the availability of funds in the customer account.
  • DR Principal Liquidation Account (Principal Amount)
  • CR LIVEDB
  • DR Interest Liquidation Account (Interest accrued amount)
  • CR LIVEIN
• LMM.ACCOUNT.BALANCES>>Outs Live Interest is updated after the repayment.
• The online partial payment for Bullet payment type contracts can be done and the Tot Interest Amt field needs to be amended with the new calculated interest amount.
• The Respite and Compression, partial payment options can be achieved by using the online partial payment functionality available in LD. It allows the user to make partial payments for the interest amount, which is yet to be accrued and passed necessary accrual adjustment entries.
  • In LMM.INSTALL.CONDS, setting the S Basis Rate Val field to No allows the user to input interest amount greater than the accrued interest.

    

  • DR Principal Liquidation Account (Principal amount)
  • CR LIVEDB
  • DR Interest Liquidation Account (Interest paid amount)
  • CR LIVEIN
  • DR LD Cap A/c (Interest paid amount – Interest accrued amount)
  • CR PL Category
• During early maturity the user is allowed to input the Interest amount that needs to be recovered from the customer in the Tot Interest Amt field. Remaining interest amount is reversed to the LIVEIN.
  • DR Principal Liquidation Account (Principal amount)
  • CR LIVEDB
  • DR Interest Liquidation Account (Value in Tot Interest Amt)
  • CR LIVEIN
  • DR LD Cap A/c (Tot Interest Amt - Interest accrued amount from LAB)
  • CR PL Category
  • DR LD Cap A/c (UN – Accrued amount – (Tot Interest Amt– Interest accrued amount from LAB)
  • CR LIVEIN
• Principal Increase is allowed for these contracts. However, it does not recalculate and pass adjustment entries for the interest portion.
• It is not possible to pre-close after doing the online partial payment on the same value date.
• There is no change in the PD related Interest bearing contract functionality like contract status change from PDO to NAB, Profit suspension, PD repayments, Write-off, and so on.
• If a new rate or new spread is defined in LD template, then the system computes the difference between the old interest amount and new interest amount, and accounting entries are raised for the adjusted interest amount. So, rate revision and spread revision are allowed for the fixed rate contracts with Live Interest setup.
• Accounting entries can be generated for the adjusted interest amount due to rate or spread change. The limit can be updated for the adjusted interest amount.

The interest rate is a fixed rate, usually for the life of the loan or deposit. Temenos Transact allows 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 to a periodic type.

It is possible to enter an interest amount rather than allowing the system to calculate the amount using fixed interest type and Interest Basis of S. Furthermore, the following functions are possible.

• Ability to define Principal Schedule
• Discounted contract
• Ability to change Interest Rate and Interest Amount
• Ability to change Maturity Date of the contract

Where there is an agreement to pay or charge interest at an agreed spread under or 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.

The Commercial Loan area uses the Periodic Manual interest type as it controls the loans, which are tied to LIBOR (London Inter Bank Offered Rate) type rates where the rate is agreed for a fixed period of 1 to 6 months. The option to add or subtract a spread is also available. The maintenance of this interest type is manual but it 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 to a fixed type.

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 is 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 then recalculates 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.

The risk-free rates are also stored in the PERIODIC.INTEREST table. These rates are only published rates and compounded daily to arrive at a final interest rate for a particular contract period.

It is enabled for discounted contracts as well. The only constraints being Rate Change Schedule (R schedule) can be defined on Interest schedule date. In addition, Principal or 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 prohibited for Floating rate or Periodic Manual types.

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

This interest rate type is enabled for S basis contracts as well.

The Int Coll Method field 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 gets collected concurrently only on that portion of the principal which is being repaid. Such interest is collected for scheduled repayments or ad-hoc repayments.

Charges are received from the client. Charge types are defined in the LMM.CHARGE.CONDITIONS application , and 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 the system defaults the charge amounts .

Charges can be taken on-line or as scheduled events. Read the Early Maturity Penalties section for more information.

Fees are paid to the client of the contract. The fee types are defined in the LMM.CHARGE.CONDITIONS application 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 the system defaults the fee amounts.

For drawdown issue fees the FT.CHARGE.TYPE or FT.COMMISSION.TYPE key may be specified directly in the DD Fee Code field.

Fees can be taken on-line, or as scheduled events.Read the Drawdown Issue Fees, Paying Fees To Agents and Multiple Charge Schedules sections for more information.

Commission may be taken on loan contracts (CATEGORY 21050 - 21089), in a similar method to interest. A commission rate is specified in the Comm Rate field, together with the day basis in the Comm Calc Method field. The commission is calculated based on the outstanding principal or highest balance for the period using the specified rate. It 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 CSN Calc Type field is HB.

Either the customer or the bank can pay the commission. This is identified by the Comm Paymt Method field, which can have three values:

• Interest Bearing - The customer can pay this commission at the end of the commission period and it is debited from the COM.LIQ.ACCT.
• Discounted - The customer can pay this commission at the start of the commission period and it is debited from the COM.LIQ.ACCT.
• Payable - The bank can pay this commission at the end of the commission period and it is credited to the COM.LIQ.ACCT.

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 Tax Principal Key, Tax Int Key and Tax Commission Key fields respectively, and the amount of tax is held in the Tot Princ Tax, Tot Int Tax, and Tot Com Tax fields.

The Tax Int Key field can be multi-valued to collect multiple taxes for deposit contracts.

The rate changed in TAX record already attached to LD effect only subsequent tax collection and no adjustment entries are raised for the tax already collected.

The APPL.GEN.CONDITION system table 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 automatically updates the Contract Grp field whenever the contract is changed.

The section APPL.GEN.CONDITION in the chapter System Tables user guide 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 Int Type and Tax Commission Type fields as opposed to the specific tax keys described above.

The Tax Int Type field can be multi-valued to collect multiple taxes for deposit contracts.

The Tax Int Type field takes precedence if Tax Int Key and Tax Int Type fields are given by the user (Tax Int Key field given by the user is ignored for calculations)

The TAX.TYPE.CONDITION system table 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 can 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.

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 has 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 are reversed along with penalty income and spread.

It is possible to suspend income accrued in a loan contract. The Asset Class field in LD is to be modified with the ID of ASSET.CLASS where the Income Recog field is set to NO. On authorisation of the contract, the accrued interest is suspended. The Overdue Status field is updated with NAB status online. Provision entries are moved to the Category set in ASSET.CLASS.PARAMETER for NAB Status. Entries for additional provision are passed online. It is possible to change to a better ASSET.CLASS, when interest starts accruing.

If there is a PD contract, then the change of ASSET.CLASS is to be done in PD. On authorisation, the Status field of PD and OVERDUE.STATUS in LD get updated with NAB. Accrued interest for PD gets suspended online. Provision entries are moved to the category set in ASSET.CLASS.PARAMETER for NAB Status. Entries for additional provision are passed online. The accrued interest of LD is suspended during COB.

To move the contract to a better ASSET.CLASS, the PD should be repaid first, making the status to become CUR. PD interest is recovered fully. Then the ASSET.CLASS in PD can be changed to a better class. During COB, the suspended interest in LD gets reversed. The ASSET.CLASS in LD is updated with the ASSET.CLASS mentioned in PD record.

The Mthly Amortisation field 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 can be defined in the Amortisn Period field. 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 or 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 or amortisation
• M – for monthly accrual or amortisation

The Amortisn Period field defines the Start Date and End Date in EB.ACCRUAL record created for accrual or amortisation.

The values in the Amortisn Period field can be:

• C - until end of contract
• nM – for n number of months
• nA – for n number of years
• R – until next schedule

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

If there are 2 schedules with same charge code on same day, the system generates EB.ACCRUAL only for one charge and the other one can be taken straight to PL.

It is also possible to reverse the earlier accruals or amortisation and rebook them daily by setting up ACCR.REV.PARAM. Read the Interest and Charges user guide for more information.

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.

Multiple charges and fees can be associated with schedule types. The calculation amount can be specified in the Chg Base Amt field as displayed above.

Valid input to this field may be as follows:

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 field. 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 field is used determines the account, which is to be used to pay or receive fees and charges as follows:

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

A charge is added into a lease agreement by updating the schedule.

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

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 Int Key or Tax Int 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.

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

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

MT202

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

A payment message is 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 is produced. Any fees or charges falling on the same date through the nostro is also added or subtracted from the payment amount.

The system produces 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 PAYINGAGENT if specified, and theSendpayment field is not set to Y.
• The Sendpayment field is set to NO.

The Sendpayment field can be used to suppress or force payments on an individual contract basis if required. Suppression of a payment that is sent requires an override.

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 LMM.ADVICES application .

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, which cover the loans department work.

For RFR contracts, the deal confirmation messages/advice has a zero interest rate and interest amount because the current interest period final rate is not available at the contract initiation. The final rate applicable is available during contract maturity, and the maturity confirmation (MT320) for RFR contracts has the actual interest rate and amount.

MT330

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

MT350

Settlement of interest at dates other than the maturity triggers 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.

MT910

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

MT935

This SWIFT message is used for Rate Change advice.For RFR contracts, this message is generated at the end of the interest period and it is not generated for daily rate changes.

It is possible to suppress confirmations and advices for an individual contract by setting the Send Confirmation field to NO.

The LD.LOANS.AND.DEPOSITS application, 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 deal changes as a result of the underlying base rate.However, for RFR contracts, the rate change advice is generated at the end of the interest period and not for daily rate changes.

A number of parameters are 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 LD Rate Change Adv field 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 are produced.

For changes to base rates, the Basic Rate Cng Adv field on the BASIC.RATE.TEXT application 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 the 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 are 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

These are amended to suit local requirements. Additional records are created to print specialised advices. Read the Delivery section of this user guide for further details.

SWIFT MT935 messages

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 is used to map from the activity details to the message details. The third column shows the DE.FORMAT.PRINT records that is used to create the printed advice.

LMM.ACTIVITY records, their relative mapping and print records are given below.

nn = last 2 digits of formatted CATEGORY

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

Formatting of CATEGORY code for DELIVERY keys

The DELIVERY formatting record used to print Loans and Deposit advices can 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.

• 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.
• In order to enable the production of specialist advices for particular types of Loans and Deposits when required, the Format Category field is provided on the LMM.ADVICEStable . This field is optional, but when present for a particular LD category, overwrites 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 Format Category field is present then the Format Category is used.

Otherwise, the following codes are assigned:

For example, the interest payment for a deposit with CATEGORY 21035 uses the 320.LD2801.1.GB format record. This is 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 is set to 21035 in which case the format record 320.LD2835.1.GB is used.

The LD module has the facility of setting the number of days prior to an event that an advice (For example, Maturity reminder) is sent to the customer. Usually this is set at the advice level through the LMM.ADVICES application. Entering a numeric in the Days Prior Post field determines the many days before the event that the physical advice is 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 Days Pre Advice field when creating or amending a contract then this number is the pre-defined number of days and supersedes the LMM.ADVICES information. This option is only available for an advice that allows the Days Prior Post field to be used. These are listed on the system help text for LMM.ADVICES.For RFR contracts, the days input in the above fields should be less than or equal to RFR Lookback Days to ensure the advice/message is not generated before the actual interest rate is calculated.

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 are processed only in the next COB.

As a result, some of the following actions during the Close of Business (COB) are possible while the others are not, as mentioned below.

• The user can input a new transaction.
• The system does not allow the user to amend a previous day’s transaction
• The user can amend a contract that was input during COB .
• The system does not allow the user to input back dated transaction
• The user is allowed to input commitment contract and drawdown against the same.
• The user cannot input drawdown against the commitment contract that was input prior to COB
• LD reports reflects only transactions that were input prior to COB
• The user cannot amend the contracts that were input prior to COB.