MISCELLANEOUS DEALS

The Miscellaneous Deals (MD) module is used to record the miscellaneous contingent
deals that are required to record ‘guarantee’ type transactions.
 Deal based module
 To book contingent transactions (non-funded) Ex: Guarantee, Line of credit.
 A bank guarantee may be defined as the irrevocable obligation of a bank to pay a sum of
money in the event of nonperformance of a contract by a third party.
 The guarantee is a separate obligation independent of the principal debt or the contractual
relationship between the creditor and the principal debtor.
 Linked to limit structure.

The following could be done in the MD module:

 Periodical Increases or decreases are possible (Principal Movement)

 For ASSET type of products, collecting time based commissions, invocation handling
and allowing registering share of participants are possible.
 For LIABILITY type of products, Commission could be paid.
 Charges maybe taken online or scheduled for a future date. Whenever, an event is
scheduled for a future date in MD, the system updates the same in a file
MD.SCHEDULES.
 In relation to commission, it can either be taken upfront or at the end of the Contract. The
system either amortizes or accrues the same in the frequency as defined in the parameter.
This scheduling of Commission can either be in terms of manual schedule or defined as a 
frequency. It is but imperative that Commission debit account is always in the Deal
currency.
 The system permits the user to collect Cash Margin(Provision) for MD Contract. Such a
Cash Margin may be collected at the time of positive principal movement or any time
Online. 
 In the event of a Principal decrease, the system permits release of cash margin on the
event date. Release of provision (Cash Margin) could be carried out online or any future
date as well.
 Such a cash margin, maybe taken in a currency different from that of the Deal currency
and may be parked in an account of different currency. An option to define a default MD
Margin account is available in the MD.PARAMETER. In the event of such a margin
taken, the user may choose to decide as the whether such margin should have an impact
on the limit line or not(INCLUDE.PROVISION).
 Links to SL(SYNDIACTED LOANS) can also be done.
 Where the invocation results in overdraft of a customer account, the PD(Payment Due)
link has been provided.
  If MD, were to be used to issue a shipping guarantee, the system supports appropriation
of Cash margin taken in LC into that of MD. The requisite LC reference and the
appropriation amount has to be decided by the user. Thus when a Drawing is done under
the Letter of Credit, quoting the reference of the MD.DEAL, the system understands the
link and generates the accounting accordingly.

The above listed are the some of the features of MD module.

MD.PARAMETER

The MD.PARAMETER file has a record for each Company. The valid deal types, sub
deal types and category code ranges are set up. The overall level rules are specified.

Basic table defining various important parameters for the MD module.

 Company’s name will be the id.

 Basic Types (CA, MA, CL, ML) and the underlying deal sub types(GTISS, GTREC,
PBOND, BBOND) are specified and Start and End Category Code for each Subtypes are
indicated and can also be created according to Clients Requirement(for e.g. SHGTE –
SHIPPING GUARANTEE).
 LIMIT checking is also set by Mandatory, No input or optional choices.
 Accruals for time based commission is also set in this table.
 Event processing : set to either END OF DAY or ONLINE
 EXPIRY MODE : can be set to MANUAL or AUTOMATIC.
 Matured Records are kept live even after maturity depending on
DAYS.POST.MAT(NW/NC)
 INCLUDE PROVISION : Provision Related field could be set to YES for the impact of
Limits to be less than provision amount taken. If it is set to No or Null, Impact for the
Limit will be for the full guaranteed amount.
 Provision could be credited to an Internal Account by setting the Field
PROV.CATEGORY when Customer Account is not inputted.
 Transaction codes for Provision, Commission and Charges, and Invocation Credit and
Debit are set.
 Old Delivery type could be continued by setting BACKWARD.DELIVERY to yes.

The above are the some the main features and settings regarding the functionality of MD deal in
MD.PARAMETER.

There is also another Application which has the salient features in setting Provision,
Commission, Charges, etc in MD deal
MD.TXN.TYPE.CONDITION

This table facilitates defaulting Provision percentage, Commission percentage and

ensuring collection of Minimum Commission amount for Guarantees issued.

The Id of this table is DEAL.SUB.TYPE(For e.g. GTISS). Input of

