OMS/Photon related questions

[markdb]

Dear Marketcetera-team,

I've downloaded the Marketcetera software the other day and would like to compliment you with this achievement. Very interesting stuff!

Having played around with the platform I have some ideas and questions I would like to share with you. I´d be very interested in your thoughts on this.

Authorisation structure and audit trail – To be truly useful in even a  small-size trading operation there would need to be a way of tracking who entered orders, cancelled orders, amended orders, etc. in the client (Photon) or into the OMS directly. At the Photon level this would enable workflow (e.g. merging orders on other traders' blotters,  crossing with orders on other traders' blotters, routing orders to traders working on a similar name, approving orders (4-eyes principle), etc.). Do you have any plans in this direction?

Trade Blotter – I think there should be more elaborate blotter functionality which would present the traders' orders in a structured way (e.g. New orders, open orders, filled orders,  not acknowledged orders,  acknowledged orders, rejected orders, baskets of orders, etc.) and would support basic order workflow (e.g. creating, cancelling, deleting, merging, crossing, allocating orders, creating list orders, etc.). As I understand it the Photon client only provides for sending and receiving FIX messages via a queue and keeping track of the orders generated in a specific session only. Once Photon is closed down that session is lost and corresponding orders would only be visible in Tradebase. This could prove troublesome in case of a crash or in a done-for-day scenario. Have you already considered this functionality?

Block trading – What are your ideas/plans around block trading? Placing a single order across multiple accounts and allocating according to some model (e.g. pro-rata, % weighting). I guess this would primarily be Photon functionality leading to allocation FIX messages being passed through the OMS.

Program trading/FIX list orders – What are your ideas around supporting this functionality in both the OMS and the Photon client?

Security master file – Have you got clearly defined ideas on the amount of security data (identifiers, place of listing, dividends, vwap, bid/mid/ask prices, etc.) you will want to store? I imagine that in a pure OMS sense you could get by only by storing a very limited amount of attributes, however, if the idea is to branch out into other areas (e.g. risk, options, post-trade) and more data attributes would be required.

Certification – What are your thoughts with respect to certification of the platform with brokers, portfolio management systems and execution management systems? This would prove beneficial in ´selling´ the platform and deployment 'out of the box'.

These are some first thoughts after having played around with the system for a couple of hours and going through documentation on your site. Again, very much interested in your comments.

Regards,
Mark de Brauw

[Rick Labs-2]

In his post to m-etc-users Mark de Brauw makes many excellent suggestions. Using those I'll just add a few comments.

* Authorization - no doubt about it you need a comprehensive authorization scheme based on roles (portfolio manager, trader, trader assistant, auditor, SEC type outside regulator, accountant).  See below article.
* Audit trail - ever look at a brokerage statement and see a journal entry, then a reverse of a journal entry? A mistake and then a correction? This is the heart of full an audit trail - every action gets recorded on an indelible journal. No ability for anyone to go back and erase or change entries like in QuickBooks. This area must be rock solid - no back door ability to change the actual record of what happened, or change the sequence of events.  
* Trade Blotter - best way to see this functionality is to look at several commercial systems. Some have a way to take trade blotter orders and drag and drop them on execution venues. That pops up a pre filled out order to that destination.
* Rebuild/Resync on disconnect - "Once Photon is closed down that session is lost and corresponding orders would only be visible in Tradebase. This could prove troublesome in case of a crash or in a done-for-day scenario." I'm not sure how you are implementing, but one way is when a connection is lost all open orders on the other end are immediately canceled. Then you need a way on the client end to rebuild everything when the connection comes back on line. The other area is in Fills. As you are getting back fills if the system goes down you need a way to quickly catch up and resynchronize position information and what fills have actually occurred.
* Security master file  - I did a write up on this a couple of years ago. At that time ISO had the best stuff. See: http://www.itsdoc.org/wiki/tiki-index.php?page=ISO+19312 Take a good long look at that chart. I'm not sure of the status of 19321 however that chart is pretty darn good. If you architect with all that in mind, yet implement only what you need, you should be in great shape.
* Certification - While Fix is a "standard" there are many "flavors" (reminds me of the days of RS-232/DB25 connections). What you really need is a demo environment that's as realistic as possible. Marketcetera should consider supplying a demo environment over the Internet. Use something like Interactive Brokers gateway (http://www.interactivebrokers.com/download/newMark/PDFs/gateway.pdf)  to let Marketcetra testers hook up to you and test things out. You let users of Marketcetra software connect back to you into the safe demo environment and "play around" to build confidence in it. On the "server" end this is very standard FIX environment. The trick here is to allow users to do whatever they want (insuring wide deployment) but to limit the required "certification" steps. Once the Marketcetera "home office" server side demo system is stable, get that certified with a few major broker dealers (perhaps starting with Interactive Brokers). After that further certification should be relatively easy (until you get into different FIX versions, non standard securities traded, FIX service packs, FIX extension packs, the new algo order standard, etc.) Every major broker has three systems: live production, demo (for customers) and development. You don't need the live production environment but you will have an ongoing need for separate demo and development environments.
* Complexity - In all of the above there is a risk that you create too large and complex a system. Here is a good philosophy to follow: http://www.itsdoc.org/wiki/tiki-index.php?page=One. Architect to allow functionality and formal security in a multi person environment. However don't loose sight of the large audience that can use (and debug) your system with just a single person using it. Don't make it like SAP where you need 20 people all at their CRT's in the AM just to turn the thing on in the morning.


