Forex Work Flow Document1

Forex Workflow document. Inter-bank A trade is entered in TT. The interface server when polling TT database, will find the trade. It will read the trade and park it in the interface. The reference data is then matched a. Counter party b. Broker c. Dealer d. Currencies If the corresponding static data is available in ITMS and other validations pass, the deal flows through. 1. In ITMS, the trade gets accounted (Position to payables /receivables /contingents). Then the trade comes in for Back Office Authorization, On authorization, the confirmation is activated. The confirmation mode can be set up at the counter party level. 2. If the counter party is an overseas counter party 2a. SWIFT MT 300 gets generated and this message is put in a specific folder and SWIFT system picks up the message from that folder. 2b. A corresponding MT300 arrives from the counter party, 2b1. If the incoming MT300 arrives before it is sent from ITMS, it waits in the interface, if confirmation recieved is in excess/ no such deal done in ITMS the deal lies in interface and is shown in non-matched report. 2b2. After the outgoing MT300 is generated , when the incoming MT300 arrives or if it has already been read, the details are matched between the two MT300 messages. 2b2a. If there is a mismatch, the errors are logged. 2b2b. If there is no mismatch, the message is marked as matched. 3. If the counter party is a local counter party, then the counter party confirmation number is to be entered in the confirmation screen. Until then, the deal remains in the unconfirmed queue. 4.If the deal is matured and waiting for confirmation still it would be moved to some other table in ITMS and it wont be seen in the deals awaiting match report. Tracers are generated based on the set up for the number of days interval between tracers. Mail confirmation is generated and printed at eod on the booking day only for deals over spot. Impact analysis on Exception report for matured deals / upto spot deals / deals marked for confirmation recd ? (Will not generate an exception for every matured deal/ upto spot deal. There is a report on unconfirmed contracts however.) Parallel to the confirmation processing, the settlement process also gets activated on Authorization. Each leg of the transaction (one if outright two if swap) will have cash flows in 2 currencies. The LCY cash flows' settlement processing happens on the due date while the FCY cash flows' settlement processing happens at spot notice . For FCY’ Message generation Options are

available (Cash/Tom/Spot notice).The check is performed against local currency. For example, if message generation is set for GBP as spot notice, it will be generated 2 INR working days before the settlement date. Until then, the trade remains in the forward deals pending queue. 4. For an LCY cash flow, on authorization the cash flow moves to the settlement pending queue. Then this cash flow may be settled in the ITMS Netted Settlement option. On settling the cash flow, 4a. The settlement accounting occurs. (Payables/Receivables to LCY Nostro). 4b. The details of the cheque/instrument are sent to the cheque printing software and 4c. The cash flow is moved to the settlement authorization queue. On authorization of the LCY settlement, the deal gets completed. 5. For an FCY cash flow, 5a. Auto-settlement i.e.no authorisation required for settlement, wheares the payment msgs will require authorisation) 5b. If it is a receivable in FCY 5b1. MT 210 is generated and auto authorized, OR 5b2. MT 210 is generated and awaits authorization (default option), OR 5b3. MT 210 is not generated. One of the above 3 happens based on the account (FCY Nostro). For each FCY Nostro, the option has to be set. 5c. If it is a payable in FCY, 5c1. The MT202 is generated and awaits authorization. MT202 supports third bank account / chips / chaps /ac # / fedwire / mail address etc. It may be noted that even as FCY settlement and messaging occurs earlier than due date, the Settlement accounting entries are posted with a future value such as to affect the Nostro balances only on the due date. I.e. the handoff of accounting entries on settlement viz, reversal of contingent entries and entries to the settlement account will be passed onto MB / banking system on the settlement date. 6. For the MT 202 and MT210 MT300 and MT320 are also included messages that are sent from ITMS, the files are read back after processing by NovaSWIFT to read whether the messages are ACKnowledged OR not. (ACK/NACK) and the status is updated in ITMS. 7. As and when accounting is done in ITMS, the accounting entries are transformed into MBreadable entries. The hand-off of accounting entries could be generated either at the time of EOD or as when the deal is accounted in ITMS. There is no provision to check if the deal has been authorised or not. For example, a trade of 1m USD purchase comes into ITMS. 1. It gets accounted in ITMS. The MB entries would also be generated in ITMS. Now, the trade moves to the authorization queue in ITMS. 2. Before it is authorized in ITMS, the MB file generation menu is used. 3. The entries for this unauthorized trade would also be posted in the file. 4. However, the unauthorized has to be acted on in ITMS before EoD. If it is not to be authorized in ITMS, it is to be rejected and reversed/amended in TT. 5. Say it is reversed in TT. Once the reversal comes in, again the reversal entries are generated. The next MB handoff would pick the reversal set of entries and file the same THE above applies for interbank trades. For CORPORATE Contracts, all accounting entries (ITMS and the MB equivalents) are generated only on authorization. For this, ITMS provides an EAS (External Accounting Software) mapping system to define and map the account heads of MB. The correspondence between the ITMS accounts and the MB accounts needs to be mapped.