PROVISION.PERCENT ensures default of this percentage in the Deal when PROVISION is set
to YES.
To ensure that a minimum amount of commission is recovered for any Deal,
MIN.COMM.AMT.LCCY and MIN.COMM.TENURE are used.

The following are some of the condition how the computed value stays.
 When the resultant commission of a Deal is greater than the default value, the computed
value stays.
 When the resultant commission of a Deal is greater than the default value, but the tenor is
less than the default value, the computed value stays.
 When the resultant commission of a Deal is less than the default value, but the tenor is
greater than the default value, the default commission is taken.
 When the resultant commission of a Deal is less than the default value and the tenor is
less than the minimum period, the commission is recalculated for the default period. If
this commission is greater than the default commission, it is applied else the default
commission is applied.

This default commission may be defined currency-wise. In the absence of any default value
for a given currency, the equivalent of the local currency is computed and applied.
In the same manner the percentage of commission for any CATEGORY under a
DEAL.SUB.TYPE can be defined and that will be defaulted in the Deal.
This definition of commission percentage becomes mandatory if MD.CSN.RATE.CHANGE is to
be invoked.

MD.CSN.RATE.CHANGE

The commission rate input for various Deals under the relevant DEAL.SUB.TYPE and
CATEGORY, may be changed using MD.CSN.RATE.CHANGE. The Id is the REVISION.DATE.
This date signifies the date on which the change of commission rate will be processed. This is an
End of Day activity and applies the new rate only on live contracts and those that are yet to
mature, in other words the status is CUR and Maturity date is a future date, as on the date of
processing.

An EFFECTIVE.DATE is mandatory signifying the date from which this change has to
take effect. This, at point of time can not be greater than the REVISION.DATE. This date may
however be back dated. If so, an option is available to define as to whether the rate change has to
take a retrospective effect or not.

Other valid inputs are DEAL.SUB.TYPE, CATEGORY and COMM.RATE. Importantly

these should have been defined in the MD.TXN.TYPE.CONDITION.

Thus the pre-condition for MD.CSN.RATE.CHANGE is its definition in

MD.TXN.TYPE.CONDITION

APPLICATIONS INVOLVED

The following main Applications are involved in MD module.

1. CUSTOMER
2. ACCOUNT
3. LIMITS
4. ACCOUNTING (ENTRIES)
5. DELIVERY

Let us discuss in detail about each Application.

1. CUSTOMER:
The Customers are the Counter party and participants in the DEAL. So we need
to have Customer Records.
2. ACCOUNTS:
We need have to Accounts for Debiting and Crediting Charges and Commissions,
Provision, Invocation etc.
3. LIMITS:
Limits for the Customer and participants are Set according to the Principal
Amount Involved in the Contract. Principal amount used for the purpose of limits
will be the highest value of the contract either today or in the future taking into
account all principal movements.
Limit will be impacted only if required (if LIMIT.UPD.REQD = YES)
4. ACCOUNTING(ENTRIES):
When a deal is Inputted, Accounting Entries are Generated such as
CONSOL.ENT.TODAY, STMT.ENTRY, CATEG.ENTRY,
RE.CONSOL.SPEC.ENTRY, etc..
5. DELIVERY:
When a MD contract is signed between the Bank and the Customer, the
information related to the contract, has to be sent to the Clients like when the deal
is signed, what is the amount, maturity date of the Contract, Provisions, charges,
 Invocation, if any with the corresponding codes. So Delivery messages are sent
for each and every action taking part in the contract.

CONCAT FILES

The following are the Concat Files updated for MD.DEAL contract.

 MD.CUSTOMER
 MD.BALANCES
 MD.PROV.BALANCES
 MD.SCHEDULES
 MD.SCHED.DATES
 MD.INVOCATION.HIST
 MD.EOD.LIST
 MD.PART.CSN.BALANCES
 RE.CONSOL.MD
 RE.MD.BALANCES

Let us look how these concat files are updated

MD.CUSTOMER
---------------------
Customer ID is the Id for this Table. It records the Customer involved in particular MD
Contract. One Customer can be involved in many Contracts and It will be listed under the
Customer Id.

