Miscellaneous Deals

TEMENOS T24 Miscellaneous Deals

Userr Guide Use

Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV. Copyright Copyrig ht 2005 2005 TE ME MENOS NOS Holding Holdings s NV. NV . All A ll rights rights reserved.

Miscellaneous Deals

MISCELL MISC ELLANEOU ANEOUS S DEALS ...... ............ ........... ........... ........... ........... ............ ........... ........... ............ ............ ............ ........... ........... ............ ............ ............ ........... .......... .......... ..... 4 Applicat Appl ication ion ov overv erview iew..................................................................................... ......................................................................................................................... .................................... 4 MD.Para MD.P aram met eter....................................................... er............................................................................................................................ ............................................................................... .......... 4 Basic Type Types s .............................................................................. ...................................................................................................................................... ........................................................ 4 User Type Types s (Dea (Deall Subtyp Subtypes) es).................................................................................................... ........................................................................................................... ....... 4 Limit Lim its s ................................................................................................... ................................................................................................................................................ ............................................. 6 Last Draw Date......................................................................................... Date................................................................................................................................. ........................................ 7 Commission and Accru Accruals........................................................................................................ als................................................................................................................ ........ 8 Correspond Corresp ondent ent Bank Lim Limit.......................... it....................................................................................................... ...................................................................................... ......... 9 MD.Deall ............................................................................................. MD.Dea ............................................................................................................................................. ................................................ 10 Flat Charg Charges es .............................................................................................. ...................................................................................................................................... ........................................ 10 Time Ba Base sed d Commis issi sion ons s .. .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... 11 Minimum Amount Amount & Tenor................................................................................................................. 11 Commission Frequ Frequency..................................................................................................................... ency..................................................................................................................... 13 Commission Rate Revision............................... Revision....................................................................................................... ................................................................................. ......... 14 Charg harges es collected collected in a currency currency wh which ich is different different from th the e deal currency currency...... ............ ............. ............. ............ ............ ........ .. 16 Accrual Accru al patt pattern for for CSN.C CS N.COMMIS OMMISS S ION calcu calculat lation.......................................................................... ion.......................................................................... 16 S che chedu duled led Increase Increase / Decr Decrease ease of P rin rincipa cipall Am Amoun ountt ........................................................................ 17 Cash Margin Margin (P (P rov rovision ision)) .......................................................................................... .................................................................................................................... .......................... 18 E xp xpiry iry Opt Option ion ................................................................................................... ..................................................................................................................................... .................................. 21 Altern Alte rnat ativ ive e ID ............................................................................................ ..................................................................................................................................... ......................................... 22 Multi-P Mult i-Part articip icipant ant Deal Deals s ............................................................................................... ....................................................................................................................... ........................ 23 Movem Mov ement ent in P art articip icipat ation ion............................................................................................ .................................................................................................................. ...................... 24 P art articip icipant ant's 's Commission............................................................................................................... 24 Account Accou nting ing Rules R ules for Com C omm mission ission................................................................................................ .................................................................................................. 25 Using an MD item as Colla C ollattera erall ................................................................................................. ......................................................................................................... ........ 26 MD cov covere ered d by Colla C ollattera eral....................................................................... l................................................................................................................... ............................................ 26 MD link to Syn S yndica dicattion .......................................................................................... ....................................................................................................................... ............................. 26 MD.Activi MD.Act ivitty ........................................................................................... ......................................................................................................................................... .............................................. 26 MD.Advices....................................................................................................................................... MD.Adv ices......................................................................................................................................... 27 S oft Deli Delive very........................ ry.................................................................................................................. ............................................................................................................... ..................... 28 Imple Im plem ment enting ing Soft S oft Delive Delivery ry in MD ............................................................................................... ..................................................................................................... ...... 30 Backward Backw ard com compat patibi ibilit lity:.................................................................... y:.................................................................................................................. .............................................. 33 System Syste m file files........................................................................................................................................ s........................................................................................................................................ 35 General Gener al Ledg Ledger er rep report orting.......................................... ing................................................................................................................... ......................................................................... 35 MD.Deall with MD.Dea with Version ........................................................................................ ........................................................................................................................ ................................ 36

TEMENOS T24 T24 Use Userr Gu Guid ide e

Page Pag e 2 of 38

Miscellaneous Deals

