Académique Documents
Professionnel Documents
Culture Documents
User Guide
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 2005 TEMENOS Holdings NV. All rights reserved.
Miscellaneous Deals
MISCELLANEOUS DEALS ................................................................................................................. 4 Application overview......................................................................................................................... 4 MD.Parameter...................................................................................................................................... 4 Basic Types...................................................................................................................................... 4 User Types (Deal Subtypes) ........................................................................................................... 4 Limits ................................................................................................................................................ 6 Last Draw Date................................................................................................................................. 7 Commission and Accruals................................................................................................................ 8 Correspondent Bank Limit................................................................................................................ 9 MD.Deal ............................................................................................................................................. 10 Flat Charges ...................................................................................................................................... 10 Time Based Commissions ................................................................................................................. 11 Minimum Amount & Tenor ................................................................................................................. 11 Commission Frequency ..................................................................................................................... 13 Commission Rate Revision................................................................................................................ 14 Charges collected in a currency which is different from the deal currency ....................................... 16 Accrual pattern for CSN.COMMISSION calculation .......................................................................... 16 Scheduled Increase / Decrease of Principal Amount ........................................................................ 17 Cash Margin (Provision) .................................................................................................................... 18 Expiry Option ..................................................................................................................................... 21 Alternative ID ..................................................................................................................................... 22 Multi-Participant Deals ....................................................................................................................... 23 Movement in Participation.................................................................................................................. 24 Participant's Commission ............................................................................................................... 24 Accounting Rules for Commission ................................................................................................. 25 Using an MD item as Collateral ......................................................................................................... 26 MD covered by Collateral................................................................................................................... 26 MD link to Syndication ....................................................................................................................... 26 MD.Activity ......................................................................................................................................... 26 MD.Advices........................................................................................................................................ 27 Soft Delivery....................................................................................................................................... 28 Implementing Soft Delivery in MD ..................................................................................................... 30 Backward compatibility:.................................................................................................................. 33 System files........................................................................................................................................ 35 General Ledger reporting................................................................................................................... 35 MD.Deal with Version ........................................................................................................................ 36
Page 2 of 38
Miscellaneous Deals
Page 3 of 38
Miscellaneous Deals
MISCELLANEOUS DEALS
Application overview
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:
In the table below a simple deal sub-type structure is illustrated, with plenty of room to add new types at a later date.
Page 4 of 38
Miscellaneous Deals
CL ML
CA
Page 5 of 38
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 banks requirements the use of a LIMIT with either Contingent or Memo Assets can be made Mandatory, Optional or No-Input using the fields CONT.LIMIT.LINK, MEMO.LIMIT.LINK, CL.LIMIT.LINK and ML.LIMIT.LINK.
Page 6 of 38
Miscellaneous Deals
The
style
of
Limit
reporting
is
user
defined,
default
LIMIT.PARAMETER record called SYSTEM. MD.DEALS may be closed/mature and the Limit may be updated on line by input into Events Processing. 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.
Page 7 of 38
Miscellaneous Deals
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
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
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.
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.
Page 11 of 38
Miscellaneous Deals
Figure 7 Definition of Minimum Commission and Tenor MIN.COMM.AMT.LCCY and MIN.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.
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
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 CAPITALIZE.DATE shall hold the end date of the current frequency input.
Page 13 of 38
Miscellaneous Deals
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 CAPITALIZE.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.
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 EFFECTIVE.DATE defined as Backdated.
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
Figure 13 MD.DEAL
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.
Page 17 of 38
Miscellaneous Deals
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.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 Leaders portion or for the balance outstanding in NET.PRIN.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.
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 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.
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 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.
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.EXPIRY 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 field AUTO.EXPIRY. 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.
Alternative 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.
Page 22 of 38
Miscellaneous Deals
Multi-Participant 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.
To book a master deal (CA) for the entire value of the guarantee issued i.e., for Leaders portion plus all participants portion. And book separate CL deals for each participants 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 participants 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 participants share in the same deal. The asset liability will be netted in the deal. The participants share of commission and tax thereon will be credited to an internal account and only Leaders share will be accrued/booked as income as explained below.
Page 23 of 38
Miscellaneous Deals
Movement in Participation
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 PARTICIPANT.
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.
Participant'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 SPLIT.COMMISSION is to be set to YES.
Page 24 of 38
Miscellaneous Deals
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 the CSN.PAYMENT.TYPE is Begin
Accruals:
DR CR
On schedule date:
DR CR
Participation Given
Page 25 of 38
Miscellaneous Deals
Accruals:
DR
CR
On schedule date:
DR CR
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.
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 LIMIT.REFERENCE field.
MD link to Syndication
A link is available in MD.DEALS to link in the Syndication ID. This may be input into Sl Ref Tranche and Sl Prod 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
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.
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.DELIVERY 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.ADVICE 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 'UNDJUR' 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 ADVICE.REQD is set to YES in the Deal.
Page 30 of 38
Miscellaneous Deals
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 1 2 MD Opening new Amending Table 2
Instrument
Code 1 2 3 4 MD CA CL MA ML Table 3
Event
Code 01
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 BANKADVICE DEBIT.CUST CSN.CREDIT PROVISION.CREDIT PROVISION.DEBIT CSN.DEBIT NOTIFICATION ACKNOWLEDGEMENT PRIN.REDUCTION CANCELLATION ADDITIONAL.MSG USER.DEFINE 1. 9 Always raised For MT760* When charge is debited Commission rate change (reduction) Whenever provision is taken / released Whenever provision is taken / released When commission is debited Participation by other banks When a guarantee is recd from another bank MT768* When principal is reduced (at EOD) MT769* When deal is reversed. When deal is amended MT767* 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 Record #2 Record #3 Record #4 Record #5 Record #6 Record #7 Record #8 Record #9 Header
User defined
REC8<1> REC8<2> REC8<3> REC8<4> REC8<5> REC8<6> REC8<7> REC8<8> REC8<9> REC8<10> REC8<11> REC8<12>
COMPANY CUS.COMPANY APP.FORMAT MESSAGE.TYPE CURRENCY DEPARTMENT TRANS.REF CUSTOMER LANGUAGE ACCOUNT VALUE.DATE 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 compatibility:
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. - Provision 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 Charge Advice Commission Advice 2320.MD.2 2900.MD.2 2900.MD.3
Page 34 of 38
Miscellaneous Deals
Provision Debit Provision Credit SWIFT Guarantee Issue Guarantee Amendment Acknowledgement Reduction/Release 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
910.MD.2 910.MD.2
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.
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
At maturity
Reinstate Limit by
GBP 10,000,000.00
Page 36 of 38
Miscellaneous Deals
To record a Bid Bond Guarantee issued we record the deal type, category and customise the screen input prompts as shown below:
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, LIMIT.UPD.REQD and ADVICE.REQD fields.
Page 37 of 38
Miscellaneous Deals
Page 38 of 38