MD.BALANCES
---------------------
The MD.BALANCES file records all the principal movements of a particular MD.DEAL
together with future charges to be deducted, and a summary of those charges that are associated
with the MD.DEAL.
A MD.BALANCES record is created whenever an MD.DEAL is entered into Globus and
remains there as long as the deal remains 'live' on the MD.DEAL file. It is updated automatically
when any modification done in the principal or charge fields on the deal.
The fields in MD.BALANCES are updated when Charges and Commissions, Invocation
are included in the Deal.

MD.PROV.BALANCES
------------------------------
 As Cash Margin (Provision) can be taken for a MD.DEAL, the details regarding the same
are stored in this file. When Provision is taken the transactions are online. The release or
additional provision may be taken either as an online activity or as an End of Day activity.
The Provision taken is stored along with the details of the Provision debit account,
Provision credit account, Provision account currency, Outstanding Provision amount, Provision
release account and Provision release amount.
On every release of Provision the release details are displayed as multi-value sets.

MD.SCHEDULES
-----------------------
This File Records all the Contingent Future Events of a MD contract. The future events
said includes future Charge schedules, Commission Schedules, Maturity schedule, Principal
Movement Schedule and Provision Release schedule.

MD.SCHED.DATES
-------------------------
This file records the Contract with daily schedules till the Maturity date.

MD.INVOCATION.HIST
--------------------------------
This file records all the history of the Invocation done. The details includes are Deal ID,
Invocation Amount, Debit Account and Credit Account, Beneficiary, Pay Date, etc. This File will
get updated only if Invocation is included in the Contract.

MD.EOD.LIST
------------------
This file will record the Contracts to be Run during the End of Day. The date is the Id of
this file and it lists the MD contracts under each date.

MD.PART.CSN.BALANCES
------------------------------------
This table gets updated when Participants in MD contract is involved. The MD deal ID is
the Id for this record. It indicates the Currency used, who are all the Participant Customers, their
Commission Start and End periods, etc.
RE.CONSOL.MD
---------------------
This is the Reporting file which gets updated with the MD contract under the Consol Key.

RE.MD.BALANCES
--------------------------
 This is also the Reporting file which will get updated with the Balance Details at End of
Day. Whenever there is Principal Movement, Charges and Commissions, and Invocation, etc. At
End of Day, this file will get updated for reporting information.

LIMITS

The Limit System is designed to monitor the availability and utilization of Limits.
Customer Limits are monitored in real-time. Back end reports are used to monitor Limits for
Commodities, Countries, Country Groups and Currencies. The design of the System is such that
the definition of the simplest through to the most complex of Limits is catered for.
Limit Reference Table

When a MD Deal is inputted in the System, the records related to LIMITS : LIMITS and
LIMIT.TXNS are updated. Limit fields can be updated by setting the limit related fields in
MD.PARAMETER application. Once they are set, Limit records are updated.
Principal amount used for the purpose of limits will be the highest value of the contract
either today or in the future taking into account all principal movements.
Limit will be impacted only if required by setting the field in MD.DEAL, LIMIT.UPD.REQD to
YES.

LIMIT.REFERENCE
-----------------------------

This table is used to define the types of Limit to be processed by the Limit System. Each
Limit type (known as a Limit Reference within the System) can be defined as being part of a
hierarchy, made up of a GLOBAL Limit, PRODUCT Limit and SUB PRODUCT Limit.
This table is also used for define whether the Limit Reference is one that requires checking each
time, or whether it is updated only for information.

A Limit Reference is a numeric code which defines a type of Limit. For those cases
where it may be necessary to sub-divide a Limit Reference, a hierarchy can be defined. A
hierarchy can consist of up to 3 levels i.e. Global Limit, Product Limit and Sub product Limit.
To define the Application which utilizes a Limit Reference, the user will specify his own
parameters and Limit checking conditions on the LIMIT.PARAMETER table.

REDUCING LIMIT field indicates whether or not a Limit is a Reducing Limit. In other
words, whether the Limit is Revolving or Non-Revolving. A reducing or non-revolving Limit
does not have its value restored when a Transaction is repaid.
 In respect to MD, this record is used to create a Limit Product. The ID is the number