Simple Simp le Bid Bond........................................................... B ond............................................................................................................................. .................................................................. 37

TEMENOS T24 T24 Use Userr Gu Guid ide e

Page Pag e 3 of 38

Miscellaneous Deals

MISCELLANEOUS DEALS Ap pl ic ati on ov erv iew The MISCELLANEOUS DEALS (MD) module is used by T24 to record the miscellaneous contingent deals that are required to record ‘Guarantee’ type transactions on the banks’ books. These range from straight forward Guarantees, both issued and received, to more specific Trade Finance related deals such as Bid and Performance Bonds. It allows for forward dated contracts, full charging facilities using standard FT.CHARGE.TYPE and FT.COMMISSION.TYPE tables. In addition customised delivery advices can be produced.

Certain types of MD .DEAL can be used to feed into the LIMIT and COLLATERAL modules. These need to be of the Contingent Liability type.

MD.Parameter The foundation block for MD module is the MD.PARAMETER, which will have a record matching the COMPANY code of the T24 account e.g. US0010001. Some of these fields are explained below.

Basic Types Essentially, there are four basic types contracts and all deal types created must be based on these types:

User Types (Deal Subtypes) Creation of user types requires the input of ranges according to the kind of deals within the 4 basic types. CATEGORY range enables for future expansion for new products that may be introduced by the bank.

In the table below a simple deal sub-type structure is illustrated, with plenty of room to add new types at a later date.

TEMENOS T24 User Guide

Page 4 of 38

Miscellaneous Deals

CL

Contingent Liability

ML

Memorandum Liability


CA

Contingent Asset MA

Page 5 of 38

Memorandum Asset

Miscellaneous Deals

Figure 1 Contingent Parameter Record

The above example shows the type CA is broken down into several different sub-types for specific usage.

Limits According to the bank’s requirements the use of a LIMIT with either Contingent or Memo Assets can be made Mandatory, Optional or No-Input using the fields CONT. LI MI T. LI NK, MEMO. LI MI T. LI NK, CL. LI MI T. LI NK and ML. LI MI T. LI NK .


Page 6 of 38

Miscellaneous Deals

See the fields on MD.PARAMETER for the settings:

Figure 2 More fields on Contingent Parameter record

The style of Limit reporting is user defined, LIMIT.PARAMETER record called SYSTEM .

default LIMIT settings are defined in

MD.DEALS may be closed/mature and the Limit may be updated on line by input into Event s Processi ng. This will enable the Bank to issue another Guarantee for this customer.

Last Draw Date When a Guarantee is issued with a value date past the Last Draw Date as defined in its limit line, the system generates an override. This override is also enabled in such instances where a Principal increase is done on a Guarantee impacting the limit and whose movement date is past the Last Draw Date of the referred limit line.

Figure 3 Last draw Date defined in the Limit Line


Page 7 of 38

Miscellaneous Deals

Figure 4 The system generates the override

Commission and Accruals Certain user defined deal sub-types may involve commission, either payable or receivable, which is time based and calculated using standard interest routines as explained in Figure 5 below. Such commission can be set by amount or rate and have scheduled accounting dates and must be preceded by the setting of fields in MD.PARAMETER such as the accrual cycle, TRANSACTION and CATEGORY codes to be used.


Page 8 of 38

Miscellaneous Deals

Figure 5 Commission and Accrual Settings

In the above part of the MD.PARAMETER the CATEGORY fields for the commission for the current period and for adjustments to prior periods are shown together with the ACCRUAL. CYCLE field, set to monthly for example.

If an MD deal is input with an account attached for Commission , Charges or a Provision related account , the system will raise forward entries when these are to be debited on a future date. Since these forward entries are raised for an account , T24 will not allow a user to close the account during the existence of forward entries and will produce the following error “Cannot close forward entries exists”. This applies to both CA and CL type of Contract with begin and end type of CSN and also for fixed and frequency type of CSN . In MD DEAL when commission rate has to be changed, it has to be done for entire category instead of one particular deal. This will result in compulsory change of rate for all the deals which falls under this particular category. Now two new fields have been introduced in MD. CSN. RATE. CHANGE – i.e Deal ID and Deal Comm. Rate, through which CSN rate can be changed for particular MD deal. Currently in MD contract commissions are accrued only in currency of the contract or the deal currency (no other currency will be accepted). Accrued commission are debited from the account that is equal to the currency of the contract. Now it has been made in such a way that the CSN.ACCOUNT will be allowed to accept a different currency account other than deal currency. The rate that will be used to convert the amount will be the mid rate from the currency table

