You are here

Trade and Contract Status Tracking

Submitted by greggles on Tue, 01/08/2008 - 08:00

I need to track trade status. Here's what I said about it briefly in my last post:

Trades can be in multiple states. At least initially we'll need "open", "canceled", "executed", and "invalid". I'm trying to figure out a good system for this. Trade status values must be exclusive - an order can't be open and canceled at the same time. I could use the taxonomy system. I could use nodequeue, workflow, or workflow "next generation". While I like nodequeue a lot, it has the drawback of not enforcing exclusivity, so that might remove it from the running. Workflow and WorkflowNG are both big scary modules to me. Taxonomy is nice and well tested, but of course lacks some features that Workflow/WorkflowNG have.

The other part I forgot about in that discussion was contract status. Contracts can also be in a couple states: "pre-launch", "available for trading", "closed", and "expired" are the first that pop up. I don't know if I really want more granular or less granular. Right now that's all I can think of.

In more detail:

Status Tracking

A trade can only have one status at a time. The status must be easily queried. Orders also need to be ordered in each status pool by the price and by date/time they were entered.

Workflow could be nice

It might be nice to have them based on a workflow module so that actions could be associated with the movement from one status to another.

Views Integration

I think it will be handy to let views create some reports to slice and dice my trades based on status values (among other things) so I need that.

Permissions and flow on State Changes

In general, things can only flow in one direction and the state changes from one to the next are quite defined:

  • Everything starts out open when the user submits it - validation at creation time makes sure that it's valid.
  • If a user cancels their trade, it can't be uncanceled - only the owner or an admin should be able to cancel trades
  • If the user runs out of money or something, the system (or an admin) could mark a trade as invalid and ideally there should be a log of why that happened - maybe in the core revision log system.
  • If the trade is valid and matched then the system or an admin should be able to mark it as executed

There needs to be protection (ideally in the status system itself) to prevent a scenario where the user is viewing a trade and has a button for "cancel" on their screen, they wait a few seconds, meanwhile the trade is executed by the system, and then the user clicks cancel which is now an invalid operation.

Usual Module Caveats Apply

It should be actively maintained, well coded, play well with others, etc.

So, what meets those goals?


But an important consideration here is that "matching" must be one of the most scalable functions in any trading system. We need to check if that module adds overhead for the task at hand and how much. Nothing really new here, as matching has been implemented so many times already, with all the exchanges around the world. If the PM module shall grow with time, there should also be flexibility in the work-flow for necessary order types. For a start, just the usual: market, limit, stop-loss, OCO. Conditional may be worth a thought as it adds a first stage.

Add new comment

Filtered HTML

  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link]( "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <h3> <blockquote>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.