Introduction to Lending Compliance

This module covers the Indian specific functionality and model configuration for lending products.

Click here to understand the terms and abbreviations used in this module.

Minimum Tenor and Working Capital

As per the regulatory guidelines defined around the controls that are required for large borrowers, the bank needs to have a minimum tenor check on the loans for these borrowers.

Large borrowers are identified from the Central Repository of Information on Large Credits (CRILC).

As per the Reserve Bank of India (RBI) guidelines, the regulation doesn’t allow the banks to disburse any working capital purpose loans for a tenor of less than 7 days for large borrowers. This validation is built in the system during loan disbursements and amendments to ensure that the loans are not having a tenor of less than 7 days. The guideline also restricts any prepayment, partial or full, on loans before the completion of the 7 days from the loan start date.

The CUSTOMER application is used to facilitate the identification of the large borrower, through the Vis Type field.

The ENQ.CUSTOMER.DETAILS.IN enquiry will fetch the details of the Customer ID by giving the input as the Legal ID. The output will display the Customer ID, Short Name and current Sector of the customer along with a drill down which will open to the CUSTOMER,LARGE.BORROWER version for updating the sector of the customer. It is mandatory to input a value in the Vis Type field, if not an error will be displayed.

The ENQ.LARGE.BORROWER enquiry is used to fetch the details of the customers that are classified as large borrowers in the system. The output will display all the Customer ID with the Vis Type field defined as large borrower along with the Short Name and Sector of the customer and a drill down which will open to the CUSTOMER,LARGE.BORROWER (classify, remove large borrower) version where the user will be able to remove the large borrower type defined in the Vis Type field and make the field blank.

Penal Interest

The Reserve Bank of India (RBI) require banks to provide a specified portion of the bank lending budget to a few specific sectors like agriculture and allied activities, micro and small enterprises, poor people for housing, students for education and other low income groups and weaker sections. This is essentially meant for an all-round development of the economy.

Every bank in India is given targets and sub-targets for lending under the priority sector.

In the case of loans given to borrowers under the priority sector, no penal interest is charged for loans that have the principal amount up to INR 25000.

The penal interest can be levied for reasons such as default in repayment, non-submission of financial statements, etc. However, the policy on penal interest should be governed by well-accepted principles of transparency, fairness, the incentive to service the debt and due regard to genuine difficulties of customers.

The functionality allows the user to configure and capture the classification of a loan under the priority sector category, to prevent charging penal interest for the principal amount up to 25000 rupees.

Foreign Currency Advances

Foreign currency advances refer to advances that would help for financing the commercial operations abroad. Usually, these advances are granted to exporters for the purchase of raw materials and also for marketing and promotional activities for their exports. Advances are repaid after due receipt of foreign currency linked to the contract. The funds raised through foreign currency advances are used following the company’s need in various foreign currencies.

The exposure related to the foreign currency advances needs to be captured and monitored in the system.

The new version of the LD.LOANS.AND.DEPOSITS application allows the bank to extend the foreign currency loans while complying with the norms laid out by the regulatory for such advances that are above 10 million USD. Also, this version facilitates to mark if a particular loan is hedged or not. If the loan is hedged, the corresponding FOREX transaction, treasury contract currency and treasury contract amount can also be captured.

The system facilitates the generation of report so that, every month, the bank can monitor and review the unhedged portion of the foreign currency exposures of their customers whose total foreign currency exposure is relatively large.

The Foreign Currency Advances functionality allows the bank to:

• Extend the foreign currency loans above USD 10 million by adhering to the policy of their boards with regard to hedging of such foreign currency loans.
• Monitor on a monthly basis and review the unhedged portion of the foreign currency exposures of their customers, whose total foreign currency exposure is relatively large.

Loan Rolled Over

The term rollover refers to the practice of extending the due date of a loan.