Correspondent Bank Limi t The user may open a CUSTOMER record for each of its Correspondent Banks who have allocated credit limits for issuing guarantees. This may be established in MD.CB.LIMITS . The Correspondent Banks limit may be indicated by input Yes/No into CB LI MI T UPDATE in MD.DEALS . The user can opt for this feature while requesting a CB to issue international guarantees or while issuing international guarantee which are to be confirmed by a CB. In such cases, the correspondent bank will be selected in the field RECEI VI NG. BANK in MD.DEAL. The CBL of the correspondent bank will be updated. Similarly any principal movement/ maturity /invocation to such MD.DEALS , CB limit will also be updated.


Page 9 of 38

Miscellaneous Deals

MD.Deal The types of deals that can be entered in MD.DEAL are related to either Contingent Liability or Contingent Assets. The main feature of these types of deals is that the risk is recorded 'off balance sheet' otherwise known as 'below the line'. With the options to utilise the LIMIT updates or not at contract level, and the ability to levy charges or commissions, the number of deal types that can be entered are many fold.

The examples in this User Guide are an interpretation of some of the deals, which can be entered, but since each user according to their unique requirements will define the actual use, the Versions used are not provided as standard in T24. The 'demo' system supplied will normally contain examples of these types of deals as the 'demo' system has been configured as a live banking environment.

With the appropriate use of VERSION you can create many different deal types.

Using the configured MD.PARAMETER detailed earlier in this guide we can allow deals such as:

•

•

•

•

GUARANTEES & BONDS ISSUED ▪

Bid Bond Issued

▪

Performance Bond Issued

▪

Rental Bond/Guarantee Issued

▪

Generic Guarantee

GUARANTEES RECEIVED ▪

Guarantee received - covering facility

▪

Guarantee received - covering overdraft

▪

Guarantee received – generic

MULTI-PARTY GUARANTEES ▪

Guarantee Issued for Client - with Participations

▪

Participation Taken in Guarantee

BILLS ACCEPTED

Record Accepted Bill

Flat Charges MD.DEAL allows for multiple charges to be levied based on the standard FT.CHARGE.TYPE and/or FT.COMMISSION.TYPE tables. It should be noted that these charges are based on the deal amount and are not time based so a 1% charge on USD 100,000.00 would be USD 1,000.00 regardless of the tenor of the deal. Similarly the calculation of such flat charge will not take into


Page 10 of 38

Miscellaneous Deals

account future principal movements, if any. Even if a type of commission is defined under FT.COMMISSION.TYPE , the same is referred as Charge in MD.DEAL.

Time Based Commi ssio ns The MD module is also able to calculate and apply commissions based on standard interest basis versus rates according to the deal tenor. The commission can be entered as a rate plus/minus a spread or entered as a fixed amount. It can be charged in advance or in arrears and the system will accrue the commission on a user-defined basis. Such commission will be calculated on product basis duly reckoning the future principal movement. These commissions are referred as CSN in MD.DEAL in order to distinguish such commission from flat charges

The settings to activate this commission are on the MD.PARAMETER file as detailed earlier.

Further details of the use of commissions are given in the section covering multi-party MD.DEAL types where the commission is both receivable and payable.

Figure 6 Input MD.DEAL

Minimum Amount & Tenor In cases where a Deal is issued for a shorter period or for smaller amount, the resultant commission calculated may fall short of the Bank's requisite minimum. This has now been addressed from MD.TXN.TYPE.CONDITION .


Page 11 of 38

Miscellaneous Deals

Figure 7 Definition of Minimum Commission and Tenor

MI N. COMM. AMT. LCCY and MI N. COMM. TENURE denote the User's minimum requisite commission in the Local Currency under a Deal and Commission period that would be used for commission calculation respectively.

In MD.TXN.TYPE.CONDITION it is also possible to define the same Currency-wise and amountwise. This amount represents the minimum amount of Commission for one single commission schedule.

The Id of this Table is DEAL.SUB.TYPE. The calculation logic will be as under.

•

When the resultant commission of a commission schedule in a Deal is greater than the default value, the computed value stays irrespective of the tenor.

•