Rick

*Richard J. Labs, CPA, CFA
*CL&B Capital Management, LLC
*7583 Hunt Lane
*Fayetteville, NY 13066-2554
*315-637-0915x11
*[hidden email]

How was Nick Leason able to use all the money in the bank? Was there no limit switch?
Best Answer - Chosen by Asker

Arbitrage was made famous in the movie "Rogue Trader" in which Nick Leeson supposedly made his millions through arbitrage of the Nikkei futures index between Singapore and UK exchanges, in the process ruining Barings plc. He was confined for nine months in Frankfurt prison and upon extradition, sentenced to six and a half years by the High Court of Singapore for forgery and cheating.

The main flaws point towards a failure in the lack of segregation of duties in financial and operational controls supported by the connivance of over confident authorities who considered trading of this nature to be of low risk.

Leeson acted as general manager, head trader and de facto head of the back office which constitutes a breach in segregation of duties. [Roles management]

The idea behind segregation of duties is to prevent any one person abusing a position of authority enabling ultimate control and knowledge of specific operations at any one time.

Where a lack of segregation of duties exist, the person making the buy and sell decisions does so at their own discretion. Normal circumstances require prior checks and balances by different hierarchical authorities to reduce likelihood of bad decisions, which are based on Management's plan and approval.

In practice, traders sometimes act on speculation without prior authorization due to the fast paced nature of the job. Most are able to cover their tracks of small losses hidden against larger gains. Usually, neither the trader nor his employer has any interest in publicizing the incident unless they are blatantly caught and the amount is significant to jeopardize the company.

Smaller losses of few tens of thousands can be easily recouped in as little as one to three days, hence small looses can be hidden in the larger gains. Some speculate that Leeson was most unlucky trader in history chalking up an streak of accumulated losses of two billion dollars.

Without an oversight, Leeson was able to transact unauthorised derivatives (futures) at off-market prices and hide losses in the 88888 account which he falsified.

When debts fell due and payable, he was similarly able to making misrepresentations to secure funds from companies within the Barings organization and mislead clients into lending funds.

With the losses hidden, he was able to reveal his other card hand that boasted gigantic profits adding an aura of unquestionably to his status as lead trader.

This in turn affects the effectiveness of audits that are based on voluntary full financial disclosures by the Client. In a sense, Leeson was the end of the audit paper trail as far as decision making was concerned; effectively the whole process controlled by one person, the skies your limit.
Source(s):
News
http://www.bbc.co.uk/crime/caseclosed/ni...
http://www.abc.net.au/7.30/content/2004/...
http://news.bbc.co.uk/1/hi/business/1803...
http://www.nickleeson.com/