India regulation restricts loans to rollover or extend maturity without repayment more than twice for a specific category of loans. There is an error preventing any more rollovers. As per the regulatory guidelines defined for rollover short-term loan contracts, the number of times a loan contract can be rolled over is 2.

This functionality allows banks to track and restrict rollovers for customer loan contracts created under the short-term loan product as per the regulatory circular and also allows users to repay past due loans.

If there is any error when the rollover is performed and a reversal needs to be done, there won’t be an increase in the rollover count. If the error requires an amendment then the bank will be able to amend without increasing the rollover count.

For tracking the number of rollovers, banks have an option to store the date of the rollovers and associated count of the rollovers. The count calculated by the system for the rollover transactions is not editable at the user level.

This functionality also allows users to link the rollover of the loan (created as a new contract) to a previous contract. Different kind of roll overs are possible. The following are some examples of typical rollover requests:

• Straight rollover: Only the term of the contract is extended.
• Decreased value rollover: Part of outstanding principal is adjusted using prepayment and the outstanding balance of the contract is rolled over to a new maturity.
• Increased value rollover: The rollover is executed with an increase in the outstanding principal of the contract.

NPA Validations and Calculations

The functionality allows banks to classify, monitor and manage the lifecycle of the accounts and non-performing assets as per the Reserve Bank of India’s (RBI) regulations. The assets are classified as following:

• Special mention account (SMA), up until 90 days, classified as SM0, SM1, and SM2.
• Non-performing asset (NPA) with various categories, such as NPA-substandard, and NPA-doubtful and loss, beyond 90 days.

Reserve Bank of India’s (RBI) has two high-level asset classifications, the special mention account (SMA), up until 90 days, classified as SM0, SM1, and SM2, and beyond 90 days, classified as NPA with various categories, such as NPA-substandard, and NPA-doubtful and loss.

A non-performing asset (NPA) is a loan or any advance for which the payment remains overdue for a period of more than 90 days.

The past-due assets are classified based on their ageing lifecycle and the recoverability quality of the asset. There are two specific stages of the classification - special mentioned account stages (SMA) and non-performing asset (NPA) stages. The SMA stage is at a facility or asset level while NPA is at a borrower level.

All assets will be classified as NPA, if any other facility offered to the customer moves to the NPA status. A non-performing asset (NPA) is a loan or any advance for which the payment remained overdue for a period of more than 90 days. After this period, the bank will access the asset classification of the loans and advances based on ageing requirements of the dues and respective provisioning as per the Reserve Bank of India’s (RBI) regulation.

The asset classification based on the overdue days is achieved using the EB.RULES.VERSION application, and using the PV.LOAN.CLASSIFICATION, PV.MANAGEMENT and PV.PROFILE applications.

Based on the risk classification, the provision amount is calculated based on the base amount and predefined percentage.

Bank Guarantee Validations and Restrictions

An important criterion for judging the soundness of a banking institution is the size and character, not only of its assets portfolio but also, of its contingent liability commitments such as guarantees, letters of credit, etc. As a part of business, banks issue guarantees on behalf of their customers for various purposes.

The guarantees executed by banks comprise both performance guarantees and financial guarantees. The guarantees are structured according to the terms of agreement, viz., security, maturity and purpose. With the introduction of risk weights for both on-balance sheet and off-balance sheet exposures, banks have become more risk sensitive, resulting in structuring of their business exposures in a more prudent manner.

This functionality allows users to define the guarantee beneficiaries and validate the specific records.

The PAYMENT.CATEG.PURPOSE application allows users to define the beneficiary categories for the guarantees.

The following versions of the MD.DEAL application are introduced for each type of beneficiaries of the guarantees:

• MD.DEAL,IN.INST.GUARANTEE.DGSD.
• MD.DEAL,IN.INST.GUARANTEE.CSTM.
• MD.DEAL,IN.INST.GUARANTEE.IATA.
• MD.DEAL,IN.INST.GUARANTEE.STEX.
• MD.DEAL,IN.GUARANTEE.FINANCIAL.
• MD.DEAL,IN.GUARANTEE.PERFORMANCE.
• MD.DEAL,IN.GUARANTEE.EXIM.

