Trade Finance

Trade finance

Trade Finance refers to the various forms of financial support and financial transactions used in international trade. The Trade Finance module in T24 consists of two closely related applications, LETTER.OF.CREDIT LETTER.OF.CREDIT and DRAWINGS,, which work together to provide a wide range of support for Trade Finance business. DRAWINGS  A letter of credit is a document document issued mostly by by a financial institution, institution, used primarily primarily in trade trade Finance, which usually provides an irrevocable payment undertaking to a beneficiary against complying documents as stated in the Letter of Credit. Letter of Credit is abbreviated as LC or L/C, and often is referred to as a documentary credit or just as credit.  A Letter of credit credit can also be revocable, revocable, confirmed, confirmed, unconfirmed, transferable, transferable, back to back or standby. LC application supports opening and amending LCs as well as Documentary collections – both import and export. It facilitates all the roles of a bank with respect to LC – advising, confirming, negotiating. Negotiation of LCs and collections are done through DRAWINGS application. application. In order to enter a drawing, the Letter of Credit Collection parent contract must first be set up in order to define the types of drawings that can be made.

Drawings can be Usance, Sight or Mixed. DRAW.NEGOTIATION DRAW.NEGOTIATIO N application serves as a s a front end tool to input multiple drawings into DRAWINGS application. This is particularly useful in the case of mixed payment negotiations. Trade Finance transactions can be handled in any currency. Drawings made under LC can also be in a different currency to the parent LC. Charges taken under an LC can also be denominated in a currency different from both the LC and the drawing. LC and DRAWINGS automate accounting, limit exposure, position updating, control and administration of trading activity and ensure efficient delivery of the related advices, documents and payments. 2nd page You would have got brief idea of the Trade Finance module and the role of Letters of credit. Now that you know what a letter of credit is, we will explain you pictorially how it actually works.  As you can see, the the parties involved in International trade are shown on the screen.  A deal is struck struck between the Seller Seller and the Buyer who are in different different countries. After the contract contract is concluded between buyer and seller, on request from the buyer, buyer's bank supplies a letter of credit to seller. Seller consigns the goods to a carrier in exchange for a bill of lading. Seller provides bill of lading to his bank in exchange for payment. Seller's bank exchanges bill of lading for payment from buyer's bank. Buyer's bank exchanges bill of lading for payment from buyer. Note that banks deal only with documents required in the letter of credit and not the underlying transaction. The issuing bank is obligated to pay under the letter of credit only when the stipulated documents are presented and the terms and conditions of the letter of credit have been met. Buyer provides bill of lading to carrier and takes delivery of goods. Thus, the cycle is complete. 3rd page LC module is dependent on many other applications/functionalities applications/functionalities in T24.

CUSTOMER: Customer records are necessary to have details of the Counterparty and Broker.  ACCOUNT::  ACCOUNT We need accounts for payment and receipt into customer settlement accounts and brokerage settlement accounts. Delivery messages to the Customer for debit/credit of his account, Broker for confirmation of trade and Depository for completion of settlement of the trade are all generated.  Accounting entries are generated on authorisation authorisation of transactions. transactions. LCs can be issued after setting up of limits and collateral. Transactions Transactions can be done without creating Limits also. In this case, System will generate an Override message notifying the absence of a Limit. On authorisation, System will automatically automatically create a Limit for the Customer for the relevant Limit Product. Other static tables which LC module makes use include CURRENCY, COUNTRY, COUNTRY, FT.COMMISSION.TYPE, etc. 4th page LC and DRAWINGS applications applications use hard coded category range 23000 – 23999. These codes could be used to reflect various LC and Collection types in line with reporting requirements like, LC Import Sight, LC Import Acceptance, LC Export sight confirmed, Collection document outward sight etc.  A default category category code may be specified specified for each type of of LC in LC.TYPES LC.TYPES table. You will learn learn more about this later. Category of an LC can be changed after authorisation through internal amendment. Further, P & L category codes for collecting and writing off charges and commission and internal provision account category codes used are indicated in LC.PARAMETERS. LC.PARAMETERS. 4th page

PERIODIC INTEREST TABLE PERIODIC.INTEREST PERIODIC.INTERE ST table defines, for each currency, interest rates for any time period desired by the user. These periods can be defined either in months, e.g. 1 month, 2 months, 3 months, 6 months etc or  in days, e.g. 7 days, 15 days, 30 days da ys etc. For each period defined by the user, both a BID and OFFER rate can be entered. Periodic interest is relevant in case of discounted drawings.

6TH PAGE In Trade finance, Bank can set up charges either at the time of L/C issuance or Advising, at anytime afterwards, or at the time of L/C payment or negotiation (or afterwards as long as the record is still available for drawing). For certain types of LCs it is possible to take additional charges until they mature. Charges/commissions are collected using the table FT.COMMISSION.TYPE. In this table, the minimum and maximum commissions, regardless of any special conditions, can be se t through the fields OVERALL.MIN.AMT and through OVERALL.MAX.AMT respectively.  Accrual or amortisation of charges are possible in FT.COMMISSION.TYPE. 7TH PAGE CHARGES AND COMISSION

LCs may often need charges/commission to be collected based on the LC period.  A charge may be made periodically, e.g, monthly, quarterly etc. The field CHARGE.PERIOD defines the number of months that constitute a charging period. The input in this field is shown as 1, 3, 6, 9, 12 or 24 indicating monthly, quarterly, half-yearly, nine-monthly, yearly or  bi-annually. To give an example, a contract lasting one year, with CHARGE.PERIOD set to 3, would incur 4 times the defined commission amount, since the period has been defined as quarterly. In conjunction with CHARGE.PERIOD, the field MINIMUM.PERIOD indicates the minimum number of  months comprising the smallest allowable charging period. The inputs in this field can also be 1, 3, 6, 9, 12 or 24. What is the functionality when both the fields are input? The contract period is divided into a number of charging periods as defined in CHARGE.PERIOD. This is compared to the value in MINIMUM.PERIOD. If the MINIMUM.PERIOD is a greater value than CHARGE.PERIOD, then this value is applied to calculate the final chargeable amount. 8TH PAGE SETTLEMENT RELATED

There are actually no standard settlement rules for accounts in LC and DRAWINGS application. If account numbers are input for opener, beneficiary, advising bank etc., then they are defaulted while collecting charges. If payment method is indicated as NOSTRO in DRAWINGS application, then the payment account is defaulted using NOSTRO.ACCOUNT for the payment currency. CURRENCY RELATED You will see more dependencies for LC module. COUNTRY table contains static details of each Country, the currency codes etc. LC makes use of  HOLIDAY table to check whether maturity or other scheduled activity date is a working day or not for an LC transaction. CURRENCY.PARAM: This table contains common elements of each Currency. This table ensures that the same numeric code and number of decimals are used for a currency, across different Companies in a multi-company environment. LC makes use of CURRENCY table for exchange rates whenever a currency conversion is involved. LC also makes use of currency markets defined in CURRENCY.MARKET table. It is possible at a Currency level to specify separate rates for each market. Up to 99 markets can be indicated in CURRENCY.MARKET table. Consolidation keys are formed market wise. Markets beyond 9 will be consolidated with the market type of the first digit, for example market 10 will be consolidated as 1. CURRENCY RELATED

Choices are available in LC application to indicate the interest day basis. Interest day basis is used for calculation of Discount and Load amounts on Drawing contracts and also for  amortising charges over the life of LC. This is defaulted from Currency table, but could be changed by the user. The various methods under Interest Day Basis are listed here.

\\\

PARAMETERS We now move into an important discussion about parameters tables pertaining to LC module. The various parameter tables can be listed as: LC.PARAMETERS

LC.PARAMETERS is a top-level parameter table containing parameters for processing LC and DRAWINGS application. ID is Company Code. The default Currency market in LC transactions can be mentioned in the field CURRENCY.MARKET. For  charges, another currency market can be specified through the field CHARGE.CCY.MARKET. The fields AMR.CYCLE.L.CCY and AMR.CYCLE.F.CCY defines the frequency of amortisation process in local currency and foreign currency. System runs the amortisation process monthly. But the user can define the day on which the amortisation process is to run in a month. Similarly, the interest accrual on discounted drawings can be done daily/monthly for local currency and foreign currency. The related fields are DIS.CYCLE.L.CCY and DIS.CYCLE.F.CCY. RECALCULATE.AMORT indicates whether amortization of charges has to be reversed and recalculated if a discount drawing is amended. The recalculation is done only when this field is set to "YES“. CLOSURE.DAYS specify the number of days after the expiry date when LC or Collection will be moved from LIVE file to History file.

If specific closing date has not been input for an LC, this field will determine the default Closing date for  the LC. The number of days specified in the CLOSURE.DAYS will be added to “Expiry Date” of the LC to arrive at the CLOSING.DATE. On this date, if there are no drawings or charges outstanding under this LC, the live file is moved to History. PRE.ADVISE.DAYS contains the number of days after ISSUE.DATE that PRE-ADVISED L/Cs will be removed from the file if no action is taken. COLL.EXTN.DAYS field is applicable only for Collection documents. This helps keep the Collection document live as long as it is not fully utilised. On the Original Expiry Date, the system rolls over the Expiry date by the number of days specified in this field. Thus, this field helps in tracking the bill and sending tracers. Sometimes, due to non-availability of credit line or due to some other business reasons, advising/nominated bank will add confirmation to an Export LC only for a part amount. Limit information could be opted for unconfirmed portion of partially confirmed Export LC through UNCONFIRMED.LIMIT field. This means that the amount confirmed only needs to be updated in credit limit of the issuing bank but not the full amount of the LC. For example, if the field UNCONFIRMED.LIMIT is set to YES and an Export LC of USD 100,000 is partially confirmed for 40,000, this will hit the Product Limit line with USD 40,000 and default Limit line with USD 60,000 for information. But, what, if the field UNCONFIRMED.LIMIT is set to NO? Then the product limit line will be hit with USD 40,000 and the information limit line is suppressed. You would have now got the functionality.

