T3TLC - Letters of Credit - R13 1

T3TLC - Letters of Credit - R13.
1 1
The Course Objectives are to equip participants with adequate knowledge
on T24 Letters of Credit (LC module) by
1. Introducing the participants to the T24 Letters of Credit (LC) module
2. Learning about linkages with core tables including interest, charges
and commissions
3. Learning to set up parameter tables connected with the module
4. Learning to input, execute and complete different types of Letters of
Credit transactions
5. Learning to issue Import LC through Internet

Banking
6. Learning about risk management, accounting and messaging, as
appropriate to this module
7. Using reports and enquiries relevant to this module
T3TLC - Letters of Credit - R13.1 2

The Trade Finance module consists of two closely related applications,
LETTER.OF.CREDIT and DRAWINGS, which work together to provide
a wide range of support for Trade Finance business. LC application
supports opening and amending LCs as well as Documentary collections
both import and export. It suits all the roles of a bank advising,
confirming, negotiating.
Negotiation of LCs and collections are done through DRAWINGS
application. In DRAWINGS application, sight and acceptance portions
should be input in different drawings as they fall under different draw
types.
DRAW.NEGOTIATION application serves as 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. Foreign currency entries
will automatically update positions where required.

We need to have Customer records to refer as counter party and Broker.
We also need accounts for payment and receipt of brokerage and
settlement purposes.
Letters of Credit could be issued after setting up limits or Limits and
collateral when collaterals are attached to limits. It is also possible to do
so without creating limits. When an override message notifying the
absence of any limit is accepted and record authorised, the system will
automatically create a default limit for the customer for the product.

Separate category codes could be used judiciously to indicate different
types of LCs and Collection instruments from reporting angle. Care
should be taken when defining additional sub-classifications that
sufficient detail does not already exist to provide the required breakdown.
For example, we should not define separate CATEGORY codes for
resident and non-resident customers or for local and foreign currency
transactions, since this information is already available on an individual
prime record.

PERIODIC.INTEREST table is used for LIBOR types of rates. Rates
vary depending on the length of time and for Bid and Offer purposes.
This table may be automatically updated/interfaced daily with an
external feed such as Reuters, or maintained manually by the user.
PERIODIC.INTEREST records are generated daily by the System.
This table is used for discounted drawings using tiered system of rate
calculation.
For example, interest on a drawing for a period of 45 days to be
calculated as below based on the above PI table:
1 day @ 4.5178
31 days @ 4.51275
Rest @ 4.52758
This means that interest for the first day would be @ 4.5178%, next 31
days @ 4.51275% and the balance 13 days @ 4.52758%.
However, interpolating all the above rates, a single rate would be
populated.

The Trade Finance application allows to set up 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). For certain types of LCs it is possible to take
additional charges until they mature. The types of charges/commission
have to be defined in FT.COMMISSION.TYPE application.
LC.TXN.TYPE.CONDITION table is used to define default charges for
Trade Finance products.
Regardless of the percentages set and the transaction value, the bank may
wish to guarantee a minimum commission receipt.
OVERALL.MIN.AMT Field is used to set the minimum commission to
be collected. A maximum can also be set, if required, in
OVERALL.MAX.AMT Field.
It is possible to accrue or amortise the charges and commissions over a
period, by suitably defining in FT.COMMISSION.TYPE.
It is also possible to take charges at one exchange rate and document
amount at a different exchange rate. It is possible to use different
accounts for collection of charges. One also has the flexibility to take
charges immediately on an acceptance/deferred payment drawing instead
of waiting till maturity.

The Field CHARGE.PERIOD defines the number of months that
comprise a charging period. A charge may be made periodically, e.g.
monthly, quarterly, etc. This Field determines the length of time for
which the commission type record applies. The period of the contract
will be split in the number of periods defined in this Field to calculate the
total commission amount. 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. For 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. The
corresponding Field MINIMUM.PERIOD can be used to specify the
minimum number of periods to be considered.
The Field MINIMUM.PERIOD defines the minimum number of months
which comprise the smallest allowable charging period, used in
conjunction with the CHARGE.PERIOD defined. The minimum period
may be defined as monthly, quarterly, half-yearly, nine-monthly, annually,
or bi-annually. The contract period will be divided into a number of
charging periods as defined in CHARGE.PERIOD. This will then be
compared against the MINIMUM.PERIOD. If the minimum period
yields a large value, this will be used to calculate the final chargeable
amount.

LCs may often need charges/commission to be collected based on the LC
period.
CHARGE.PERIOD Field defines the number of months that constitute a
charging period. In the above FT.COMMISSION.TYPE case, if the
contract is for 6 months, it consists of 6 charge periods, and hence six
times charges defined will be taken.

In R12 there is no feature available in the system to calculate and collect
charges based on the tenure of the contract i.e. to collect periodic
commission/charges. LC.PARAMETERS, LETTER.OF.CREDIT,
DRAWINGS, LC.ACCOUNT.BALANCES are enhanced to cater to the
requirement of calculating commission based on the tenure of the
contract. A new table was introduced for defining the period based
banded structure of commission rates. Step 1: Define
FT.COMMISSION.TYPE records for amount band for each period. Care
must be taken not to define maximum and/or minimum amounts. Step 2:
Define the period bands in PERIODIC.COMMISSION table (new table)
attaching the FT.COMMISSION.TYPE record ids for the respective
bands. Step 3: Create another FT.COMMISSION.TYPE record with the
same id as that of PERIODIC.COMMISSION. Attach transaction codes,
category, minimum & maximum commission amount, tax code, etc. In
the CHARGE.ROUTINE field, define the routine as
@PERIODIC.COMMISSION.

There is no standard rules or order for defaulting settlement accounts in
LC application.
If account numbers are input for opener, beneficiary, advising bank etc.,
then they are defaulted while collecting charges.
They are also defaulted in DRAWINGS application.
If payment method is indicated as Nostro in DRAWINGS, then Payment
account is defaulted using NOSTRO.ACCOUNT for the payment
currency.

Holiday table will be used to check whether maturity and/or other
scheduled activity date is a working day or not at the time of inputting a
contract. It is possible to indicate country code or Region code in the
Field BUSINESS.DAY.DEFINITION while inputting a contract.
Accordingly, while inputting a contract, holidays for those
countries/Regions will be checked for all scheduled activities and suitable
overrides will be generated. This is a multi valued field. More than on
country or Region holiday can be checked.
Interest day basis will be defaulted to transaction records as per the
currency used. However, it can be modified at contract level.

Choices are available in LC application to indicate the interest day basis.
This is useful while discounting usance drawing to calculate the amount
of discount.
When charges are collected in advance, but proposed to be amortised
over the life of an LC, then the basis for amortising would be
decided by this choice.
This is defaulted from Currency table, but could be changed by the user.
To support the 252 day interest basis (specific to Brazilian market), two
interest day basis, W and W1 are introduced.
W 252/252: Here, the numerator represents the number of business
days between the start and the end dates of the contract.
W1 252/252: The number of days in the numerator represents the
number of business days between the start and end days of the contract. If
the number of business days is less than 21 days in a month, then the
number of business days in a month is considered to be 21. If the number
of business days is more than 21, system accrues only till the 21st day.

