VOBAN R16 Highlights Corporate Lending and Trade Finance

NBG T24 CC
NBG T24 Competence Center
HIGHLIGHTS
T24 DIFFERENCES BETWEEN R13 AND R16
Corporate Lending and Trade Finance
NBG Competence Center 1 5/29/2019

NBG T24 CC
Contents:
I. INTRODUCTION ........................................................................... 3
II. HIGHLIGHTS................................................................................. 3
II.1. CORE CHANGES .......................................................................... 3
II.2 LOCAL CHANGE AND AFFECTED BRDS ........................................ 34

NBG T24 CC
I. INTRODUCTION
This document is prepared with regards to the upgrade process of Vojvodjanska Banka
core Banking system from Release 13 to Release 16 Browser of T24. This document serves
to explain and highlight the main differences between the two releases in the Corporate
lending and Trade Finance areas, the innovations introduced, the obsolete items and the
pipeline items affected by the upgrade.
The document has as a scope LD.LOANS.AND.DEPOSISTS, LIMIT, COLLATERAL,

MISCELENIOUS.DEALS, LETTER.OF.CREDIT and DRAWINGS applications.
The corporate loans are maintained in LD module of the system. For each loan a revolving
or non-revolving commitment could be opened in order the unused amount to be
reported on the off balance.
For each loan a LIMIT is opened in order to track the liability in the system. Collaterals of
the bank are registered in the system and linked to respective limits.
Received and Issued guarantees are booked in the MISCELENIOUS.DEALS module.
Import and Export letters of credits and Inward and Outward Collections are booked in
LETTER.OF.CREDIT application. The actual payments are processed through DRAWINGS
application.
II. HIGHLIGHTS
In the releases between R13 and R16 Browser, changes were performed mainly for MD,
LETTER.OF.CREDIT and DRAWINGS contracts. New implementations effects on refund
charges/commissions reinstate of maturity date, claim commission and netting provision
in letter of guarantees. Implementations regarding Trade Finance are manual maturity
of letter of credit and drawings, periodic commission, settlement of drawings in multiple
installments, refund of charges, auto process of inward messages, accrual of claim
charges, netting of provision entries in Drawings and etc.

NBG T24 CC
II. CORE CHANGES
Limits:
 Limits for OBSI Products
The existing T24 LIMIT module allows mixing products of different types on the level of
the GLOBAL limit but restricts mixing sub-products of different types. Enabling the
mixture of such limits on the level of limit products, allows external systems to register
limits exposure in T24.
Previous functionality:
- The existing T24 LIMIT module allows mixing products of different types on the
level of the GLOBAL limit but restricts mixing sub-products of different types.
- Percentage of Limit utilisation by the transaction booked within T24 can be set at
any level between 1 and 100%.
- Collateral utilisation levels could be controlled on the level of the individual asset
type.
New functionality:
- Provided, that the parent limit allows mixing child products of different types
would allow booking limit utilisation of any type through the sub-product
associated with the contingent account.
- By enabling 0% limit utilisation in FX and TB – related products, the system

suppresses the automated calculation of the Limit exposure.
- The user sets up Limit products and or Limit record with utilisation levels
thresholds using a percentage ratio between the limit utilisation and the available
limit amount. The background process checks Limit utilisation against the linked
collateral and in case if any of the threshold is found broken, the internal log table
is updated with the relevant record for reporting purposes.

NBG T24 CC
 Limits for Sight Discounted Drawings - The liability of the risk party gets updated
when sight drawings under an Import/Export LC is discounted. Limit can be raised
when a letter of credit record is discounted at sight. LIMIT.REFERENCE records
have to be created and conditions have to be set under LIMIT.PARAMETER record.
Collaterals:
 Collateral Advance Ratio - Margin rates can be defined and applied for Non
Security Collaterals as well. The Assets and Liabilities of a customer can be
consolidated and margin surplus/deficit can be determined.
In T24, the Collateral (CO) module was used the record the collaterals held by the
customer and used to secure the liabilities of the customer; Collaterals can be used to
secure the limits created for the customer or can be directly attached to contracts.
Previously, the T24 Collateral module calculated collateral figure for assets held by a
customer on T24. It was done at two levels:
- The calculation of a collateral value on assets held individually by a customer
- The calculation of a collateral value on assets held as a grouped T24 portfolio
(SEC.ACC.MASTER record)
On T24, customer can have more than one portfolio and can hold assets and liabilities
outside of a portfolio. T24 had slightly different calculations of collateral for assets held
as part of a portfolio and assets held outside of a T24 portfolio. There were also different
calculations for different types of assets.
The value of the portfolio was calculated by the Securities module and collateral
consumes this value from SC.POS.ASSET table. Margin rate for the asset to calculate
margin value (Collateral value) was defined at different levels such as
SC.CUSTOMER.MARGIN, MARGIN.CONTROL, ASSET.BY.CATEG, ASSET.TYPE and
SUB.ASSET.TYPE tables.
For the assets held outside of the portfolio, the margin rate was setup in
COLLATERAL.TYPE application field as % of nominal value (%N).
Also, there was no process to consolidate all the assets held by customer and compute
whether collateral value is surplus or deficit.