Option Arbitrage involves the simultaneous buying and selling of options between exchanges or the same exchange. Some options strategies include: strike, calendar, intra-market, conversions, boxes, straddles.

Early assignment may be exercised of any in the money options for all American Style Exercise Options (exercise before expiration) and dividend liability exists on any exercised short puts during dividend dates. It was the simplest and deemed least risky which fraud was able to transpire.

"I was astonished that nobody stopped me. People in London should have known that I was making up the numbers..... My numbers were hopelessly out of orbit, yet nobody stopped me." - p. 33, 177, Nick Leeson, 'Rogue Trader.'


_______________________________________________
m-etc-users mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[gm-mrktc]

Some javascript/style in this post has been disabled (why?)

Mark,
First, let me say, thanks so much for the feedback and encouragement.  You have brought up a number of important issues.  Please see my comments inline below.

On 4/29/07, mdebrauw <[hidden email]> wrote:

...

Authorisation structure and audit trail – To be truly useful in even a
small-size trading operation there would need to be a way of tracking who
entered orders, cancelled orders, amended orders, etc. in the client
(Photon) or into the OMS directly. At the Photon level this would enable
workflow (e.g. merging orders on other traders' blotters,  crossing with
orders on other traders' blotters, routing orders to traders working on a
similar name, approving orders (4-eyes principle), etc.). Do you have any
plans in this direction?

Let me tease these apart a little bit.  The first step in supporting all of the features you mention here is a robust authentication/authorization framework.  Our current plan is to add a JAAS support to the Marketcetera platform as of version 0.4, though we are certainly open to other technologies, if you have other suggestions.  I have added a RFE to track progress on this step ( http://trac.marketcetera.org/trac.fcgi/ticket/208 ).  This will enable simple audit actions, such as auditing orders, cancels, replaces, as you mention.

The next piece is a set of workflows built on top of this new concept of separate users and roles. Most likely, we will depend on the specific needs of our users and customers to define and prioritize these.  Could you give us some indication as to which of these are most important to you?  And maybe you could flesh out a little bit more the requirements for the most important ones.  Feel free to add RFE's for these workflows in Trac ( http://trac.marketcetera.org/ ).

Trade Blotter – I think there should be more elaborate blotter functionality
which would present the traders' orders in a structured way ( e.g. New
orders, open orders, filled orders,  not acknowledged orders,  acknowledged
orders, rejected orders, baskets of orders, etc.)

Some of this is available in the "FIX Messages", "Average Price", "Fills", and "Open Orders" views inside of Photon.  Would adding an arbitrary filter on the FIX Messages view make these actions more flexible?  For example being able to filter for all the CancelReject messages?
 

and would support basic
order workflow (e.g. creating, cancelling, deleting, merging, crossing,
allocating orders, creating list orders, etc.). As I understand it the
Photon client only provides for sending and receiving FIX messages via a
queue and keeping track of the orders generated in a specific session only.

Once Photon is closed down that session is lost and corresponding orders
would only be visible in Tradebase. This could prove troublesome in case of
a crash or in a done-for-day scenario. Have you already considered this
functionality?

We have, but I have specifically just added an RFE in trac to monitor progress. http://trac.marketcetera.org/trac.fcgi/ticket/209   We would love it if you could comment.

 

Block trading – What are your ideas/plans around block trading? Placing a
single order across multiple accounts and allocating according to some model
(e.g. pro-rata, % weighting). I guess this would primarily be Photon
functionality leading to allocation FIX messages being passed through the
OMS.

Certainly we could support this message flow between Photon and the OMS, which would cause allocations to occur in the Tradebase.  However I think maybe to make this functionality really useful would also require the cooperation of your broker.  To date we have only engaged in FIX-based interaction with brokers and brokerage groups inside larger financial institutions.  The FIX implementation guides we get from these groups often indicate no support for post-trade allocation messages, nor fields like AllocAccount.  If your experience has been different we would love to hear about it.
 

Program trading/FIX list orders – What are your ideas around supporting this
functionality in both the OMS and the Photon client?