The first level file in LC module is the LC.PARAMETERS file which
provides the user with the option to specify accounts and accounting
entries that are passed in T24; what accrual cycles are set; and the
transaction codes to use. Record Id is Company code.
CURRENCY.MARKET table is defaulted for LC transactions. Up to 99
markets can be defined in the CURRENCY file and one can be picked up
for LC transactions. One more currency market can be picked up in
CHARGE.CCY.MKT Field for charges which can be different. Thus 2
different currency markets can be chosen for LC transactions and
charges.
System runs the amortisation process monthly. But user can define the
day on which the amortisation process is to run in a month.
AMR.CYCLE.L.CCY and AMR.CYCLE.F.CCY Fields defines the
frequency of amortisation under LC transactions in local currency and
foreign currency. Similarly, the interest accrual on Discount drawing can
also be done daily or monthly for local currency and foreign currency.
RECALCULATE.AMORT Field 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 Field indicates the number of days after the expiry
date when LC or Collection will be moved from LIVE file to History file.
The number of days will be added to EXPIRY.DATE Field of the LC or
Collection to determine the CLOSING.DATE Field. On this date, if there
are no Drawings or Charges outstanding under the said LC or Collections,
the LC Live file is moved to History.
For pre advised LCs, the number of days indicated in
PRE.ADVISE.DAYS Field is added to ISSUE.DATE Field to produce the
CLOSING.DATE Field in LC. For Operation is P closing date = expiry
date + PRE.ADVISE.DAYS.
COLL.EXTN.DAYS Field helps keep the Collection document live as
long as it is not fully utilized. On the Original Expiry Date, the system
rolls over the Expiry date by this many number of days. This reset is also
carried out on the Closing Date and on the Limit line.

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. 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. This could either be a fixed amount or a percentage of
the L/C amount.
In an Unconfirmed Letter of Credit, limit line defaults to the info line
unless and otherwise defined in LIMIT.PARAMETER. Likewise in the
case of Confirmed Letter of Credit the limit line goes as per the definition
in the LIMIT.PARAMETER. But with partial confirmation, an option is
available with the user to choose to hit the info line or not for the
unconfirmed portion of the Letter of Credit. This can be set up in
LC.PARAMETERS by setting the UNCONFIRMED.LIMIT Field to
Yes or No.
When an export LC is partially confirmed, the limit line is split and one is
set against the confirmed portion and the other against the unconfirmed.
When this information limit line is considered redundant in a partially
confirmed LC, this may be suppressed by assigning `NO to this Field. If
set to YES, the information limit line appears. Suppression of
information limit line is done only if the LC is partially confirmed.

EXCH.TOLERANCE Field is used to indicate the tolerance that can be
ignored while calculating the limit amount minus provision amount.
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. An input of a tolerance figure in this
Field will be understood by the system as a limit to be ignored and when
the difference falls within the parameter value it will be ignored.

Advice / Report related fields to define how many number of days prior
to an event should a message be sent or reported.
REIMBURSE.DAYS Field to send reimbursement message in case of
Usance Drawing before Maturity. It is also used to decide when to send
MT 742 and MT 754 Swift messages.
REVOL.ADVICE.DAYS Field is to send a revolution advice before next
revolution.
MATURITY.USANCE Field is used to report imminent maturity of
Usance drawings.
COLLECTIONS.DUE Field will report imminent due date of
Collections.
For export LC, choice available in DEL.WITH.NO.DISCREP Field. 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 are used in STMT.ENTRY and CATEG.ENTRY for
narrating the underlying transactions affecting Accounts and PL heads.
PAY.TRANS.CR Field is for Narrative or transaction code when
passing credit entry for payment account.
PAY.TRANS.DR Field is for Narrative or transaction code when
passing debit entry for payment account.
REIMB.TRANS.CR Field is for narrative or transaction code when
passing debit entry for draw down account.
DISC.TRAN.CODE.CR and DISC.TRAN.CODE.DR Fields for discount.
LOAD.TRAN.CODE.CR and LOAD.TRAN.CODE.DR Fields for
discount spread.

Transaction codes are used in STMT.ENTRY and CATEG.ENTRY for
narrating underlying transactions affecting Accounts and PL heads.
UNCOLLECTED.TR.CR Field - Narrative to be used when entries have
been created relating to charges under L/Cs that are uncollected.
WRITE.OFF.TR.CR Field- Narrative to be used when entries have been
created relating to written off charges made under L/Cs.
AMORT.TRANS Field- Narrative used when entries have been created in
the Amortisation of charges at Close of Business.
PROVISION.CR and PROVISION.DR Fields Narrative to be used
when Provision (Cash Margin) Credit / Debit entries are passed.

ROUND.RULE Field enables the user to define the type of rounding that
should take place while debiting or crediting a customers account in
DRAWINGS application. Pre defined rules set in
EB.ROUNDING.RULE can be used.
Natural, Round up, Round down, Tax Up, Tax down or None are options
already available in EB.ROUNDING.RULE.
In a Syndicated LC, the bank might want to collect some charges that are
common for the bank and the participant banks. In that case, the
commission collected is split between the agent bank and its participant.
To enable splitting of commission between the agent bank and its
participants, the charges that have to be split need to be defined in
SYND.CHG.CODE Field.
Only the charges that are defined in this field can be syndicated. This is a
multi value field and the bank can define more than one type of
charge/commission.
At the LC level, SYNDICATE.CHARGE Field has to be Yes to
syndicate the charges.

DISC.CAT.CODE Field: PL category code to be debited/ credited with
the discount amount for discounted drawings.
LOAD.CAT.CODE Field: PL category code to be debited / credited for
discount spread amount of discounted drawings.
UNCOLLECTED.CATRG Field: PL category for charges claimed and
booked to PL and yet to be collected from the party concerned.

WRITE.OFF.PL Field: The value is Pl write off category code for
claimed charges. This identifies the PL category code to be used when
claimed and booked charges are written off.
EXCH.PRFT.CAT Field: 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 Field: 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.

Default internal accounts / Category code Fields are used to facilitate
automatic debit / credit into internal accounts. Category codes between
10000 to 19999 can be used.
Internal Accounts in local currency should be opened using these
Category codes. System opens in other currencies, when needed.
If Provision is not proposed to be kept at Customer (Account) level, then
Internal account opened using the Category code indicated in
PRO.CATEGORY Field will be used as Credit Provision account.
Currency of this account would be that of Debit Provision account

PAY.SUBDIVISION Field identifies the subdivision to be used whenever
an internal A/C number is generated by the system for A/C entries related
to L/C payments (it is the equivalent of a G/L sub-ledger number). 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.

Delivery process in LETTER.OF.CREDIT and DRAWINGS module
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 Field has to be
set to NO.
LC.CLASS.TYPE and EB.CLASS.NO multi value Fields are necessary
for soft delivery set-up. It is recommended to use the model bank data
for the initial build.
If TAKEOVER.PROCESS Field is set to Yes, no delivery message will
be produced. This can be used during take over from existing system.
A Customer record can be created for the Bank using the System by input
in CUST.BY.ORDER Field. Information in this Field will be used in
Swift messages Tag 50 Ordering Cust.

After the introduction of soft delivery, certain existing Fields are not
used.
They include - IN.SWIFT.DAYS, CLAIM.ENTRIES,
DEL.CHARGES.ADV, CON.ACCR.TRCR, PON.ACCR.TRCR,
CON.ACCR.CATEG, CON.PREV.MTH, CON.PREV.YEAR,
OPN.ACCR.CATEG, OPEN.PRV.MTH, OPEN.PREV.YEAR,
REDUCE.LIMIT.BAL, COMBINE.CHARGES, CHARGE.AT.END,
DRAFT.PRINT, WP.PATH, CHRG.CAL.METHOD,
PROV.CAL.METHOD, BROK.CAL.METHOD.

Bank will have an option to define whether the provision is to be
calculated for LC amount or Liability Amount at parameter level for
which a new field are provided in LC.PARAMETERS application.
Likewise, a new field are provided in LETTER.OF.CREDIT application
also to default the value defined at the parameter, If user wants to modify
the defaulted value, the same can be done at LC contract level. T24 will
calculate and collect provision from customer based on these settings.
A New field are introduced in LC.PARAMETERS and
LETTER.OF.CREDIT applications. Validation are provided with error
message, if user selects value in field PROV.CALC.BASE but not
selected value in field PROVISION as YES in LC application, System
will throw an error message set the field provision as yes .For Example if
a user is opening an Import LC for USD Ten Thousand with 50 % cash
margin and the provision calculation base is LC amount . Then system
calculates USD 5000 as cash margin . If the user has given 10% credit
tolerance and the calculation base is liability amount then the amount of
provision that is calculated by using the same example it works out to
USD 5500. LC value is 10000 plus 10% tolerance which is 1000 . Margin
is calculated at 50 % on 11000 which works out to 5500

Option will be available to the user to net the proportionate Cash margin
released with the drawings amount and debit the balance amount from the
drawdown account when drawings are initiation.
A new field, "PROV.NETTING" is introduced in LC.PARAMETERS
and DRAWINGS application.
Value defined in LC.PARAMETERS will be defaulted. User can amend
the defaulted value. This field will assume significance only if provision
is collected in the underlying Letter of Credit. This will be a no change
field. Drawings payment entries will be netted with the proportionate
amount of cash margin released only when the drawings currency and
credit provision account currency are the same.

Users can create different types of LCs using the LC.TYPES application,
where combinations of the major features of an LC can be set up. For
example - Import or Export, sight or usance, payment or acceptance,
confirmed or unconfirmed.
This file is used to set the type of LC and the way T24 will treat the
transaction through its various phases from opening, drawing and to
maturity. It defines and describes the Letter of Credit (and Collection)
types required in the system, and also to set-up the default Category Code
for each type. The characteristics of each LC and Collection type are
recorded in this file, e.g. Import or Export , Transferable or not,
Confirmed or Unconfirmed, Payment Type By Payment/ Negotiation/
Acceptance etc, Documentary Collection or not, Clean Collection or not,
Whether Back to Back LC or Standby.

Generally any bank should have minimum LC.TYPES, say one for any
pre-advices; one for the actual advices; one for adding confirmations.
Depending on each pay-type further LC.TYPES can be added.
The records provided with the T24 installation should be treated as a
starting point and each one must be reviewed/amended and new ones
entered according to the type of Trade Finance business, the customer is
engaged for present as well as future requirements.
CATEGORY.CODE Field used as the default when the Category code is
not entered as part of L/C input data. If any LC transactions are existing
under this LC.TYPES in the live file or unauthorised file, this Field
cannot be modified as that would lead to conflict in ASSET.TYPE in
CRF entries.

Depending on whether IMPORT.EXPORT Field contains I or E, the
processing will treat the LC as an Import or Export. This defines whether
the product is an Import (Issuance) or Export (Advising/Confirming) type
of credit. 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.

TRANSFERABLE Field with options No and Yes. 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.
Yes or No option in STANDBY Field helps mapping in advices whether
the LC is a Standby LC.
As a standard feature, Yes option is not allowed for TRANSFERABLE
and STANDBY Fields together.

The different pay types are: P Payment; A Acceptance; N
Negotiation; M Mixed payment and D Deferred payment. They are
used for different types of LCs :
Sight payment LC P - Payment
Acceptance LC A - Acceptance
Deferred Payment LC D Deferred Payment
Negotiation LC N Negotiation meant for Draw type of
MX SP / AC portions negotiable and not finalised at LC opening stage
Mixed Payment LC M Mixed Payment meant for pre-decided
Draw types of SP and AC combination.
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.
DOC.COLLECTION Field, if set to YES then all processing is carried
out for Documentary collections and not LC.
CLEAN.COLLECTION Field should be set to YES if the underlying
collection is meant to be handled without documents.
BACK.TO.BACK Field is meant only for Export LCs. Yes option will
enable creating back to back Import LCs at transaction level. Then the
LC.TYPE of the proposed back to back Import LC to be mentioned in
Field BACK.LC.TYPE.

By entering the LC application field names in UCPDC.DEFAULT multi
value Field , cross validation Field defaults could be suppressed.
However, Field level default is not affected by this. Duplicate check for
Export LCs. It is possible to check for duplicate export LCs by pre-
defined conditions set in EB.DUPLICATE.TYPE.
Id of EB.DUPLICATE.TYPE records are to be mentioned in
DUPLICATE.CHECK multi value Field. Override generated even if one
condition is met.
PRE.ADVISED Field contains a counter of the number of Pre-Advised
L/Cs (OPERATION = P) outstanding for an LC.TYPE.
OPENED Field contains a counter of the number of L/Cs opened for this
type.
EXPIRED.NOT.CLOSED Field contains a counter of the number of L/Cs
which have expired but have not yet been closed in the system for this
Type. Will not include Pre-Advised L/Cs on which EXPIRY.DATE is
passed.
These Fields are also used to determine whether the LC.TYPE can be
deleted.

It is possible to set rules for checking whether an LC transaction is likely
to be a duplicate of another similar transaction by setting rules in
EB.DUPLICATE.TYPE. The Id of this record is alpha numeric for
example, LCEXPLC - for duplicate checking in LC is used for export
LC.
Application for which duplicate check is intended should be indicated in
APPLICATION Field.
The Field values that are to be compared for determining whether the
transaction is duplicate or not are to be indicated in multi value Fields.
This may be user-defined Field or a user-defined calculated value (Field
type "I") on STANDARD.SELECTION.
If LC.CURRENCY and LC.AMOUNT Fields are indicated, a transaction
will be termed as duplicate, if only its currency as well as amount are the
same as that of another transaction.

One or more records of EB.DUPLICATE.TYPE can be attached to
required LC.TYPES records. 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. Id of
EB.DUPLICATE depends on the Field defined in
EB.DUPLICATE.TYPE file. If only one Field was defined on the
EB.DUPLICATE.TYPE file, then the key will be composed of that one
Field. If more than one Field were defined, then the key will be
composed of the number of Fields defined; joined together with
asterisks.
Any contracts that matches this key while it is held on file will cause a
possible duplicate override, and will be added to the TRANS.REF
Field. The record will be deleted from the EB.DUPLICATE file in
accordance with the number of days defined in the PURGE.DAYS Field
on the EB.DUPLICATE.TYPE file.

When creating Letters of Credit (Import), we are often required 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 which enables us 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.

In addition to document descriptions, Trade Finance may also require the
input of many lengthy clause narratives. As with documents, T24 also
has the capacity to store clause narratives in the application
LC.CLAUSES. These narratives can be used in various Fields of
LETTER.OF.CREDIT application including CLAUSES.TEXT and
ADDITIONL.CONDS (Additional Conditions) Fields.

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.
When Documents are negotiated under Reserve, the LC issuing Bank
continues to be held as the risk party.
Where there is discrepancy in documents, the negotiating Bank may hold
the documents presenting party as the risk party.

When documents conform to LC terms strictly, the negotiating Bank
would pay and obtain reimbursement from LC issuing Bank.
When the discrepancy is minor, payment is made by negotiating Bank
under Reserve.
If the discrepancy is major, the bank may wish to pay under Reserve or
send the Bills under collection.

DR.DISCREPANT.TYPE table is used to define 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.
Authorising Reimbursement (for import) and Internal Reserve, External
Reserve, Holding of documents, On approval and On collection for
exports are also recorded in this table.
Id could be up to 13 alpha numeric characters.
For each type, whether for Import or Export to be indicated in
INSTRUMENT.TYPE Field which is a no change Field.

URESERVE.REQ Field controls the payment under reserve for drawings
with this discrepancy type. Y input here will allow the user to make
payment under reserve for drawings with this discrepancy type. This
Field controls the UNDER.RESERVE Field in DRAWINGS whenever a
discrepant type is input in a Drawing. Once authorised, this Field cannot
be changed.
Risk party for such payments to be indicated as Issuing Bank or Presenter
in RISK.PARTY Field. If IN.DISCRE.REQ Field set to Yes, details of
discrepancy should be indicated in IN.DISCREPANCY Field in
DRAWINGS. This will not be communicated.
Whether giving details of external reserve should be made mandatory in
Drawings is decided in EX.DISCRE.REQ Field. This Field, if set to Yes,
details of discrepancy should be indicated in DISCREPANCY Field in
DRAWINGS. This will be communicated through advice of discrepancy
through MT 750. Input of No/None in DISCREPANCY Field will
suppress generation of MT 750 message.

For each discrepant type, Tracer mechanism should be made mandatory
by indicating TRACE.DATE.REQ Field in DRAWINGS. If this is 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. Internal Ticklers can be controlled
through TICKLER.DAYS, TICKLER.MODE and DEFA.TICKL.TXT
Fields.

Trade Finance makes extensive use of short codes - say O for open to
enable fast and accurate input. LC.ENRICHMENT file holds enrichment
descriptions for a variety of Codes/Abbreviations used in L/C input which
are not obtainable from other files in T24.
If the user desires to have different enrichment data to be displayed when
inputting transactions, then suitable changes could be made here.
Viewing LC.ENRICHMENT records with Alpha Ids requires a . before
the letter that one wishes to view the enrichment values for example,
.Y. This is because many of the letter options are also valid T24
commands, for example, C - copy, I - input etc
To S(ee) the enrichment for `Y the input should be - LC.ENRICHMENT
S .Y.