When the resultant commission of a commission schedule in 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 commission schedule in 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.

In MD.TXN.TYPE.CONDITION it is also possible to define the default commission for a Category under a DEAL.SUB.TYPE .


Page 12 of 38

Miscellaneous Deals

Figure 8 Default commission for a Category

Commission Frequency Commission may be defined as a frequency, such as Weekly, Monthly, Quarterly, and Half-yearly etc instead of defining them manually. Here an option is made available as to when the Capitalization of the cycle should take place in the event of the last day of the schedule falling on a holiday. This may be Forward, meaning the next working day, Backward, the previous working day or Calendar, on the same day. The default is Calendar day.

Figure 9 Capitalisation in case of Holiday

When the frequency is defined, the CSN. DATE can not be used. The system will accept only the CSN. AMOUNT (if set to Fixed) and the CSN. ACCOUNT. The field CAPI TALI ZE. DATE shall hold the end date of the current frequency input.


Page 13 of 38

Miscellaneous Deals

Figure 10 Either Frequency or Manual

This feature may be used for Call/Notice contracts where the Maturity date is not known. In the event of the normal contract maturing on a date prior to the end of the calendar cycle, the field CAPI TALI ZE. DATE shall be opened up after the contract has matured but the capitalization is pending. In such a scenario, the user has the option to input a date on which the capitalization is to take place, which otherwise during the life of the Deal is a no-input field.

Commissi on Rate Revision Option is available for revision of the commission rates for all live contracts on the date of change of rate. This is handled through MD.CSN.RATE.CHANGE .


Page 14 of 38

Miscellaneous Deals

Figure 11 The date from which the changes is to be effected

The Id for this file is the date, which is referred to as the Revision date, cannot be less than current date. This date indicates the day on which the rate change is processed. Valid inputs into this file are Effective Date, Deal sub type, Category, Commission rate and Retrospective effect.

Effective Date indicates the date from which the new rates should take effect. This can be any day such as past, current or future but cannot be greater than the Revision date. Deal sub type has to be a valid Id in the MD.TXN.TYPE.CONDITION . For a given Deal sub type it may take any Category as defined in the Parameter. For each of this Category, a commission rate may be defined. The field RETRO. EFFECT throws up the option as to whether the changes have to take a retrospective effect in the event of EFFECTI VE. DATE defined as Backdated.

Figure 12 Decision on Retrospective change

This field has to be set to YES or NO. If the impact of the change results in additional commission to be collected, the same is done from the account that was/is debited/to be debited in the running schedule. Alternatively, if it results in refund of commission, the current schedules account is credited. The tax component will however be recovered if additional commission is to be recovered, however no repayment of tax component will be done if the change results in customer credit.

In respect of Participation Deals, CSN Rate change shall not carry any retrospective effect. However, the new rate shall be computed from the revision date onwards.


Page 15 of 38

Miscellaneous Deals

Charges collected in a currency which is different from the deal currency A field, ‘Conver si on Type’ has been introduced in MD.DEAL next to the field ‘Csn Account ’ with the drop down to choose either buy, sell or mid, which will decide the rate to be used from the currency table for the calculation of commission. The last exchange rate updated in the currency table before COB will be used as the exchange rate. If no value is defined, system defaults to mid. This field opens up only if the commission account currency is different from the deal currency.

Figure 13 MD.DEAL

Accrual pattern for CSN.COMMISSION calculat ion A USER can create and select differing CSN.COMMISSION calculation methods to be applied to MD.DEAL transactions. These methods should be defined in EB.ACCRUAL.PARAM , which can then be applied within MD.DEAL in the ACCRUAL. PARAM field Using the fields I NCLUDE. START. DATE and LAST. DAY. I NCLUSI VE the USER can control the interest calculation method. By setting I NCLUDE. START. DATE to “Yes” and LAST. DAY. I NCLUSI VE to “No” CSN.COMMISSION will be calculated for the first day and not calculated for the last day of the payment period of every scheduled period. A record of this type in EB.ACCRUAL.PARAM will be the default calculation method that is applied to all MD.DEAL transactions should the USER fail to select any other method. By setting both of these fields to “Yes” the commission will be calculated for both the first day and the last day of the initial scheduled period. For subsequent scheduled periods the commission will be calculated for the last day but exclude the first day.


Page 16 of 38

Miscellaneous Deals