The IN.MD.CUST.SECTOR.RISK.CLASS application is introduced to identify the sector values, using the entered Sector codes.

The ENQ.MD.IN.INST enquiry lists the issues of the guaranteed based on the selected MD.DEAL version.

Merchanting Trade and Interest on Import Bills

This functionality allows banks to monitor and control the merchanting trades. Merchanting trades are transactions when there is a trader in India buying and selling goods from country A and country B with the goods never coming to India. The merchanting trades happen when the supplier of goods is resident in one foreign country, the buyer of goods is resident in another foreign country and the merchant or the intermediary is resident in India. The merchant or the intermediary will be resident in India, will book the order from the buyer, place the order with the supplier, and coordinate the shipment of goods from the supplier’s country and deliver the same in the buyer’s country.

The system performs the following primary checks for the merchanting trades:

• Is the deal reasonably profitable.
• Tenor < 9 months (end to end).
• Max outlay (4 months).
• Earmarking.

The following items are introduced as part of this functionality:

• The AC.LOCKED.EVENTS,MTT.IN version is used to create locked events.
• The AC.LOCKED.EVENTS,REVERSAL.IN version is used to reverse locked events.
• The MTT.EARMARKING.IN enquiry is used to check the earmarking funds and to remove the locked funds.
• The INLEND.MTT.LC.DRAWING and INLEND.MTT.LETTER.OF.CREDIT routines can be attached in any drawings or LC versions respectively to validate the Merchanting Trade Transaction (MTT) cycle.

The following fields are added to the INLEND.IMPORT.EXPORT.ATTRIBUTES application:

• Mtt Period: This field allows the user to provide the maximum merchant trading transaction period in months, for example, 9M.
• Exp Proceed Prd: This field allows the user to provide the maximum period for the export proceeds to be realized, in months, for example, 4M.
• Mtt Exp Purpose Code: This field allows the user to provide the purpose code for export proceeds.
• Mtt Imp Purpose Code: This field allows the user to provide the purpose code for import proceeds.

Import and Export Data Processing and Monitoring System

The functionality allows banks to manage the import process and transactions. The system allows the issuance of a bill of entry (BOE), the BOE acknowledgement letter, and if needed, the extension of the BOE, settlement and closure. The functionality also allows the user to upload of an outward remittance message (ORM).

IDPMS (Import Data Processing and Monitoring System) is an RBI (Reserve Bank of India) system introduced to ensure the better monitoring of import of goods and software and facilitating the AD (authorised dealer) banks to report various returns through a single platform. It was launched to overcome the shortcomings in the import reporting processes.

IDPMS was launched by RBI to overcome the shortcomings in the import reporting processes.

IDPMS designed and implemented a robust and fool proof procedure to ensure that all import documents reach the banking channel for settlement against the payment made and also ensure a vigorous and effective follow-up procedure for monitoring the closure of import transactions.

The Reserve Bank of India launched a comprehensive IT-based system called Export Data Processing and Monitoring System (EDPMS) for better monitoring of the export of goods and software and facilitating authorised dealer (AD) banks to report various returns through a single platform.

The following applications are introduced as part of the functionality:

• The INLEND.IMPORT.EXPORT.ATTRIBUTES application stores all important configuration data and other data for the IDPMS and EDPMS functionalities.
• The INLEND.IDPMS.ORM application stores the data for all the outward remittances made.
• The INLEND.IDPMS.BOE application stores the data about the bill of entry.
• The INLEND.BOE.SETTLEMENT application is used to map the invoices amounts in the BOE with the ORM.
• The INLEND.IDPMS.BTT application provides details of the utilised and unutilised amount of an invoice.
• The INLEND.PORT.LIST application stores the details of ports designated for imports or exports and their allotted port codes. The port code is a 6 digit alphanumeric code, allotted by the Government of India.
• The INLEND.IDPMS.OBB application is introduced to store the details of the bill of entry tagged to the other bank’s AD code and requested for settlement by a different bank.
• Multiple enquiries are provided as part of the functionality to list the details of the IDPMS BOE, BOE settlement, ORM, ORM settlement, and invoice records