The values in LC will have an enrichment as specified here. This is
important as values in LC need to conform to SWIFT standards.
The value defined in LC.ENRICHMENT table is used in different Fields
of LETTER OF CREDIT and has different enrichments.

INT.CALC.CCY Field can either be DRAW.CCY or LCCY. When
DRAW.CCY option 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 Field, the User may
accordingly set up the CONV.RATE Field as Buy or Sell or Mid.
Likewise if the INT.CALC.CCY Field 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 Field in DR.INT.CALC.COND. This would now form the
amount on which DISCOUNT.RATE Field would be applied and
Discount component calculated. On arriving at the Discount amount the
same CONV.RATE Field as mentioned in the DR.INT.CALC.COND
would be applied to calculate the Drawing currency equivalent that is
populated in DISCOUNT.AMT Field.

LC.TXN.TYPE.CONDITION table is used to set up the default charges
for all Letters of Credit/Documentary Collections and Drawing types.
Each input into the Letter of Credit system will have a set of default
charges in this file set up. The defaulting mechanism works by defining
in this file a record corresponding to each type of L/C (LC.TYPE),
together with the operations that can be performed.
For Letters of Credit, the key is defined as: [LC.TYPES]'-
'[OPERATION].
For Drawings, the key is defined as: [LC.TYPES]'-'[DRAWING.TYPE]
where LC.TYPES is from the parent Letter of Credit record.
The following Fields are not currently in use :
CHARGE.PERIOD, MINIMUM.PERIOD, FLAT.CONFIRM.AMT (now
available in respective Charge/Commission types),
CONFIR.COMM.CODE, FLAT.OPENING.AMT, and
OPENING.COMM.CODE (now available in LC application)

We have seen so far that, via LC.TXN.TYPE.CONDITION, T24 can
default charges directly on to a Letter of Credit transaction. The
defaulted charge is not, however, based upon the Customer but, instead,
the LC type and operation. This structure is ideal for the use of standard
tariffs, but in a bank many customers are given benefit from some form of
preferential tariff.
With this in mind, T24 allows us to create groups of customers that we
can arrange the defaulting of non-standard tariffs for. The
CONDITION.PRIORITY file is set at implementation, and determines
what T24 will look at to assign a customer to a particular condition
group. The determinants are chosen based on TF business needs of the
bank. Hence could vary from the other CONDITION.PRIORITY files.

LC.GEN.CONDITION assigns a condition group code and attributes
based on the selection criteria laid down in CONDITION.PRIORITY.
General conditions of customers are defined to form meaningful
combination of LC charge groups, in line with banks policies. Groups
are formed based on attributes selected in CONDITION.PRIORITY
table. They are like
Group 1 is of US residence, Private Sector, Software industry
Group 2 is of US residence, Private Sector, all other industries
Group 99 is of Any residence, any sector, any industry
System has provision for 99 groups with Id numeric. The system always
does a best fit for every Customer based on Customer Field selections.
Customers actual group is recorded in CUSTOMER.CHARGE for all
applications. It is also possible to effect change into any other group at
this level.

LC.GROUP.CONDITION is used to define the preferential tariffs for that
group of customers. The Id is the same as the Id of the
LC.GEN.CONDITION group that we are setting the preferential tariffs
for. When that number is entered, T24 will pick up the name of the group
from that file. It is possible to lay down the conditions for a particular
customer. In such case, the Id of the customer must be preceded by 'C-'
(e.g. C-100010). This will automatically get defaulted to
CUSTOMER.CHARGE.

Where a customer or group of customers are given preferential exchange
rates RATE.SPREAD Field is used to define what percentage of the
standard Customer Spread (as defined in the Currency table) should be
applied. If left blank the Rate Spread will be the same as for a standard
customer (as if 100% was entered).
PAYMENT.TYPE Field is used with CUSTOMER.FLOAT Field to give
different Value Date conditions. ALL means that the condition specified
in Customer Float is applicable to all transactions irrespective of the fact
that these transactions involve conversion of Currencies. CONV for
transactions involving conversion of Currencies. NOCONV for
transactions not involving conversion of Currencies.
CUSTOMER.FLOAT field indicates the number of days after which the
value date will be given. If '0' is input, the Group of Customers will
receive SAME day value as the bank itself.

It is recommended to use LC.GROUP.CONDITION when a single
customer requires special conditions. Customer specific condition can be
set through LC.GROUP.CONDITION with Id as C-XXXXXX . Then,
Customer Id is shown as Actual Group in CUSTOMER.CHARGE.
They can also be stored for information in
LC.CUSTOMER.CONDITION with Id as Customer Id. This table has
additional facilities to indicate Provision related information also in
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.