I have always thought that basket-related features would be useful and straightforward to implement.  Once again, I think there may be a brokerage-support issue here.  Could you let us know if you have FIX connections that allow list orders? 
 

Security master file – Have you got clearly defined ideas on the amount of
security data (identifiers, place of listing, dividends, vwap, bid/mid/ask
prices, etc.) you will want to store? I imagine that in a pure OMS sense you
could get by only by storing a very limited amount of attributes, however,
if the idea is to branch out into other areas (e.g. risk, options,
post-trade) and more data attributes would be required.

Certification – What are your thoughts with respect to certification of the
platform with brokers, portfolio management systems and execution management
systems? This would prove beneficial in ´selling´ the platform and
deployment 'out of the box'.

We are currently undergoing certification with a number of brokers as we speak, and we will publish as much of the results as we are allowed.  Additionally we would love to be able to include broker-specific adapters in our product that describe the particular dialect of FIX used by each broker's FIX servers, though again we may be restricted in what we can openly distribute.  If you have a particular broker that you would like to use Marketcetera with, please let us know and we will work to get a certification done as soon as possible.

These are some first thoughts after having played around with the system for
a couple of hours and going through documentation on your site. Again, very
much interested in your comments.

Thanks very much!

graham

--
Marketcetera Trading Platform
download.run.trade.
www.marketcetera.org
_______________________________________________
m-etc-users mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[Grigory Kagan]

Some javascript/style in this post has been disabled (why?)

Craham/Mark

Adding my 2 cents,

 

I see priority #1 in adding Security and Audit Trail to the system.

In respect to Allocations (pre- and post-trade), unfortunately most of the trading solutions do not support such feature;

 

Mark,

Please comment, If there is a way to utilize marketcetera  to process Allocations via FIX drop copy feed?

 

Thank You,

 

On 4/30/07, Graham Miller <[hidden email]> wrote:

Mark,
First, let me say, thanks so much for the feedback and encouragement.  You have brought up a number of important issues.  Please see my comments inline below.

On 4/29/07, mdebrauw <[hidden email]> wrote:

...

Authorisation structure and audit trail – To be truly useful in even a
small-size trading operation there would need to be a way of tracking who
entered orders, cancelled orders, amended orders, etc. in the client
(Photon) or into the OMS directly. At the Photon level this would enable
workflow (e.g. merging orders on other traders' blotters,  crossing with
orders on other traders' blotters, routing orders to traders working on a
similar name, approving orders (4-eyes principle), etc.). Do you have any
plans in this direction?

Let me tease these apart a little bit.  The first step in supporting all of the features you mention here is a robust authentication/authorization framework.  Our current plan is to add a JAAS support to the Marketcetera platform as of version 0.4, though we are certainly open to other technologies, if you have other suggestions.  I have added a RFE to track progress on this step ( http://trac.marketcetera.org/trac.fcgi/ticket/208 ).  This will enable simple audit actions, such as auditing orders, cancels, replaces, as you mention.

The next piece is a set of workflows built on top of this new concept of separate users and roles. Most likely, we will depend on the specific needs of our users and customers to define and prioritize these.  Could you give us some indication as to which of these are most important to you?  And maybe you could flesh out a little bit more the requirements for the most important ones.  Feel free to add RFE's for these workflows in Trac ( http://trac.marketcetera.org/ ).

 

Trade Blotter – I think there should be more elaborate blotter functionality
which would present the traders' orders in a structured way ( e.g. New
orders, open orders, filled orders,  not acknowledged orders,  acknowledged
orders, rejected orders, baskets of orders, etc.)

Some of this is available in the "FIX Messages", "Average Price", "Fills", and "Open Orders" views inside of Photon.  Would adding an arbitrary filter on the FIX Messages view make these actions more flexible?  For example being able to filter for all the CancelReject messages?
 

and would support basic
order workflow (e.g. creating, cancelling, deleting, merging, crossing,
allocating orders, creating list orders, etc.). As I understand it the
Photon client only provides for sending and receiving FIX messages via a
queue and keeping track of the orders generated in a specific session only.