In the absence of any records being defined in EB.ACCRUAL.PARAM the system will revert to coded routine based calculations where CSN.COMMISSION will be calculated for the first day and not calculated for the last day of the payment period of every scheduled period.

Scheduled Increase / Decrease of Princip al Amou nt The principal amount in a deal need not be fixed. MD.DEAL allows the definition of one or more scheduled changes to the principal amount. Schedules can be either for increasing the principal amount or reducing it. 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.


Page 17 of 38

Miscellaneous Deals

Figure 14 Options in MD.DEAL Principal movement

Cash Margi n (Prov isio n) In MD.DEALS cash margins may 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 .

Figure 15 Defining Provision


Page 18 of 38

Miscellaneous Deals

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. PRI N. AMOUNT. Similarly when an amount is entered, it is converted to the percentage of NET. PRI N. 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. PRI N. AMOUNT. It is possible to establish a percentage for a contract group in APPL.GEN.CONDITION. Here the user may stipulate different provision rates for the same category of guarantee like deal amount-wise, if required.). Care should be taken to define the groups in such a manner that no contract falls in two different groups. If so, the first fit will be returned and the Grouping may be defeated.

MD.GROUP.CONDITION may be used for setting up provision percentage of a particular GROUP deal subtype-wise and category-wise. (GROUP id as defined under APPL.GEN.CONDITION will be the id here). In addition to that, C-1001 will be accepted as id where the customer number is 1001. The specific condition for the customer will be defined here.

Figure 16 Input to determine Provision in Deal

When Provision is set to YES, in MD.DEAL, the related fields will 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 a Close of Business activity.


Page 19 of 38

Miscellaneous Deals

Figure 17 Input of Provision fields

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.

Figure 18 Impact on Limit

The field I NCLUDE. PROVI SI ON 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.

Figure 19 Online release of Provision

The field OUTS. PROV. AMT holds the entire amount of Provision under the Deal. A table MD.PROV.BALANCES is made available that displays the Debit Provision account, Credit Provision account, Currency of Provision and the Total Provision outstanding.


Page 20 of 38

Miscellaneous Deals

Figure 20 Balances file on 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.

Figure 21 Provision taken in Movement

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 P rincipal 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. PRI N. AMOUNT.

Expiry Option An option has been made available to keep the Deal live till the original Guarantee is returned. This means that beyond the maturity date the deal stays with the status CUR and does not become LIQ unless the user sets the AUTO. EXPI RY to YES. This is controlled from the Parameter level and from the record level.


Page 21 of 38

Miscellaneous Deals

Figure 22 Options on Expiry in Parameter

At the Parameter level the EXPIRY.MODE may be defined as AUTOMATIC or MANUAL. When set to Automatic, the record has the default value of YES in the fieldAUTO. EXPI RY. When set to YES at the record, the Close of Business activity on the date of maturity changes the record status to LIQ. The user may clear out this default at the record, resulting to NULL, ensuring that the record status is not changed. As the status is at CUR, the user has the option to change it to LIQ by changing NULL to YES.

Figure 23 Expiry control at Deal level

Alternatively, when set to MANUAL at the Parameter level, the record is defaulted to NO. This ensures that the record does not move to history unless the user changes it to YES.

Alt ernative ID A MD Deal may also be identified with an alternate Id. This is to be input by the user in the field ALTERNATE.ID. The deal may be invoked by using this Id as well.

Figure 24 Input field in the Deal


Page 22 of 38

Miscellaneous Deals

Multi-Parti cip ant Deals These are usually Guarantees issued on behalf of a client where the amount requires the participation of other banks to spread not only the risk but also sharing the commission collected. It is convenient to use terminology such as Syndicated, Participant, Lead Bank and Issue Customer in explaining how MD.DEAL caters for Multi-participant deals.

Typically there will be a master deal issued by the Lead Bank with one or more banks participating. The client will be charged a commission based on the amount and tenor of the deal, some of which is passed on to the participants. The Lead Bank will assume the remainder of the deal risk and the commission.

The user has two options to input participant deals:

♦

To book a master deal (CA) for the entire value of the guarantee issued i.e., for Leader’s portion plus all participants’ portion. And book separate CL deals for each participant’s share. Asset Liability will not be netted in the master deal. The entire commission collected from the client will be booked/accrued as income under CA deal and participant’s share will be accrued/distributed as expense under CL deals. The accounting rules for such set of guarantees are explained below.

