Slashdot Mirror

"If NASDAQ acknowledged receiving the order but didn't confirm that the order was placed, it's entirely possible that the right thing to do was send the order again under the assumption that it didn't get filled."

Exactly, you resend with a poss resend flag on the fix message

http://fixprotocol.org/FIXimate3.0/en/FIX.4.2/tag97.html

my guess is an algo went out of control at the swiss bank.

(disclaimer, I work with FIX messaging as a day job and I used to worked for a company that is now part of OMX-NASDAQ)

I work in the industry. Stock exchanges (and futures, options etc) and investors use a variety of protocols to distribute stock prices and accept orders and there is a huge variety of middleware and endware involved.

Learn about the FIX protocol, learn about the basics of multicast binary protocols, and learn a bit about how basic stock trading works (or indeed even just namedrop all those things during an interview) and all other things being equal you should be able to get a job working on or with such software.

Some links you might find useful:

http://fixprotocol.org/
http://fixprotocol.org/fast/
http://www.moneyweek.com/tutorials

I work in the industry. Stock exchanges (and futures, options etc) and investors use a variety of protocols to distribute stock prices and accept orders and there is a huge variety of middleware and endware involved.

Learn about the FIX protocol, learn about the basics of multicast binary protocols, and learn a bit about how basic stock trading works (or indeed even just namedrop all those things during an interview) and all other things being equal you should be able to get a job working on or with such software.

Some links you might find useful:

http://fixprotocol.org/
http://fixprotocol.org/fast/
http://www.moneyweek.com/tutorials

Full disclosure - I am a founder of a startup that develops an open source automated trading platform targeted at institutional investors.

As was mentioned in above postings, there are a series of open source tools available to bootstrap your trading system development:

• QuickFIX and QuickFIX/J (I'm also a developer of QFJ project) - a C++ and Java open source implementations of the FIX protocol, the underlying standard protocol for connectivity between financial institutions. Think of it as the HTTP of finance.
• QuantLib - an open source risk analytics package
• Esper - an open source complex event processing engine
• EclipseTrader - Eclipse-based open source trading GUI that's targeted more at retail investors
• ActiveMQ and AMQP and Qpid for messaging (AMQP standard was initially contributed by JPMorgan)

And then of course there's my company Marketcetera - we build on top of a lot of the tools mentioned above and others (ActiveMQ, MySQL, Ruby on Rails, QFJ, etc) to provide the basic underlying platform that institutional traders (think quantitative hedge funds) can use to build their proprietary algorithms and start trading. After implementing a few trading systems in a row ourselves for various trading firms we realized that there was an obvious need for an open source trading platform so that people wouldn't have to reinvent the wheel and write systems from scratch every single time.

To answer the OP's question about which commercial firms use FOSS: - a lot of proprietary trading software is implemented on top of OSS - JPMorgan famously built their trading GUI [PDF] on top of Eclipse, and Progress Apama is built on top of Eclipse RCP as well.

Not surprisingly, most trading applications are very Windows-heavy (although quite a few companies have Linux clusters, and some exchanges run on Linux as well). Most of the apps that your broker will provide for you to trade with are Windows-only (such as Bloomberg, Goldman Redi, MicroHedge, etc), and a lot of the APIs available from vendors are .NET or COM components and nothing else. We implement our systems mostly in Java (including the Eclipse RCP), thought have connectors for some of the Windows-specific components.

We know that flexibility is at the heart of any powerful trading application, and we think the open-source model maximizes the ability of our users to control the application. Some think the open-source model is antithetical to the secretive finance industry, but we see it as the perfect fit.

what FOSS software do you use for financial analysis, trading, system development, and testing in a Un*x environment?

I am aware of TA-Lib, QuantLib and libraries implementing the FIX protocol to be used in commercial products and private Un*x trading applications.

Sadly, most people looking for a solid FOSS trading platform will find that they need to roll up their sleeve to get something decent working.

I have found that software in this area seems quite sparse.

Indeed. I closely monitor the FOSS community since 1998 for a trading platform. What I observed was a lot of well intended projects, but even to these days, none did reach satisfying maturity.

I think it relates to under estimation of the complexity. Most project starts with a lot of energy then goes idle because of unattainable short-term goals.

A general purpose platform will not emerge until someone put coherently together existing building blocks instead of starting yet another weak trading platform from scratch.

Example of building block is the FIX protocol. Many FIX libraries have matured. Quantlib is another solid example.

My contribution to the whole picture is TA-Lib. It is a set of functions for people who care about technical analysis (shameless plug).

\Mario

I work in the financial industry (trading) and I do not think you really know what the FIX protocol does. Take a look at their adopters, This is a stock/option trading protocol not a banking exchange protocol. http://fixprotocol.org/adopters/18

Particularly what internet protocols are you using, or equivalently how are you accessing these banks electronically? As an example: are we talking Financial Information eXchange or something different?

About two years ago I bagan using an XP style approach, or at least adopted many of the practices. Most notably Unit Tests with a Test First approach. Coded Functional Tests and Continuous Integration

To answer your questions one by one:

* the industry you are in

Financial Industry ( focusing on real-time trading application in the options, futures, and equity industries )

* the kind of project

Mostly applications that either provide infrastructure for doing electronic trading, or applications that implement particular trading strategies.

* how it was done before

The sorts of applications I would work on were often quick prototypes that were meant to exploit an opportunity in the market. This would often mean lots of shortcuts were taken because chances are the code would be thrown away anyway. Problem is that once in a while an application will become become succesful and grow out of one of these prototypes. Since little time was available for proper design, such applications generally became a maintenance nightmare as they kept growing. XP solved this problem by provideing a framework that allowed me to only design what I need when I need it, but enabled me to radically alter the design if ever necessary.

* what prompted you to make the switch to XP

I was exposed to it by some people who were working on a project at my company. I found many of the practices allowed me to create "prototypes" just as quickly as before, but with a higher degree of reliability and a framework that allowed them to grow as requirements changed. I was really sold on it when I saw how simply I was able to implement pieces of functionality that had previously just seemed more complicated.

Pair Programming gets a lot of flak. But really I fully credit it for getting me interested in these techniques. Because I generally paired with someone who knew these practices better than me, I was able to actively see the value of these practices while writing production code. It was far more of an eye opener than reading any book or article.

A lot has been said about Pair Programming that is just not true. It does NOT mean that there is one computer for every two people. Everybody has a machine. Just because you try to write all production code in pairs doesn't mean that everything is done in pairs. Also, you do not get paired up with someone like a ball an chain. Pairs switch, sometimes several times a day. Pairs are NOT assigned. If I need to write an ordermatching algorithm and I've never done it before, I'm going to try to pair with someone who has. By the time we are done with the task, we now have two people who know how to write an ordermatching algorithm. It's also untrue that one person is the designated typer while the other one just sits back and criticizes. Both people type, switching sometimes several times a minute while designing a class or method. Code is typed as a way to communicate concepts. If I want to convey the direction I think something should go, I write a little code. If the pair has another idea, he'll start tapping his ideas in the keyboard. It's a very actively collaborative process.

* how that switch work and how long it took

I haven't yet seen a project switch to an XP style process without problems, and from what I understand is that it is possible but slow. Part of the problem is that people who switch often do so from a less test-centric approach. This makes it difficult as XP is so reliant on aggressive testing to be succesful. It is also a new concept for many developers to take responsibility of some of the testing that has traditionally been soley in the domain of QA.

* and how things have been since moving to XP

Like I said, I have not been involved in a switch, but can speak about the difference I've seen between similar projects. One problem that I've solved in both a non-XP approach and an XP approach is in implementing the FIX protocol.

This protocol is relatively simple, but it is rife with various possibilities for boundry errors, off by one errors, and complicated resend logic. The big difference I found is that I never broke old logic when modifying the code. Generally when doing development, you are only testing the piece of functionality you are working on, so you get that working, but you break something else. This might not be discovered for quite some time. With an XP approach, while developing, you test everything you've ever tested. You find out immediately if your changes break old code.

Not only this, but despite the overhead of writing tests, I found functionality was implemented quicker, more reliably, and far simpler. Some of this was because I learned from previous mistakes, but primarily it was due to a different way to approach a problem.

* do you know others doing XP, if so how many

Yes. But they all do it a little differently. I have not seen two XP projects that look exactly the same. The core value I always see is the emphasis on repeatable tests.