This field is a one time input only.

Banks generally take provisions/ cash margins from the Customer for LC transactions. If the limit is to be impacted with net of provision, then the field LIMIT.WITH.PROV should be set to YES. Setting this to NO, would ensure that irrespective of the Provision taken the limit would be impacted for  the entire Liability. The field EXCHG.TOLERANCE is used to indicate the tolerance that can be ignored while calculating the limit amount minus provision amount in case of foreign exchange calculations. When 100% provision is taken on a Foreign Currency LC, the limit when calculated in Limit currency may work out to 100.01% or 99.78% depending on the exchange rate. System will ignore the difference if the values are within that specified in this field. Valid input will be percentage from 1 to 100.

Let us look at some report/advice related fields. REIMBURSE.DAYS indicates the number of days before maturity when the reimbursement message should be sent in case of Usance Drawing. REVOL.ADVICE.DAYS field facilitates control of the number of days prior to generation of advice before next revolution. MATURITY.USANCE is used to report imminent maturity of Usance drawings.

COLLECTIONS.DUE will report imminent due date of Collections.

The field DEL.WITH.NO.DISCREP is associated with export LC. If Yes is indicated, MT 750 and 1750 messages are produced whether drawings are discrepant or not. If No is indicated MT 750 message is produced only if drawings have discrepancies. Transaction Codes from 500 to 599 are earmarked for LC/Collections. These codes are used in accounting entries for narrating the underlying transaction.

PAY.TRANS.CR and PAY.TRANS.DR fields are for Credit and Debit entries for payments, respectively.

REIMB.TRANS.CR and REIMB.TRANS.DR are used for credit account entries and debit account entries for reimbursement, respectively. DISC.TRAN.CODE.CR and DISC.TRAN.CODE.DR are for credit account entries and debit account entries for LCs discounted, respectively. LOAD.TRAN.CODE.CR and LOAD.TRAN.CODE.DR identify the transaction codes for credit account entries and debit account entries for LCs discounted with load (spread) amounts. We continue with some more fields related to transaction codes. UNCOLLECTED.TR.CR and UNCOLLECTED.TR.DR are fields to be used when entries are created relating to charges under L/Cs that are uncollected. WRITE.OFF.TR.CR identifies the Transaction code to be used on Credit A/C Entries for charges written off under L/Cs.  AMORT.TRANS identifies the Transaction code to be used on Credit A/C entries for Amortisations under  L/Cs. PROVISION.CR and PROVISION.DR specifies the Transaction code to be used when Provision (Cash Margin) credit/debit entries are passed.

What is the rounding that should take place while debiting or crediting a Customer’s account? The rule can be set up in the field ROUND.RULE of LC.PARAMETERS. In this field, an ID from the EB.ROUNDING.RULE is attached. The options are NATURAL, ROUNDDOWN, ROUNDUP, TAX.DOWN, TAX.UP or NONE.

You will now look into fields related to PL category.

DISC.CAT.CODE specifies the PL category code to be debited / credited with the discount amount for  discounted drawings.

LOAD.CAT.CODE specifies the PL category code to be debited / credited for discount spread amount for  discounted drawings. UNCOLLECTED.CATRG assigns the PL category for charges claimed and booked to PL, but yet to be collected from the party concerned. WRITE.OFF.PL: This field identifies the PL Category code to be used when claimed charges are written off. EXCH.PRFT.CAT: The exchange profit or loss arising on account of spread on the exchange rate specified at the drawings will be credited to this PL category. This spread actually represents the difference between the rate collected from the Customer and the Treasury rate and is meant for the Trade Finance Department. DIS.RETAIN.CODE: Identifies the category code where excess interest will be posted if discounted drawings is amended and excess interest is not paid back to the Customer.

Cash margins are collected by Banks from Customers on LCs.  A default category code to credit the cash margin amount can be set in the field PRO.CATEGORY.

The category specified will be that of an internal category code between 10000-19999. PAY.SUBDIVISION field identifies the type of transaction when an entry is raised for internal account. For  example, if “1” is indicated here and if 16505 Category code is proposed to be used for Internal account, System will use USD165050001 for USD Provision and GBP165050001 for GBP Provision. Thus, the sub-division will be used whenever an internal account number is generated by the system for account entries related to LC payments. CHEQUES.ISSUED.ACC, B.P.ISSUED.ACC and DRAFTS.ISSUED.ACC fields indicate internal Accounts to be credited for payments under LC made through local currency cheque, Bankers Pay order and Drafts respectively.

Delivery process in LETTER.OF.CREDIT and DRAWINGS applications allows us to produce additional messages/advices other than standard ones provided by the system. Through the soft-delivery mechanism, the user can attach any additional message and send it via delivery. To have soft delivery option, the field BACKWARD.DELIVERY has to be set to “NO”. LC.CLASS.TYPE and EB.CLASS.NO multi value fields are necessary for the soft delivery set-up. The field TAKEOVER.PROCESS is designed for implementers in the change over process, where the data have been taken over from the old system to T24. If it is set to YES, no delivery will be produced. This field should always be set to NO during the real transaction inputting. CUST.BY.ORDER field is mainly used in Delivery to signify the sender of the Message. Information in this field will be used in Swift messages - Tag 50 representing Ordering Customer.

Now, you will be wondering where are the different types of LCs handled defined? This is done in the parameter table LC.TYPES. This table is used to set various types of LCs and how T24 will treat the transaction through its various phases from opening, drawings till maturity. Features like default category code, import or export, transferable or not, confirmed or unconfirmed, documentary collection or not, whether clean credit, whether back to back or Standby, the payment method for the credit etc are recorded in this table. LC.TYPES

Now, you will be wondering where are the different types of LCs handled defined? This is done in the parameter table LC.TYPES. This table is used to set various types of LCs and how T24 will treat the transaction through its various phases from opening, drawings till maturity.

Features like default category code, import or export, transferable or not, confirmed or unconfirmed, documentary collection or not, whether clean credit, whether back to back or Standby, the payment method for the credit etc are recorded in this table.

The ID of a LC.TYPES record can have from 2 to 4 alphanumeric characters. For example, CDIS can represent Collection Documentary Inward Sight, IAC can mean Import Acceptance Confirmed and so on. LC types are added/provided keeping in view the Trade finance business and the future requirements of  the bank. The field CATEGORY.CODE will assign the category code for the particular LC type. This will be the default code on input. Remember, this value cannot be modified if there are outstanding LCs under this LC.TYPES. The LC.TYPE has to be specified as IMPORT (I) or EXPORT (E). T24 will use this setting to dynamically configure which fields are available and mandatory when opening or amending an LC. This field cannot be modified once LC transactions under this LC type have been entered.  An LC can be a confirmed one or unconfirmed. This is specified in the field CONFIRMED. For export LCs, this field will have an impact on Limit processing. Again, for import LCs, this helps for Confirming request to receiver – which reflects in Tag 49 of MT 700 message. The ID of a LC.TYPES record can have from 2 to 4 alphanumeric characters. For example, CDIS can represent Collection Documentary Inward Sight, IAC can mean Import Acceptance Confirmed and so on.

LC types are added/provided keeping in view the Trade finance business and the future requirements of  the bank. The field CATEGORY.CODE will assign the category code for the particular LC type. This will be the default code on input. Remember, this value cannot be modified if there are outstanding LCs under this LC.TYPES. The LC.TYPE has to be specified as IMPORT (I) or EXPORT (E). T24 will use this setting to dynamically configure which fields are available and mandatory when opening or amending an LC. This field cannot be modified once LC transactions under this LC type have been entered.  An LC can be a confirmed one or unconfirmed.

This is specified in the field CONFIRMED. For export LCs, this field will have an impact on Limit processing. Again, for import LCs, this helps for Confirming request to receiver – which reflects in Tag 49 of MT 700 message. The LC has to be specified whether Transferable or not, in the field TRANSFERABLE of LC.TYPES. If Yes is opted here, in Export LCs, system allows transfer of LC to third party. In Import LCs, this prints data for Transferable LCs on Swift messages. Field STANDBY specifies if the LC.TYPE supports Standby L/C or not. Please note, as a standard feature, the option YES is not allowable for Transferable and Standby LCs together. The payment method under LC can be of different types. In a Sight payment LC, payment will be made at sight against compliant presentation. Where the LC is a Acceptance LC, the payment will be made on maturity subject to acceptance of the drafts drawn under the Bill.

Payment Type can be N, if the letter of credit provides for Negotiation. Mixed payment functionality allows one to handle Letters of Credit that have payments partly on sight basis and partly on deferred basis. Direct Credit Reimbursement is a Deferred payment LC where payment will be made at a future date against compliant presentation. Based on input for a product here, T24 will determine which settlement type is allowed under this. For  example, if P has been defined here, A or D type of drawings will not be allowed under this product. CLEAN.CREDIT field should be set to YES if the underlying LC is meant to be handled without documents. Banks also receive documents for collection under L etters of credit. DOC.COLLECTION if set as yes, means the LC.TYPE is only meant for documentary collections.  Again, CLEAN.COLLECTION, if set to YES means, the underlying collection is meant to be handled without documents.

The user can specify whether back to back processing is possible in the field BACK.TO.BACK. If set to YES, then the LC.TYPE of the proposed back to back LC should be mentioned in the next field BACK.LC.TYPE.