8. A file generation software is available to generate the flat files as per MB-readable form which takes the entries from 7(??) and creates files for upload into MB. IT to comment. 9. On reversal/amendment of a deal in TT, the information is again polled in to ITMS through the interface, and the above work flow repeats. a. There is no restriction on reversal/amendment of a trade in TT based on workflow. A trade may be modified or reversed any time even after it has been processed in a back office system (but on or before the maturity date.) b. When an amendment of a trade is received in ITMS from TT, the old details are reversed and a new trade is booked BUT the old (deal) number is retained. c. If the messages have already been generated (au in ITMS for the trade, a new ‘cancel’ and ‘amend’ MT300 messages are generated in ITMS. What happens to a. if confirmation is already recd for the original deal from c’party and is correct, hence marked as confirmed ? (ITMS will generate a message. It will wait for a new message AGAIN from the counter party for matching. The users are to explain the requirements in this scenario.) b. if confirmation is recd for the original deal from c’party but with errors (and the errors were on our contract confirmation for which the amendment is recd now and hence their confirmation is correct and needs to be marked as confirmed) . (YES) if confirmation is recd for the original deal from c’party but with errors (and the errors are not matching with the amendment is recd now). (The deal will remain in the “awaiting match queue”) Complete impact analysis on exception report (The confirmation mismatch report will show this as still not matched).. If the contract is cancelled, for which their confirmation was recd and matched off – impact analysis on exception report / deal confirmation queue etc. (ITMS exception report will not show these exceptions). d.

What about mt202 and MT210 for amendments and cancellations? ( For amendments, a new MT202/MT210 will be generated. The removal of existing messages are to manually handled )

10. Accounting entries for brokerage on booking the deal? 11. Brokerage calculation? 12. Brokerage payments? 13. Accounting entries on brokerage settlement? 14. Brokerage accounting for amendments and cancellations? 15. Deal to be kept on hold / release the hold – not mentioned 16. Revaluation 17. Process – how to change, brokerage / settlement instructions / broker inITMS before and after authorisation in ITMS. ( For points 10-17 refer to Brokerage handling in ITMS, provided as the last part of the document)

Corporate Forward Contracts A trade is entered in TT. The interface server when polling TT database, will find the trade. It will read the trade and park it in the interface. The reference data is then matched a) Counter party b) Dealer

c) Currencies d) Branch (Branch information is picked up from ITMS masters only) e. Product code ? 1.

The deal stays in the interface screen and one can ‘hold’ the deal in the interface. And when required, the deal can be pulled in. Impact of ‘hold’ deals on revaluation, mb accounting entries, position, gaps etc.?? ( Deals kept on hold will not be accounted in ITMS) Refer to “General” section at the bottom half of the document.

2. When the trade is pulled in, if the corresponding static data is available in ITMS and other validations pass, the deal flows through to ITMS. a) In ITMS, the trade should be picked up in the booking screen and authorized. b) On authorization, the deal gets accounted in ITMS (Position to contingents). On the maturity date, at the beginning of the day ? (actually an accounting server task, immediately after the beginning of the day). ITMS consists of an accounting server and an interface server components. These are continuously running programs that start immediately after BoD and stop just before EoD. The accounting server program would handle the auto-maturity of forward contracts. This has been done so that even during the day, premature closure of contracts can be handled.) PLEASE note that the distinction between ODD-normal and ODD-cash, (basically cash items and export bills) has not been specified in the ‘FX workflow’ docs. We’ll be using deal type ODD to read a trade as ODD. If the ACCOUNTING GROUP for a trade with deal type ODD is read as ‘manual’, it is assumed to be an export bill and processed in ITMS, while if it is ‘auto’, it is not processed and left in the interface. the contract is automatically matured. The contingents get reversed to a dummy nostro account (settlement a/c specified by users). (The system will pick the dummy nostro account automatically and there is no user intervention) 3.

4. On cancellation, the cancellation again flows into ITMS, identified by ‘cancel’ accounting group. The cancelled amount gets reversed and the rest is rebooked in ITMS. 5.

As and when accounting is done in ITMS, the accounting entries are transformed into MBreadable entries, and the same are handed off to MB at the end of the day ?in the form of flat files. Remark mentioned in point # 7 of I/B ). The entries are created and kept ready as soon as ITMS accounting for the same is done (immediately for inter-bank trades and on authorization for corporate trades). The file may be generated as and when desired by the user through a menu provided for MB handoff.

1) On full cancellation, the deal again flows into ITMS, identified by ‘cancel’ accounting group. If the user has entered the cancellation rate in userfield 3 in TT, the interface will hold the cancellation rate. But, the cancellation in ITMS is done at the booking rate only. For cancelled amount a new Cancellation deal is booked with the same deal number in ITMS. There is no authorisation provided for this process. Since changing the accounting group to “cancellation” does not reduce the position in TT, a fresh trade with the opposite flow of the original trade must be entered in TT. But, as Interface/ITMS senses the cancellation based on the old trade, the new trade will not be processed in ITMS (will remain in the interface itself) 2) Part cancellation is a two step process. a) The trade in TT is split into two. So, a reversal of the old trade and two new trades (with ld accounting group) will be generated. At this point, Interface/ITMS would reverse the old trade and generate two new trades accordingly.