(depends on the Global, Product and Sub-product level). For e.g. 2500 is the
LIMIT.REFERENCE of the GUARANTEE ISSUE (GTISS). Similarly, we can define our own
reference for each category.
If any Sub-Product limit reference is needed, it is set here in this record.

LIMIT.PARAMETER
---------------------------
Within this file are defined parameters which determine the way in which the Limit
system operates. These are as follows:
1. An indicator to specify whether Foreign Exchange contracts are, or are not, to be netted before
Limit comparison.
2. A 'number of days' to define how many days prior to Limit Expiry Date and Limit Review Date
the approach of these events is to be reported.
3. A date and cycle to indicate when the first revaluation will occur and at what frequency
thereafter.
4. A date and cycle to indicate when a full Central Liability report (including those Liability
numbers which did not move) need to be produced in the back-end process.
5. A date and cycle to indicate when the Commodity, Country and Currency reports must be
produced.
6. A number of days (administrative extension days) which defines the maximum number of days
by which the expiry date of a limit can be "administratively" extended before a new expiry date is
reassigned to the limit.
7. The Limit product definition according to the specific requirements of the Bank. The most
important feature of this file is that it allows the user, for each Financial Application, to define the
precise rules applicable to his environment. In this way, the Limit verification process can be
established by the user according to his own set of rules without any program maintenance.
8. The product group definition which will allow the user to specify which are the different
products which in his opinion must be part of the Commodity, Country and Currency exposure.

The default LIMIT settings are defined in LIMIT.PARAMETER record called SYSTEM.
This Application is similar to MD.PARAMETER application, where the essential fields for
LIMIT is set here. For MD (GTISS) the Product ID created in the LIMIT.REFERNCE is assigned
under each application. For E.g. 2500 is the LIMIT.REFERENCE code created for GTISS, which
is assigned for MD Application.

Let us discuss about the LIMIT and LIMIT.TXNS record.

LIMIT
--------
Limit record will get created when the MD contract is inputted in the System. The ID of
the LIMIT record is CUSTOMER ID.LIMIT.REFERENCE code for E.g. the LIMIT for a MD
Deal is 1000.002500.01

1000 - CUSTOMER ID (involved in the Deal)

2500 – LIMIT.REFERENCE number (for GTISS)
(2500.01 shows it is Sub product level)

Note : we can create our own LIMIT record by inputting for a particular Customer with
LIMIT.REFERENCE.

LIMIT.TXNS
----------------

The LIMIT.TXNS record ID is same as the LIMIT record plus the CUSTOMER ID. It
shows the Transaction data of contract related to LIMIT. It states, in MD contract (ID), with
Currency (USD say), with the LIMIT.AMOUNT in the Deal, valid till the Maturity date of the
contract for the company (BNK) with the LIMIT.REFERENCE code.
For e.g.

BNK R05BASE LIMIT.TXNS SEE

CREDIT.LINE.NO.... 1000.0002500.01.1000 PACKERK:Gtees Issued:PACKERK

-----------------------------------------------------------------------------------------------------
1 TXN.DAT MD0035700010\USD\-10000\20001229\BNK\-10000\0002500

Deal ID CURRENCY LIMIT.AMOUNT MAT DATE LIMIT.REFERENCE

CHARGES AND COMMISSIONS

As previously stated, MD has the features of collecting Charges and Commissions. The
Commission and charges codes are defined in the FT.CHARGE.TYPE AND
FT.COMMISSION.TYPE. In MD.DEAL, the fields related to Charges and commissions are as
follows:

Field 20 – 26 is the multi-value set.

20 - CHARGE.DATE
21 - CURRENCY OF THE CHARGE TO BE TAKEN
22 – CHARGE ACCOUNT
23 – CHARGE CODE (must be a valid charge code from FT.CHARGE.TYPE)
24 – CHARGE AMOUNT
25 – TAX CODE
26 – TAX AMOUNT