he field UCPDC.DEFAULT specifies the fields on the LETTER.OF.CREDIT application in which defaulting is to be suppressed on cross validation. The field PRE-ADVISED contains a number of the Preadvised LCs outstanding for a LC.TYPE. Please note, this is a no input field.

Cases of duplication in transactions may happen in LCs. To overcome this, duplicate check is possible through the field DUPLICATE.CHECK. The rules/conditions for duplicate checks are pre-defined in the table EB.DUPLICATE.TYPE. The ID ought to be suggestive of the purpose of the check. You can specify the application for which the check is intended in the field APPLICATION. The field values that are to be compared have to be specified in the multi-value fields called FIELDS. The relevant ID from this table is attached to the multi-value field DUPLICATE.CHECK of LC.TYPES. When an LC of the chosen type is input, System creates a record in EB.DUPLICATE, if not already present, and checks this with subsequent transactions for possible duplicates. T24 generates overrides if any duplicate data is found. Details retained for comparison for the period are defined in the field PURGE.DAYS of  EB.DUPLICATE.TYPE. In the example shown, a transaction will be termed duplicate only if the EXTERNAL.REFERENCE and LC.AMOUNT are same as that of another transaction.

You learnt about duplicate checking for LC transactions. We will show you a demo for creation in EB.DUPLICATE.TYPE. The purpose is to check duplication of fields in APPLICANT, BENEFICIARY, LC.CURRENCY and LC.AMOUNT in LETTER.OF.CREDIT application. The record has been created in EB.DUPLICATE.TYPE. In the next demo, you will learn how this record will be put to use for duplicate checking. LC.CLAUSES

Standard LC clauses are held in the table LC.CLAUSES. They can be included in a Letter of Credit or  Collection by the use of a code, avoiding the need for retyping. The ID of a LC.CLAUSES record can be up to six alphanumeric characters. Full description of the clause is given in the field DESCR. The clauses are input in the field ADDITIONL.CONDS where the user may enter free-format text. The codes defined in LC.CLAUSES can be invoked in CLAUSES.TEXT. You can see in the screenshot showing LC application, the code has been input. On validating the code gets expanded to the full text.  ACCOUNT.CLASS

With regard to LC, in ACCOUNT.CLASS, internal categories are specified to facilitate automatic debit/credit by the system. For example, LCAMORT record specifies the internal category for amortisation of charges and commissions, instead of immediately booking to PL.

LCDIFF record is created to post the differential amount on account of application of exchange rate for  the currencies involved in the transaction. TFLC record is to default a suspense account in case there is no NOSTRO account for the credit currency when bill proceeds are remitted within DRAWINGS application. CUSDEBIT record is to specify a internal category when a customer account is not available for debit in case of sight bills. It is essential to open internal accounts in local currency for these Account Categories. Even if present business does not warrant such setup, it is recommended to create them for future use. DR.INT.CALC.COND

Drawings can be discounted on Export or Import Letters of credit. In a Discounted Drawing, the method of  calculation of Discount component can be specified using DR.INT.CALC.COND. INT.CALC.CCY field identifies the Currency for calculating the discount amount. The value can be DRAW.CCY or LCCY. The distinction between the two methods can be explained with an example. Let us consider Discount party charged is Beneficiary. Assume local currency is USD. Case 1: INT.CALC.CCY is LCCY, and CONV.RATE is BUY. Document amount of GBP 100,000 will be converted using the Buy rate, say 1.45 resulting in USD 145,000. On this amount, Interest as defined will be calculated and the interest thus arrived would be (say Interest @7% for 100 days) USD 2,780.82.  Assume the Customer has contracted the Drawing at 1.46

The payment would be for USD 146,000 - 2,780.82 = 143,219.18 Case 2: INT.CALC.CCY is DRAW.CCY, and CONV.RATE is SELL,  Assume the GBP interest rate is 5% and the bill period as 100 days. In this instance, the interest amount will be GBP 100,000 @ 5 for 100 days = GBP 1,369.86 The local equivalent of GBP 1369.86 @1.48= USD 2027.39 (1.48 being the SELL rate). If the Drawing were contracted at 1.45 and the payment currency is USD (Local), Then the credit amount shall be USD 145,000 - 2,027.39 = USD 142,972.61 So, you see in the first case, the entire Drawing amount is converted into local currency at a rate specified in CONV.RATE field in DR.INT.CALC.COND. On arriving at the Discount amount, the same CONV.RATE would be applied to calculate the Drawing currency equivalent that is populated in DISCOUNT.AMT of DRAWINGS application. In the second case, the discount is calculated on the Drawings currency and applied in DISCOUNT.AMT of the DRAWINGS application. Local currency equivalent is shown in the field DISC.AMT.LOCAL of  DRAWINGS , which is arrived at as per the conversion rate in CONV.RATE in DR.INT.CALC.COND. LC.ENRICHMENT

The Trade Finance module makes extensive use of short codes, to minimise input time and effort. Thus, LC.ENRICHMENT holds enrichment descriptions for various codes/abbreviations used in LC transactions. You can see in the screenshot, the ID 2 holds the enrichment for CHRG.STATUS field of LC application.

The next screenshot you see holds the enrichment for ID as A. When used in the field OPERATION of LC application, it means “Amendment of Letter of Credit”. Again, when used in field PAY.TYPE of LC.TYPE, it means “By acceptance”. Some of the single letter codes, such as I, A, Y etc, must be input with a preceding full stop (.) because they can be confused by T24 function codes. LC.ADVICE.TEXT

When creating Letters of Credit (Import), Banks have to enter lengthy document descriptions with the details to which the Beneficiary needs to adhere to, to present compliant documents. These descriptions are used frequently during many transactions generated every day. To assist and speed up the processing of document descriptions, T24 has the application LC.ADVICE.TEXT. This enables users to record the descriptions against a coded ID, and then, simply input the document code into the transaction for T24 to display the related text. ID of a LC.ADVICE.TEXT record can be up to ten alphanumeric characters. Description is recorded in the field NARRATIVE. The relevant record ID is attached to the field DOCUMENT.CODE of LETTER.OF.CREDIT and DRAWINGS application. DR.DISCREPANT.TYPE

Discrepant document processing

Before we move to the next parameter table, DR.DISCREPANT.TYPE, it is important for you to have an idea of how processing of documents takes place. When documents conform to LC terms strictly, the negotiating Bank would pay and obtain reimbursement from LC issuing Bank. When documents presented are not in conformity with LC terms, the Negotiating/Issuing bank has different options depending on the nature of discrepancy. The choices available are Negotiate and Pay, Pay under Reserve, Send for collection or Reject and return. The bank will find out if the discrepancy is minor or major. It will take a call on whether to take a risk on the Customer. When Documents are negotiated under Reserve, the LC issuing Bank continues to be held as the risk party.

If the discrepancy is major, the bank may wish to pay under Reserve or send the Bills under collection. DR.DISCREPANT.TYPE is used to define the different types of discrepancies and rules for handling them. Rules to decide whether payment under reserve can be made for documents under export LC and if so, who is the risk party and type of message to go and whether the discrepancy is internal or not.  Available standard types for import and export could be reviewed and new types can be created, if  necessary. ID of a record could be up to 13 alpha numeric characters.

The type of Instrument (Export/Import) for the Particular Discrepant type is mentioned in the field INSTRUMENT.TYPE. Once authorized this field cannot be changed. The risk party is indicated in the field RISK.PARTY, which can be the issuing bank or the presenter. Bank can specify any Internal discrepancy which it finds in a Documentary collection and can keep it for  internal purposes without communicating to any other party. This is mandatory in DRAWINGS application through the field IN.DISCREPANCY only if the field IN.DISCRE.REQ field in DR.DISCREPANT.TYPE is set to YES. Similarly, there is a field DISCREPANCY in DRAWINGS, in which details of discrepancies are specified, to be communicated through advice of discrepancy – MT 750. Now, this field is made mandatory only if  the field EX.DISCRE.REQ in DR.DICREPANT.TYPE is set to YES. For each discrepant type, whether Tracer mechanism should be made mandatory in Drawings is decided in field TRACE.DATE.REQ. If set to Yes, TRACE.DATE field in DRAWINGS becomes mandatory. Whether LC liability should be reduced with a Drawing of this type is decided through REDUCE.LIAB field. YES will reduce the LC liability with Drawing amount even though the Drawing type is CO (collection). NO will not reduce the liability.

Ticklers or inquiries requesting information are normally sent by Banks to trace the status of collections. Internal Ticklers can be controlled through fields TICKLER.DAYS, TICKLER.MODE and DEFA.TICKL.TXT. TICKLER.DAYS will be used in the DRAWING application for the specific Discrepant type to calculate the Tickler Date on which the Tickler Message would be sent. TICKLER.MODE holds the mode of the Tickler. DEFA.TICKL.TXT is a mandatory field if TICKLER.MODE is set to Automatic. This will be the text for the Tickler message. EB.DUPLICATE.TYPE CONDITION.PRIORITY LC.GROUP.CONDITION LC.TXN.TYPE.CONDITION

 As applicable to any other T24 application, Trade Finance module also involves charges for various activities. Obviously, it would be convenient for the Bank to set default charges for all LCs/Documentary collections and Drawing Types somewhere. This set up is done in LC.TXN.TYPE.CONDITION. The ID of this table will be “LC.TYPE- OPERATION” for LCs and “LC.TYPES-DRAWING.TYPE” for  DRAWINGS. Duly defined FT.COMMISSION.TYPE records can be included through multi value fields COMM.TYPES and CHARGE.TYPES. LC.GEN.CONDITION LC.CUSTOMER.CONDITION