Once Photon is closed down that session is lost and corresponding orders
would only be visible in Tradebase. This could prove troublesome in case of
a crash or in a done-for-day scenario. Have you already considered this
functionality?

We have, but I have specifically just added an RFE in trac to monitor progress. http://trac.marketcetera.org/trac.fcgi/ticket/209   We would love it if you could comment.
 

 

Block trading – What are your ideas/plans around block trading? Placing a
single order across multiple accounts and allocating according to some model
(e.g. pro-rata, % weighting). I guess this would primarily be Photon
functionality leading to allocation FIX messages being passed through the
OMS.

Certainly we could support this message flow between Photon and the OMS, which would cause allocations to occur in the Tradebase.  However I think maybe to make this functionality really useful would also require the cooperation of your broker.  To date we have only engaged in FIX-based interaction with brokers and brokerage groups inside larger financial institutions.  The FIX implementation guides we get from these groups often indicate no support for post-trade allocation messages, nor fields like AllocAccount.  If your experience has been different we would love to hear about it.
 

Program trading/FIX list orders – What are your ideas around supporting this
functionality in both the OMS and the Photon client?

I have always thought that basket-related features would be useful and straightforward to implement.  Once again, I think there may be a brokerage-support issue here.  Could you let us know if you have FIX connections that allow list orders? 
 

Security master file – Have you got clearly defined ideas on the amount of
security data (identifiers, place of listing, dividends, vwap, bid/mid/ask
prices, etc.) you will want to store? I imagine that in a pure OMS sense you
could get by only by storing a very limited amount of attributes, however,
if the idea is to branch out into other areas (e.g. risk, options,
post-trade) and more data attributes would be required.

Certification – What are your thoughts with respect to certification of the
platform with brokers, portfolio management systems and execution management
systems? This would prove beneficial in ´selling´ the platform and
deployment 'out of the box'.

We are currently undergoing certification with a number of brokers as we speak, and we will publish as much of the results as we are allowed.  Additionally we would love to be able to include broker-specific adapters in our product that describe the particular dialect of FIX used by each broker's FIX servers, though again we may be restricted in what we can openly distribute.  If you have a particular broker that you would like to use Marketcetera with, please let us know and we will work to get a certification done as soon as possible.


 

These are some first thoughts after having played around with the system for
a couple of hours and going through documentation on your site. Again, very
much interested in your comments.

Thanks very much!
 

 

graham

--
Marketcetera Trading Platform
download.run.trade.
www.marketcetera.org
_______________________________________________
m-etc-users mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

_______________________________________________
m-etc-users mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[markdb]

Grigory, Graham,

On the specific topic of allocations:

I agree with Graham that the uptake of allocation message flow will be more likely dictated by brokers starting offering this functionality to their clients.  My experience is no different than what you describe.

However, being able to execute block orders across multiple accounts would certainly be part of the requirements of a typical institutional investor. By doing this via allocation messages into Tradebase, as Graham suggests, you add an important feature to the platform and prepare for the future where you would actually be able to send allocations to the broker directly.

I think this would be worthwhile putting on the roadmap, not sure about priority. I will give it some more thought and maybe submit an RFE.

Rgds, Mark

Grigory Kagan wrote:

Craham/Mark
Adding my 2 cents,

I see priority #1 in adding Security and Audit Trail to the system.
In respect to Allocations (pre- and post-trade), unfortunately most of
the trading solutions do not support such feature;

Mark,
Please comment, If there is a way to utilize *marketcetera*  to process
Allocations via FIX drop copy feed?

Thank You,