This slide shows the links between the various files making up the
Condition Group structure for LC charges and commissions.
The application LC.CUSTOMER.CONDITION works like
LC.GROUP.CONDITION, but is specific to a single customer rather than
a group of customers.
The concessional charges and commissions go with CON.CUS.LINK and
CUSTOMER.LINK Fields in LC and DRAWINGS applications. For the
Customer Id appearing in these Fields, if any concessional rates have
been stipulated in LC.GROUP.CONDITION, then that is applied to the
respective LC / DRAWINGS.

ACCOUNT.CLASS records are required for automatic debit/credit by the
system. Internal accounts in local currency to be opened for this purpose.
LCAMORT record indicates the internal account for amortisation of
charges and commissions if required by the user.
LCDIFF record to post the differential amount of 0.01 or 0.02 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 an internal suspense account used 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 set-
up, it is better to create them. They can be used only if needed.

The order in which these files should be created, in the ascending build
reference order, is given in the left.
The mandatory and optional files are shown by different colour codes.
Wherever there are dependencies to fill up values in the tables in build
sequence, the dependencies are shown on the right.

Trade Finance module supports the recording and administration of LCs
and documentary collections. The module has three applications:
LETTER.OF.CREDIT application is used to send Pre-advices, Open LCs
and make amendments.
DRAWINGS and DRAW.NEGOTIATION applications are used for
negotiations.
Efficient delivery system is the backbone of the entire module. It is linked
on-line with soft delivery which means the user has the
Option to verify delivery messages before being transmitted.

Trade Finance transactions can be handled in any currency. Drawings
made and/or charges collected can be denominated in a currency -
different from LC currency.
Charges can be collected now (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.

The Trade Finance application makes extensive use of short codes (such
as O for open) to enable fast and accurate input. A single code may have
different meanings when used in different places. Each place where a
code may be used is identified in the LC.ENRICHMENT application.
P - accepts reduced amount of information regarding LC. Limit can be
optionally checked and utilised.
O - opens new LC or converts pre-advised LC to Live LC. Credit limits
are automatically checked and utilised.
A - Amends an existing LC.
Contingent accounting entries are passed at all the above stages. It is also
possible to collect charges and commissions directly while using any of
these operation codes, or getting it defaulted through
LC.TXN.TYPE.CONDITION.
C - used to collect Null status charges or collect additional charges.
D - used to decide on amendments in LC.AMENDMENTS.

SHIP.DESPATCH and TRANSPORTATION Fields are used to indicate
the port of dispatch and final destination.
Draw Type (Drawing Type) Sight, Acceptance, Deferred and Mixed :
The valid values are SP, AC, DP and MX. This Field is derived by
PAY.TYPE Field in LC.TYPES where
'P' will default 'SP'
'A' will default 'AC'
'D' will default 'DP'
'N' will default 'MX'
If 'M', this Field will become mandatory, and input is required.

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.
Adherence to the terms of LC are very important. 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.
PERCENTAGE.DR.AMT Field specifies the negative tolerance relative
to the documentary credit amount as a percentage. For example,
If the LC.AMOUNT = $1,000,000.00 and the percentage entered here 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.
PERCENTAGE.CR.AMT Field used to define the percentage to be added
to the letter of credit amount (LC.AMOUNT) to calculate the full liability
amount or maximum amount that can be drawn.

The basic elements of LC are Operation code O, Type of Credit,
Applicant, Beneficiary, Advising Bank using ADVISING.BK.CUSTNO /
ADVISING.BK Fields, Intermediary Bank using
ADVISE.THRU.CUSTNO / ADVISE.THRU Fields and Reimbursement
Bank using THIRD.PARTY.CUSTNO / THIRD.PARTY Fields.

UCP 600 Article 6 states about the Availability, Expiry date and Place
for Presentation.
Availability
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
Latest shipment:
Last date before which the shipment should be made. Should be less than
the credit expiry date to enable timely submission of documents
(Shipment period Field can also be used instead) .

In order to avail the credit value, the Beneficiary of the LC must also
conform the other details/conditions.
In terms of liability, when we are acting as the Issuing Bank, our risk is
with the Applicant. As the Issuing Bank we are guaranteeing to make a
payment on behalf of the Applicant, and we would, therefore, only wish
to do so this if we knew the Applicant was 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.
As a Confirming Bank, our risk is with the Issuing Bank. This is because
we are undertaking to pay the Beneficiary prior to receiving
reimbursement from the Issuing Bank. Again limits and provision can be
used to cover this risk exposure.

Option to manually liquidate Letter of Credit contracts.
To cater to this requirement, the following new fields are introduced in
LETTER.OF.CREDIT applications.
Field AUTO.EXPIRY in LETTER.OF.CREDIT application- When
AUTO.EXPIRY is set to 'Yes', system will automatically liquidate the
contract on the expiry/maturity date and when set to 'No', the contract
has to be manually liquidated. This field will default to 'Yes', if not input
by the user.

System allows to set up 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. For all charges within
the multi value set, this can be different. 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 in CHARGE.AMOUNT Field. Input of an
amount here 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. Input of an amount, however, when accepted to allow
the user to override the amount calculated, the charge period will be of no
significance and will be overridden.
Input of a Numeric 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 ad hoc charges for special
services like faxing them a copy of an LC that just issued.
In DRAWINGS application it can be done via CH operation code to
collect deferred charge of a particular AC or DP type of drawing.

In R12 there is no feature available in the system to calculate and collect
charges based on the tenure of the contract i.e. to collect periodic
commission/charges. LC.PARAMETERS, LETTER.OF.CREDIT,
DRAWINGS, LC.ACCOUNT.BALANCES are enhanced to cater to the
requirement of calculating commission based on the tenure of the
contract. A new table was introduced for defining the period based
banded structure of commission rates. Step 1: Define
FT.COMMISSION.TYPE records for amount band for each period. Care
must be taken not to define maximum and/or minimum amounts. Step 2:
Define the period bands in PERIODIC.COMMISSION table (new table)
attaching the FT.COMMISSION.TYPE record ids for the respective
bands. Step 3: Create another FT.COMMISSION.TYPE record with the
same id as that of PERIODIC.COMMISSION. Attach transaction codes,
category, minimum & maximum commission amount, tax code, etc. In
the CHARGE.ROUTINE field, define the routine as
@PERIODIC.COMMISSION.

LC.ACCOUNT.BALANCES file 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 file. This is done to reduce the size of the L/C record which
can become excessively 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 only if there is no pending charges to be collected or decided
upon to collect (viz. all pending charges should either be collected or
decided not to collect and be waived or written off).

CHARGE STATUS Field in LC and DRAWINGS applications is used to
identify if the status of charges collected. Different options like - taken,
claimed, or to be deferred etc can be recorded. They 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 CRF
(claimed bucket) 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. Then 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 file, 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 file and update the status from 3 to 5. This
will reverse the profit and loss and credit to CRF bucket.
7 - System generated where deferred charge position (blank charge status)
is proposed to be reversed and charges will not be collected.

Charge status 1 in DRAWINGS indicates that charge will be taken in
drawing but drawing is not authorised.
8 - charge has been taken by adding the amount to a reimbursement claim
via a drawing.
9 - charge has been taken by deducting the amount from a payment via a
drawing.
11 - charge will be taken by deducting the amount from a payment (status
9) at maturity.
12 - charge will be taken by adding the amount to a reimbursement claim
(status 8) at maturity.
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.

To cater to the requirement of partial settlement/write off of claimed
charges, three new fields are introduced in LC.ACCOUNT.BALANCES
as a part of charge multi value set.
CLAIM.STLE.AMT- This field is used to settle the claimed amount. The
amount will be debited from settlement account.
CLAIM.DIFF.AMT- The field calculates the difference between the
claimed and settled amount. The amount will be debited from claim
difference account.
CLAIM.DIFF.ACC- This field defines the account which has to be
debited for the differential amount. P&L category, in case of write off.
In LETTER.OF.CREDIT application, charges can be claimed from the
beneficiary or a third party by inputting in the field, CHARGE.STATUS
as 3. The charges so claimed can either be accounted directly into P&L
or amortised over the life of the contract.
When the fields AMORT.CHARGES is set to Yes and
CHARGE.STATUS is set to 3, system will amortise the claimed charge
over the life of the contract.

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. A revolving credit guarantees
each part payment of an LC. If a part payment has not been utilised
within the time stipulated, it may lapse or carried over to the next
installment period.
As per Article 32 of UCP 600, If a drawing or shipment by instalments
within given periods is stipulated in the credit and any instalment is not
drawn or shipped within the period allowed for that instalment, the credit
ceases to be available for that and any subsequent instalment.
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. However, 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. T24 provides for revolution on
a fixed date for each period. (viz. if first revolution is on 15th, the next
one will also be on 15th only).

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. 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.
On this date all CRF contingent entries and Limits will be liquidated.
After this date no further drawings can be made.
BOOKING DATE - the date of opening LC in the banks books, viz. the
date when the LC accounting is effected or CRF entries produced.
ADVICE.EXPIRY.DATE - 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.

Amendment of a Letter of Credit facility will allow the user to insert any
changes which will produce an amendment to the original terms and
conditions of an LC. It is also possible to automatically generate all
relevant accounting entries for commissions, increase or decrease of the
principal amounts, and advices and documents to the Electronic delivery
system. In an irrevocable LC, as the contract is binding on the issuing
bank, amendments can be effected only with the concurrence of or at the
request of the beneficiary and applicant. These amendments are effected
by quoting the suitable references (correspondence details). Amendment
advices are delivered to the beneficiary through the advising bank.
There are two basic classifications of amendments 1) Internal
amendment, where no advices are needed and 2) The External
amendment where changes need to be sent to external parties involved in
the LC. Using the AMENDMENT.DEL Field, which accepts an input
only when the OPERATION type is for an amendment, makes this
decision. Yes indicates that delivery is required and hence this is an
external amendment type. Using this Field allows for corrections to the
LC where the external parties do not need to know of the change of
circumstances where the advice(s) have not actually been sent first.
However, internal amendments can be effected which does not affect the
position of the beneficiary in any way. In such cases, Amendment