♦

To book a consolidate deal for the entire value defining the various participant’s share in the same deal. The asset liability will be netted in the deal. The participant’s share of commission and tax thereon will be credited to an internal account and only Leader’s share will be accrued/booked as income as explained below.


Page 23 of 38

Miscellaneous Deals

Figure 25 Asset Liab Netting in MD.DEAL

Movement in Particip ation In a Participation Deal, positive or negative movement for the Participant is now permitted. The only pre-condition for the movement to happen be that participant should first defined under PARTI CI PANT.

Figure 26 Defining Movement for Participants

The fields PART.CUS and PAR.PRN.MVMT are multi-value sets and the balance of the movement amount if any, is apportioned to the leader. The MOVEMENT.DATE defines the date on which the impact has to be made. All these activities happen at End of Day.

Partici pant's Commission In MD.DEAL it is possible to split the Participant's commission, which was otherwise ending up in the books of the Leader and thereby moving into the P&L account entirely. At the Parameter an account may be defined as shown that would receive the Participant's share in the Deal.

Figure 27 Defining in Parameter

After defining the Internal account category in the Parameter, its account in the Local currency shall be opened. At the Deal level SPLI T. COMMI SSI ON is to be set to YES.


Page 24 of 38

Miscellaneous Deals

Figure 28 Decision on apportioning Commission

Then the commission portion relating to the Participant gets accounted here. The amount due from each of the Participants is tracked here up to date in the current schedule. This can be used to find the balance due to a participant on a given date should the Participant wish to withdraw. This gets multivalued for each of the Participant customer in the file MD.PART.CSN.BALANCES .

The account statement also shows the break-up of the above. The table MD.BALANCES also shows the entire amount of the Participants' share. This file is not available, where theCSN. PAYMENT. TYPE is Begin

Ac co un ti ng Rul es f or Com mi ssion The following accounting rules apply to the Commission if participation guarantees are booked without splitting commission.

•

Guarantees Issued (and our participation taken)

Ac cruals:

DR

Commission Income (asset type)

CR

Commission Receivable P&L

CURRENT. ACCRUAL category on MD.PARAMETER file

On schedul e date:

DR

CSN.ACCOUNT on MD.DEAL

CR

Commission Income (asset type)

•

Participation Given


Page 25 of 38

Miscellaneous Deals

Ac cruals:

DR

Commission Payable P&L CURRENT. ACCRUAL category on MD.PARAMETER file

CR

Commission Expense (asset type)

On schedul e date:

DR

Commission Expense (asset type)

CR

CSN.ACCOUNT on MD.DEAL

The CSN. ACCOUNT on MD.DEAL can be a Client Account, a Nostro or an Internal account. In the case of internal accounts, the actual payment of funds is outside the scope of the MD module and can be made by manually entering FT transactions.

Using an MD item as Collateral MD deals (most likely Guarantees Received) will be used as Collateral for other applications. This is set-up using the COLLATERAL, COLLATERAL.TYPE and COLLATERAL.RIGHT applications. There are no special considerations of the deals, which can be used as items of Collateral.

MD covered by Collateral As well as being used as Collateral items MD deals can in fact be covered by Collateral. For instance there may be a requirement that the amount of guarantees issued for a client is dependent on the amount of collateral held. This can be through the use of a variable LIMIT where the LIMIT increases/decreases based on the amount of collateral; or the collateral item can be linked to the MD deal using COLLATERAL.RIGHT . The MD.DEAL reference would be entered instead of the LIMIT id in the LI MI T. REFERENCE field.

MD link t o Syndication A link is available in MD.DEALS to link in the Syndication ID. This may be input into Sl Ref Tr anche and Sl Pr od Type. This will create a link to any syndicated structure. This will support the same enabling as an online update of such a structure along with the static update of the requisite information.

MD.Activity These records provide descriptions for the delivery advices created by MD.DEAL; they are referred to by MD.ADVICES . TEMENOS T24 User Guide

Page 26 of 38

Miscellaneous Deals

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

Figure 29 MD.ACTIVITY records

MD.Advices This file is used to specify which format 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 .

Figure 30 Options in MD.ADVICES


Page 27 of 38

Miscellaneous Deals

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

Figure 31 Decision on Soft delivery

