some modules of an algo trading platform - chat with YH

A few modules I know
* MM (mkt datafeed reader)
* OMS (or order book, or EMS, including exchange gateways and smart order routers.
* PP (pretrade pricer)
* BB (trade booking engine, when an execution comes back successful. BB is the main module affecting the position master DB)
* PNL (real time pnl engine),
* RR (real time risk engine)

I guess BB, PP or PNL might be absorbed into the OMS module. In some places, OMS might be the name for any real time component of
the entire system, so MM, PP, BB, PNL, RR (all real time) can all be considered part of OMS in that sense. There's a narrower
definition of OMS though, so I will just refer to that definition as the EMS (execution management system). For a micro hedge fund,
PP EMS RR may not exist, and the rest (MM BB PNL) can be manual. In contrast algo shops must automate all steps.

Where does MOM fit in? It's an enabling technology, usable in many of the functional modules above.

How does dynamic data fabric fit in? Also known as data grid or in-memory DB. There are 2 types
* generic technology, often integrating SQL, MOM technologies
* functional module with complex business logic, such as CEP engines, often tightly integrated with MM OMS PP RR

These two descriptions are not mutually exclusive. Many data grid systems include features of both. However, for simplicity, in this
write-up I treat data grid as the generic technology just like a DB or MOM.

How do reference data fit in? I guess it's just another separate service to interface with database, which in turn provide reference
data to other modules when needed?

Ref data tend to be fairly static -- update frequency would be once a few hours at most, right? It is essentially a readonly
component to the algo engine modules. Readonly means those modules don't update ref data. It's one-way dependency. In contrast, MM
is also readonly, but more dynamic. MM is the driver in an event-driven algo engine.

I feel ref data read frequency can be high, but update frequency is low. Actually, i feel the occassional update can be a
performance issue. Those dependent modules can't cache ref data if ref data can change mid-day. There are techniques to address this
issue. A fast engine must minimize DB and network access, so if ref data is provided on the network, then every read would be
costly.

Some moules are simpler, like PNL and BB so no big deal. Pricing lib is used for PP and perhaps RR, which are quantatitively
complex. MM EMS are technically challenging.

The "algo" tends to be in the MM PP EMS and RR modules

A High frequency shop also needs to assess market impact. Not sure where it fits in, perhaps the EMS

Where does STP fit in? I feel STP is largely non-realtime.

OMS in FX vs equities

OMS is often the biggest and the core module in any trading platform that supports pending orders and FIX execution.

What are the differences between an eq OMS (see the Complete Guide) and an FX OMS?

FX is fundamentally OTC and quote-driven, not order driven as listed markets are.

Q: in FX, there's no exchange making the (irrevocable) matching?

RFS ^ ESP in forex FIX protocol

ESP (Executable Streaming Price) -- executable bids and offers published for instant execution.

RFS/RFQ (RequestForStreaming/Quote) -- these quotes may not be executable.

These are all part of the standard FIX protocol for FX.

See also http://www.360t.com/cnt_trading/i-tex.php.

DB tables]FX cash trading system(any bank

Q999: database tables that are the biggest or busiest

A: see blog on Currency Tables and SymbolSourceMapping tables to compute safe crosses.
A999 from ZJW and Piroz
- Trade table,
- Order table --limit orders are pending and have a lifetime. Also, London traders often need to hand over overnight orders to NY, either mandatory stop-loss-orders or unfilled customer orders.
- A family of RFQ tables like my bidans/bidstreet/bidreq tables.
- IncomingQuote table is (according to ZJW) the biggest and busiest, but there's probably a separate table for each quote source.
- OutgoingQuote table ??
- ClientPosition table has a primary key on (ClientAcct, Currency)
- TraderPosition table is the mos interesting. Even though there could be a small number of trader accounts, I was told it's unlikely that system maintains a separate table for each account. Primary key would be (TraderAcct, Currency). In cash trading, most positions are flat i.e. closed out quickly, so there should be relatively few rows in this table. However, if base currency is USD, then a particular trader's JPY row would get a lot of concurrent updates. Since this row represents real inventory, all updates must follow strict ACID transaction rule. Possibly a bottleneck just like in bond trading.

Q: Any reference data tables

CurrencyPairDescription
CounterPartyAccount
ClientAccount
TraderAccount
FeedSource ??