Delivery advices are not sent out to the beneficiary.
Example of some Internal amendments - Taking / amending Provisions; Changes to
Closing dates (NOT expiry dates of LCs)

In business there is a possibility of amendment being rejected by the
beneficiary. Currently the Trade Finance module does not have the
facility to reject an amendment. This Amendment application records
them and updates the Letter Of Credit based on the decision taken by the
beneficiary. Proposed amendments are created through
LC.AMENDMENTS as amendment 1, 2, 3 etc. After beneficiarys
decision (consent or otherwise) is known for a particular amendment,
Operation code D is used to give effect to it.
When LIMIT.UPDATE Field is set to YES, the limit update takes place at
input stage itself for any upward impact in limit. This detail is
maintained separately and can be viewed through Enquiry LIM.TXN as
two different limit update transactions the latter is shown with TF
NO.AMENDMENT.NO as appearing in LC.AMENDMENTS. Only
after the approval of the amendment this second line is deleted and the
original LC line is impacted.
If the LIMIT.UPDATE Field is set to NO, then there is no limit update at
this stage. However, when the amendment is approved, the limit is
updated.

The Trade Finance application allows for provision (also known as
margin or collateral or cash cover) up to and exceeding 100% of the L/C
amount. Provision can be calculated based on either LC amount or
Liability amount. If nothing is mentioned in LC application the values get
defaulted based on the setting made in LC. PARAMETER. Frequently,
L/C provision is required in excess of 100% in cases where there is a
tolerance or an additional amount specified for the L/C or where a
shipping guarantee against the L/C has been issued. This is also the case
where the fluctuation between provision account currency and the LC
currency is high. Provision may be credited to an interest bearing
account of the customer himself if the bank so desires. Alternatively, it
may be credited to an internal account.
When MARGIN.REQUIRED Field is set to 'YES', an account/percentage
provision can be entered. The system will then calculate (using the
percentage entered) a provision amount, which will be passed to the
PROVISION.AMOUNT Field. This amount is in the currency of the
provision account. Provision processing is also known as Margin
processing.
For a customer with a standard provision account and percentage we can
set-up the LC.CUSTOMER.CONDITION file with defaults for the
provision account/percentage by Letter of Credit type.

Trade Finance module also provides for a refund or release of the
provision at the time of settlement or as required at any time earlier. The
provision can be collected from the customers account in any currency.
PROVISION.RATE Field displays the mid rate between the LC
CURRENCY and the PROVISION CREDIT ACCOUNT CURRENCY.
When a Cash Margin is taken under a Letter of Credit, the limit is
impacted after netting out the margin amount taken. Optionally a facility
is made available in the LC.PARAMETERS, as to whether the margin is
to be considered for limit impact or not. This is controlled from
LIMIT.WITH.PROV Field, which accepts Yes/No. The default value is
however YES, meaning netting of limit with provision. When set to Yes,
the existing workflow of netting of Provision happens.
For example, when a 60% provision is taken on a 100,000 amount, the
limit line is impacted for 40,000 as under:
At the parameter the value of this Field may also be left as NULL, which
is considered as YES. Although the value of such limit impact may be
defined in the parameter, this can be overridden at the Letter of Credit, in
LIMIT.WITH.PROV Field. This Field in Letter of Credit is a one-time
input and it cannot be changed once committed. So the treatment to that
particular Letter of Credit and all the Drawings done under it shall have
the limit treatment as defined in the LC but not as in Parameter.

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.
For an Import LC, the process starts from the customer of T24 bank.
Whereas for an Export LC, the process started by the counterpart of T24
banks customer in another country. When a customer of T24 bank
receives an LC, the same is dealt by the bank in different roles. For
Export L/C's the client is defined as the Issuing/Opening bank.
Sometimes, the LC Issuing Bank may request us to advise (with or
without adding our confirmation) and in due course we may undertake to
accept documents from the beneficiary under the terms of the Credit.
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. The same conditions can apply in as much as the Credits
can be at sight, acceptance or deferred payments and our scale of charges
is related to the role of the Exporter's bank. On receipt of incoming
SWIFT message, with proper interfaces, LC goes to IHLD status
automatically. On authorisation, it is entered into our books.
Different types of Export LCs are defined in LC.TYPES file, 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.

ADVISING.BANK.REF Field is used to display the Issuing
Bank/Handling Bank/Customer reference for use on messages and
advices. For Export LCs this is the Issuing Bank's reference.
ISSUING.BANK.NAME Field identifies the Issuing Bank for an Export
Letter of Credit.
APPLICANT.ID Field identifies the applicant on whose behalf the Letter
of Credit is issued, if the applicant is held on the CUSTOMER file.
Either this Field or APPLICANT.NAME Field (a text description of the
applicant) must be entered. Similarly BENEFICIARY.ID Field is our
customers Id. If customer number is not available,
BENEFICIARY.ADDRESS Field should be filled in. This is mandatory if
the BENEFICIARY.ID Field has not been input.

The banker would want an option to reset the limits of Issuing Bank
against that of the Reimbursing Bank when these two parties are
different. Inputting a customer number in RISK.PARTY Field resets the
CON.CUS.LINK Field and updates the limit accordingly.
CON.CUS.LINK Field is a system maintained Field. It identifies the
CUSTOMER used for accounting and limits processing.
For Import Letters of Credit this will contain the APPLICANT.CUST.NO
Field.
For Export Letters of Credit this will contain the ISSUING.BANK.ID
Field.

As per Article 38 (b) of the UCP 600 - Transferable credit means a credit
that specifically states it is "transferable". A transferable credit may be
made available in whole or in part to another beneficiary ("second
beneficiary") at the request of the beneficiary ("first beneficiary").
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).
TRANSFERRED.LC Field indicates the T24 transaction reference of
Child L/C(s) and associated with TRAN.PORT.AMT Field. It is used for
maintaining the serial control between Parent and Child L/C(s) in
transferable L/C process.
TRAN.PORT.AMT Field is applicable to Transferred Letters of Credit
Only and displays the corresponding transferred amount for the child
L/C(s) in TRANSFERRED.LC Field. It is used for maintaining the serial
control between Parent and Child L/C(s) in the transferable L/C process.
Both these Fields are system maintained.

Back-to-Back letters of credit are related to each other usually with one
acting as security for the other. T24 can help with the preparation of
details by using one as the basis for generating the other.
BACK.TO.BACK Field indicates whether a back-to-back LC is to be
generated. Input is allowed in this Field only if the BACK.TO.BACK
Field is set to YES in the LC.TYPES record of an export letter of credit.
The type of the generated LC is taken from the BACK.LC.TYPE Field in
the LC.TYPES record. The associated import letter of credit will be
generated in the IHLD status when the record is authorised.
If Back to Back LC is not required to be opened immediately, then this
Field may be left blank or NO. Whenever the back to back LC is to be
opened, then this LC may be AMENDED to input YES in this Field.

In the books of Advising or Reimbursing Bank: It has decided to
confirm only a portion of the LC amount.
The limit should be affected for the confirmed part as that is the exposure
it has for the LC opening bank.
Alternately, it may choose to have 2 limits One for the confirmed part
and another for the Unconfirmed part (Information line).
For updating the limits the relevant limit lines are hit for the respective
amounts. This is done as defined in the LIMIT.PARAMETER for the
confirmed portion and the information limit line for the unconfirmed
portion. By default the limit line for the unconfirmed Letter of Credit is
the Information line.
There may be instances where the Bank may choose not to hit the
information limit line for the unconfirmed portion in a partially
confirmed Letter of Credit. This is controlled from the
LC.PARAMETERS in UNCONFIRMED.LIMIT Field. When this is set
to YES the unconfirmed limit line, in the absence of any user input in
UNCONF.LIMIT.REF Field in the Letter of Credit, is hit with the
information line and when set to NO, limit update happens only for the
confirmed portion.
Provision calculation only on the confirmed part. But in cases where

provision is already taken, and then the Letter of Credit is to be partially confirmed,
the entire provision has to be released first.

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. The
system is fully integrated within T24 to provide Accounting, Limit
Exposure, Position Updating, Control and actual administration of L/C
Collection activity together with ensuring efficient delivery of the related
Advices, Documents, Covering Letters, and Payments. 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 applicants 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).

Drawings could be in a different currency from that of the draw down account.
System will accept a maximum of 999 drawings under a letter of credit . Any
drawings beyond 999 system will throw a error message. The payment date can
be future or back valued. Id of the drawing TFYYDDDNNNNNAAA. Where
AAA stands for drawing sequence number. When the number of drawing
exceeds 999 system will trigger an error message.
The date entered here will be the date that CRF, Statement, and Category entries
will be generated for this L/C. If the date specified is in future, then the end of
day batch of this date will generate the required entries.
FULLY.UTILISED Field provides the user with the ability to indicate that no
further drawings will be made under the letter of credit.
Account to be debited or applicants account in the case of import is indicated in
DRAWDOWN.ACCOUNT Field. Account to be debited or issuing banks /
reimbursing banks account in the case of export. Where MT 742 needs to be
sent, this account should be a Nostro.
PAYMENT.METHOD Field to be indicated with N (Nostro), IT (Internal
Transfer), BP (Bankers Payment) or CH (Cheque Payment)
PAYMENT.ACCOUNT Field holds the Account to be credited with the amount
of drawings. Account of advising/reimbursing bank in the case of import or
account of beneficiary in the case of export. If pay method is N, then this
account has to be a Nostro. For pay method IT, the account can be an internal or
a customer account. For BP and CH account, will be as per LC.PARMETERS.