The following are some of the Commission related fields are from 48 – 60
48 – CSN.PAYMENT.TYPE (can be either BEGIN or END)
50 – CSN.RATE (commission Rate)
51 – CSN.SPREAD
54 – SPLIT.COMMISSION(must be set to YES or NO) default value is NO. When the Deal
contains Participants, then the commission has to be split to the participants.
55 – CSN.FREQUENCY , the Commission can be paid on daily, monthly, yearly basis.
58 – 60 are Multi-value set.
58 – CSN.DATE (Commission Date on which commission has to be paid, If
CSN.PAYMENT.TYPE = BEGIN, then this field contains VALUE.DATE, if
CSN.PAYMENT.TYPE = END, then this field contains MATURITY.DATE.)
59 – CSN.AMOUNT (Commission Amount to be collected)
60 – CSN.ACCOUNT (Account on which Commission is debited)

The Charges can be included during a new contract is inputted, or even after
authorization of a contract. But Commission can be included only during the stage of inputting a
new contract. Once the MD contract is authorised, the Commission cannot be inputted.

PRINCIPAL MOVEMENTS

So far the amount on a deal has appeared to be fixed. However, MD.DEAL allows the
definition of one or more scheduled changes to the amount ie PRINCIPAL MOVEMENT.
Schedules can be either for increasing the amount or reducing it. The Movement (either Positive
or Negative) are done on the Movement Date which is the mandatory field when doing Principal
Movements. Where a LIMIT update is involved the risk will be deemed to be the sum of the
current amount plus all forward increases. Forward decreases will impact the LIMIT on the
date(s) they become effective.
PROVISION or CASH MARGIN

In MD.DEALS cash margins may now be taken and they are online. For a default
mechanism however, the user needs to set up a MD.TXN.TYPE.CONDITION for the same with
DEAL.SUB.TYPE.

This is optional and at the record level the same is defaulted, but permits the user to
override. Here the user has the option to define either a percentage or the amount. When a
percentage is entered the amount is calculated on the NET.PRIN.AMOUNT. Similarly when an
amount is entered, it is converted to the percentage of NET.PRIN.AMOUNT. In other words, for
Participation Guarantees, Cash Margin will be applicable only for the Leader’s portion or for the
balance outstanding in NET.PRIN.AMOUNT.

When Provision is set to YES, in MD.DEALS, the related fields open up. User has the
option to define the account from which provision is to be taken and into which it is to be kept
through the fields PROV.DR.ACCOUNT and PROV.CR.ACCOUNT. Using the field
PROV.REL.DATE the user may define the date on which the provision is to be released.
Although the default release account is PROV.DR.ACCOUNT, yet the user may specify a
different account in PROV.REL.ACCOUNT. This release of provision is done as and End of Day
activity.

It may be observed that PROV.REL.ACCOUNT has been defaulted with

PROV.DR.ACCOUNT. The PROV.PERCENT has been defaulted from
MD.TXN.TYPE.CONDITION. The date of release of provision can be defined in
PROV.REL.DATE. The PROV.CR.ACCOUNT, which otherwise is a user input field, has been
made to default from MD.PARAMETER by setting up a category for the same.

The field INCLUDE.PROVISION in the Parameter is used to impact the limit line. When
set to YES, the limit is netted out after considering the Provision amount taken. A similar field is
also available at the record, which gets defaulted from the Parameter and permits the user to
override. At the record level it becomes a no-input field on authorization.

It is possible to release Provision online at any point of the life of the Deal. This is
controlled from the field RELEASE.PROV. This is to be set to YES and followed by input in
RELEASE.AMT. The field OUTS.PROV.AMT holds the entire amount of Provision under the
Deal. The table MD.PROV.BALANCES is updated with the Debit Provision account, Credit
Provision account, Currency of Provision and the Total Provision outstanding during Provision.

Cash margin may be also be taken or released at the time of any movement of Principal.
Fields PROV.AMT and REL.AMT have been added into the movement multi-value sets. This
facilitates taking additional Provision for a Principal increase and releasing Cash margin for a
Principal decrease.

Accounting relating to Provision towards principal movement happens at End of Day of

the Movement date. These are user input fields. The relevant messaging for these activities is also
generated. When a current deal is later amended setting fresh Principal movement, provision
amount, if any, should be input by user and if the provision percentage is reset, then provision
will be taken for the outstanding NET.PRIN.AMOUNT.

INVOCATION