CONDITION PRIORITY

You have learnt that default charges for LC transactions are specified in LC.TXN.TYPE.CONDITION. The defaulting is based on LC type and operation. Even though this structure may be standard, a Bank would like to give preferential treatment for some Trade Finance Customers. Thus, a separate charge structure can be made applicable to certain groups of  Customers. Well, where will the top level rules for grouping be set? This is done exactly in the table CONDITION.PRIORITY. The ID of the record for LC will be LETTER.OF.CREDIT. Here, order of priorities are assigned from fields in CUSTOMER application. The example shows the first priority as field SECTOR, the second priority as TARGET from CUSTOMER application. Please remember the determinants are chosen based on the Trade finance business needs of the Bank. LC.GEN.CONDITION

Now that the top level criteria are created in CONDITION.PRIORITY, groups are formed in LC.GEN.CONDITION. These groups are based on the attributes from CONDITION.PRIORITY. ID of a record will be numeric and a maximum of 99 groups can be formed. The first screenshot shows Group 1 formed with individual Customers classified as Private Client – Standard (Based on SECTOR and TARGET values).

The second screenshot shows a default group 99 formed with any SECTOR and any TARGET. Based on these selections, system places a Customer in a group by doing a best fit. A Customer’s actual group is recorded in the table CUSTOMER.CHARGE for all applications. It is also possible to effect change into any other group at this level. LC.GROUP.CONDITION

 After the groups have been formed in LC.GEN.CONDITION, where will the preferential tariff be defined? This is done in the table LC.GROUP.CONDITION. ID of a record will be the same ID as in LC.GEN.CONDITION to denote preferential charges are for the specified group. The percentage of the spread/commission/charge to be applied can be specified in the fields RATE.SPREAD, COMM.TYPE, COMM.PERCENT, CHARGE.TYPE and CHARGE.PERCENT. Instead of specifying Charge/Commission IDs in the multi-value fields, value ALL can be indicated to include all records.

There is also a choice of fixed amount (see fields COMM.F.AMT, CHARGE.F.AMT ) which supersedes the minimum and maximum set in respective Charge/Commission types. PAYMENT.TYPE and CUSTOMER.FLOAT fields define special Value Date conditions applicable to a specified customer or group of customers. The options in PAYMENT.TYPE are ALL – for all transactions, CONV for transactions involving conversion of currencies, NOCONV for transactions not involving conversion of currencies. CUSTOMER.FLOAT indicates the number of days after which value date will be given.  A value of ALL in PAYMENT.TYPE and '0' in CUSTOMER.FLOAT means the Group of Customers will receive same day value for all transactions.

CHG.COMM.SEPARATE field denotes whether in Customer statements, Charges and Commission should be separated from LC transaction entries.

Where it is necessary that special conditions be set for a single Customer, it can be done so in LC.GROUP.CONDITION. ID will be C- Customer number. For example, C-100112.

Then, the value in ACTUAL.GROUP of CUSTOMER.CHARGE will change to the LC.GROUP.CONDITION ID for that particular Customer. Besides LC.GROUP.CONDITION, LC.CUSTOMER.CONDITION table has additional facilities to indicate Provision related information through fields PROVIS.ACCT, PROV.PERCENT, LC.TYPE and CREDIT.PROV.ACC fields. Provision percentage could be indicated LC.TYPE wise or a common percentage for all types by indicating “DEFAULT” in LC.TYPE field. Accounts, if entered, must belong to the same customer and be in the same currency. IMPORT LC

Before we go into Import LCs, we will brief you about the features in Trade Finance module, more particularly about LC application. Trade Finance module has three applications: LETTER.OF.CREDIT application is mainly used to send Pre-advices, Open LCs and make amendments. DRAWINGS and DRAW.NEGOTIATION applications are used for payments. Trade Finance transactions can be handled in any currency. Drawings made and charges collected can be denominated in a currency - different from LC currency. Charges can be immediately or at any time later. Users can create different types of LCs using the LC.TYPES application, where combinations of the major  features of LC can be set up – import or export, sight or usance, payment or acceptance, confirmed or  unconfirmed. OPERATION CODES

Have a look at the field OPERATION in LC application. The options in this field are O, P, A, C, T or D. O refers to Open new Letter of Credit / Documentary Collection contract. P indicates Preadvice new Letter of Credit contract.  A is Amend an existing Letter of Credit / Documentary Collection contract. C means Direct charge processing for an existing contract. T to Trace existing Documentary Collection contract and D is Decision on an Amendment. Amendments pending acceptance of counterparty kept in LC.AMENDMENTS. On counterparty advice, decision is effected to LC. Remember, Contingent accounting entries are passed at all the above stages. ISSUING PREADVICE

Pre-advice of an Import LC is Preliminary information about a letter of credit (L/C) sent by the issuing bank to the advising bank. The operation in LC application will be identified by the code P. The type of Trade Finance contract is specified in the field LC.TYPE. Relevant information like Applicant, Beneficiary, Advising Bank details, Currency, Amount, Expiry date, Expiry place, etc are to be entered. The field PREADV.LIMIT is used to decide if the limit is to be impacted for Operation 'P'. The value cannot be amended once the record is authorised. Fields SHIP.DESPATCH and TRANSPORTATION are used to indicate the port of dispatch and final destination. The field DRAW.TYPE is derived by PAY.TYPE field in LC.TYPES. Note P from PAY.TYPE will default to SP, A will default to AC, D will default to DP, N will default to MX. If  M is specified in LC.TYPES, then the field DRAW.TYPE becomes mandatory and input is required. Delivery message can be viewed even before committing a pre-advice record. OPENING AN IMPORT LC

LCs can be opened with or without pre-advice. The Pre-advice is only for information purposes and is not a legally binding contract. Terms can be changed while opening the LC. Only irrevocable LC becomes a binding contract on the issuing bank. If the price of a merchandise is stipulated to be X units in LC, then even if it is supplied at X.1 units, it is not as per terms of LC. Tolerance finds a practical usage in such circumstances. Tolerance is the extent to which the LC amount is admitted to move up or down. Positive and/or Negative tolerance percentage are specified through fields PERCENTAGE.CR.AMT and PERCENTAGE.DR.AMT. If the LC.AMOUNT = $1,000,000.00 and the percentage entered in PERCENTAGE.DR.AMT is 10.00, then the minimum drawing expected under this letter of credit is $900,000.00 and the maximum is $1,000,000.00. The LIABILITY.AMOUNT will be equal to $1,000,000.00.

Field ADD.AMT.COVERED can be used as free text to indicate other amounts covered by this LC. BASIC ELEMENTS

For opening an LC, basic elements required are Operation code, LC.TYPE, Applicant, Beneficiary, Currency, Amount, Advising Bank, Intermediary Bank and Reimbursement bank.  All Credits must stipulate an expiry date and place for presentation of documents for payment/ acceptance/negotiation. There are different ways in which the Issuing Bank makes the value of the credit “available” to the Beneficiary i.e. by his submitting: documents “FOR PAYMENT” a draft for “ACCEPTANCE” a draft for “NEGOTIATION” The last date before which the shipment is to be made should be specified. This date should be less than the credit expiry date to enable timely submission of documents.

The screen shows the LC issued by the Issuing Bank. In order to avail the credit value, the Beneficiary of the LC must also conform the other details/conditions in LC. In terms of liability, when the Bank is acting as the Issuing Bank, it’s risk is with the Applicant. The Issuing Bank is actually guaranteeing to make a payment on behalf of it’s Customer on the due date, if payment is not made by the Customer applicant. Thus, it is important that the Bank should know if the Applicant is good for the value. Often Applicants will have LC limits, but sometimes, the Issuing Bank may require a cash deposit from the Applicant to cover  its risk. This is called Provision, also known as cash cover. If a Bank acts as a Confirming Bank, it’s risk is with the Issuing Bank. This is because Confirming bank undertakes to pay the Beneficiary prior to receiving reimbursement from the Issuing Bank. Again limits and provision can be used to cover this risk exposure. CHARGES AND COMMISSION The T24 Bank can collect charges either at the time of L/C issuance or advising, at any time afterwards, or at the time of L/C payment or negotiation(or afterwards as long as the record is still available for  drawing).