NBG T24 CC
New functionality:
This enhancement is done to treat all the assets of a customer together when calculating
the collateral value of a customer. As a result of this, a new functionality to use advance
ratio (Margin value) for calculating collateral value should be consistent for all assets.
This modification is specifically concerned with the calculation of the collateral amount
that will be available from the assets of a customer.
This calculation is done within the Collateral module of T24 and is possible to trigger from
inside or outside of T24. Examples of routines that calls this process:
- Called by securities module in T24 when revaluing the portfolio
- Called by Triple A Plus when performing pre-trade checks on orders; this will be
through Securities and hence no specific change is required
- Called when the Advance Ratio is changed to recalculate the collateral using the
new Advance Ratio
T24 calculates Collateral Amount (margin amount) based on Advance Ratio (Margin Rate)
for the customer. When doing this, it takes the existing calculation on T24 and enhance
it to include the following functionality:
- Application of a concentration cap based on specific asset types, currency, country
and so on (Covered in another enhancement 'Concentration cap’)
- It should be possible to override the concentration cap
- Lower Advance Ratio is used if there is a currency mismatch between the base
currency of a portfolio and the unallocated assets of the portfolio.
The Advance Ratio value is calculated and fed to T24 from CETREL. It is not required to
be calculated by T24.
Advance Ratio can be defined at different levels. These levels are:

- Customer Level
- Individual Security
- Product
- Currency
- Definition of Advance Ratios based on Tiering

NBG T24 CC
 Concentration Cap Calculation - This enhancement facilitates applying cap for a

collateral value, which is used to ensure that an asset is not used extensively,
defining whether a collateral can be allocated for a liability i.e. eligible for
allocating to a particular liability or not and configuring the order of collaterals to
be used for allocation of liability (ranking of collaterals).
In T24, collateral (CO) module is used to record the collaterals held by the
customer and used to secure the liabilities of the customer. Collaterals can be
used to secure the limits created for the customer or can be directly attached to
contracts.
The loan contract tried to utilize a limit, if it was a secured limit, then allocation
would be done based on the underlying collateral value. Allocation of asset to
liability would be done only when the collateral was attached to the limit, which
was utilized by the liability.
New functionality:
Concentration Cap
The Concentration cap can be applied on collateral values to avoid extensive

usage.
It is possible to configure different concentration cap rules.
The concentration cap at different levels:

1. Single Counter Cap, this is a limit set-up for using a specific instrument as
collateral. For securities, this should be recorded on the Security Master record,
for other assets it should be recorded at a product level.
2. Standard Maximum counter cap when there is no single concentration cap
defined, then cap defined at parameter level has to be used. There are exceptions
to this rule. For example, this rule does not apply to cash so it should be possible
to exclude products from this concentration cap.
3. Single EM (Emerging Market) country concentration cap for countries UCR2+ to
4- at 40% of total collateral portfolio. For Asset Types like e.g. Hedge Funds - e.g.
next to a 10% single counter cap (i.e. on a specific hedge funds instrument) a 15%

NBG T24 CC
overall hedge funds cap on the total collateral can be defined. There are also
concentration caps for Subordinate and Perpetual bonds.
4. For Equities - Tier-1 40% concentration cap, Tier 2 and 3 - 30% concentration
cap. For this purpose it is required to have the possibility on Equity (FI) level to
indicate the tier (link with Securities Static Data PRL).
As Concentration Caps are kept on various levels as the final collateral is

calculated, each defined Concentration Cap will be processed in turn when
calculating the final collateral value for the customer.
When a concentration cap is exceeded, this should trigger an alert to a

Relationship Manager. The alert itself will be triggered by an update to the T24
file CO.CONC.CAP.EXCESS. This file will be updated whenever a Concentration Cap
is exceeded by the assets of a customer.
Collateral Eligibility
The new application CO.ELIGIBILITY can be used to define the eligible collaterals
for a particular category.
When deciding which asset to use against which loan in the calculation of the
Collateral Deficit or Surplus, the system checks the Category of the loan against
the CO.ELIGIBILITY table.
If the category of the loan is not on the CO.ELIGIBILITY table then no eligibility
rules have been set-up so all assets will be considered as eligible against the loan.
If the customer has more than one loan then the system will read the
CO.ELIGIBILITY record for each of the loans in turn and then rank the liability order
of the loans. The loan with the strictest eligibility will be used first. For example, if
a loan only has cash as eligible collateral then this will be processed before a loan
that has cash or marketable securities as eligible collateral.
If a customer does not have sufficient eligible collateral to cover a loan then this
will be processed as a collateral deficit and an alert is sent to the Relationship
Manager.

NBG T24 CC
Collateral Ranking
Ranking of collaterals to allocation to a liability can be defined in the new

application CO.RANKING.
When deciding which asset to use as collateral, the following order of processes
will be followed:
First, T24 will check that the collateral is eligible to use as collateral (using
CO.ELIGIBILITY).
Then a check will be made that the currency of the asset matches the currency of
the loan.
T24 looks at the CO.RANKING record and processes the collateral in the order
defined on CO.RANKING where more than one asset has a currency that matches
the loan. So, the CO.Ranking can be set-up as follows:
- Cash
- Deposits
- Marketable Securities
In which, Cash items in the same currency as the loan will be used first, then
deposits and finally marketable securities. If there is more than one marketable
security that matches the currency, then the type of security would be used to
decide, which asset should be used first. The proposed order is:
- Equities
- Bonds
- Structured Products
- Funds
- Discretionary Portfolios
So, an equity position in an eligible security would be used before a bond position
in an eligible security.
If there are two assets in the same security type, both of which match the loan
currency, then assets with a RISK.COUNTRY that is a developed market will be
used before assets with a RISK.COUNTRY that is an emerging market.

NBG T24 CC
If there are two assets of the same currency, with the same security type and the
same RISK.COUNTRY, then the asset with the largest market value will be used
first.
 Collateral Exclusion - This enhancement provides a facility to exclude the

collaterals i.e., not consider a collateral’s value based on the Country, Currency,
Security, Industry and Issuer.
Collateral application is used to record the assets submitted by the customer, asset’s
values and optionally the liability for which the collateral can be covered. A customer can
pledge the account, deposit, security portfolio, security assets and so on as collateral.
Collateral can be attached to a secured limit. If the limit was a variable limit, then the
limit value would be changed based on the collateral value. The link between collateral
and limit was established by the application COLLATERAL.RIGHT. Without creating
collateral right, collateral cannot be created. The allocation of collateral to the limit was
recorded in the file LIMIT.COL.ALLOC.WORK. Allocation by default would be done by
system and can be done manually based on setup defined in
CO.ALLOCATION.PARAMETER.
There was no option to exclude a collateral from the asset value calculation of a customer
and from the allocation to the liability
New functionality:
A collateral can be excluded from being considered as the customer’s asset and in the
liability allocation.
Collateral can be excluded based on the following:

- Country
- Currency
- Security code
- Industry
- Issuer
A new application COLLATERAL.EXCLUSION has been introduced to define the collateral

static values based on which the collaterals can be excluded. For example, all

NBG T24 CC
Zimbabwean Assets such as Zimbabwean Securities and Zimbabwean property can be

marked for exclusion.
MD module:
 Non-stop processing is enabled for MD.DEAL application.
Previous Functionality: New contracts can be input in MD.DEAL application only
when the system is in online status.
New Functionality: The following activities can be performed when COB is run:
Issuance of new guarantee
 Auto processing of inward MT760.
 Generation of Swift Messages - MT 790 & MT 791 - Swift Messages MT791/MT491

is generated when commission is claimed and MT790/MT490 when commission
or charge is debited to a vostro account. In Guarantee transactions, commission
can be collected or claimed. Though the system supports collection or claim of
commission, the generation of SWIFT messages MT 791 for a claim and MT 790 or
an advice on debit/credit of commission to the account of a correspondent bank
is not supported from the application. MD module supports the collection of
charges and collection and claim of periodic commission. AC.CHARGE.REQUEST
application is to be used to generate MT790, MT791, MT490 and MT491
messages. MD module supports the generation of MT 791 when commission is
claimed and MT790 when a debit or credit happens to a VOSTRO account. MD
module supports the generation of MT790 when a debit or credit happens to a
VOSTRO account. When commission is claimed for the guarantees received, the
details of the commission will be populated in tag 32a: Amount of Charges of MT
768. When commission is claimed for the issuance of guarantee, the system will
generate MT 791 to the Receiver Bank. Override will be generated when Receiver
Bank is not input.
The tags of the swift MT791 and their corresponding mapping fields of MD.DEAL
application are:

NBG T24 CC
Tag Tag Name Field Name
MT791–Request for Payment of Charges Application: MD.DEAL
20 Transaction Reference Number Transaction ID
21 Related Reference NON REF
32B Currency code Amount CURRENCY CSN.AMOUNT
Generating MT790
When commission and charges are debited from a VOSTRO account, the system will
generate MT790 to the VOSTRO account holder.
When refund of charges happens to a VOSTRO account through MD.FEE.SETTLEMENT,
the system will generate MT790 to the account holder.
The tags of the swift MT790 and their corresponding mapping fields of MD.DEAL
application are:
MT790 – Advice of Charges Application: MD.DEAL
20 Transaction Reference Transaction ID

Number
21 Related Reference NON REF
25 Account Identification CHARGE.ACCOUNT CSN.ACCOUNT
32a Value Date, Currency code, ISSUE.DATE CHARGE.CURRENCY

Amount CHARGE.AMOUNT

NBG T24 CC
71B Details of Charges CHARGE.CODE
The system generates a single MT 790 message for the consolidated amount, in case
multiple charges are collected from a vostro account. Swift Messages MT791 is
generated when commission is claimed and MT790 when commission or charge is
debited to a vostro account.
 Auto processing of the inward SWIFT messages MT768 and MT769 is supported.
- The MT768 message type can be sent by a bank which has received a guarantee
to the bank which issued the guarantee or 0an amendment thereto. It may also
be sent by a bank which has been requested to issue a guarantee to the bank
which requested the guarantee or an amendment thereto. It is used to
acknowledge receipt of any message relating to a guarantee and, where
applicable, to indicate that action has been taken according to the instructions.
- The MT769 message can be sent by a bank which has received a guarantee to the
bank which has issued the guarantee. It may also be sent by a bank which has
been requested to issue a guarantee to the bank which requested the issuance of
the guarantee. It is used to advise the Receiver that it has been released of all
liability for the amount specified in field 33B or field 39C.
MT 768
T24 system is now supporting the auto processing of an inward MT768 message. This
message is used to acknowledge receipt of any SWIFT message relating to a guarantee
and, where applicable, to indicate that action has been taken according to the
instructions.
When an inward MT768 is received for processing, system checks whether the value in
tag 21 (Receiver’s Reference) matches either with the value in the field, ALTERNATE.ID
or @ID of an existing MD.DEAL record.
When the system identifies the MD.DEAL record to which acknowledgement is received
through MT768, the tags of the message are mapped to the MD record. The tags 20,

NBG T24 CC
25, 32A, 57A, 71B, 72 are mapped to the respective fields of the MD.DEAL application
as shown in the below table.
If the system is unable to find the related MD.DEAL record using the tag 21, then the
message can be placed in `Repair’ queue.
The SWIFT tags of the message and their mapping fields in MD.DEAL application:
M=Mandatory and
O=Optional
MT768 –Acknowledgement Application: MD.DEAL
20 Transaction Reference REFERENCE.1 M

Number
21 Related reference ALTERNATE.ID or M(field not mapped)

@ID
25 Account Identification SETTLE.ACCOUNT
30 Date of Message Being DEAL.DATE M(field not mapped)

Acknowledged
32a Amount of Charges AMT.OF.CHGS O
57a Account With Bank ACCT.WITH.BANK O
71B Details of Charges CHG.DETAILS O
72 Sender to Receiver SENDER.INFO O

Information
An enquiry lists all incoming MT 768 which have been successfully processed. The
incoming SWIFT message can also be viewed from the enquiry shown in the following
screenshot.

NBG T24 CC
"Processing of Repaired Messages" enquiry lists all messages which are not
automatically processed. User can view such messages and perform further
investigation through MT799.
MT769
T24 system is now supporting the auto processing of an inward MT769 message. This
message is sent by a bank which has received a guarantee to the bank which has issued
the guarantee. It may also be sent by a bank which has been requested to issue a
guarantee to the bank which requested the issuance of the guarantee. It is used to
advise the Receiver that it has been released of all liability for the amount specified in
field 33B or field 39C.
When an inward MT769 is received, system has to check whether the value in tag 21
(Receiver’s Reference) matches either with the value in the field, ALTERNATE.ID or @ID
of MD.DEAL record and CONTRACT.TYPE is ‘CA’.
When the system identifies the MD.DEAL record to which MT769 is received, the tags
of the message are mapped to the MD record. Tags 20, 25, 30, 32A, 33B, 39C, 57A, 71B,
72 if present in the inward SWIFT are mapped to the respective fields of the MD.DEAL
application as shown in the below table.
If the system is unable to find the related MD.DEAL record using the tag 21, then the
message can be placed in `Repair’ queue.
The SWIFT tags of the message and their mapping fields in MD.DEAL application:
Tag Tag Name Field Name M=Mandatory and

O=Optional
MT769 – Advice of reduction Application: MD.DEAL

or release
20 Transaction REFERENCE.1 M
Reference Number

NBG T24 CC
21 Related Reference ALTERNATE ID or @ID M (field not mapped)
25 Account SETTLE.ACCOUNT O
Identification
30 Date of Reduction or MOVEMENT.DATE.1 O

Release
32a Amount of Charges AMT.OF.CHGS O
33B Amount Reduced or PRIN.MOVEMENT.1 O

Released
34B Amount Outstanding O (field not mapped)
39C Amount AMOUNT.SPEC O

Specification
57a Account with Bank ACCT.WITH.BANK O
71B Details of Charges CHG.DETAILS O
72 Sender to Receiver IN.SENDER.INFO (New O

Information field)
An enquiry lists all incoming MT 769 which have been successfully processed. The
incoming SWIFT message can also be viewed from the enquiry shown in the following
screenshot.
LC module:

NBG T24 CC
 Auto processing of many trade related inward swift messages are supported.
However there are few inward swift messages which are not covered under the
scope of auto processing. The enhancement widens the scope of such inward swift
messages.
Previously: Trade Finance module supports the auto processing of inward MT700,
MT701, MT705, MT707, MT710, MT711, MT720, MT721, MT734 and MT750 swift
messages.
In the new release: In addition to the existing inward swift messages supported
through auto processing, the following swift messages will also be supported:
MT 740- Reimbursement authority
MT 742 - Reimbursement claim
MT 747 - Amendment to Reimbursement authority
MT 752 – Authorization to Pay, Accept or Negotiate
MT 754 - Advice of Payment, Acceptance or Negotiation
MT 756 – Advice of Reimbursement or Payment
 In the new release conditions for discrepancy processing can be pre-defined and
the discrepancy text defaulted at the time of checking the documents presented
under a letter of credit.
Previously: Collection (CO) draw type was used to register the documents
presented under letter of credit. The discrepancies are to be manually checked by
the user and record the discrepancy text.
New Functionality: Two new draw types Register Document (RD) and Document
Check (DC) are introduced to register and check the documents under a letter of
credit.
RD - When documents are presented under a letter of credit, the receipt of
documents is recorded / registered in Drawings application. This process is
optional in T24.
DC - This draw type enables the user to check the documents presented and to
record discrepancy, if any. The system also performs the automatic checking for
discrepancies based on the conditions defined
The drawings can be initiated under a LC with draw type as either RD or DC. The
system allows amending the draw types in the following hierarchy:
The delivery messages generated for various events in DC drawing type are:

NBG T24 CC
Event Document Messages to be

Status Generated
Drawings under Non- Notification to the

import LC discrepant importer/opener
Drawings under Discrepant Notification to the

import LC importer/opener
Drawings under Non- MT742 to Reimbursing

export LC discrepant Bank
MT754 to Issuing Bank
Notification to the
exporter/presenter
Drawings under Discrepant MT750 to Issuing Bank

export LC
Notification to the
exporter/presenter
In addition to the above, customer advices for the charges can be generated. The
charges can be defined with draw type as DC in LC.TXN.TYPE.CONDITION and
defaulted at the drawings level.
LC.DISCREPANCY.CONDITIONS. table is introduced to define the conditions for

discrepant checking.
The ID of the table can be either SYSTEM or a valid record ID of LC.TYPES. In this
table, user can define the value of the field in DRAWINGS application to be
checked against value of a field in LETTER OF CREDIT application, condition to be
checked and the discrepancy text to be defaulted when the condition fail.
User can also attach a local routine for the discrepancy conditions.
When a DC type of drawing is input and on validating, the system checks whether
discrepancy conditions are predefined for the LC type and performs the

NBG T24 CC
validations. If discrepancy condition is not available for the LC type the system
validates based on the conditions defined with the ID as SYSTEM.
When the conditions fail, the system defaults the discrepancy text in the
transaction.
User can amend the defaulted discrepancy text and also add new discrepancies.
New fields are introduced in the DRAWINGS application to default the
"Documents Required" from LETTER OF CREDIT application and to record their
statuses. Further "Additional Conditions" is also defaulted in DRAWINGS
application from LETTER OF CREDIT application.
 A new draw type, MX is introduced to support the feature of settling sight as well
as acceptance/deferred payment portions of a mixed payment type LC through a
single drawing.
Previously: Multiple payment portions under a Mixed Payment LC are settled
through individual drawings.
New Functionality: A new draw type MX is introduced to support the feature of
settling sight as well as acceptance/deferred payment portions of a mixed
payment LC through a single drawing.
When a drawing is input under a mixed payment LC wherein the drawing types
are defined, system allows the user to input the different payment types in a single
drawing when settlement term is set to Mixed Payment. The draw type of the
drawing must be either DC or MX.
The system updates the Import-Acceptance/Deferred Payment limit for all the
future dated settlements under the drawing (acceptance/deferred payment
portions) and generates ACPT/DEFPAY contingent liability entries.
For discounting the drawing (with multiple pay portions) as a whole, the existing
discount fields are to be used. However, system accepts the discount rate and not
discount/spread amount, as the appropriation of discount amount amongst the
pay portions is not possible.
In mixed payment LC, if drawing type is defined as MX, as against SP, AC or DP
then one drawing record is to be created for each draw portion.
The following features are not supported at present under MX type of Drawings:
Defining settlement instructions for each instalment and its assignment thereof
Periodic commission

NBG T24 CC
Revolving LCs
Syndicated LCs
Transferrable LCs
Shipping guarantee
All the other existing features of Drawings application are extended to MX type of
drawings.
 Generation of Swift Messages - MT 790 & MT 791 - When commission or charge

is claimed swift message MT 791/MT 491 is generated and MT790/MT 490 when
commission or charge is debited to a vostro account. In Trade transactions,
charges and commissions can be collected or claimed .Though the system
supports collection or claim of charges and commission, the generation of SWIFT
messages MT 791/MT 491 for a claim and MT 790/MT 490 for an advice on
debit/credit of charges and commission to the account of customer who is a
correspondent bank is not supported from the respective application. LC module
supports the collection and claiming of charges and the party against which the
charges are collected /claimed can be specified.LC module supports the collection
and claiming of Commission for Import LC’s. System supports collection and
claiming of charges and also defining from whom the charges are to be
collected/claimed. AC.CHARGE.REQUEST application is to be used to generate
MT790, MT791, MT490 and MT491 messages.
LC module supports the generation of MT791 when charges are claimed and
MT790 when a debit or credit (refund of charges) happens to a VOSTRO account.
LC module supports the generation of MT791 when commission is claimed and
MT790 when a debit or credit (refund) happens to a VOSTRO account.
Collection module supports the generation of MT491 when charges are claimed
and MT490 when a debit or credit happens to a VOSTRO account. When charges
and commission are claimed at the time of issuance/advising of LC, system will
either generate MT791 or convey the details through other messages depending
on the event.
EVENT CHARGE PARTY ACTIVITY

STATUS CHARGED
Issue import LC 3 - Claimed B- MT791 to Advising Bank

Beneficiary

NBG T24 CC
Commission B- MT791 to Advising Bank

Beneficiary
Amendment to 3 - Claimed B- MT791 to Advising Bank

import LC Beneficiary
Commission B- MT791 to Advising Bank

Beneficiary
Advise export 3 - Claimed O - Opener Details to be part of tag

LC 32A of MT730
3 - Claimed T – Third MT791 to Third Party

Party Customer
3 - Claimed T– MT791 to Advise through

Beneficiary Customer
Inward 3 - Claimed B- Details to be part of MT410

collection Beneficiary
Outward 3 - Claimed O - Opener Details to be part of

collection covering/forwarding
schedule
The tags of the swift MT791 and their corresponding mapping fields of LETTER.OF.CREDIT
application are:
Tag Tag Name Field Name Export LC

Import LC
MT791– Request for Payment of Application: LETTER.OF.CREDIT

Charges

NBG T24 CC
20 Transaction Reference Transaction ID Transaction ID

Number
21 Related Reference NON REF ISS.BANK.REF
32B Currency code, Amount CHARGE.CURRENCY CHARGE.CURRENCY

CHARGE.AMOUNT CHARGE.AMOUNT
71B Details of Charges CHARGE.CODE CHARGE.CODE
Generating MT790 from LETTER.OF.CREDIT application

When commission and charges (charges with Charge Status =’2’) is debited from a
VOSTRO account, the system will generate MT790 to the VOSTRO account holder.
When refund of charges happens to a VOSTRO account through LC.ACCOUNT.BALANCES,
the system will generate MT790 to the account holder.
The tags of the swift MT790 and their corresponding mapping fields of LETTER.OF.CREDIT
application are:
Tag Tag Name Field Name Export LC

Import LC
MT790 – Advice of Application: LETTER.OF.CREDIT

Charges
20 Transaction Transaction ID Transaction ID

Reference
Number
21 Related NON REF ISS.BANK.REF

Reference

NBG T24 CC
25 Account CHARGE.ACCT CHARGE.ACCT

Identification COMM.ACCOUNT COMM.ACCOUNT
32a Value Date, ISSUE.DATE ISSUE.DATE

Currency code, CHARGE.CURRENCY CHARGE.CURRENCY
Amount CHARGE.AMOUNT CHARGE.AMOUNT
71B Details of CHARGE.CODE CHARGE.CODE

Charges
The LC.MESSAGE.CLASS and EB.MESSAGE.CLASS triggers the swift messages MT 790, MT

791, MT 490 and MT 491. The system would generate a single MT791/MT 790 messages
for the consolidated amount in case multiple charges are to be claimed/collected.
 Daily Amortization of Charges - Amortization of the collected/claimed charges can

be on a daily or monthly basis based on parameterization. Charges
collected/claimed charges can be amortized either on a daily or monthly basis
based on the parameterized value. Fields AMR.CYCLE.L.CCY and AMR.CYCLE.F.CCY
in LC.PARAMETERS are enhanced to accept the frequency ‘DAILY’ in addition to
the existing ‘MONTHLY’ frequency. When the above fields in LC.PARAMETERS are
set to ‘Daily’, and the field AMORTISE.CHARGES in LETTER.OF.CREDIT/
DRAWINGS is set to ‘Yes’, system credits the charge amount to the internal
account created using the category code defined in LCAMORT record of
ACCOUNT.CLASS. Amortization to P&L will take place from this internal account
on daily or monthly basis. Amortization will take place from charge date till expiry
date (for a Letter of Credit) or maturity review date (for Drawings). Amortization
details will be updated in LC.ACCOUNT.BALANCES. When expiry date/maturity
review date is amended, balance amount to be amortized will be recalculated
when RECALCULATE.AMORT field in LC.PARAMETERS is set to ‘Yes’.
 New activity code is introduced for expiry of import LC. Up to know system did not
make difference between LC expiry and internal amendment and was producing
one and same activity LC-2801.The new activity code is LC-2804
 Waiving Defaulted Charges

NBG T24 CC
Previous functionality - System allowed user to either waive all the charges
defaulted under the LC or Drawings contract but cannot waive a particular charge.
When the field WAIVE.CHARGES was set to Y, all the charges defaulted under the LC
or the DRAWINGS contract would be waived. If a particular defaulted charge was to
be waived, then the respective set of multi value fields had to be deleted.
New functionality - One or more charges can be waived under a contract without
the need of waiving the entire set of charges defaulted under the contract.
When one or more charges are defaulted/applied under a transaction, system

allows waiving of one or more charges without having to waive all charges. A new
charge status 15 is introduced for the waiver.
 Export Transferable LC - When transferring a documentary credit, MT720 will be

sent to the advising bank. Option is also available to define the advise through
bank. MT 720 is a swift message used by banks when transferring an Export
letter of credit. T24 supports the generation of the MT720 from a transferable
type of LC. Upon the request of the first beneficiary, the transferring bank
advises the transferred credit to the bank advising the second beneficiary. In R16
the transferred credit MT720 is sent to the bank indicated under the fields
ADVISING.BK.CUSTNO/ADVISING.BK of the LETTER.OF.CREDIT application. This
bank advises the transferred credit to the second beneficiary. If the MT720 is to
be further advised to a second advising bank, then this information is indicated
under the field ADVISE.THRU/ ADVISE.THRU.CUSTNO fields.
The SWIFT MT720 generated is transmitted to the BIC ID of the bank indicated under
the fields ADVISING.BK.CUSTNO/ADVISING.BK. If the second advising bank detail is
available in the letter of credit under ADVISE.THRU.CUSTNO or ADVISE.THRU fields,
then these fields are mapped to tag 57A/D of the outgoing MT720.
Drawings:
 System supports generation of the following:

Processing of Inward MT400
Processing of Inward and Outward MT416
Processing of Inward MT420
Processing of Inward and Outward MT422
Processing of Inward MT 430

NBG T24 CC
Previous Functionality: The following outward messages are supported under

MT 4xx series:
MT400 - Advice of Payment
MT410 – Acknowledgement
MT412 - Advice of Acceptance
MT420 - Tracer
MT430 - Amendment of instructions
Automatic processing of the following inward messages under MT4xx series are
supported:
MT410 - Acknowledgement
MT412 - Advise of Acceptance
New Functionality: The following Outward Messages are supported under MT
4xx series:
MT416 - Advice of Non payment or Non Acceptance
MT422 - Advice of Fate and Request for Instructions
Automatic processing of the following Inward Messages under MT4xx series are
supported:
MT400 - Advice of Payment
MT416 - Advice of Non payment or Non Acceptance
MT420 - Tracer
MT422 - Advice of Fate and Request for Instructions
MT430 - Amendment of Instructions
MT4xxx
System maps swift tags of the message to the fields of LETTER.OF.CREDIT based
on the mapping defined in the respective DE.MAPPING records and places the
record in INAU status.
The inward messages processed can be viewed and the record can be drilled
down for further processing.

NBG T24 CC
MT400- Inward
When an inward swift message MT400 is received, T24:
 Checks whether the value in the Swift tag 21 (Related Reference)

corresponds to ID of a LETTER.OF.CREDIT wherein in the attached LC.TYPES,
IMPORT.EXPORT is set to ‘E’ and DOC.COLLECTION or CLEAN.COLLECTION is set
to ‘Yes’ and no DRAWINGS record exist under the LC, then SP’ type of drawing
under the LC is created
 Maps the swift tags of MT400 to the fields of the Drawings record and
places it in IHLD Status
Otherwise, inward message is placed in ‘Repair’ queue.
The MT400 tags and their corresponding fields in the DRAWINGS application are:
MT400 – Advice of Payment Application: DRAWINGS
20 Sending Bank’s TRN PRESENTOR.REF
21 Related Reference LC - @ID
32A Amount Collected Field not mapped
33A Proceeds Remitted VALUE.DATE

DRAW.CURRENCY
DOCUMENT.AMOUNT
52A Ordering Bank Field not mapped
53A Sender’s SENDER.CORR

Correspondent

NBG T24 CC
54A Receiver’s RECEIVERS.CORR

Correspondent
57A Account With Bank ACCOUNT.WITH
58A Beneficiary Bank Field not mapped
71B Details of Charges CHGS.DEDUCT
72 Sender to Receiver BANK.TO.BANK

Information
73 Details of Amounts CHGS.CLAIM

Added
MT416
MT416 Inward
On receipt of Inward MT416 message, system checks whether the value in the
Swift tag 21 (Related Reference) corresponds to ID of a LETTER.OF.CREDIT record
and maps values in swift tags 71F and 77A to the fields of LETTER.OF.CREDIT as in
the table given below. Processed messages are placed in Message Processed
queue. From this queue, the Inward messages can be viewed and the record
updated can be accessed for further processing.
The MT416 tags and their corresponding fields in the DRAWINGS application are:
MT416 – Advise of Non- Application:

Payment/Non-Acceptance LETTER.OF.CREDIT
20 Sender’s Reference EXTERNAL.REFERENCE

NBG T24 CC
21 Related Reference @ID of

LETTER.OF.CREDIT
23E Advice Type Field not mapped
51 Sending Institution Field not mapped

A
53a Sender’s Field not mapped

Correspondent
71F Sender’s Charges ACK.CHG.CLAIM
77 Reason for Non- NOPAY.REASON

A Payment/ Non-
Acceptance
21 Related Sequence @ID of

A Reference LETTER.OF.CREDIT
32a Face Amount of ISSUE.DATE/DATE.ACCEP

Document TED
MT416 Outward
Outward MT416 is auto-generated and sent out on the respective tracer dates
automatically by the system during COB. MT416 can also be generated by the
system on a manual trigger on adhoc basis.
A new field GENERATE.MSG is introduced with MT416 as one of the allowed
values in LETTER.OF.CREDIT application to generate MT416 on adhoc basis for
any inward documentary collection.
Tracer date is defaulted to the expiry date or accepted date if the date is not
input at the time of lodgement of inward collection.

NBG T24 CC
MT416 – Advise of Non- Application:

Payment/Non-Acceptance LETTER.OF.CREDIT
20 Sender’s Reference @ID of LETTER.OF.CREDIT
21 Related Reference EXTERNAL.REFERENCE
23E Advice Type NACC or NPAY is defaulted

(OTHR – Not supported)
51A Sending Institution Not required
53A Sender’s System defaults the

Correspondent correspondent bank from
NOSTRO.ACCOUNT for the
currency of the charges
claimed in tag 71F
71F Sender’s Charges ACK.CHG.CLAIM
77A Reason for Non- NOPAY.REASON

Payment/ Non-
Acceptance
21A Related Sequence EXTERNAL.REFERENCE

Reference
32A Face Amount of ISSUE.DATE/DATE.ACCEPTED

Document
MT420 - Outward

NBG T24 CC
A new DE.MAPPING record is created to enable the auto processing of inward

MT420. When an inward swift message MT420 is received, T24:
 Checks whether the value in the Swift tag 20 (Sending Bank’s TRN)
matches with a value in the field, EXTERNAL.REFERENCE of a LETTER.OF.CREDIT
and/or tag 21 (Related Reference) corresponds to ID of a LETTER.OF.CREDIT
 Maps the swift tags of MT420 to the fields of the LC record through
operation A and places it in INAU status.
Otherwise, inward message is placed in Repair queue.
The MT420 tags and their corresponding mapping fields in the LETTER.OF.CREDIT
application are:
MT420 – Tracer Application:

LETTER.OF.CREDIT
20 Sending Bank’s TRN EXTERNAL.REFERENCE
21 Related Reference @ID of LETTER.OF.CREDIT
32 Amount Traced DAYS

A
COLL.MAT.CODE
DATE.ACCEPTED
LC.CURRENCY
LC.AMOUNT
33 Date of Collection ISSUE.DATE

A Instruction
59 Drawee BENEFICIARY.CUSTNO
BENEFICIARY

NBG T24 CC
72 Sender to Receiver IN.BK.TO.BK

Information
MT422 – Inward
When an inward swift message MT422 is received, T24:
 Checks whether the value in the Swift tag 21 (Related Reference)

corresponds to any LETTER.OF.CREDIT record with the attached LC type having
value ‘E’ in the field, IMPORT.EXPORT and ‘Yes’ in the field, DOC.COLLECTION or
CLEAN.COLLECTION
 Maps the swift tags of MT422 (except tags 21 & 32a) to the fields of the
LC record through an internal amendment and places it in INAU status
Otherwise, inward message is placed in Repair queue.
The relevant fields of T24 application to swift tags of MT422 are:
MT422 – Advise of Fate and Application:

Request for Instructions LETTER.OF.CREDIT
20 Send Bank’s TRN EXTERNAL.REFERENCE
21 Related Reference @id of LETTER.OF.CREDIT
32A Amount of DAYS

Collection
COLL.MAT.CODE
DATE.ACCEPTED
LC.CURRENCY
LC.AMOUNT

Information

NBG T24 CC
MT422 - Outward
Automatic Generation
When an incoming MT420 (Collections Tracer) is received for an unsettled
Inward collection transaction (T24 system identifies the transaction by checking
the value in Swift Tag 20/Swift Tag 21), then MT422 (Advice of fate and request
for instructions) message for the same transaction is generated to the Remitting
Bank.
Manual Generation of MT422 Message
MT422 (Advice of fate and request for instructions) swift message can be
manually generated to Remitting bank for any unsettled Inward collection
transaction by selecting the value MT422 in the the field GENERATE.MSG
through an internal amendment provided,
 The attached LC type has value ‘I’ in the field, IMPORT.EXPORT and ‘Yes’
in DOC.COLLECTION or CLEAN.COLLECTION
 FULLY.UTILISED is not set to ‘Yes’
 No drawings exists under the LC

Charges can be collected with status as ‘2’.
New records are defined in the following tables to support generation of
 DE.FORMAT.SWIFT
 DE.MAPPING
 DE.MESSAGE
The fields of T24 application to be mapped to swift tags of MT422 are:
MT422 – Advise of Fate and Application:

Request for Instructions LETTER.OF.CREDIT
20 Send Bank’s TRN @id of LETTER.OF.CREDIT

NBG T24 CC
21 Related Reference EXTERNAL.REFERENCE
32A Amount of DAYS

Collection
COLL.MAT.CODE
DATE.ACCEPTED
LC.CURRENCY
LC.AMOUNT

Information
MT430- Inward
A new DE.MAPPING record is created to enable the auto processing of inward
MT430. When an inward swift message MT430 is received, T24:
 Checks whether the value in the tag 20 corresponds to value in the field,
EXTERNAL.REFERENCE and/or tag 21 (Related Reference) corresponds to ID of a
LETTER.OF.CREDIT wherein in the attached LC.TYPES, IMPORT.EXPORT is set to I
and DOC.COLLECTION or CLEAN.COLLECTION is set to ‘Yes’ and no DRAWINGS
record exist under the LC.
 Map the swift tags 33a, 72 and 74 of MT430 to the fields of the LC record
through an internal amendment and place it in INAU status.
Otherwise, the inward message is placed in Repair queue.
The relevant fields of T24 application to swift tags of MT430 are:
MT430 – Amendment of Application:

Instructions LETTER.OF.CREDIT
20 Sending Bank’s TRN EXTERNAL.REFERENCE

NBG T24 CC
21 Related Reference @ID of LETTER.OF.CREDIT
32 Existing Maturity EXPIRY.DATE/DATE.ACCEPTED

A Date, Currency Code,
LC.CURRENCY
Amount
LC.AMOUNT
33 Amended Maturity EXPIRY.DATE/DATE.ACCEPTED

A Date, Currency Code,
LC.CURRENCY
Amount
LC.AMOUNT
59 Drawee APPLICANT
72 Sender to Receiver IN.BK.TO.BK

Information
(New field)
74 Amendments AMENDMENTS
o To support MT 796 at Drawings, a new field MT 796.ANSWER is introduced in

DRAWINGS application. It is a narrative field mapped to tag 76. This field supports
a negative response up to 6 lines of 35 characters each. User input is allowed only
when DRAWING.TYPE is 'CR’ and an inward MT 750 is received for Drawings.
Whenever an inward ‘MT 750 Advice of Discrepancy’ is received, the response is
sent either through ‘MT 752 Acceptance of Discrepancy - for positive response' or
‘MT 796 Answers for negative response'.
MT 796 will be generated when draw type of drawings created from an inward
MT 750 is changed to 'CR'.
Benefits: User can decide the stage at which MT740 needs to be sent which can
be either at the LC issuance or Drawings stage. MT 796 can be sent when the
discrepancies in the documents conveyed via MT 750 are rejected by the Issuing
Bank/Applicant

NBG T24 CC
 SWIFT Changes 2015 - Tag 59F - The requirement as per SWIFT 2015 changes, is
to additionally support new option “F” to the existing tag 59 (Beneficiary
customer), in order to specify the beneficiary details in a structured format, as per
regulatory reporting requirements. TF application is enhanced to support 59F, if
user inputs the details in the new format.
- Payment messages MT103 and MT202C support tag 59F along with the existing
tag 59.
- If customer ID is provided by the user in the respective ID fields (PRESENTOR.CUST,
ASSN.CUST.NO or INV.BENEFICIARY in the respective application), then the system
generates MT103 and corresponding MT202C in the existing manner with tag 59.
- If name and address are provided by the user in respective fields (PRESENTOR.1,
ASSN.ADD.1 or INV.BENEFICIARY.1), then the System first identifies if the user
intends to specify tag 59 or tag 59F based on input in the above mentioned fields
in the respective application.
- If the user input values in the respective multi-valued fields, starts with a number
followed by “/”, then the system determines that the required format is tag 59F
and validates if the input is as per the new validation rules and generates error if
format incorrect. The System will then, generate MT103 and corresponding
MT202C with new tag 59F
- User is provided with help text for the new SWIFT rules, for easy reference if user
wishes to enter details as per new format 59F. The User may wish to continue
using 59 as per existing process.
III. LOCAL CHANGE AND AFFECTED BRDS
Ad result of the Browser all validations that makes fields’ mandatory/ non-mandatory,
input/no-input should be redesigned in order to become validations that work on
record commitment.
Affected BRDs:

NBG T24 CC
IV. CHANGES RELATED TO T24 BROWSER
 New approach regarding the enquiries that needs more time to retrieve the
results and in regards to that in T24 Browser Time Out error is given.
The enquires in T24 Browser are redesigned (by attaching a new build routine in
the enquiry designer) as a background service that is creating a file in HOLD
directory whenever the particular enquiry is started.
After that in order to check the result file the user should run additionally
enquiry that will shows the result files from HOLD directory produced by the
particular user.

VOBAN R16 Highlights Corporate Lending and Trade Finance

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

VOBAN R16 Highlights Corporate Lending and Trade Finance

Caricato da

Copyright:

Formati disponibili

NBG T24 CC

NBG T24 Competence Center

Corporate Lending and Trade Finance

NBG Competence Center 1 5/29/2019

NBG Competence Center 2 5/29/2019

The document has as a scope LD.LOANS.AND.DEPOSISTS, LIMIT, COLLATERAL,

Received and Issued guarantees are booked in the MISCELENIOUS.DEALS module.

NBG Competence Center 3 5/29/2019

II. CORE CHANGES

 Limits for OBSI Products

- By enabling 0% limit utilisation in FX and TB – related products, the system

NBG Competence Center 4 5/29/2019

NBG Competence Center 5 5/29/2019

Advance Ratio can be defined at different levels. These levels are:

NBG Competence Center 6 5/29/2019

 Concentration Cap Calculation - This enhancement facilitates applying cap for a

The Concentration cap can be applied on collateral values to avoid extensive

It is possible to configure different concentration cap rules.

The concentration cap at different levels:

NBG Competence Center 7 5/29/2019

As Concentration Caps are kept on various levels as the final collateral is

When a concentration cap is exceeded, this should trigger an alert to a

NBG Competence Center 8 5/29/2019

Ranking of collaterals to allocation to a liability can be defined in the new

NBG Competence Center 9 5/29/2019

 Collateral Exclusion - This enhancement provides a facility to exclude the

Collateral can be excluded based on the following:

A new application COLLATERAL.EXCLUSION has been introduced to define the collateral

NBG Competence Center 10 5/29/2019

Zimbabwean Assets such as Zimbabwean Securities and Zimbabwean property can be

 Generation of Swift Messages - MT 790 & MT 791 - Swift Messages MT791/MT491

NBG Competence Center 11 5/29/2019

Tag Tag Name Field Name

MT791–Request for Payment of Charges Application: MD.DEAL

20 Transaction Reference Number Transaction ID

21 Related Reference NON REF

32B Currency code Amount CURRENCY CSN.AMOUNT

Tag Tag Name Field Name

MT790 – Advice of Charges Application: MD.DEAL

20 Transaction Reference Transaction ID

21 Related Reference NON REF

25 Account Identification CHARGE.ACCOUNT CSN.ACCOUNT

32a Value Date, Currency code, ISSUE.DATE CHARGE.CURRENCY

NBG Competence Center 12 5/29/2019

71B Details of Charges CHARGE.CODE

NBG Competence Center 13 5/29/2019

MT768 –Acknowledgement Application: MD.DEAL

20 Transaction Reference REFERENCE.1 M

21 Related reference ALTERNATE.ID or M(field not mapped)

25 Account Identification SETTLE.ACCOUNT

30 Date of Message Being DEAL.DATE M(field not mapped)

32a Amount of Charges AMT.OF.CHGS O

57a Account With Bank ACCT.WITH.BANK O

71B Details of Charges CHG.DETAILS O

72 Sender to Receiver SENDER.INFO O

NBG Competence Center 14 5/29/2019

Tag Tag Name Field Name M=Mandatory and

MT769 – Advice of reduction Application: MD.DEAL

NBG Competence Center 15 5/29/2019

21 Related Reference ALTERNATE ID or @ID M (field not mapped)

30 Date of Reduction or MOVEMENT.DATE.1 O

32a Amount of Charges AMT.OF.CHGS O

33B Amount Reduced or PRIN.MOVEMENT.1 O

34B Amount Outstanding O (field not mapped)