Beneficiary may invoke the guarantee and lodge the claim asking the Issuing bank to pay
the guaranteed amount. If the claim is as per the terms of the guarantee, the issuing bank is bound
to make the payment as demanded by the beneficiary. This facilitates invocation of Guarantees as
a part of MD.DEAL by generating necessary payment messages and passing accounting entries.

To start with, MD.PARAMETER is to be set with necessary Delivery Message details

and Invocation Transaction Codes when the INVOCATION is inputted.

Invocation can be done only for Authorized MD contracts. The invocation functionality
has three stages viz. PROCESS, EXECUTE and CANCEL. In the invoked MD.DEAL, once
the field INV.STATUS is opted with the first stage PROCESS, the other relevant fields will open
up. Upon populating necessary details of invocation payment and authorization, appropriate
messages will be generated demanding funds from the applicant and other participants to the deal.

Under Process status the invocation will neither generate any accounting entries nor
update limit. Only Delivery Messages are generated under PROCESS status. The user can either
Execute or Cancel the invocation under Process status. If cancelled, there will not be any change
to the original data of the deal. Once Executed, payment message MT100 or MT202 will be
generated depending upon the INV.BENEFICIARY is a non-bank or a bank.

Upon Execution of an INVOCATION, relative MD.BALANCES file will get updated as follows:

 In CSN BEGIN type deals, revised Principal balances with effect from the next CSN
schedule and
 In CSN END type deals, revised Principal balances effective from the value date of
INVOCATION.

Accordingly, the accrual / amortization of CSN on the revised principal shall be effective
from the next CSN schedule if the CSN type is BEGIN.
 In case, Liquidation is set as Manual, PD(PAYMENT DUE) would be created
irrespective of availability funds in the settlement account, if Semi-Automatic, the EXECUTION
of an INVOCATION shall create a PD if the settlement account does not have sufficient balance
to meet the invocation. If Liquidation is set as Automatic, the EXECUTION of an INVOCATION
shall debit the settlement account even if it does not have sufficient balance to meet the
invocation.

The Table MD.INVOCATION.HIST will get updated with all the Invocation details like
Invocation Amount, Invocation Debit Account, Debit Value date, Settle Account, Exchange Rate
if Foreign Currency is used, Corresponding Bank if any, etc.

DELIVERY

As previously stated, the Delivery module along with MD application generates the
Delivery Messages for each activity done in the MD contract. The following tables are related to
DELIVERY module in MD deal.

MD.ACTIVITY
-------------------
The file contains the activity codes for the production of advices.

This file is used to define and control delivery output from the miscellaneous deals
module. Activities that produce delivery output are defined by the records on this file. These
activities relate to specific events during the life of a contract.

Whenever delivery output is produced via the miscellaneous deals module the activity
code of the relevant advice is recorded on the originating record, MD.DEAL. When this record is
subsequently viewed these activity codes will be displayed and enriched with the description
recorded on this file. They are referred to by MD.ADVICES.

At present there are only 4 activity codes used, these are:

ACTIVITY CODE DESCRIPTION

********* ********
1.100 CHARGES.
2.101 CONFIRMATION OF NEW DEAL.
3.102 CONFIRMATION OF AMENDMENT.
 4.103 CONFIRMATION OF CANCELLATION.

MD.ADVICES

This file controls which activities will produce delivery output and the format of that
output for different categories of contract. This control is made at category code level. Therefore,
separate records defining the output required, and, the format of that output may be entered for
each category used within the Miscellaneous Deals module.

However, the output format required for some categories will be the same as for others.
Therefore this file allows a given category to use the format definitions of a secondary category.
This eliminates the need to duplicate format details for similar categories of contract.

This file is used to specify which format delivery advice is sent for each CATEGORY of
deal. It is likely that a standard advice is to be produced to cover the many different types of deal
that can be entered in MD.DEAL. Using this application you can control which activity requires
an advice to be sent based on the deal category. It is possible to reduce the number of
DE.FORMAT.PRINT records required by having a common format that is called instead of a
unique one for each CATEGORY.

Below Screen shots explain about the Table MD.ADVICES:

BNK R05BASE CONTINGENT DELIVERY CONTROL SEE