On 4/30/07, Graham Miller <[e-mail]> wrote:
>
> Mark,
> First, let me say, thanks so much for the feedback and encouragement.  You
> have brought up a number of important issues.  Please see my comments inline
> below.
>
> On 4/29/07, mdebrauw < [e-mail]> wrote:
> >
> >
> > ...
> >
> > Authorisation structure and audit trail – To be truly useful in even a
> > small-size trading operation there would need to be a way of tracking
> > who
> > entered orders, cancelled orders, amended orders, etc. in the client
> > (Photon) or into the OMS directly. At the Photon level this would enable
> > workflow (e.g. merging orders on other traders' blotters,  crossing with
> > orders on other traders' blotters, routing orders to traders working on
> > a
> > similar name, approving orders (4-eyes principle), etc.). Do you have
> > any
> > plans in this direction?
>
>
> Let me tease these apart a little bit.  The first step in supporting all
> of the features you mention here is a robust authentication/authorization
> framework.  Our current plan is to add a JAAS support to the Marketcetera
> platform as of version 0.4, though we are certainly open to other
> technologies, if you have other suggestions.  I have added a RFE to track
> progress on this step ( http://trac.marketcetera.org/trac.fcgi/ticket/208 ).
> This will enable simple audit actions, such as auditing orders, cancels,
> replaces, as you mention.
>
> The next piece is a set of workflows built on top of this new concept of
> separate users and roles. Most likely, we will depend on the specific needs
> of our users and customers to define and prioritize these.  Could you give
> us some indication as to which of these are most important to you?  And
> maybe you could flesh out a little bit more the requirements for the most
> important ones.  Feel free to add RFE's for these workflows in Trac (
> http://trac.marketcetera.org/ ).
>
>
>
> > Trade Blotter – I think there should be more elaborate blotter
> > functionality
> > which would present the traders' orders in a structured way ( e.g. New
> > orders, open orders, filled orders,  not acknowledged
> > orders,  acknowledged
> > orders, rejected orders, baskets of orders, etc.)
>
> Some of this is available in the "FIX Messages", "Average Price", "Fills",
> and "Open Orders" views inside of Photon.  Would adding an arbitrary filter
> on the FIX Messages view make these actions more flexible?  For example
> being able to filter for all the CancelReject messages?
>
>
> and would support basic
> > order workflow (e.g. creating, cancelling, deleting, merging, crossing,
> > allocating orders, creating list orders, etc.). As I understand it the
> > Photon client only provides for sending and receiving FIX messages via a
> > queue and keeping track of the orders generated in a specific session
> > only.
>
> Once Photon is closed down that session is lost and corresponding orders
> > would only be visible in Tradebase. This could prove troublesome in case
> > of
> > a crash or in a done-for-day scenario. Have you already considered this
> > functionality?
>
>
> We have, but I have specifically just added an RFE in trac to monitor
> progress. http://trac.marketcetera.org/trac.fcgi/ticket/209   We would
> love it if you could comment.
>
>
>
>
>
>
> Block trading – What are your ideas/plans around block trading? Placing a
> > single order across multiple accounts and allocating according to some
> > model
> > (e.g. pro-rata, % weighting). I guess this would primarily be Photon
> > functionality leading to allocation FIX messages being passed through
> > the
> > OMS.
>
>
> Certainly we could support this message flow between Photon and the OMS,
> which would cause allocations to occur in the Tradebase.  However I think
> maybe to make this functionality really useful would also require the
> cooperation of your broker.  To date we have only engaged in FIX-based
> interaction with brokers and brokerage groups inside larger financial
> institutions.  The FIX implementation guides we get from these groups often
> indicate no support for post-trade allocation messages, nor fields like
> AllocAccount.  If your experience has been different we would love to hear
> about it.
>
>
> Program trading/FIX list orders – What are your ideas around supporting
> > this
> > functionality in both the OMS and the Photon client?
>
> I have always thought that basket-related features would be useful and
> straightforward to implement.  Once again, I think there may be a
> brokerage-support issue here.  Could you let us know if you have FIX
> connections that allow list orders?
>
>
> Security master file – Have you got clearly defined ideas on the amount of
> > security data (identifiers, place of listing, dividends, vwap,
> > bid/mid/ask
> > prices, etc.) you will want to store? I imagine that in a pure OMS sense
> > you
> > could get by only by storing a very limited amount of attributes,
> > however,
> > if the idea is to branch out into other areas (e.g. risk, options,
> > post-trade) and more data attributes would be required.
> >
> > Certification – What are your thoughts with respect to certification of
> > the
> > platform with brokers, portfolio management systems and execution
> > management
> > systems? This would prove beneficial in ´selling´ the platform and
> > deployment 'out of the box'.
>
> We are currently undergoing certification with a number of brokers as we
> speak, and we will publish as much of the results as we are allowed.
> Additionally we would love to be able to include broker-specific adapters in
> our product that describe the particular dialect of FIX used by each
> broker's FIX servers, though again we may be restricted in what we can
> openly distribute.  If you have a particular broker that you would like to
> use Marketcetera with, please let us know and we will work to get a
> certification done as soon as possible.
>
>
>
>
>
> These are some first thoughts after having played around with the system
> > for
> > a couple of hours and going through documentation on your site. Again,
> > very
> > much interested in your comments.
>
>
> Thanks very much!
>
>
>
>
> graham
>
> --
> Marketcetera Trading Platform
> download.run.trade.
> www.marketcetera.org
> _______________________________________________
> m-etc-users mailing list
> [e-mail]
> http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users
>
>