On AC or DP drawing types, additional charges can be collected till they mature. PARTY.CHARGED field is used to input a code to determine the identity of the party from whom the charge is to be taken. Some of the charges can be levied against the Opener(O), others against the Beneficiary(B), and some against a Third Party(TP). Using the conditions specified for the charge code in FT.COMMISSION.TYPE table, system automatically calculates the amount to be charged in LCY. Input of an amount in CHARGE.AMOUNT field will be the amount in charge currency. This amount will be converted to charge account currency using the exchange rate in the field CHARGE.XCHG. Otherwise system defaults mid rate of Currency market chosen. Input of a Numeric in the field CHARGE.AMOUNT followed by the percent (%) sign will cause the system to calculate the percentage amount on the LC.AMOUNT.

 AMORT.CHARGES field is used to define whether charges are to be amortised over the life of the LC. If this field is set to YES, then this charge will not be taken into the profit and loss account defined for this charge/commission code immediately, but will be amortised over the indicated period. The charges could be collected while doing any LC operation like opening, negotiating etc. Alternately, by using the operation code `C’ in the field OPERATION, charges can be collected directly without any other  LC operation including collecting adhoc charges for special services.

In DRAWINGS application it can be done via CH operation code to collect deferred charge of a particular   AC or DP type of drawing. Charges can be waived using field WAIVE.CHARGES.

\

LC.ACCOUNT.BALANCES

LC.ACCOUNT.BALANCES table contains all authorised charges under a single Letter of Credit transaction. Each record is automatically created, updated and maintained by the System. For each new authorised Letter of Credit transaction, all charges are moved from the contract to a new record in this table. This is done to reduce the size of the L/C record which can become e xcessively large with all the charges generated. Then for each new authorised change to the L/C, any additional charges produced are appended to this record and any charges for authorised drawings under this Letter of Credit are also appended to this record. The record will automatically be closed and written to history when the Letter of Credit is closed from the system. Letter of Credit will move to history file o nly if there is no pending charges to be collected. STATUS OF CHARGES CHARGE STATUS field in LC and DRAWINGS applications is used to identify if the status of charges collected.

Different options in LC are: Blank - Charge has not been collected (In this stage, only the charge amount will be calculated and written in LC.ACCOUNT. BALANCES. Related tax will be calculated at the applicable rate on the day the status changes to 2). 2 - Charge has to be taken immediately to the debit of the charge account. 3 - Charge has been claimed. This means, system will debit to Receivable and credit profit and loss. At this stage tax if any associated with the FT.COMMISSION.TYPE will not be debited to the CRF bucket. A claim advice is sent to the charge party. 4 - A claimed charge has been settled. When the charge is paid, user should manually access the LC.ACCOUNT.BALANCES table, update the status from 3 to 4 to indicate that the payment has been received, and the CRF claimed bucket reimbursed. 5 - A claimed charge has been written off to the debit of profit or loss. When claimed charge is not paid, user should manually access the LC.ACCOUNT.BALANCES table and update the status from 3 to 5. This will reverse the profit and loss and credit to CRF bucket. 7 - means Charges unpaid has been reversed. This is maintained by System when `R’ is used in PARTY.CHARG field to reverse charges already deferred through Blank status. In DRAWINGS, Charge status 1 indicates that charge will be taken in drawing, but drawing is not authorised. 8 - means charge has been taken by adding the amount to a reimbursement claim via a drawing.

9 - Indicates charge has been taken by deducting the amount from a payment via a drawing. 11 - indicates charge will be taken by deducting the amount from a payment at maturity. 12 - indicates charge will be taken by adding the amount to a reimbursement claim at maturity. Note, Status 11 and 12 are applicable for usance drawings. When a drawing is entered whereby payments are made or reimbursement is required, then the charge amount will be either deducted from the payment amount or added to the reimbursement amount in order  to make a profit and loss entry. The charge status that was initially blank will change as applicable to charge status 8 or 9. REVOLVING LC – IMPORT

The Trade Finance application allows us to set up revolving or reinstatement L/Cs. T24 supports both cumulative and non-cumulative types of revolving credits.  A cumulative credit will carry forward unutilised L/C amount to the next period. Under Non cumulative type the un-utilised portion lapses. We will differentiate with an example.

 Amount of credit USD 10,000 revolving 3 times. When installment of USD 10,000 has been utilised, the credit automatically becomes valid for the next USD 10,000 until the maximum USD 30,000 is reached. The total liability in this case is USD 30,000. For a non-cumulative Letter of Credit, the amount available for utilization at any point of time cannot exceed the individual cycle’s amount. Under the Non cumulative option, where the unutilised portion is not going to be carried over to the next installment, the User has an option to impact the Limit only with the current installment amount. Setting the field LMT.FOR.REVOLVING to SINGLE can do this. The LIABILITY.AMT would continue to display the entire amount of liability under the Letter of Credit, but the field CUR.REVOL.LIAB would display the liability under the current revolution.

While opening Revolving Import LCs, the following fields need input: ISSUE DATE - is the initial date of the contract i.e. the date Letter of Credit is Issued/Advised/Confirmed. It can be prior to or after the deal input date. EXPIRY DATE - is the 'Expiry Date' of the Letter of Credit in the bank's book and not necessarily the actual Expiry Date of the Letter of Credit. After this date no further drawings can be made.

BOOKING DATE - is the date of opening LC in the bank’s books, viz. the date when the LC accounting is effected.  ADVICE.EXPIRY.DATE - is the date on which a letter of credit expires from the beneficiary's point of  view. This will usually be a number of working days before the EXPIRY.DATE. Charge calculation and customer advices will be using this field whereas accounting, limit updates will still take place on EXPIRY.DATE. If this is not filled up, EXPIRY.DATE will be taken automatically as  ADVICE.EXPIRY.DATE. EXPORT LC

You learnt about Import LCs in the previous unit. We will now deal with Export LCs. Export Letters of Credit are handled and treated in a similar fashion to Import LCs. In simple terms, it is  just the reverse process of Import LC. In the letter of credit cycle, the Issuing Bank issues the letter of credit, on application from the applicant and forwards it to the Advising Bank. The transaction is thus “Issue of Import LC” for the Issuing Bank. The Advising bank authenticates the letter of credit and delivers it to the beneficiary who is the Seller. It is thus an Export LC for the Advising Bank. As far as the Export LC is concerned, there may be several roles involved like, Advising bank, Confirming bank, Negotiating bank and Reimbursing bank.

T24 supports the creation of the LC manually or on a semi-automatic basis upon receipt of an incoming SWIFT message. The process is same as in the case of an Import LC, but in this instance we would be in the opposite role. On receipt of incoming SWIFT message, with proper interfaces, LC goes to IHLD status automatically. On authorisation, it is entered into the Bank’s books. Different types of Export LCs are defined in LC.TYPES table, to be used for quoting different roles. For an Export Letter of Credit opened, the system will produce an MT730 (SWIFT message for the LC Opening bank) and a printed acknowledgement (1730) to the beneficiary.

The important details to be filled for Export LC handling are:



Suitable LC.TYPES to reflect the Export and payment type



Advising Bank reference to display the Issuing Bank reference for use on messages and advices



Issuing Bank s details



Applicant s details



Beneficiary s details

’

’

’

RISK.PARTY: This shows the party against whom the risk is to be borne. For Import LC, it is APPLICANT.CUST.NO. For Export LC, this may be set as Issuing Bank or Reimbursing bank, if different. When a Customer  Number is input here, this updates CON.CUS.LINK field. CON.CUS.LINK field is a system maintained field to identify the Customer Number used for accounting and limits processingFor Import LC, it is APPLICANT.CUST.NO. For Export LC, it is ISSUING.BANK.ID. TRANSFERABLE LC

LCs can be transferred in full or  in part if permitted by the Issuer. The Trade Finance application allows a beneficiary of Export LC to transfer it another party. This is possible only where the first LC is transferable (in LC.TYPES the field TRANSFERABLE is set to yes). This is how to enter a transferable L/C: Enter the details for the original, or parent, transferable Export L/C.

 Authorise the parent, or original, Export L/C. Open the transferred L/C by inputting the field PARENT.LC.NO in the child L/C. This will default all information except beneficiary and amount from the parent L/C. The beneficiary of the second L/C and the amount of transfer should be completed and the transaction committed. In the parent LC, the system updates the fields TRANSFERRED.LC and TRAN.PORT.AMT for  information and validation.

LCs can be transferred in full or in part if permitted by the Issuer. The Trade Finance application allows a beneficiary of Export LC to transfer it another party. This is possible only where the first LC is transferable (in LC.TYPES the field TRANSFERABLE is set to yes). This is how to enter a transferable L/C: Enter the details for the original, or parent, transferable Export L/C.  Authorise the parent, or original, Export L/C. Open the transferred L/C by inputting the field PARENT.LC.NO in the child L/C. This will default all information except beneficiary and amount from the parent L/C.

The beneficiary of the second L/C and the amount of transfer should be completed and the transaction committed. In the parent LC, the system updates the fields TRANSFERRED.LC and TRAN.PORT.AMT for  information and validation. BACK TO BACK LC

Back-to-Back letters of credit are related to each other usually with one acting as security for the other. Export LC should have used LC.TYPES permitting Back to Back and indicating the Import LC type. The steps for Back to Back LC can be explained as: In the Export LC, BACK.TO.BACK field should be set to YES. Once the Export LC has been input with all relevant details, committed and authorised, the associated import letter of credit will be generated in the IHLD status with the type of LC indicated in field LC.TYPES.

Please note, this may be opened any time and fresh terms can be set up for the Back to back Import LC. Though all the terms can be changed, expiry date and amount should not exceed the original / parent LC. For Limit updating and accounting purposes, the Import LC is treated as a stand alone and not linked to the parent LC. PARTIAL CONFIRMATION OF LC

It may so happen that the Confirming bank has decided to confirm only a portion of the LC amount. Such a facility is available only for Non transferable Export LCs. T24 Bank has two choices. 1. It may choose to update Limits with only confirmed portion 2. Else, it may update transaction limit with confirmed portion and information limit with un confirmed portion. This is controlled from the LC.PARAMETERS through the field UNCONFIRMED.LIMIT. When this is set to YES, the unconfirmed limit line is hit with the information line. If set to NO, limit update happens only for the confirmed portion Provision calculation is made only on the confirmed part. But in cases where provision is already taken and the Letter of Credit is to be partially confirmed, the entire provision has to be released first. DRAWINGS

DRAWINGS is an application under the Letter of Credit system that is used to effect the transfer of funds and the acceptance of documents under Letters of Credit and Documentary Collection transaction. In order to enter a drawing, the Letter of Credit Collection parent contract must first be set up in order to define the types of drawings that can be made. When goods are despatched and appropriate documents are presented to the bank for payment (via an advising bank), if the documents are in order, then the opening bank should input a drawing. The drawings can be simple – Sight payment made by debiting the applicant’s account with the LC amount plus the outstanding charges. Or could be more complex and involve different settlement instructions – can be acceptance or deferred or mixed payment. Drawings will record the transaction, altering credit limits and accounting appropriately. It will automatically make the required payment, (via SWIFT, if need be) and advise various parties if required. Charges could also be taken at this point or collected later (in case it is not Sight payment).