CATEGORY.......... 28-000
------------------------------------------------------------------------------
2. 1 ACTIVITY.CODE.. 101 Confirmation of a New Deal
3. 1 MESSAGE.TYPE... 2320 Contingent Confirmation   (Refer) A
4. 1 FORMAT......... 101   Application Format of delivery message
2. 2 ACTIVITY.CODE.. 102 Amendment of a Deal
3. 2 MESSAGE.TYPE... 2320 Contingent Confirmation
4. 2 FORMAT......... 102
2. 3 ACTIVITY.CODE.. 103 Cancellation of a deal
3. 3 MESSAGE.TYPE... 2320 Contingent Confirmation
4. 3 FORMAT......... 103
2. 4 ACTIVITY.CODE.. 100 Charge Confirmation
3. 4 MESSAGE.TYPE... 2900 Contingent Charge Advice
4. 4 FORMAT......... 100
A (MESSAGE.TYPE)
*******************
The ID of the DE.MESSAGE record.

This field is used by miscellaneous Deals to link a particular Activity to a particular

DE.MESSAGE record.

For example if the MD.ADVICES record is set up as follows:

2.1 ACTIVITY.CODE 100

3.1 MESSAGE.TYPE 2900
4.1 FORMAT 1
2.2 ACTIVITY.CODE 101
3.2 MESSAGE.TYPE 2320
4.2 FORMAT 1

Then when a MD.DEAL is input (activity code 101) an advice based on the DE.MESSAGE
record 2320 will be sent to delivery with the format ID of 2320.1.1.GB (assuming it is an English
language customer).
On the other hand when charges are raised against the deal (activity code 100) an advice
based on the DE.MESSAGE record 2900 (charge confirmations) will be sent to delivery with the
format ID of 2900.1.1.GB.

DELIVERY AND PGM.FILE

The Delivery Preview icon can be set by making changes in settings of PGM.FILE of
MD.DEAL.
The following screen shots show the PGM.FILE set for MD.DEAL

BNK R05BASE PROGRAM FILE SEE

PROGRAM MD.DEAL
------------------------------------------------------------------------------
1 TYPE.............. H
2. 1 GB SCREEN.TITLE CONTINGENT ASSET AND LIABILITIES
3 ADDITIONAL.INFO... .NOH.PREVIEW   Preview message Icon is set here
5 PRODUCT........... MD
14 CURR.NO........... 4
 After setting the PGM.FILE, while using DESKTOP, the DELIVERY MESSAGE
PREVIEW ICON IS ENABLED

DELIVERY PREVIEW ICON

Then the Delivery Messages relating to the MD contract is listed like the following

Each list can be clicked to view the Delivery Message. For E.g. The Delivery message for
type 2320 is shown below.

TO; MR KERRY PACKER TEMENOS BANK

TEMENOS TOWER
54 PARK STREET WORLD TRADE CENTRE
SYDNEY AUSTRALIA NEW YORK
NY 100048

CUSTOMER : 1000
DEAL NO. : MD0035700002

As agreed on 22 DEC 2000

We confirm your GTISS with us as follows:

From : 22 DEC 2000

To : 29 DEC 2000

For the amount of 10000.00 USD

 -------------

If you have any queries regarding the above details please contact us as
soon as possible quoting our deal number.

Similarly, the other Delivery Messages can be viewed and the information done on the
each activity in MD Contract can be known.

SOFT DELIVERY

All the four important SWIFT messages MT760, MT768, MT767 and MT769 are
supported now. Setting the BACKWARD.DELIVERY field in the Parameter to NO shall
enable these.

It is however important to note that SWIFT messages would not get triggered unless the
field ADVICE.REQD is set to YES in the MD Deal.

The following are the Swift Messages generated related to MD Module

SWIFT Description Field Name

MT760 Guarantee Issuance Field 87 Issue or Request For Tag 23
Field 95 Guarantee Details For Tag 77 C

Field 96 Sender Info For Tag 72