This functionality also allows banks to manage the export process and transactions. The Reserve Bank of India had launched a comprehensive IT based system called Export Data Processing and Monitoring System (EDPMS) for the better monitoring of export of goods and software and facilitating AD banks to report various returns through a single platform. Additionally, direct NOSTRO payments can be performed in EDPMS.

The following applications are introduced as part of the functionality:

• The INLEND.IEC.STATUS application stores all important configuration data and other data for the IDPMS and EDPMS functionalities.
• The INLEND.EDPMS.RECEIPT.DOCUMENT application holds the data of the shipping bills.
• The INLEND.EDPMS.TF.PAYMENT.INFO application holds data about the received payments.
• The INLEND.EDPMS.PAYMENT.REALIZATION application holds data about the received payments.
• The INLEND.IDPMS.OTHER.BANK.FIRC application holds the foreign inward remittance certificate (FIRC) issued by other banks.
• The INLEND.EDPMS.ERROR.CODES application stores the error codes as specified by the EDPMS system.

Issuance of Electronic Bank Realisation Certificate (eBRC)

This functionality allows banks to create electronic bank realisation certificates (eBRC). The system validates whether the bills are closed in EDPMS before any eBRC is issued. The system also has an option to cancel the eBRC.

Bank realisation certificates (BRC) are issued by banks based on the realization of payment against export by an exporter. BRC will be provided only against export. Hence any advance payment received will not be entitled for BRC.

Any firm applying benefits under the foreign trade policy is required to furnish valid BRC as proof of realization of payment against exports made (foreign inward remittance certificate, FIRC) along with supporting documents such as invoice, shipping bill, custom documents, etc.

The following application and enquiries are introduced with this functionality:

• The INLEND.EDPMS.EBRC application is used to capture the details required to generate eBRC for the shipping bill.
• The INBASE.IFSC.CODE application is used to store the IFSC details of the branch or bank.
• The ENQ UPLOADED.EBRC enquiry is released to list the eBRC’s with the error code not equal to 000.
• The ENQ FAILED.BRC enquiry is released to display all the BRC’s with the Error Code not equal to 000 and not equal to Null.
• The ENQ CANCELLED.BRC is released to display the list of eBRC’s which have the status as cancelled.

New fields are added to the INLEND.IMPORT.EXPORT.ATTRIBUTES application to provide the required fields for uploading the eBRC to the directorate general of foreign trade (DGFT) server.

SFMS - Structured Financial Messaging System

This functionality allows the user to capture the Indian Financial System Code (IFSC) codes of the banks and generate INFINET (Indian Financial Network) Format Number (IFN) messages whenever transaction happens in the LC (letter of credit), BG (bank guarantee) or Bills application, that warrants the exchange of messages between two banks or branches within India.

The structured financial messaging system (SFMS) is a secure messaging standard that serves as a platform for intra-bank and inter-bank applications like the National Electronics Funds Transfer (NEFT), Real Time gross Settlement (RTGS) and so on. It is an Indian standard that is similar to the SWIFT standard used for financial messaging globally.

The bank or branch within India for whom the IFSC code is to be captured is created as a customer in Temenos Transact following an entry in the DE.ADDRESS application and also in the RD.CENTRAL.BANK.DIR application.

The DE.MAPPING application channels the SFMS messages based on the IFSC bank code.

The following versions and applications are introduced with this functionality:

• The CUSTOMER,INLEND.BANKBRANCH.INPUT version is introduced to hold the basic minimum details that are required to create the customer record.
• The INLEND.SFMS.HEADER.DETAILS application is used to hold the values that will be used for the creation of the header in the SFMS message.