_______________________________________________
m-etc-users mailing list
[e-mail]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[markdb]

Graham,

I've added some further comments inline:

Rgds, Mark

gm-mrktc wrote:

Mark,
First, let me say, thanks so much for the feedback and encouragement.  You
have brought up a number of important issues.  Please see my comments inline
below.

On 4/29/07, mdebrauw < [e-mail]> wrote:
>
>
> ...
>
> Authorisation structure and audit trail – To be truly useful in even a
> small-size trading operation there would need to be a way of tracking who
> entered orders, cancelled orders, amended orders, etc. in the client
> (Photon) or into the OMS directly. At the Photon level this would enable
> workflow (e.g. merging orders on other traders' blotters,  crossing with
> orders on other traders' blotters, routing orders to traders working on a
> similar name, approving orders (4-eyes principle), etc.). Do you have any
> plans in this direction?


Let me tease these apart a little bit.  The first step in supporting all of
the features you mention here is a robust authentication/authorization
framework.  Our current plan is to add a JAAS support to the Marketcetera
platform as of version 0.4, though we are certainly open to other
technologies, if you have other suggestions.  I have added a RFE to track
progress on this step (
http://trac.marketcetera.org/trac.fcgi/ticket/208).  This will enable
simple audit actions, such as auditing orders, cancels,
replaces, as you mention.

The next piece is a set of workflows built on top of this new concept of
separate users and roles. Most likely, we will depend on the specific needs
of our users and customers to define and prioritize these.  Could you give
us some indication as to which of these are most important to you?  And
maybe you could flesh out a little bit more the requirements for the most
important ones.  Feel free to add RFE's for these workflows in Trac (
http://trac.marketcetera.org/ ).

http://www.nabble.com/forum/ViewPost.jtp?post=10445063&framed=y
I think this important to work on. I will try to free up some time to work on some basic concepts. The basic structure would look like this:

- Portfolio Management
- Trading
- Mid/Back Office

Segregation of duties is important between these groups.
 
Photon:
Traders should never enter orders by themselves, these should originate from portfolio managers. Maybe front office personnel should not be able to create new securities. Support for round trips to a compliance system would require some sort of intermediate step between generating the order and releasing it to the traders. Etc. etc.

Tradebase:
Maybe there should be a seperation of who sees what in tradebase. Some portfolio managers should not be able to view other portfolios. Only back office personnel should be authorised to add new accounts, market data, positions, trades (corrections) , etc.

OMS:http://www.nabble.com/forum/ViewPost.jtp?post=10445063&framed=y
It should not be possible for anyone to upload orders via an csv file into the system. Likewise the ActiveMQ, (via Photon and Excel Plugin) route should be guarded against unauthorised access.



Trade Blotter – I think there should be more elaborate blotter functionality
> which would present the traders' orders in a structured way ( e.g. New
> orders, open orders, filled orders,  not acknowledged
> orders,  acknowledged
> orders, rejected orders, baskets of orders, etc.)