BASIC ELEMENT

ID of a record in DRAWINGS will be LC number followed by the Drawing Sequence number. Drawings could be in a different currency from that of the draw down account. The payment date can be future or back valued. The field FULLY.UTILISED or not field provides the user with the ability to indicate that no further  drawings will be made under the letter of credit. DRAWDOWN.ACCOUNT is the account to be debited or applicant’s account in the case of import.  Account to be debited or issuing bank’s / reimbursing bank’s account in the case of export. Where MT 742 needs to be sent, this account should be a Nostro. PAYMENT.METHOD: identifies the method of payment for the drawing. The options are N (Nostro), IT (Internal Transfer), BP (Banker’s Payment) and CH (Cheque Payment). PAYMENT.ACCOUNT reflects the account to be credited. This is the account of advising/reimbursing bank in the case of import or account of beneficiary in the case of export. If PAYMENT.METHOD is N, then this account has to be a Nostro. For the option IT, the account can be an internal or a customer  account. For BP and CH account, the value will be as per LC.PARAMETERS.

DEBIT.VALUE field is used by Sight drawings where user can specify a different debit value date from the credit value date. ROUND.RULE field enables the user to define the type of rounding that should take place while debiting or crediting the customer’s account. Type of rounding needed for interest, commission, charges and fees can be defined here by using ID of a pre-defined rule in EB.ROUNDING.RULE table. The value input in this field overrides the condition defined at the product level i.e., in LC.PARAMETERS. If no value is input in this field, then rounding will take place as defined at the product level. DRAWING TYPE