b) The deal (with the cancellation amount) should be picked up in TT and the accounting group should changed to “Cancel”. This deal will follow the same process as in 3. 3) In case of early full utilization, the value date of the trade is amended in TT to cash date (assuming that the utlisation happens today). When it come to ITMS, the old trade is reversed and a new trade is created but with the same deal number. 4) In case of early part utilization, the trade in TT is split into two and such that the component that is being utilized will have the cash date and the other will have the original forward date. When it come to ITMS, the old trade is reversed and a two new trades are created but with the same deal number. (The auto-utilization program takes care of the utilization component.) 6. For ODD items, the same workflow as above is followed until 5. At this time, for ODD items, the entries are not handed back to MB. This is because these entries originate from MB in any case and providing the entries back to MB would result in double counting in MB. Absolutely wrong. To repeat again, ODD is of two types a. fcy reporting by the branches – this is not taken in ITMS at all for any reason b. Export bills – these deals will be taken in ITMS for Revaluation and gaps purpose. (Yes) These deals are auto authorised in ITMS. (No, these deals are to be authrosied in ITMS manually. Auto-authorization, if required can be provided) No accounting entries to be generated to be handed off to MB. (YES) 7. Revaluation 8. Part / early Utilisation 9. Accounting entries on amendment / cancellation – part or full / part or early utilisation (all the above - on due date / before due date) 10. Position calculation for cancellation – whether it considers the cancellation details or booking details? Cancellation entries are passed at booking rate or cancellation rate? 11. Confirmations (booking as well as cancellations and amendements) 12. Branch accounting in MB - in case of other branches deals like, chennai, Delhi, Bangalore, Calcutta etc.

General 1) Based on the party type defined in ITMS the deal will go into ITMS as an IB or merchant deal. If the party is assigned a role of ‘merchant counterparty’ then deal comes into ITMS as a merchant contract, else it comes as an IB deal. 2) The trade-entry-date should be less than or equal to the business date in ITMS. If yes, then the deal is taken for processing, else it is marked as a forward entry-dated deal. The forward entry-dated deal would be picked up when the entry date and the business date are equal. 3) If the interface process “Posting deals into ITMS” is not selected, the user can ‘hold’ the deal in the interface once it is picked from TT. On “Releasing” the hold the deal get processed in ITMS. 4) There is provision to put the deals on auto-hold. On user initiation, all the deals coming in to the system after this event will stay at interface itself. The next day the users should release the hold so that it gets processed in ITMS also. 5) The system does not support cross-desk deals.

Brokerage Handling in ITMS:

The Brokerage definitions have to be made for the various deal types. eg. Spot & Outright, Short swap, Long Swap etc. The brokerage is calculated based on the definitions made. When a deal is booked in TT and if it has been identified as a broker deal by entering a broker then the broker details flows to ITMS from TT and the brokerage will be calculated as per the definitions made. The brokerage calculated can be changed during Back office authorisation by rejecting the deal. The rejected deal can be modified using the Deal Modification screen. Even if a deal flows through the interface as a non broker deal, the deal can be made as a broker deal in the deal modification screen( the brokerage amount has to be manually keyed in) and the broker and the brokerage can be changed. After making the modifications when the deal is saved, it is saved with the same deal no. The deal will be available for Back office Authorisation and has to be authorised. After authorisation the broker payment will be available for settlement on the value date of the deal. 10. Accounting entries for brokerage on booking the deal : Brokerage Paid (Exp Ac) Dr Brokerage Payable (Broker) Cr 11. Brokerage Calculations : The calculations are based on brokerage definitions. The definition screen has the following options Direct - % on the deal amount(USD equivalent) Slab - Based on various slabs Cumulative - All slabs NonCumulative - Particular slab in which it falls Minimum - Minimum Brokerage for the deal type Maximum - Maximum Brokerage for the deal type 12. Brokerage Payment : The brokerage payments to be made will be available for settlement on the value date after backoffice authorisation and can be settled through the settlement screen available in ITMS back office. 13. Accounting entries on brokerage settlement : Brokerage Payable (Broker) Dr Nostro Bank (Seqno ) Cr 14. Brokerage accounting for amendments and cancellations When the broker/Brokerage are amended in the Backoffice then the previous set of accounting entries passed will be reversed and fresh entries will be passed as said above for the broker/Brokerage 17. Process - How to change broker/brokerage/Settlements instructions/narration in ITMS

The brokerage/Settlements instructions and broker can be changed using ITMS Deal Modification screen after the deal being rejected in the Back office authorisation screen.