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 MB-
readable 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).

3. 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)

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 MB-
readable 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.