What is algorithmic trading

To start with it may be useful to quickly describe the concept of trading. Briefly trading (used in this context) typically involves clients that want to buy or sell a security, cash, or commodity. The client would typically interact with a broker or with the sales arm of an investment bank to obtain the security. The broker / sales person then interacts with a trader. The trader is responsible for pricing instrument and actually executing the trade.

Trading is usually split into electronic and voice trading. Where voice trading is performed over a telephone and electronic trading using a computer to place and confirm trades. Firms such as Bloomberg, Tradeweb, and Reuters are often used to provide a platform for clients and traders to meet and exchange electronic messages to support trading activity. Exchanges such as LSE, NYSE, CME, etc. are also used for electronic trading, but these exchanges are further restricted to members that are allowed to trade, as such it is trader-trader market place.

High frequency algorithmic trading is typically performed against exchanges. The basic idea behind this form of trading is that you spot trends in the market and by being faster then the other market participants are able take advantage of opportunity. The HF trading algo is also often used to support efficient hedging of internal trade positions build up by customer trades. In HF trading success or failure is often determined by the latency of the algorithm in making trading decisions and updating prices. Typically latencies in this space is measure in the order of micro-seconds and as such most of the software developed in this space is written in C++ and the use of custom silicon to perform actions such as processing market data and timing is standard fare. It is also a requirement to be co-located with the exchange you are trading on. This involves placing the hardware and software in specially designed data-centres that are directly connected with the exchange, thus eliminating as much of the delay that would be incurred by additional network connections.

There is also the longer lived algorithmic trading that is used to more efficiently place trades. This style of trading is not based on super low latencies such as that required by HFT algo's, but is more about implementing trading strategies that can more efficiently place trades and hedge positions. An example of this style of trading is found the world of equities where clients wish to purchase a large amount of a particular stock, if the trader just placed a single large order it is unlikely there would be sufficient liquidity to immediately fill the order, and even if there were, liquidity is provided in tranches at different prices. The more that you attempt to obtain in a single go, the more you pay. So a better strategy would be to place a large number of small order over a period of time. This has risk in that if the market were to guess there was a large buyer in the market the price is likely to rise and so an algo is used to attempt to place trades in a such a way as to minimise the price paid for the trade and to place trades in such a way as to minimise the foot print in the market so as not to artificially raise prices whilst attempting to fill the order.

Set Oriented Databases

Forget Object Databases, the future is SODS. For the unwashed masses who haven't even managed to get passed Relational Databases. You can move out of the dark ages of databases and move directly to the 21st century.

What is a SOD you may be asking yourself, well here is a light weight introduction:

What is a Set Oriented Database

What is a Set

The notion of set used in this document is based on the notion of a set described by Set theory (or number theory). The basic notion of a set is a construct existing in a world where:

There exists operators equality (=) and element of (∈). Equality allows for us to determine is one set is considered the same as another. The element of operator determines whether or not a value is an member of the set.

Sets are uniquely determined by their elements, that is if set A and B are equal (A = B), then there members are the same, or A = B ⇔ ( x ∈ A ⇔ x ∈ B ).

There exists a unique set, called the empty set. In set theory this is the building block of all sets. The empty set is represented as ∅. In our world we simplify things slightly and allow for sets that have members which do not practically resolve to the empty set, for example the set of integers. There is a mapping in set theory of the integers to the empty set, However, the need to support this decomposition seems irrelevant for practical purposes.

A set, with its members, is represented as A = { a1, a2, …, an }

The members of a set are unordered, and unique. That is { a1, a2, a3 } = { a2, a1, a3 } (unordered), and { a1, a1 } does not exist, however, when constructing a set, a set that could be constructed by addition, i.e. {} (or the ∅) with the addition of a1 = { a1 }, then a further addition of a2 = { a1, a2 }, however if a1 = a2, this will be = { a1 } (uniqueness).

What is a Set Oriented Database (SOD)

A set oriented database is a data storage tool that is capable or performing persistent Create, Read, Update, and Delete (CRUD) operations on sets.

A relational database would be an example of a subset of a SOD (where the names have been customised to deal with the constraints imposed).

An object database would also be a subset of a SOD.