Some of this is available in the "FIX Messages", "Average Price", "Fills",
and "Open Orders" views inside of Photon.  Would adding an arbitrary filter
on the FIX Messages view make these actions more flexible?  For example
being able to filter for all the CancelReject messages?

 
I guess that would be a good start. Not sure about priority, though. My feeling is all the functionality is indeed there but is scattered across various windows. Pulling everything together into one logical tool for the trader would add in usability. I will try to put some time into describing this in more functional terms maybe by knocking up some sort of prototype.


and would support basic
> order workflow (e.g. creating, cancelling, deleting, merging, crossing,
> allocating orders, creating list orders, etc.). As I understand it the
> Photon client only provides for sending and receiving FIX messages via a
> queue and keeping track of the orders generated in a specific session
> only.

Once Photon is closed down that session is lost and corresponding orders
> would only be visible in Tradebase. This could prove troublesome in case
> of
> a crash or in a done-for-day scenario. Have you already considered this
> functionality?


We have, but I have specifically just added an RFE in trac to monitor
progress. http://trac.marketcetera.org/trac.fcgi/ticket/209  We would love
it if you could comment.

Will do so.




Block trading – What are your ideas/plans around block trading? Placing a
> single order across multiple accounts and allocating according to some
> model
> (e.g. pro-rata, % weighting). I guess this would primarily be Photon
> functionality leading to allocation FIX messages being passed through the
> OMS.


Certainly we could support this message flow between Photon and the OMS,
which would cause allocations to occur in the Tradebase.  However I think
maybe to make this functionality really useful would also require the
cooperation of your broker.  To date we have only engaged in FIX-based
interaction with brokers and brokerage groups inside larger financial
institutions.  The FIX implementation guides we get from these groups often
indicate no support for post-trade allocation messages, nor fields like
AllocAccount.  If your experience has been different we would love to hear
about it.

See http://www.nabble.com/forum/ViewPost.jtp?post=10445063&framed=y

Program trading/FIX list orders – What are your ideas around supporting this
> functionality in both the OMS and the Photon client?

I have always thought that basket-related features would be useful and
straightforward to implement.  Once again, I think there may be a
brokerage-support issue here.  Could you let us know if you have FIX
connections that allow list orders?


We have quite a number of connections supporting FIXLIST messages. Even if brokers don't support the functionality it would be nice to support this functionality in the Photon client, i.e. a way to bundle a couple of orders for seperate securities and submitting them in one go. This could very well translate to seperate single orders with some sort of identification on the message identifying them as part of a program in order for the broker to route them correctly internally.


Security master file – Have you got clearly defined ideas on the amount of
> security data (identifiers, place of listing, dividends, vwap, bid/mid/ask
> prices, etc.) you will want to store? I imagine that in a pure OMS sense
> you
> could get by only by storing a very limited amount of attributes, however,
> if the idea is to branch out into other areas (e.g. risk, options,
> post-trade) and more data attributes would be required.
>
> Certification – What are your thoughts with respect to certification of
> the
> platform with brokers, portfolio management systems and execution
> management
> systems? This would prove beneficial in ´selling´ the platform and
> deployment 'out of the box'.

We are currently undergoing certification with a number of brokers as we
speak, and we will publish as much of the results as we are allowed.
Additionally we would love to be able to include broker-specific adapters in
our product that describe the particular dialect of FIX used by each
broker's FIX servers, though again we may be restricted in what we can
openly distribute.  If you have a particular broker that you would like to
use Marketcetera with, please let us know and we will work to get a
certification done as soon as possible.

I'd be interested in the results that come out of your certfication effort. We currently don't have a  requirement  for a new OMS. I am intrigued by the notion of open software pushing into the enterprise application area and as such am only a an interested party. I would like to make a contribution to this project where I can.


These are some first thoughts after having played around with the system for
>
> a couple of hours and going through documentation on your site. Again,
> very
> much interested in your comments.


Thanks very much!


graham

--
Marketcetera Trading Platform
download.run.trade.
www.marketcetera.org

_______________________________________________
m-etc-users mailing list
[e-mail]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users