The requisite activities such as Issues, Amendments are fetched from EB.ACTIVITY .

Figure 32 Available activities

Similarly the relevant message types are fetched from the EB.MESSAGE.CLASS . The message class shall also be defined conforming to the nature of the event.


Page 28 of 38

Miscellaneous Deals

Figure 33 EB.ADVICES

After enabling the Preview, with the input of PREVIEW in the MD PGM.FILE , all the SWIFT related messages might be viewed, provided the relevant fields for the said messages are input. In case the valid fields are not input appropriate override/error messages are displayed.

Figure 34 Related SWIFT message

For a given activity the apt messages are triggered. Option is available to override the Carrier and the Address. Setting the SEND. ADVI CE to YES generate the messages and NO would suppress them. More than one message may also be set for a given activity or event. Separate message class for such as Debit Provision, Debit Commission, Bank Advice etc may also be attached.


Page 29 of 38

Miscellaneous Deals

An option has been made available in MD.CLAUSES , where the user inputs the standard formats and invokes them at the Deal, by the input of the MD.CLAUSES Id and committing.

Figure 35 User definable Guarantee text

This MD.CLAUSES on authorization may be invoked in the Deal using the Id 'UNDJ UR' and Committing.

Figure 36 Register format in Deal

As this field is a multi-value field, more clauses may be added to the Deal in as many multi-value sets. It is however important to note that SWIFT messages would not get triggered unless the field ADVI CE. REQD is set to YES in the Deal.

Figure 37 Record level decision to trigger messages

Implementi ng Soft Delivery in MD In the present set-up, the activities involved and advices generated in MD are:


Page 30 of 38

Miscellaneous Deals

Activity code

Description

Advice

100

Charge advice

2900

101

Deal confirmation

2320

102

Deal amendment

2320

103

Deal cancellation

2320

To implement soft delivery in the lines of LC, the various activities involved in MD need to be identified. As followed in LC, the activity code can be of 3 parts viz. operation, instrument and event. Hence, an activity code in MD will look like MD-XYZZ where,

X - identifies the operation Y - identifies the instrument and ZZ - identifies the event

Operation Code

MD

1

Opening new

2

Amending Table 2

Instrument Code

MD

1

CA

2

CL

3

MA

4

ML Table 3

Event

Code

MD

01

Input / Authorisation Table 4


Page 31 of 38

Miscellaneous Deals

Moreover, like in LC, message classes need to be raised for sending advices based on some conditions. These are internal classes confined only to MD and will be mapped to generic EB message classes.

Message classes:

MD BASIC.MESSAGE

Always raised

BANKADVICE

For MT760*

DEBIT.CUST

When charge is debited

CS N.CREDIT

Commission rate change (reduction)

PROVISION.CREDIT

Whenever provision is taken / released

PROVISION.DEBIT

Whenever provision is taken / released

CS N.DEBIT

When commission is debited

NOTIFICATION

Participation by other banks

ACKNOWLEDGEMENT

When a guarantee is recd from another bank MT768*

PRIN.REDUCTION

When principal is reduced (at EOD) MT769*

CANCELLATION

When deal is reversed.

ADDITIONAL.MSG

When deal is amended MT767*

USER.DEFINE 1…. 9

Always raised (for the users to attach additional messages) Table 5

* Only when RECEIVING.BANK is mentioned

All the messages that need to be produced are attached to the corresponding activities thru EB.ADVICES . Some messages will be produced regardless of whatever message classes are raised. Like confirmation of deal, confirmation of amendments etc., other messages will be produced only when the related message classes are raised during the activity. Hence, online or during EOD, we need to build up the correct activity code and raise relevant message classes to produce necessary messages. Besides, by setting the MESSAGE to PREVIEW, the 'preview' button will be enabled in the desktop.

The HANDOFF record needs to be built in a different fashion. The structure of the HANDOFF for soft delivery will be as follows:


Page 32 of 38

Miscellaneous Deals

Record #1

R.NEW

Record #2

R.OLD

Record #3

Charges

Record #4

Commission

Record #5

Provision

Record #6

-

Record #7

SWIFT tags

Record #8

Header

Record #9

User defined