MT767 Amendment Field 94 Amendment No. For Tag 59E
Field 95 Guarantee Details For Tag 77 C
Field 96 Sender Info
For Tag 72
MT768 Guarantee Field 90 Settle Account For Tag 25
Acknowledgement Field 91 Acct with Bank
For Tag 57a
(If not filled existing account

MT769 Guarantee reduction relationship is to

Field 90 Settle be used)
Account For Tag 25
Field 91 Acct with Bank
(Generated as part of For Tag 57a
EOD job)

ENTRIES RAISED
 The Entries Raised regarding MD Module are as follows:
1. STMT.ENTRY
2. CATEG..ENTRY
3. CONSOL.ENT.TODAY
4. RE.CONSOL.SPEC.ENTRY

1.STMT.ENTRY
--------------------
Statement Entry will be raised when the MD module has included the Accounts.
So each Credit and Debit will be generated as STMT.ENTRY. The MD Module will use
Accounts for PROVISION, INVOCATION,CHARGES AND COMMISSION, etc. So, whenever
Provision, Invocation, charges and Commissions are included, STMT.ENTRY will get raised.

STMT.ENTRY is generated Online.

2. CATEG.ENTRY
-----------------------
The CATER.ENTRY will be raised when CHARGES AND COMMISSIONS are inputted
in MD module. Normally, CATEG.ENTRY will be raised when there is a credit to the Bank.
CATEG.ENTRY will be raised only at the END.OF.DAY.

3. CONSOL.ENT.TODAY (CET)
----------------------------------------
For every Deal input, changes in deal, for maturity, etc.. the CONSOL.ENT.TODAY will
get raised. For E.g. When a MD deal is inputted, CET for LNW will be raised. If any Static
changes are done, APP CET entries are raised. If any Customer Static Changes are raised, CUS
CET entries will be raised and for (Invocation)Repayment FRP, etc

4. RE.CONSOL.SPEC.ENTRY
--------------------------------------
Special Entry will get raised for all the CONSOL.ENT.TODAY(CET) entries raised
Online. During END OF DAY, CET entry will be converted to RE.CONSOL.SPEC.ENTRY.

EVENT.PROCESSING

In MD deal, Event Processing was END OF DAY in earlier releases, then

ONLINE is also used. When EVENT.PROCESSING is set to END OF DAY, all the entries are
generated only at the EOD. When set to ONLINE, the entries are generated Online.

ONLINE MATURITY
---------------------------
It is now possible to mature a Guarantee Deal Online. This is achieved by setting
ONLINE.MAT to YES. It is however imperative that EVENTS.PROCESSING should have
been set as ONLINE.

When a Deal is set to Online Maturity, there shall be no current or future dated
movements or future dated charges scheduled. The status of the Deal has to be CUR and shall not
be FWD (Forward). Such online maturity shall always be treated with MATURITY.DATE as
today, that the system shall default.

Where commission is set as manual schedule, with end type, the CSN.DATE is to be
changed to today; although this would not apply to Begin type manual schedule. However for a
Begin type schedule, the balance amount to be amortized shall be done on this day. Where the
Commission is set as frequency, the system shall set the CAPITALIZE.DATE as today to pass the
accounting entries relating to commission. The AUTO.EXPIRY shall be reset to YES and overdue
status shall not relate to PD. In the event of any Cash Margin (Provision) outstanding, the same
shall be released online.

The reinstatement of Limit lines would happen online and the contract would be set to
LIQ status when matured so. Online maturity cannot be done if any invocation is set. In such
cases the INV.STATUS must not be in the Process or Execute states.
SCENARIO WHEN CONTRACT IS NOT MATURED:

1. When the AUTO.EXPIRY field is set to NO, then the Contract will not get matured
even when the contract has passed the MAT date.

CONTRACT MATURED, LIMIT NOT UPDATED:

1. The MD Contract would have matured, but the LIMIT.AMOUNT would have not
updated to Zero. When the Contract is matured, the LIMIT.AMOUNT will
automatically become ‘0’.
2. When the Deal is inputted, the LIMIT and LIMIT.TXNS record will get created.
Once the deal is matured, the LIMIT and LIMIT.TXNS record will get deleted. There
are some situations where LIMIT and LIMIT.TXNS record will get deleted even after
the MD contract matured.
3. Also, LIMIT.TXNS record updated twice for a single Contract, so that CUSTOMER
POSITION ENQUIRY will get affected.