DEBIT.VALUE Field is meant for SP drawings.
ROUND.RULE Field enables the user to define the type of rounding that should take place
while debiting or crediting the customers account. 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.

Limits can be set separately for Opening LC and Usance drawings. If
DRAWINGS limit products are not set in LIMIT.PARAMETER, Usance
drawings use LC opening limits. Provision release is proportional to the
drawings which can be optionally regulated. AUTO.EXPIRY Field will
allow the user to input value only for AC/DP type of drawings . When
AUTO.EXPIRY is set to yes system will automatically liquidate the
contract on the expiry / maturity date . When it is set to NO the contract
has to be manually liquidated. This field will default to NO if not input by
the user.

When correct documents are presented,
SP Payment made immediately to the beneficiary or collecting bank
with reimbursement claimed from applicant or opening bank.
AC and DP used as per tenor. These may be discounted by the bank.
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 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.

RP - For export LC, this indicates 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.

PAYMENT.METHOD Field to have a value - N (Nostro), IT (Internal
Transfer), BP (Bankers Payment) or CH (Cheque Payment)
DRAWDOWN.ACCOUNT Field to hold the Account to be debited or
applicants account in the case of import. Account to be debited or
issuing banks / reimbursing banks account in the case of export. Where
MT 742 needs to be sent, this account should be a Nostro.
PAYMENT.ACCOUNT Field indicates the Account to be credited.
Account of advising / reimbursing bank in the case of import or account
of beneficiary in the case of export. If pay method is N, then this account
has to be a Nostro. For pay method IT, the account can be an internal or a
customer account. For BP and CH account, will be as per
LC.PARMETERS.
MATURITY.REVIEW Field 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 importers bank from exporters bank. The
importer may not like to pay till he sights documents. Hence, it is
possible to debit an internal account and pay the exporters bank while
the importers 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.
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.

Option will be available to the user to net the proportionate Cash margin
released with the drawings amount and debit the balance amount from the
drawdown account when drawings are initiation.
A new field, "PROV.NETTING" is introduced in LC.PARAMETERS
and DRAWINGS application.
Value defined in LC.PARAMETERS will be defaulted. User can amend
the defaulted value. This field will assume significance only if provision
is collected in the underlying Letter of Credit. This will be a no change
field. Drawings payment entries will be netted with the proportionate
amount of cash margin released only when the drawings currency and
credit provision account currency are the same.

DRAW.NEGOTIATION application serves as a front end tool to input
multiple drawings into DRAWINGS application. 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, the system will generate TWO or more DRAWINGS
on hold. This application contains various Fields in DRAWINGS which
when entered gets mapped to the appropriate Field in DRAWINGS. It
also generates activity. Hence through soft delivery any related messages
can be generated.

During the issuance of Usance Letter of Credit, the bank has to define
whether the settlement of LC amount will be made in instalments or not.
Based on this selection, the system will allow the user to handle multiple
instalment payments on different maturities from a Drawing record.
Besides, the bank wants to generate MT 756 message for each
instalments with due date and amount of instalment. On the instalment
due date, the system will generate MT 202 message for each instalment
amount if Reimbursement authority is not provided in the letter of credit.
If an Export Letter of Credit with Reimbursement Bank, the system will
generate separate MT 742 message for each instalment amount. Likewise,
MT 754 will be generated for each instalment independently.
An option will be provided to the bank to select value in LC application
for generation of MT 740 either from LC contract or drawing contract.

There are 2 methods in which drawings could be effected in Transferable
LCs.
1) Through the Parent LC
2) In the Child LC directly

A Beneficiary of an Export Usance transaction may wish to receive funds
in advance before the maturity date.
If the beneficiarys 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 beneficiarys 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 the LC.PARAMETERS file.
Components of a Discounted Drawing are -
Discount Rate
Load / Spread for the Treasury Dept
Value date
Interest amount
Spread amount
Charges

For discount of Sight Drawings, an internal account CUSDEBIT
available in ACCOUNT.CLASS is used. When a 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 Field to MATURITY.REVIEW
Field. By default DISC.EFF.DATE shall hold the VALUE.DATE.

When a Drawing is set to NOTDEBITED the system uses CUSDEBIT as
DRAWDOWN.ACCOUNT to post the reimbursing entry. When set to
NOTDEBITED the MATURITY.REVIEW Field 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 be for the period from DISC.EFF.DATE Field to
MATURITY.REVIEW Field.
DISC.EFF.DATE Field by default shall hold the VALUE.DATE Field.
Where the User intends to provide Grace time for calculation of interest
component the DISC.EFF.DATE Field 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 Field cannot be less than the VALUE.DATE or greater
than the MATURITY.REVIEW Field.

When the final settlement is to be done, User has to do an online maturity
using 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
RECEIV.SETT.ACCT Field.
When the customer account is DEBITED, choice 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 RETURN.INTERST Field.
When DR.DEBIT.TO.CUST Field 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.
The input in RECEIV.SETT.ACCT Field 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.

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 Field in the PERIODIC.INTEREST table, the
same needs to be specified in the Drawings record as Market Offered
Rate (MOR) in the INT.MLR.MOR Field. Such Tiered rates may be used
for Usance or Sight Discounting.

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.

Agency charges may be taken in the DRAWINGS application. An agent
is a Broker or middleman between the Importer and the Exporter and
obtains his fee or commission from the Drawing amount as a percentage
or a flat amount.
The Brokerage details are entered on the Drawings contract where
required. The Brokerage may be settled in any currency defined on the
Broker record. The amount of the Brokerage is held in three places,
which may be in three different currencies.
BROKERAGE - Held in the currency of the Drawing.
BROKER.AMOUNT - Held in the Broker currency.
BROKER.AMT.LCY - 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.

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 ASSN.REFERENCE, ASSN.CUSTNO, ASSN.ADD,
ASSN.AMOUNT, and ASSN.NOTE Fields. 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 Field
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.

DRAWINGS supports multiple debits from one or multiple customer
accounts at different exchange rates. Amount to be debited from the
regular DRAWDOWN.ACCOUNT is defined by use of
APP.DRAW.AMT and MULTI.DR.AMT Fields, which are expressed in
the currency of Drawings. Default value in APP.DRAW.AMT Field is
that of DOCUMENT.AMOUNT Field.
When user desires to choose the multiple debits option, the amount to be
debited from DRAWDOWN.ACCOUNT is to be input in
APP.DRAW.AMT Field. When the value in this Field is less than the
DOCUMENT.AMOUNT, system populates the balance in the
MULTI.DR.AMT Field.
Multiple drawings can be achieved by input of TPRECV in the
ASSIGNMENT.REF Field.
System uses transaction codes set up in LC.PARAMETERS,
ASSN.TRAN.CODE.CR and ASSN.TRAN.CODE.DR Fields for
Assignments.

As per URC 522 Article 2:
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 buyers acceptance of a draft.
LC.TYPES file should provide for all these types of collections.

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 sellers 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

COLL.MAT.CODE Field in conjunction with DAYS Field supports
Option K of Tag 32a in 4** series of SWIFT. Triggered if DAYS Field
has a value and DATE.ACCEPTED Field is left blank. The default
values are ST in the case of Sight Document and BE in the case of
Usance documents. In case DATE.ACCEPTED Field is input, then that
will be taken to form F32 of MT 400.
To input a draft of '120 days from the bill of lading date', the number
'D120' would be inserted in DAYS Field. The descriptive text i.e. 'days
from the bill of lading date' could be inserted in TENOR Field or
COLL.MAT.CODE Field (may also be input with BE in this case).
Values in COLL.MAT.CODE Field could be like BE (after date of Bill of
Exchange), CC (Customs clearance of goods), FD (after goods pass Food
and Drug administration), FP (First presentation), GA (after arrival of
goods), ID (after Invoice date), ST (Sight).

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.
The customer may like to give his own serial numbers instead the banks
running numbers. The application DIR.COL.ALL enables input of a
range as displayed above to be allotted to the customer. The id is the
customer Number.

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.PARAMETERS or COUNTRY file 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.

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.

At the request of the Customer (Drawee) the bank issues a shipping
guarantee to clear the goods from the port of discharge when the relative
shipping documents have not been received at the counters of the
collecting bank. In these cases, the collecting bank will issue a shipping
guarantee and link the same to the collection documents.
The linking of the shipping guarantee with the collection document will
be done through the field GURANTEE.REF in the LC application. The
field GUARANTEE.REF will be opened up for input when the user
books the documentary collections.
The Cash Margin/Provision collected under the guarantee will be credited
to an internal account of the bank or customers account until the
settlement of the Collection Document. The collected cash margin will
be netted at payment of the Sight Documents. For the Accepted collection
documents the bank may release the cash margin after the return of the
original shipping guarantee. A new field (SG issued for) has been
introduced in the MD application with an optional value Import LC and
Import Collection. The user should select the appropriate value based
on the nature of transaction.

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).