The header (Record #) is structured as follows :

REC8<1>

COMP ANY

REC8<2>

CUS.COMPANY

REC8<3>

APP.FORMAT

REC8<4>

MESSAGE.TYP E

REC8<5>

CURRENCY

REC8<6>

DEP ARTMENT

REC8<7>

TRANS.REF

REC8<8>

CUSTOMER

REC8<9>

LANGUAGE

RE C8<10>

ACCOUNT

REC8<11>

VALUE.DATE

RE C8<12>

AMOUNT

Then EB.HANDOFF will be called (instead of APPLICATION.HANDOFF) with activity code. In 'preview' mode we pass on only the activity codes to EB.HANDOFF . The ACTIVITY.CODES array returned will be populated with the corresponding message classes and messages. These values are retrieved and populated in the relevant fields in the deal. 8 new fields are added for this purpose.

Backward compatibilit y: Since the structure of handoff is now different from the previous one, we may have to amend the DE.MAPPING records for messages relating to MD while implementing soft delivery. Alternatively, if the client wants to continue with the existing delivery mechanism, we can have a parameter level field to direct the program to run old delivery program or the new program. Handoff Rec 3 - Charges

Date


Page 33 of 38

Miscellaneous Deals

Currency Account Code Amount Total Charge Description Account title Handoff Rec 4 - Commission

Date Currency Account 'COM' (as code) Amount Total amount 'Commission' (as description) Handoff Rec 5. - Provis ion

Movement date Debit amount LCY Debit currency Debit amount FCY Credit amount LCY Credit currency Credit amount FCY Exchange rate (debit) Exchange rate (credit) Provision amount Provision Debit account customer Provision credit account customer New Messages :

760 767 768 769 New Mapping keys:

Contingent Confirmation

2320.MD.2

Charge Advice

2900.MD.2

Commission Advice

2900.MD.3


Page 34 of 38

Miscellaneous Deals

Provision Debit

910.MD.2

Provision Credit

910.MD.2

SWIFT

Guarantee Issue

760.MD.2

Guarantee Amendment

767.MD.2

Acknowledgement

768.MD.2

Reduction/Release

769.MD.2

DFS

760.1.1 767.1.1 768.1.1 769.1.1 DFP

760.1.1.GB 767.1.1.GB 768.1.1.GB 769.1.1.GB

System files MD.BALANCES MD.PARTICIPANT.CSN.BALANCES MD.PROV.BALANCES MD.SCHEDULES MD.SCHED.DATES These files hold the details of the MD.DEAL record accounting movements and schedules; they require no input or maintenance by users.

They may be used for providing details for ENQUIRY records created locally, or for reports and advices.

General Ledger reporti ng Given that the system has been configured for the types of deal that are to be used by the bank, the next stage is to ensure that the different type of deals are defined both for reporting, financial and with appropriate input screens.


Page 35 of 38

Miscellaneous Deals

In order to report the deals to the appropriate ledger line the following values can be used in RE.STAT.REP.LINE in the field ASSET. TYPE:

Whilst the Contingent Assets/Liabilities are reported below the line, the memo equivalents are usually off-balance sheet. However, these can be used for internal ledger purposes.

If we consider a MD.DEAL for GBP 10mio as an example, the GL accounting and Limit updates will take place as follow:

•

On value date

Credit CONTDBGBP 10,000,000.00

Reduce Limit byGBP 10,000,000.00

•

At maturit y

Debit CONTDB GBP 10,000,000.00

Reinstate Limit by

GBP 10,000,000.00

MD.Deal with Vers ion With the appropriate use of VERSION , we can create different deal types according to the requirement of each user. The following screenshots illustrate how different deal 'products' can be tailored for ease of use. These Versions are available in the T24 'demo'.


Page 36 of 38

Miscellaneous Deals

Simple Bid Bond A Bid Bond (also known as a Tender Guarantee) is normally to assure the buyer inviting bids from wasted effort and expense in evaluating bids from contractors. And from losing offers from other companies if the original bidder drops out.

To record a Bid Bond Guarantee issued we record the deal type, category and customise the screen input prompts as shown below:

Figure 38 BID BOND GUARANTEE

Behind the VERSION called MD.DEAL, BID we have to pre-set some of the data which will be populated each time.

Here is an extract of the VERSION record for MD.DEAL; BID showing we are populating the CONTRACT. TYPE, DEAL. SUB. TYPE, CATEGORY, LI MI T. UPD. REQD and ADVI CE. REQD fields.


Page 37 of 38

Miscellaneous Deals

Recommend Documents