We will now discuss about various Drawings Types. The option SP means Payment will be made immediately to the beneficiary or collecting bank with reimbursement claimed from applicant or opening bank.  AC and DP are used as per tenor. For 'AC' and 'DP' type drawings, once the maturity review date is reached and the drawing undergoes maturity processing, then the Drawing type will automatically change to 'MA' (From 'AC') and 'MD' (From 'DP'), indicating that these deals are now matured. However, it is to be noted that for Export usance Drawing to Mature automatically, either the CONFIRM.INST field in LC application should hold the value as CONFIRM or the Drawing must have been discounted. In the absence of either of these the Drawing has to be manually matured. In the case of Import usance Drawing, maturity is always automatic with an option for the user to manually mature the same. The option RP indicates for export LC, that documents are presented as per LC terms and will generate a claim for reimbursement. For Import LC, it will generate release of payment to beneficiary in the form of  customer transfer. We have seen that the charges could be collected while doing any LC operation like opening, negotiating etc. Alternately, by using the operation code `C’ the charges can be collected directly without any other  LC operation. In Drawings application it can be done via CH operation code to collect deferred charge of  a particular AC or DP type of drawing.  AD reflects amendment to SP / MA / MD drawings. DRAWING HANDLING STEPS

The field MATURITY.REVIEW contains the date on which Acceptance/ Deferred Payment drawings will mature, or Letter of Credit Collection drawings will be due for chasing. Normally, there will be transit period being the time taken for a negotiated bill to reach the importer’s bank from exporter’s bank. The importer may not like to pay till he sights documents. Hence, it is possible to debit an internal account and pay the exporter’s bank while the importer’s account could be debited after  the usual transit time. For Sight drawings MATURITY.REVIEW field is to be used when Discounted, indicating the date up to which interest is to be calculated, when a rate is input.

Drawings can handle situations when the Draw currency differs from the Draw down account and Payment Account currencies. If so, then treasury rate can be input in RATE.BOOKED and TREASURY.RATE fields for Debit and Credit rates respectively. If not input, the mid rate from Currency is used. Trade Finance Department spread for the customer can be input in RATE.SPREAD and CUSTOMER.SPREAD fields for Debit and Credit rates respectively. DRAW NEGOTIATION DRAW.NEGOTIATION application serves as a front end tool to input multiple drawings into DRAWINGS application. The ID format is DNSSDDDNNNNN. In a mixed payment negotiation, the document may contain some sight and usance components. In DRAWINGS application, we need to input the Sight portion first in one drawing and then the  Acceptance portion in the next drawing. This results in user inputting the DRAWINGS two times. DRAW.NEGOTIATION can be used to enter both the components in the same application.

Once the input is complete and the record status flagged as settled through the field DISCREPANT.STATUS, the system will generate two or more DRAWINGS on hold. The Drawings will require completion and authorisation. Understand that this application contains various fields in DRAWINGS which when entered gets mapped to the appropriate field in DRAWINGS. DISCOUNTED DRAWINGS It can so arise that a Beneficiary of an Export Usance transaction may wish to receive funds in advance before the maturity date. If the beneficiary’s bank is prepared, it may discount the drawing, paying the face value of the presentation to the beneficiary, less a percentage charge over the remaining period until maturity. The beneficiary’s bank will be reimbursed when funds are received from the Issuing/Remitting Bank at maturity. The discount amount will be accrued over the life of the drawing at the frequency specified in LC.PARAMETERS. Components of a Discounted Drawing are Discount Rate, Load / Spread for the Treasury Dept, Value date, Interest amount, Spread amount and Charges. On authorisation of discounted drawings and for subsequent amendment of drawings, a live file LC.DISCOUNT.BALANCES gets updated. DISCOUNTED SIGHT DRAWINGS Sight Drawings can be discounted. When the field DR.DEBIT.TO.CUST in Drawing is set to NOTDEBITED the system uses CUSDEBIT, as DRAWDOWN.ACCOUNT to post the reimbursing entry. When set to NOTDEBITED the MATURITY.REVIEW opens up for Sight Drawings. This needs to be input to enable the system to calculate the number of days for which interest is to be charged. The calculation of interest shall however flow from DISC.EFF.DATE (i.e effective date of discount)to MATURITY.REVIEW. By default DISC.EFF.DATE shall hold the VALUE.DATE. Where the User intends to provide Grace time for calculation of interest component the DISC.EFF.DATE may be input with an effective date or simply “NND” where “NN" would indicate the number of days of  Grace, which would be translated to a date, being number of days from the VALUE.DATE and amortization would happen only from that date. DISC.EFF.DATE cannot be less than the VALUE.DATE or greater than the MATURITY.REVIEW date.

DIS.PARTY.CHRD field can be used to indicate who will bear the charges – Beneficiary or Opener.

SETTLEMENT OF DISCOUNTED SIGHT DRAWINGS When the final settlement is to be done, User has to do an online maturity using application DR.DISC.AMENDMENTS. The customer may either be debited or a Loan may be arranged. In the case of the latter the Draw down account of the loan has to be input as the settlement account in the field RECEIV.SETT.ACCT. When the customer account is DEBITED, choice is available to either return the un-amortised portion of  the discount amount to the account of the Discount party charged or book it into P&L, depending on the value input in field RETURN.INTERST. When DR.DEBIT.TO.CUST is set to TRFLOAN, the entire interest component, both the ones amortised and the balance to be amortised, are credited to the account of the Discount party charged. The reason for such reversal is that when a Loan at such instances is extended, the same would be back-valued, thus the customer would not be charged twice.  AMENDMENTS TO DICOUNTED DRAWINGS The input in the field RECEIV.SETT.ACCT shall bear the same currency as that of the CUSDEBIT used to debit in the original Drawings. It is possible to amend some features of discounted drawings through DR.DISC.AMENDMENTS.  Automatic maturity of Usance discounted drawing is done during COB on the maturity date. Any time earlier, on line maturity can be done using DR.DISC.AMENDMENTS. Maturity dates could be changed, with this, discount and load rates can also be changed. Excess discount can be retained or returned. Excess discount retained in internal account defined in LC.PARAMETERS in DIS.RETAIN.CODE field. LC.DISCOUNT.BALANCES keeps track of these changes also. On line maturity of discounted drawings before maturity date can be done by inputting “TODAY” in NEW.MATURITY.DATE field. TRADE RATES FOR DISCOUNTED DRAWINGS

In the Drawings record there is an option to specify the currency of the PERIODIC.INTERST table and whether the rates should be calculated on the Lending rate or the Offer rate. The default would be that of  Market Lending Rate (MLR) in the Drawings record, denoting the equivalent of OFFER.RATE in the PERIODIC.INTEREST table. Where the User chooses to use BID.RATE in the PERIODIC.INTEREST table, the same needs to be specified in the Drawings record as Market Offered Rate (MOR) in the field INT.MLR.MOR. Such Tiered rates may be used for Usance or Sight Discounting. To use PI table in DRAWINGS, the prerequisite is to fill in INTEREST.KEY and INTEREST.ROUTINE fields in LC.PARAMETERS. EXCHANGE RATE FOR DISCOUNTED DRAWINGS The method of calculation of Discount component for a discounted drawing can be specified in the table DR.INT.CALC.COND. In the application DR.INT.CALC.COND, the field INT.CALC.CCY can either be DRAW.CCY or LCCY. When DRAW.CCY is input the system is designed to calculate the discount component on the Draw currency with a rate other than that in the contract. In this case the calculation of interest is same as earlier as far as the DISCOUNT.AMT is concerned. However, to arrive at the local currency equivalent, DISC.AMT.LOCAL, the User may accordingly set up the CONV.RATE as Buy or Sell or Mid. Likewise if the INT.CALC.CCY is selected as LCCY, the calculation of Discount amount is altogether  different. Here the entire Drawing amount is converted into local currency at a rate as specified in CONV.RATE in DR.INT.CALC.COND. This would now form the amount on which DISCOUNT.RATE would be applied and Discount component calculated. On arriving at the Discount amount the same CONV.RATE as mentioned in the DR.INT.CALC.COND would be applied to calculate the Drawing currency equivalent that is populated in DISCOUNT.AMT. BROKER  A Broker, you must be aware, is an agent or middleman, in this context, between the importer and exporter. He obtains his fee or commission from the Drawing amount as a percentage or a flat amount. Brokerage may be applied in the DRAWINGS application. But first, the Broker must be defined in the BROKER table. The Brokerage may be settled in any currency defined on the Broker record. The Brokerage details are entered on the Drawings contract through relevant fields. The amount of the Brokerage is held in three places, which may be in three different currencies.

BROKERAGE is held in the currency of the Drawing. BROKER.AMOUNT is Held in the Broker currency. BROKER.AMT.LCY is the Local currency equivalent of the BROKER.AMOUNT. The payment amount of the Drawing is reduced by the BROKERAGE taken on the contract and the brokers’ account is credited with the broker amount. The date on which this credit entry has value is always the date on which the payment and reimbursement is made.  ASSIGNEMENT OF PROCEEDS The Trade Finance application allows assignment of proceeds. If the beneficiary informs the bank of assignment, this may be noted in the LC itself by use of the fields  ASSN.REFERENCE, ASSN.CUSTNO, ASSN.ADD, ASSN.AMOUNT and ASSN.NOTE. This is a multi value field to enable the beneficiary to assign proceeds to multiple persons. Though this is generally done in export LC, T24 allows assignment in Import LC also. The actual assignment and payment of proceeds happens only when a drawing is input. Entering the information in the LETTER.OF.CREDIT makes the input in drawings simpler. Where the information is already available in LC, it is sufficient to key in the ASSN.REFERENCE from LC to the  ASSIGNMENT.REF field in DRAWINGS. This will automatically default other information from LC. Wherever an assignee has not been specified in the LETTER.OF.CREDIT but has to be introduced in DRAWINGS, the ASSIGNMENT.REF field to be input with TPPAY. MULTIPLE DEBITS IN DRAWINGS

One added feature of Drawings is that through Assignment related fields, it is possible to have multiple draw down accounts with different exchange rates. Field APP.DRAW.AMT in Drawings to be used to indicate the amount to be used from DRAWDOWN.ACCOUNT. When this amount is less than the DOCUMENT.AMOUNT, System populates the balance as MULTI.DR.AMT. The default value in the field APP.DRAW.AMT is that of DOCUMENT.AMOUNT. Multiple drawings can be achieved by input of “TPRECV” in the field ASSIGNMENT.REF to debit several accounts with different exchange rates. ASSN.AMOUNT field should indicate amount in DRAW.CURRENCY. System uses transaction codes set up in LC.PARAMETERS fields ASSN.TRAN.CODE.CR and  ASSN.TRAN.CODE.DR for Assignments. COLLECTONS “Collection” means the handling by banks of documents in order to (i) Obtain payment and/or acceptance, or  (ii) Deliver documents against payment and/or acceptance, or deliver documents on other terms and conditions The liability of the banks is restricted mainly to the forwarding and releasing of documents against payment or acceptance. When there are major discrepancies in Documentary credit, then the bank may choose to send it for collection without any risk or responsibility on its part. Like Import and Export LCs, Collections are classified as Inward and Outward. They may be mere clean bills or accompanied by documents for delivery. The collecting bank is required to release the documents against immediate payment or the buyer’s acceptance of a draft. LC.TYPES table should provide for all these types of collections. Examples of suitable collection types may be CCIS reflecting Collections Clean Inward Sight, CCIT reflecting Collections Clean Inward Tenor etc. \\ BASIC ELEMENTS

Collections are handled through LC and DRAWINGS applications. There are generally 4 parties involved in a documentary collection: The principal / remitter/seller/drawer – who hands over the documents to his bank with a collection order. The remitting bank which is the seller’s bank. The collecting / presenting/issuing bank which takes care of the actual collection by presenting to the buyer the documents as per terms of collection. The drawee / buyer/beneficiary/importer to whom the collection documents are presented. BASIC ELEMENTS

We will now discuss important elements related to tenor. The fields COLL.MAT.CODE or TENOR field in LC can be used to indicate Collection tenor – say 3 days after sight, 1 month from date of Bill of Exchange etc. Values in COLL.MAT.CODE can be ST, BE, CC etc while TENOR field allows free text input. DAYS field allows 3 digit number preceded by D or M. These fields are used together in Option K of Tag 32a in 400 series of SWIFT message. When a Usance collection is accepted by Drawee, two methods available to effect payment. Drawing could be input with Payment type AC. When payment is received, Payment type could be changed as MA. Else, DATE.ACCEPTED field in LC used to record maturity date of an Usance draft. When payment is received, Drawing input with SP Payment type. DIRECT COLLECTION AMOUNT

When dealing with highly valued customers, the bank may at its discretion, permit them to send export documents directly on collection and merely take the information and copies for the purpose of its records. For this purpose, it has to allot a series of numbers / range to each o f the select customers to identify the documents. The application DIR.COL.ALL is used to input the range. ID is Customer Number for whom the arrangement is made, Say, 100384. Range can be given with prefix and Start and End. For example, Prefix like AN and Start and end like 100 and 200. These numbers could be used in the LC in the field DIRECT.COLL.NO. After authorising the LC, the respective records may also be fetched by giving IDs like 100384.AN101 etc. COLLECTION TRACER  A document when sent on collection may need to be followed up with reminders or Tracers. In addition to the existing tracing operations available in LC and DRAWINGS application, by inputting the TRACER.DATE with a date greater than the Bank date, generation of Tracers during COB is enabled.  As soon as a tracer is generated, the next date for tracer generation is automatically decided by the EB.FREE.PARAMETER or COUNTRY table input.  Any time during the life cycle, the scheduled tracer can be stopped by changing the status to STOP in EB.FREE.MESSAGE. Alternately any scheduled tracer can be stopped by removing the TRACER.DATE in the application.  AMENDEMENTS TO COLLECTION

When an export document is sent on collection for realisation, the concerned importer may not be able or  willing to take possession of the goods for various reasons, prompting the exporter to find an alternate buyer. In such cases, the new buyer may be banking with another bank, different from the one of the original importer. This needs to be recorded with the exporter. This may also necessitate changing the Collecting and/or reimbursing bank. By effecting these changes, the limit set against the Collecting / reimbursing bank changes. In Collections, the RISK.PARTY field could be left blank if the counterparties are not our Customers. DISCREPANT DOCUMENT OPTION DRAWINGS application is used to input Non discrepant as well as discrepant documents under LC. When documents presented are not in conformity with LC terms, the Negotiating / Issuing bank has four  options depending on the nature of discrepancy. 1. Pay in spite of discrepancy as they are minor and claim reimbursement in normal course 2. Pay but with the risk shifted to beneficiary and claim reimbursement in normal course

3. Pay but with the risk shifted to beneficiary and seek confirmation and 4. Not to pay but to send the documents seeking instructions Export docs received with discrepancies are first recorded under Drawing type CO. Depending on the nature of discrepancy, payment is made under reserve, if need be. If the beneficiary rejects the discrepancies, draw type is changed to CR (Collection Rejection) and suitable message sent to applicant. In the absence of any instructions, when the documents are to be returned to the applicant, draw type is changed to FR (Final Rejection). Import docs received with discrepancies are first recorded under Drawing type CO. If the applicant rejects the discrepancies, draw type is changed to CR (Collection Rejection) and suitable message sent to negotiating bank. If the negotiating bank gives any instruction for amendment of Collection, they are carried out. When the documents are to be returned to negotiating bank, draw type is changed to FR (Final Rejection). SIGHT EXPORT LC We now present an instance, where the Bank has advised a Sight Export LC to its Customer. The Customer will be shipping goods in three batches and two batches will be shown in this demo. In the first batch, no discrepancy is observed, thus the bank has paid the Customer the amount and claimed reimbursement. In the second batch, Bank has observed an external discrepancy and paid the amount under reserve. Later, it has received a message from the Beneficiary bank that the discrepancy for the second batch is acceptable. The bank has incorporated this in its records.  All the activities spoken about, will be shown in this demo. The Export LC has been advised. The bank will now make payment for the first batch of shipment. The Payment under export LC has been made. The next batch will be paid under Reserve due to discrepancies observed. The payment for the export LC has been made under reserve. The bank has received a message from the Beneficiary bank that the discrepancy is acceptable. This will be incorporated in the record. The acceptance of the discrepancy has been incorporated and drawings effected.

REJECTION OF DISCREPANT DOCUEMNT In the previous demo, you saw an instance where the T24 Bank had advised an Export LC to its Customer and the Customer had shipped the goods in batches. We will now demonstrate a situation, where, in the last batch shipped, Certificate of Origin, was not presented as per terms of LC. Now the T24 Bank has treated this as an external discrepancy and sent the bill for collection. Later the bank has received a message that the discrepancy is not acceptable. This has been recorded in the books and after receiving the original documents, the bank has treated it as Final Rejection. The processes will be demonstrated for your learning. The bill has been sent for collection. Rejection of documents has been recorded. On receipt of documents from the beneficiary's bank, T24 bank will record final rejection. The final rejection of documents has been recorded.

TRUST RELEASE

When a discrepant document is received under Import LC, the Bank, at its discretion, may release the document prior to receipt of payment.  At this juncture, the Bank records delivery of the document in a Trust delivery receipt, has the same acknowledged by the Importer.

However, the bank must be sure that the Customer will on no account make use of the documents before the collection conditions are fulfilled. The collecting bank remains responsible towards the principal and remitting bank and bears the full risk of loss or unauthorised use of the documents by the drawee. Should the drawee decide not to take up the documents, he must return them to the collecting bank forthwith. The same may also happen for Import Collection documents.

TRUST.REL field is activated in DRAWINGS for Import LCs and in LC application for Import Collections. The values accepted are RELEASE, ACCEPT or REJECT and can also be left blank. TRUST.REL field should be set to RELEASE while releasing the documents to drawee. The user can accept or reject the documents at a later stage and accordingly update the TRUST.REL field. Whenever documents are accepted under trust, the system will hit the trust limit set up in LIMIT.PARAMETER. Also instead of the normal COLL contingent entry, system will create a contingent entry with TRCOLL. Subsequently when the documents are accepted, the previous limit and contingent entries will be reversed and the normal collection limit and contingent entry will be created. When the documents are rejected, the previous limits and contingent entries will be reversed out and the LC liability will become zero. When this field is kept as null, the system processes like a normal collection. The valid sequences allowed are: RELEASE – REJECT or RELEASE – ACCEPT. If a document has been released under trust and it is neither accepted nor rejected before the expiry date, the system will expire the LC and will update this field as EXPIRED. No drawings are allowed in the system unless the documents released under trust are accepted.

By now, you know that Banks generally take Cash margin for LCs. Where a Bank collects a Cash Margin for Issuance of LC and if a Shipping Guarantee were to be issued under this Letter of Credit, through MD.DEAL, the system can now set aside a portion of the margin or the entire Cash Margin can be utilised for the guarantee. This may be done to assist the importer from funding for margin, twice. If required, additional Provision can also be recovered besides the LC Margin. This detail on the Guarantee into which the Cash Margin of LC has been parted with is stored in GTEE.REFERENCE field in LC. Such apportioning of Cash Margin can be done into various Guarantees as long as the margin is available in LC. In such cases, system multi-values as and when apportioned. In DRAWINGS also, we have the field GTEE.REFERENCE. Input here signifies that the Drawing is done where a Shipping Guarantee is issued. Here, input will be a valid MD.DEAL ID. Please note that the DRAWDOWN.ACCOUNT of the DRAWINGS needs to be the same as PROV.CR.ACCOUNT in MD.DEAL. Depending on the Cash margin available in Guarantee, the system releases or recovers the additional provision through the PROV.COVER.ACCT in DRAWINGS.

 ACCOUNTING

 Accounting entries generated in Trade Finance module are Contingent as well as Non contingent. STMT.ENTRYs are generated for Customer Accounts and Internal accounts and CATEG.ENTRYs for PL heads. RE.CONSOL.SPEC.ENTRIES passed on line. Different Asset types are PREADV, ISSUE, DEFPAY, ACPTCONTRA, ACPTBANK, COLL, TRCOLL,  ADVICE, CONFIRM, ACPT, OPEN (for RP status in Drawings)which are contingent and PAYRES which is non contingent. LIVEDB used for discounted drawings. Transaction codes for accounting entries are specified through LC.PARAMETERS and FT.COMMISSION.TYPE. RE.TXN.CODES used are NEW, INC, DEC, LIQ, PAY, MAT, CUS, etc.

The screen shows the entries generated for Import Sight LC. The First entry is generated when Pre advice is issued or LC is opened. Second entry when there is an increase by way of amendment.

Third entry when there is a decrease by way of amendment.  All these are contingent entries. Fourth entry is also a SPEC entry when the LC is paid (On maturity for the balance unused amount an entry with MAT as RE.TXN.CODE will be passed). Fifth and sixth entries when the beneficiary’s a/c is credited through Nostro A/C or otherwise and our  Customer’s (L/C Opener’s) account is debited.

The screen shows entries generated for Import Acceptance LC. They are very much similar to what you saw for Sight LC. First entry is when LC is opened. Second entry is the reversal of first entry when the usance drafts are accepted by the beneficiary. Third and fourth entries are contingent entries passed for the accepted usance drafts. Fifth and sixth entries are reversal of contingent entries and passed on maturity of the usance period.

 All the above are SPEC entries passed. The last two entries are STMT.ENTRYs passed for effecting payment of the accepted usance drafts.

 An Export LC could merely be advised, confirmed or opened. Accordingly, the transaction code for the first entry will be different. The second and third entries are passed while amending. The fourth entry is passed when the payment is made.  All these are contingent entries. The last two entries are STMT.ENTRYs while making payment. The Nostro account or beneficiary’s account is debited and the exporter’s (Customer’s) account will be credited.

 Accounting entries for charges and commissions are passed in three different situations. Two situations arise while taking a charge (debiting a charge) – Paid immediately and Claimed, viz. Customer account debited for the charges and Claimed but yet to be paid viz. amount yet to be received as due from beneficiary’s bank etc. TWO situations arise while crediting to P & L – Applied immediately or Amortised and will be credited to P & L over a period. The resultant situations, thus, are: Collected and credited to P & L immediately. Collected immediately but amortised over a period. Claimed (but yet to be paid) and credited to P & L immediately. On debiting a customer’s account, a STMT.ENTRY is raised and CATEG.ENTRY is passed for crediting a P & L account. SPEC.ENTRYs are passed for claim made.

SWIFT MESSAGE SUPPORTED \

The Trade Finance application automates production of SWIFT messages in the 700 and 400 ranges (700 for Letters of Credit and 400 for Documentary Collections). The system also generates MT100 and MT200 series messages for payments.  As per the SWIFT changes, new Message Type MT202COV has also been introduced. Normally for  payments to beneficiaries, MT103 is generated and simultaneously MT202 which is a cover payment. Now a new message type MT202COV will be generated exclusively for Cover Payments which will contain the details of the corresponding MT 103 also. The screen shows messages of the MT 700 series.

Outward delivery process

If you are not familiar with the delivery setup in T24, we will discuss some tables essential for the delivery process. DE.MESSAGE: This table contains contents of basic message types. For example, ID 700 is meant for  DE.MESSAGE: “Issue of Documentary Credit”. When a transaction is authorised, all transaction details are written to DE.O.HANDOFF. DE.O.HANDOFF. These can be viewed through Enquiry DE.HANDOFF.DETS. DE.MAPPING defines where data is located and helps mapping. For example, ID700.LC.1 (which has DE.MAPPING components Message type, Application and sub classification) maps through Input Position (information (information from DE.O.HANDOFF DE.O.HANDOFF or Application) and Field Name (Tag names pre defined in DE.MESS DE.MESSAGE). AGE). DE.FORMAT.SWIFT formats the message. ID 700.1.1 formats as Field Tag, Field Name ,Tag 27 Field DE.FORMAT.SWIFT SEQ, Tag 40A Field TYPE.OF.CREDIT. DE.PRODUCT sets rules Company wise, Customer / Account wise, Message type wise Number of  DE.PRODUCT copies, Carrier to be used etc. DE.ADDRESS DE.ADDR ESS helps store Company wise, Customer wise, Carrier wise addresses. DE.O.HEADER lets us know the message disposition. It is used to track the message. This table contains DE.O.HEADER information about the processing and status of the message. Re-submission of the message is possible through this table.

Soft delivery

Each action in LC and DRAWINGS produces an activity.  A four digit code is triggered by by the latest activity activity in the life life cycle of transaction. transaction.

EB.ACTIVITY contains all activity codes hard coded in LC and DRAWINGS life cycle. The ID must be of  EB.ACTIVITY the format AA-nnnn, where AA is a 2 character T24 application ID and nnnn is a 4 digit numeric code defining each activity. For example, in the code LC-1801, 1 is Operation P(Pre advise new Letter of Credit) or O (Open new Letter of Credit), 8 is import LC and 01 is input/Authorise. For each activity a set of advices are defined in EB.ADVI EB.ADVICES. CES.

EB.ACTIVITY codes are linked to required Message Types and Message classes like Advice, Payment EB.ACTIVITY etc. For example, you can see in the screenshot, LC-1801 is used to produce 700 message type of Operation message class with mapping key 700.LC.1 and 740 message type of Reimbursing message class with mapping key 740.LC.1. Preview of messages

One distinct feature is that once input is complete in LC/DRAWINGS preview of all related message for  that activity can be launched.  At the launch of all related messages, messages, user can change the the default carrier, carrier, insert change of address and decide to send the message or not. For example, MT 700 has been set to go via SWIFT in DE.PRODUCT. DE.PRODUCT. If the Advising Bank is not on SWIFT, or any other reason, we may have to send the 700 by mail. In this case, the User can simply change the Carrier (method of despatch) to PRINT, and enter the address. Lc system maintained tables

Some important System Maintained tables are: LC.APPLICANT LC.APPLIC ANT shows Customer wise list of applicants. LC.BENEFICIARY LC.BENEF ICIARY shows Customer wise list of LC beneficiaries. LC.DISCOUNT.BALANCES shows LC wise discounted drawings. LC.ISSUING.BANK LC.ISSUIN G.BANK lists Customer wise details of Issuing Bank for Export LCs and export collections. LC

There are some more system generated tables which are: LC.NEGOTIATE contains LC wise details of DRAW.NEGOTIATE. LC.PARENT.DRAW shows LC wise list of Drawing in Child LC done THROUGH Parent LC. LC.REVOL shows due date wise list of Revolving LCs. LC.TRANSFERABLE contains Parent wise list of Child LCs. LC.ACCOUNT.BALANCES shows Live LCs, Currency and date wise entire history of Charges and payments. EB.CONTRACT.BALANCES