The drawee is entitled to examine the documents at the collecting bank
prior to making payment. However, prior inspection or examination of
the goods is not permissible without special authorisation from the
principal. If the drawee is a good and regular customer, the collecting
bank may send him the documents `in trust. However, the bank must be
sure that he 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.
TRUST.REL Field is activated for Import Collections. The values
accepted are RELEASE, ACCEPT or REJECT and can also be left blank.
On opening of an LC the valid value accepted in this Field is RELEASE.
This denotes that the documents have been accepted under TRUST. 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.
When this Field is kept as null, the system processes like a normal
collection. 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 updates this Field as EXPIRED. No drawings are allowed in the system
unless the documents released under trust are accepted.

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. The first valid value
accepted in this Field is RELEASE. This denotes that the documents
have been accepted under TRUST. 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.

A Facility can be attached to an LC also. Both Import and Export LCs
can be linked to a Facility. In an Import LC, applicant is the customer and
in an Export LC, the issuing bank is the customer. The products LCI and
LCE are to be defined in Facility to attach it to the LC. However both
LCI and LCE cannot be attached to the same Facility.
When a Facility is attached to an LC, the LC uses the Facility limit only.
The participants in the LC get defaulted from the Facility as per the ratio
defined in the Facility. The ratio can be altered at the LC level but the
share of each participant should not exceed the total share defined in the
Facility for that particular product.
Ex : Suppose in the Facility, we have defined USD 100,000 for
participant X and the percentage of participation is 60%. In the LC of
USD 100,000, it gets defaulted to 60,000 (as per the ratio). Here we can
change the default value from 60,000 to 100,000 but not more than that.

Below are the steps to be followed to attach a Facility to an LC:
Create a PRE.SYNDICATION.FILE
Define the Facility. In the Facility, choose multiproduct to be yes.
Include LCI or LCE as one of the allowed products
Input an LC
Field SL.REFERENCE.TRANCHE holds the ID of the Facility-Tranche.
This is the field that links the Facility to the LC
Then select the product type (LCI or LCE)
Once the product type is selected, the details of the participant and the
details of their share gets defaulted from the Facility

Following are the exclusions:
Preadvise is not allowed for Syndicated LCs
An LC with Provision cannot be linked to a Facility
Revolving LCs are not allowed under Syndication
While issuing an Import LC, the applicant of the LC should be the
Facility customer or any other allowed customer defined in the Facility.
In an Export LC, the issuing bank should be the Facility customer or any
other allowed customer in the Facility.
The LC currency should be the Facility currency or any other allowed
currency in the Facility.
A Syndicated LC cannot be overdrawn.

Facility can be linked to an LC while issuing the LC or while amending
the LC. However if the LC has a drawing already, Facility cannot be
linked to an LC.
The bank can choose to split the charges collected under the LC with its
participants also. If the bank wants splitting of charges, those charges
(defined in FT.COMMISSION.TYPE or FT.CHARGE.TYPE) have to be
defined in LC.PARAMETERS. If the charges are not defined in
LC.PARAMETERS, they cannot be syndicated.
The bank can choose to collect these charges (defined in
LC.PARAMETERS) or not. The choice is at the LC level. Field
SYNDICATE.CHARGE controls this. If this field is YES, the charges are
split between the participants as per their share in the Facility. Only the
agents share of the charges hits the P&L.
If the bank does not want the charges to be syndicated, the field
SYNDICATE.CHARGE has to be No. If the charges are not
syndicated, the entire charges is taken to the agent banks P&L.

We have already seen that a syndicated LC uses facility limit. If an
existing LC is attached to a Facility, the initial limit line is reversed and
the Facility limit line gets hit. Limit gets hit for the own bank share only.
Revolving Facility reinstates limit and facility whereas non revolving
facility does not.
Accounting entries are also generated for own bank share only.

Both Sight and Usance Drawings under syndication behave like normal
drawings. Only facility limits are affected. There is no separate limit line
for Usance Drawings under syndication. If the Facility is revolving, limit
and facility get reinstated.
Syndicated charges can be collected at the Drawings stage also. Only
charge status 2 is allowed at this stage.
Discrepant drawings also are handled in the same way as they are
handled under normal LC.

Both Sight and Usance Drawings (AC and DP) can be discounted. For
Sight Discounts the account defined using the CUSDEBIT category code
is debited for Own Bank share and for Usance discounts, LIVEDB is
debited. In both the cases, participants nostro or their account with us is
debited for their share.
There is an option where the own bank or the participants can choose not
to participate in the discount. Field PART.DISC.AGREE in Drawings is
used for this. If the field value is YES, the participant is agreeable to the
discount. If the value is NO, the participant does not agree to the
discount.
If any of the participants (including own bank) choose not to participate
in the discount, the bill amount less that particular participants share is
credited to the beneficiary.
For revolving facility, the limit and facility get reinstated on the maturity
dates.

To establish a letter of credit through internet banking, T24 bank should
first create Login names and password for the clients . In Corporate
Internet Banking , the organisation is the customer of a bank . Corporate
Employees are the users and thus corporate users need Internet Banking
Access. Users within a corporate may have different access rights. For
instance, some may have access to input transactions in the system and
the others might have access to authorise those transactions. In the Model
bank Corporate ARC-IB Configuration, the Corporate Users are broadly
classified into different classes. For instance Director Group, Manager
Group, Clerk Group, Admin Group. Each Group may have different
access rights.
The Director of the company has options to Authorise & view the
transactions of the Corporate Company. He has access to all accounts of
only the parent Company and has rights to authorise transactions. In
Model Bank Setup, the Managers of the corporate have access to all
accounts of the corporate. They have the "Authorisation Rights" for
authoring transactions like that of a funds transfer and bulk payments
made. Clerk User has access to the parent Company only. He has access
only to input transactions in the ARC IB and does not have the rights for
authorisation. The Administrator has access to the parent Company only.
He does not have access to any of the accounts of the parent Company .

Once an IB client is created system will have a record established in
DE.CUSTOMER.PREFERENCES

To enable this functionality Initially bank has to create login profiles for
all the corporate user. Again depending upon the roles played by the user
in the respective client organisation, appropriate profiles will be created
by the bank. For example There could be clerks in Corporate organisation
who needs to input the LC application . There could be officers in the
corporate organisation who needs to verify and authorise the LC
application. Based on the roles played Bank will create Proxy Permission
and Internet settings in T24 under Internet Banking administration.
Once the proxy and Internet settings are created with their Login options ,
then the corporate users can launch their activities through ARC IB for
requesting the establishment of LC. Once those details are entered, the
corporate user will click the radio button to Submit the same to the Bank.

During the process of import LC issuance request initiated by the
corporate customer through internet banking, IB.LIMIT Field in
LC.PARAMETERS will determine the stage at which limit should get hit
for the applicant. If it is set as YES, limit entries will get raised
immediately after the transaction is entered by the corporate user. If the
bank decides to hit the limit only after authorising the transaction by the
Bank user, this field should be set as NO. LIMIT.BROKEN Field is
provided to facilitate the ARC IB client for providing necessary
information to the bank in case of the transaction amount exceeding
available limit for him. CONTACT.INFO Field provides the contact
details of the person who can be contacted by the bank if they need any
clarification.

Internet Banking helps the clients to request the issuance of an LC by
sitting at their desk. To send this request online, the officer who works at
the Client side will input the terms and conditions of the LC (He should
have been given sufficient privileges to do so).
This LC has to approved by another officer/manager who has the rights to
approve the request. When the approving officer/manager logs into
Internet Banking, he will be able to view the LC with the status
Pending.
If the Limit has to be hit at this stage itself, the Field IB.LIMIT in
LC.PARAMETERS has to be set as Yes.

When the record is authorised by the competent user of the corporate
client, the transaction will appear at the Bank side with OPERATION
Field value as IO and IB.STATUS as Pending. LC.TYPE Field value
in LC record would be arrived based on values available for
PAY.TERMS, TRANSFERABLE, CONFIRM.INST and STANDBY.LC
Fields given by the ARC IB user. For example, if PAY.TERMS and
CONFIRM.INST Fields have values entered as Acceptance and
CONFIRM, the LC.TYPE Field will get updated as IAC (LC Import
Acceptance Confirmed) at the bank side. When a situation arises wherein
the LC.TYPE could not be ascertained from the given combination,
system will update the catch all LC.TYPE IARC which can be reviewed
and corrected by the bank to reflect the correct LC.TYPE.
EXPIRY.DATE of the documentary credit will be arrived by adding the
ADVICE.EXPIRY.DATE field value given by the ARC IB client with the
EXPIRY.DAYS field value available in LC.PARAMETERS.
During the process of import LC issuance request initiated by the

corporate customer through internet banking, IB.LIMIT Field in
LC.PARAMETERS will determine the stage at which limit should get hit
for the applicant. If its set as YES, limit entries will get raised
immediately after the transaction is entered by the corporate user. If the

bank decides to hit the limit only after authorising the transaction by the Bank user,
this field should be set as NO. LIMIT.BROKEN Field is provided to facilitate the
ARC IB client for providing necessary information to the bank in case of the
transaction amount exceeding available limit for him. CONTACT.INFO Field
provides the contact details of the person who can be contacted by the bank if they
need any clarification.

If the Bank is satisfied with the information provided by the ARC IB
customer and accepts the request as it appears, the OPERATION field
will be set as O, IB.STATUS will become as Approved at bank side
and remain as Pending at the ARC IB side. Once the transaction is
authorised by the Bank, the status at the ARC IB side will be updated as
Approved. Delivery messages including SWIFT messages and the
accounting entries pertaining to the transaction will get generated. Once
the transaction is authorised, system will not allow amending the
OPERATION field value from O to IO.
If the Bank requires any additional information or need to amend any

existing details, the IB.STATUS will be set as Modification requested
with the expected changes updated in the IB.REASON field. The initial
version of the client request would be made available in history for audit
Trial. On looking at the IB.STATUS field in ARC IB updated as
Modification Requested the corporate user will amend the LC request
and resubmit with necessary changes sought for. Now the IB.STATUS
field at ARC IB side and at the bank side would appear as Modified.
The transaction will be available to the Bank for further processing.

If the Bank decides to reject the LC request for some reason, the
IB.STATUS can be set as Rejected stating the reason for rejection in
IB.REASON field. Limit for the client would get reinstated at this stage
when IB.LIMIT is set as YES. The record will be moved to history after
crossing the CLOSING.DATE.

The Cash margin taken in LC may be apportioned or entirely used up in
MD.DEAL, towards issue of a shipping guarantee. This may be done to
assist the importer from funding for margin, twice. In such a scenario,
the Margin for Shipping Guarantee may be taken in MD.DEAL, quoting
the LC reference along with the amount. This detail on the Guarantee
into which the Cash Margin of LC has been parted with is stored in
GTEE.REFERENCE Field. 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.

Accounting entries are Contingent as well as Non contingent.
STMT.ENTRY and CATEG.ENTRIES are generated for Customer
Accounts and Internal accounts and PL heads.
RE.CONSOL.SPEC.ENTRY passed for other entries.
Different Asset types are: PREADV, ISSUE, DEFPAY, ACPTCONTRA,
ACPTBANK, COLL, TRCOLL, ADVICE, CONFIRM, ACPT, OPEN
(for RP status in Drawings) are contingent and PAYRES which is non
contingent. LIVEDB used for discounted drawings.
Transaction codes for accounting entries are specified through
LC.PARAMTERS and FT.COMMISSION.TYPE.

Accounting entries generated for various types of Imports on the date of
input or value date are below:
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 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 beneficiarys a/c is credited through
Nostro A/C or otherwise and our Customers (L/C Openers) account is
debited.

Similar to Import Sight LC, accounting entries are generated with slight
changes.
First entry 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.ENTRIES 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 beneficiarys account is debited and the exporters
(Customers) 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 beneficiarys 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 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
Debiting a customers account is a STMT.ENTRY and crediting a P & L
account is a CATEG.ENTRY.
SPEC.ENTRIES are passed for claim made. Suitable STMT and/or
CATEG.ENTRIES are passed when the respective events occur (Debiting
Nostro a/c when charges are received, Crediting to PL, its due share at the
end of every month etc)

The Trade Finance application automates production of SWIFT messages
in the 700 and 400 ranges (700 for Letters of Credit and 400 for
Documentation 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.

DE.MESSAGE contains contents of basic message types. Id 700 is
meant for Issue of Documentary credit and defines all Tags by Name like
SEQ, TYPE.OF.CREDIT etc.
When a transaction is authorised, all transaction details are written to
DE.O.HANDOFF. These can be viewed through Enquiry
DE.HANDOFF.DETS.
DE.MAPPING defines where data is located and helps mapping. Id
700.LC.1 (Message type, Application and sub classification) Maps
through Input Position (information from DE.O.HANDOFF or
Application) and Field Name (Tag names pre defined in DE.MESSAGE)
.

DE.FORMAT.SWIFT formats the message. Id 700.1.1 formats as Field
Tag, Field Name ,Tag 27 Field SEQ, Tag 40A Field TYPE.OF.CREDIT.
DE.PRODUCT sets rule Company wise, Customer / Account wise,
Message type wise Number of copies, Carrier to be used etc.
DE.ADDRESS helps store Company wise, Customer wise, Carrier wise
addresses. Can be used to hold mail.
DE.O.HEADER lets us know the message disposition.
Used to track the message. Contains information about the processing and
status of the message. Can also be used to re submit a message.

System would be able to perform auto processing of inward MT734,
MT750 and MT754 messages. When the system receives MT750 or
MT754 message for processing, it immediately checks for the value in
tag 21 (Related Reference). If the value corresponds to Letter of Credit
ID issued by the bank, system creates a drawings record in IHLD status
with Draw Type as following:
MT750 -`CO
MT754 - SP'
If the value in tag 21 does not correspond to Letter of Credit ID issued by
the bank or if any error is encountered during auto processing the
message will be placed in the 'Repair' queue.
DE.MAPPING records, 750.DR.IN and 754.DR.IN are defined to map
the swift tags to the fields in DRAWINGS.

