A Typical Trade Life Cycle

A brief description of systems functions and the trade flow:

1. FO: capture orders from clients.
2. FO: route orders to external broker (if step-out to external broker).
3. FO: slice orders and route execution to exchange (if we have seat on the exchange).
4. FO: receive filled execution from external broker/exchange.
5. FO: pass filled (fully/partial) orders to MO.
6. MO: allocate filled order to client's sub-accounts via Tel/OASYS. These client allocations are called client trades.
7. MO: send confirmation about allocated client trades.
8. BO: receive client allocations, and book them into settlement system.
9. BO: receive market executions at EOD, group by trade date, buy/sell, security, and book them as market trades.
10. BO: book matching: make sure client trades matches with market trades on security and quantity.
11. BO: post to general ledger for financial movements on trade entry event (T+0).
12. BO: for each client trade, send SSI to the custodian for trade matching (T+0, T+1, T+2).
13. BO: for each client trade, receive SSI matching status from custodian (T+0, T+1, T+2) and tag the match status of trades.
14. BO: settle the client trade on T+3 if SSI matches. Or allow the client trades to be settled manually.
15. BO: post to general ledger for financial movements on trade settle event (T+3).
16. BO: generate cash/stock position reports for credit control.
17. BO: generate various regulatory or reconciliation reports.

Three other systems to support the FO/MO/BO systems.

1. Instrument Database:
   • to host the instrument ids and descriptions on each market
     • FO and BO have different requirements on the ids of instruments. e.g. FO use trade symbols which are mostly known as localcode, ticker or viewcodes; and BO needs ISIN, RIC, BBG, SEDOL, etc for various reporting purpose.
     • Different markets have different data model. e.g. JP/US/IN/DE has multi-listed model, where same instrument can be traded on different exchange with the same ticker, but different RIC code. An agency business needs to decide in what granularity it wants to use the data and store them in FO/BO systems.
   • to provide price information
     • FO generally needs real-time price feed.
     • BO generally needs EOD closing price for credit control.
   • to provide market information
     • One country has multiple markets, sharing the same trading calendar.
     • One country has multiple market with different trading calendar.
     • Trading calendar are different from settlement calendar.
2. Client Database:
   • to host the client information
     • each client has a organizational-level account (parent account).
     • each client can have one or more fund-level accounts (sub account).
     • details for allocation channel for each client (Tel, OASYS).
     • client confirmation details at organizational-level and/or fund-level, such as address, tel, representative, fax, email, etc.
     • SSI information for each client at organization/fund level, with different delivery channel, e.g. SWIFT, EUCLID, etc.
   • to host entity calculation model
     • For global brokerage business with multiple entities setup in different markets, under different regulatory rules would have to model a client trade into multiple intra-company trades. The entity model should be setup to support the auto-calculation of such intra-company chains.
   • to host charge calculation model to automate below feature:
     • client based commission
     • market specific charges
     • intra-company cash flows
3. Middle-ware:
   • to link all the above systems via file transfer, messaging, database inserting/updating.