The Operation codes are as follows;
1000 LC Opening and Pre-advice
2000 LC Amendment/Charges/Tracing
3000 Drawings - Sight Payments
4000 Drawings - Usance Payments
5000 LC Shipping guaranteed
For 1000 series
100 Outward
200 Inward
400 Export
00 Input/Authorisation (Default)
01 Opening Input/Authorisation
02 Pre-advice Input/Authorisation
11 L/C Expired on LC.EXPIRY date
12 Pre-advice Expiry on LC.EXPIRY date
90 Reversal / Authorisation

For each activity a set of advices are defined in EB.ADVICES .
EB.ACTIVITY codes are linked to required Message Types and Message
classes like Advice, Payment etc.
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.
But 740 will be produced only if THIRD.PARTY.CUST.NO NE in LC.

Prior to authorisation, the User can make amendments to the messages
generated if required.
For example, the MT 700 has been set to go via SWIFT in
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.

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

Some important System Maintained tables are:
LC.NEGOTIATE LC wise details of DRAW.NEGOTIATE.
LC.PARENT.DRAW This shows LC wise list of Drawing in Child LC
done THROUGH Parent LC.
LC.REVOL is for due date wise list of Revolving LCs.
LC.TRANSFERABLE is Parent wise list of Child LCs.
LC.ACCOUNT.BALANCES shows Live LCs, Currency and date wise
entire history of Charges and payments.

For each LC contract, a unique EB.CONTRACT.BALANCES record will
be updated. This will hold contract currency, balances by asset types,
daily movements for each asset types and Consol key. This file will be
updated by core accounting process at authorisation level.

LC enquiries are:
LC.SUMMARY to show Overview of an individual LC including its
drawing history.
LC.REIMBURSE.CLAIM to show overview of drawing wise
reimbursements due.
LCAC.CHARGES to give Details of charges amortised LC wise.
LC.HIST gives Complete history of LCs.

LC Standard reports are
LC.SUMMARY -Overview of an individual LC including its drawing
history.
LC.REIMBURSE.CLAIM - Overview of drawing wise reimbursements
due.
LCAC.CHARGES- Details of charges amortised LC wise.
LC.HIST-Complete history of LCs.

We have so far seen
The overview of the LC module
Linkages between LC module and T24 Core and other applications
Dependencies and parameter tables to be set up
Main business features of LC module
Import LC Issuance through Internet Banking
Accounting, messaging and enquiries


T3TLC - Letters of Credit - R13 1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

T3TLC - Letters of Credit - R13 1

Загружено:

Авторское право:

Доступные форматы

T3TLC - Letters of Credit - R13.

5. Learning to issue Import LC through Internet

T3TLC - Letters of Credit - R13.1 2

T3TLC - Letters of Credit - R13.1 3

T3TLC - Letters of Credit - R13.1 4

T3TLC - Letters of Credit - R13.1 5

T3TLC - Letters of Credit - R13.1 6

T3TLC - Letters of Credit - R13.1 7

T3TLC - Letters of Credit - R13.1 8

T3TLC - Letters of Credit - R13.1 9

T3TLC - Letters of Credit - R13.1 10

T3TLC - Letters of Credit - R13.1 11

T3TLC - Letters of Credit - R13.1 12

T3TLC - Letters of Credit - R13.1 13

T3TLC - Letters of Credit - R13.1 16

T3TLC - Letters of Credit - R13.1 17

T3TLC - Letters of Credit - R13.1 18

T3TLC - Letters of Credit - R13.1 19

T3TLC - Letters of Credit - R13.1 20

T3TLC - Letters of Credit - R13.1 21

T3TLC - Letters of Credit - R13.1 22

T3TLC - Letters of Credit - R13.1 23

T3TLC - Letters of Credit - R13.1 24

T3TLC - Letters of Credit - R13.1 25

T3TLC - Letters of Credit - R13.1 26

T3TLC - Letters of Credit - R13.1 27

T3TLC - Letters of Credit - R13.1 28

T3TLC - Letters of Credit - R13.1 29

T3TLC - Letters of Credit - R13.1 30

T3TLC - Letters of Credit - R13.1 31

T3TLC - Letters of Credit - R13.1 32

T3TLC - Letters of Credit - R13.1 33

T3TLC - Letters of Credit - R13.1 34

T3TLC - Letters of Credit - R13.1 35

T3TLC - Letters of Credit - R13.1 36

T3TLC - Letters of Credit - R13.1 37

T3TLC - Letters of Credit - R13.1 38

T3TLC - Letters of Credit - R13.1 39

T3TLC - Letters of Credit - R13.1 40

T3TLC - Letters of Credit - R13.1 46

T3TLC - Letters of Credit - R13.1 49

T3TLC - Letters of Credit - R13.1 52

T3TLC - Letters of Credit - R13.1 53

T3TLC - Letters of Credit - R13.1 54

T3TLC - Letters of Credit - R13.1 55

T3TLC - Letters of Credit - R13.1 56

T3TLC - Letters of Credit - R13.1 57

T3TLC - Letters of Credit - R13.1 58

T3TLC - Letters of Credit - R13.1 59

T3TLC - Letters of Credit - R13.1 60

T3TLC - Letters of Credit - R13.1 65

T3TLC - Letters of Credit - R13.1 66

T3TLC - Letters of Credit - R13.1 67

T3TLC - Letters of Credit - R13.1 68

T3TLC - Letters of Credit - R13.1 72

T3TLC - Letters of Credit - R13.1 76

T3TLC - Letters of Credit - R13.1 77

T3TLC - Letters of Credit - R13.1 79

T3TLC - Letters of Credit - R13.1 82

T3TLC - Letters of Credit - R13.1 83

T3TLC - Letters of Credit - R13.1 84

T3TLC - Letters of Credit - R13.1 85

T3TLC - Letters of Credit - R13.1 94

T3TLC - Letters of Credit - R13.1 95