Transaction Cost (Part 1)

For some time i have been researching on how to apply TCA on the strategies i am developing. Here i write some highlights on cost analysis main points, asking the educated reader forgiveness for the low level of detail. I will intend to add more color as possible keeping in mind this only but a beta of the document i want to write.

Transaction cost consists on hidden and visible costs. Hidden costs are not measurable directly but visible are.  Since transaction costs are a random process, they are estimated or forecasted from statistical analysis with all the consequences and common assumptions, first of them transaction costs have an average value as well as a standard deviation or risk, and they have meaning as well as the ergodicity assumption is valid.

• Visible Costs
  • Taxes
  • commission Cost
  • Fees (Exchanges, infrastructure, etc)
  • Spread Cost
• Hidden Costs
  • Delay Cost : Drift in price from the decision is taken and the order is active in the market (mostly latency and processing time)
  • Price Appreciation: Drift in price due to external reasons
  • Market Impact Cost: Drift in price derived from the execution taking liquidity.
  • Timing Risk: Cost of extending the execution during time (i.e: Executing a 30 min TWAP instead of market)
  • Opportunity Cost

Benchmarks

Benchmarks are measures that we will use to compare statistically how well we are executing, some common benchmarks are:

TWAP :Is the  average execution price weighted by time, that’s slice your execution in equal slices, sum each slice price and then divide by number of slices.

Arrival Price :  the price that was in the market at the moment the order was placed

VWAP : Is the volume weighted average prices,  that’s the average price adjusted by liquidity.

Mean Spread: The difference between best bid and best ask prices, gives a notion of the cost of taking liquidity.

Note: It’s common for broker to provide TWAP and VWAP algos, these could either use these measures as a triggering price or intend to reach an execution as close as possible to those benchmarks. Further analysis is recommended in each case, before attempting to use thee algos in production.

Measuring Costs:

Arrival :  (Sarrival -Se) / Sarrival  [bps]

So :  (Sarrival -Se) / Sarrival  [bps]

Slast :  (Slast -Se) / Slast  [bps]

Liquidity Cost :   (Se -VWAP) / MeanSpread

Implementation Shortfall:  (SExe – PortfolioBenchmark) / SExe

Predicting Transaction Costs:

It is common to use several flavors of model for predicting transaction costs. These could be as simple as a linear system or as complicated as neural networks or other non-linear systems. The selected tool should depend on the data available for training, the expected improvement, as well as asset specific issues such as tick frequency, volatility, etc.

Bibliography

Robert Kissel & Morton Glantz, Optimal Trading Strategies : Great primer on TCA

Johnson, Algorithmic Trading  & DMA : Good overall reading, and benchmark explanation.

Almgren, R Chriss, Optimal Execution of portfolio Transactions, Must read paper on the equivalent risk return optimization for execution

Ljung, System Identification Theory for the user : Good old book in system identification (For creating cost models)

Back from long holydays

So much time have past and so much I had learnt from my last post.

After almost 10 years working in software projects in different industries, its time to share the lived experiences on the different projects and teams i was part of.

During my career i was lucky enough for participating in engineering  projects for several industries like health, space, energy and finance.

Right now i am engineering solutions for the financial industry. My work consists in implementing systematic trading models as well as engineering the required infrastructure for execute them.

In the following posts i will write on how to design and implement software for executing low-frequency trading strategies as well as how we can apply electrical engineering tools like signal processing, system identification  and control theory into the quantitative system problem.

My intend is to first describe the general architecture for executing quantitative systems, after that state which technologies and solutions are found for solving its different blocks and how to easily implement some hoping that this information will be useful for avoiding the mistakes i committed in the way as well as, from your feedback, learn to do things even better.

Patron de diseño Comando

Introducción

El patrón comando encapsula una llamada como un objeto,por lo que nos permite parametrizar distintos objetos con diferentes llamadas. Este patrón nos sirve de utilidad cuando necesitamos desacoplar el objeto que hace un determinado requerimiento de los objetos que saben como realizar los dichos requerimientos

Descripcion

 

Diagrama de Clases del Patrón Comando

• Cliente : Es el responsable de Crear un comando concreto (de hacer el new) y de establecer su Receptor.
• Receptor : El receptor es el que sabe que trabajo debe realizarse para que el requerimiento pueda ser realizado satisfactoriamente.
• Interface de Comando : Define la Interface comun para todos los comandos homegeneizando la forma de invocar los distintos comandos que puede haber un sistema
• Comando Concreto : Define el lazo entre las acciones que debe realizar el receptor para lograr un determinado requerimiento y el solicitante que pide que un determinado sea ejecutado mediante la interface de Comando
• Solicitante : El solicitante tiene acceso a un determinado comando y hace el requerimiento para que este sea realizado llamando al metodo Ejecutar() del mismo

Ejemplo

Algunas Máximas de Programación Orientada a Patrones

• Dependa de Clases Abstractas no de Clases Concretas
• Programe Orientado a Funcionalidades (Interfaces) no a implementaciones
• Encapsule lo que varia
• Las Clases deberían estar Abiertas a Extension pero cerradas a modificaciones

Multithreading en VB .NET

Que es un Thread

Un Thread se define como un camino posible de ejecucion a lo largo de un proceso. Cada proceso (programa) tiene uno o mas threads de ejecucion. Cuando se inicia una aplicacion se crea el proceso de la misma y consigo se ejecuta el thread principal a partir del entry point del mismo.

La creacion y gestión de threads en .Net se halla enmascarada bajo el namespace Threading. En particular para crear un nuevo Thread en nuestra aplicacion el framework de .Net nos provee una clase que gestiona todos los pequeños detalles del mismo, la clase Threading.Thread.

Apartments States

Cada thread de .Net tiene un apartment state, un Apartment es un conjunto de reglas coompartidas por un determinado grupo de objetos. El concepto de Apartment State viene de la transicion de los primeros windows que no soportaban multithreading y define el nivel de seguridad del thread (es decir que consideraciones tendra el sistema para acceder a los datos de los objetos que viven en dicho thread), a saber hay tres tipos de Apartment States:

• MTA Multi Thread Apartment: Los Objetos se diseñan para correr en ambientes completamente asincronicos (las variables del objeto pueden cambiar en cualquier momento de la ejecucion del programa por lo que debe sincronizarse el acceso a las mismas)
• STA Single Thread Apartment: Estos objetos estan diseñados para ejecutarse en threads unicos por lo que el acceso a sus datos debe de ser secuencial. En cada STA existira uno y solo un Thread. Las llamadas a los metodos de los objetos de un STA son sincronizados por una cola de Mensajes 
• NA Neutral Apartments: Tiene la Particularidad de que los objetos que se ejecutan en este apartment pueden ser llamados Directamente desde cualquier otro apartment. Este apartment a la diferencia de MTA y STA no tienen ningún thread sino que los objetos son ejecutados en los threads desde los que son llamados

En un programa pueden existir varios STAs pero a lo sumo un solo MTA y un NA.

Ejemplo

Ahora volviendo al tema de la creacion de los threads para crear un nuevo thread simplemente entramos las siguientes lineas:

'Declaro un variable del Tipo Thread
Dim NuevoThread As Threading.Thread
'Instancio la variable llamando al constructor que recibe como parametro la direccion del punto de entrada del thread
NuevoThread = New Threading.Thread(AddressOf CreateNewForm)
'Seteo que tipo de Apartment State Tendra el thread
NuevoThread.SetApartmentState(Threading.ApartmentState.STA)
'Inicializo el thread
NuevoThread.Start()

 
Luego de que llamamos al metodo Start() comenzara a ejecutarse un nuevo thread en el proceso que comenzara ejecutando el Metodo que le especificamos en el constructor ” New Threading.Thread(AddressOf CreateNewForm) “, en este caso el metodo sera CreateNewForm que abre un formulario nuevo que correra bajo el thread creado. El thread finalizara cuando se cierre el formulario creado

 

 
Private Sub CreateNewForm()
Dim NuevoForm As New Consola
Application.Run(NuevoForm)
End Sub
 

Introduccion a la Autogeneración de Codigo C++ Parte 1

Introducción

La autogeneración de codigo es un tema que muchas veces pensamos que se encuentra lejos de los arduos dominios del  C++. Tengo que admitir que la primera vez que me enteré del tema gracias al  Ing. Carlos Marcelo Santos ,  me causó mucha envidia ver como para los lenguajes de alto nivel existen tantas herramientas que le hacen tan sencilla y llevadera la vida a los programadores.

 Por ello es que recientemente me puse a investigar sobre el generador de codigo que generosamente Angel Lopez pone a la disposicion de la comunidad y aprovechando la versatilidad del mismo comencé a pensar una manera de poder extenderlo para poder generar codigo C++ en un principio, sinedo mi objetivo último poder generar objetos COM, extendiendo la versatilidad de ATL.

Pero antes de poder generar aplicaciones (o componentes) enteras en C++, me propuse generar el clásico de ejemplo del Kernigan´s “Hello World”, tema sobre el cual trata esta primera nota introductoria.

Dependencias

Para poder realizar el ejemplo necesitaremos del generador de codigo AjGenesis  de Angel “Java” Lopez, que se puede bajar gratuitamente desde la pagina del autor.

A su vez utilizare un herramienta que se llama NAnt(la version de .Net del clasico Ant) que nos permite automatizar tareas y que la utilizaremos para automatizar el proceso de construccion de nuestro codigo autogenerado, la misma se puede bajar de la página del proyecto.

 Una guia para la instalación y puesta en marcha de los programas necesarios para correr el proyecto se puede encontrar en el Blog de Carlos Marcelo Santos, en particular recomiendo leer los articulos:

• Como generar codigo con ajgenesis sirviendonos de nant parte 1
• Como generar codigo con ajgenesis sirviendonos de nant parte 2
• Extendiendo el modelo AjGenesis y Nant

Construyendo el Proyecto Hola Mundo

Una vez de que tenemos instalado el NAnt y el AjGenesis en nuestra PC debemos
bajar el proyecto hola mundo y descomprimirlo en alguna carpeta de nuestra computadora
a su vez debemos abrir el archivo HelloWorld.build y modificar la entrada:

...

< property name="ajgenesis.dir" value= "D:CodeGenerationAjGenesis-0.5" >

...

Por el Path Donde Tenemos instalado el AjGenesis. Luego abrimos un editor de linea de comando y dentro del directorio donde descomprimimos los archivos del proyecto Hola Mundo y Voila, el generador Automatico nos generara una carpeta Build donde podemos abrir nuestra primer Solución Autogenerada en C++, lista para compilar

Interfaces con C++

Introducción

En esta primera nota veremos el tema de la programación de interfaces en C++. Comenzaremos describiendo que es una interface en C++, luego veremos como definimos una interface en el código, y finalmente analizaremos las ventajas de este paradigma de programación.

¿Que es una Interface?

Las interfaces surgen como una evolución de la POO (programación Orientada a Objetos) ante la necesidad de reutilizar y agrupar las distintas funcionalidades de un objeto en subconjuntos mas manejables.

Debido a la creciente complejidad de los sistemas modernos cadaz vez mas los objetos (que antes necesitaban solo algunos métodos para poder definir sus funcionalidades) fueron creciendo en complejidad, hasta el punto de tornarse inmanejables por la excesiva cantidad de metodos que contenian (pensemos por ejemplo en un simple control activex que muestre una imagen segun el estado del tiempo y que se insertará en una página Web). Debida a esta creciente complejidad en los sistemas fue que surgiò la necesidad de agrupar las funcionalidades de los objetos en pequeños modulos que a su vez fuesen reutilizables por otros objetos que utilizaban otras implementaciones de la misma funcionalidad.

Podríamos decir en una definición muy casera que “una interface en terminos de c++ es una clase abstracta que encapsula los métodos que definen un cierto comportamiento de un objeto “.

Una interface es una clase abstracta, por lo tanto podemos deducir que una interface, en el sentido puro de la palabra, carece de implementacion. Es decir la implementación de los métodos de la misma estará a cargo del objeto que la contenga, lo cual es logico porque por ejemplo los métodos para dibujar un cuadrado serán muy distintos a aquellos para dibujar una imagen, pero ambos definen un mismo comportamiento por lo que en definitiva podríamos estar hablando de implementaciones distintas de un único metodo dibujar declarado una interface IDibujar.

Entonces la primer pregunta que se nos puede venir a la cabeza será, ¿no existirá alguna manera de ahorrarme de escribir la implementación de cada una de las interfaces que utilice? para solucionar este problema ya hay arquitecturas (COM,DCOM, CORBA) y librerías (ATL) que nos facilitarán enormemente el uso de de interfaces.

¿Como se define una Interface?

Una interface puede ser definida utilizando las palabras reservadas class, struct o interface. El beneficio de utilizar struct o interface es que la visibilidad por defecto de la interface será public mientras que si usamos una clase deberemos especificarlo explicitamente. Por lo tanto una manera sencilla de definir una interface sería:

/*! Interface Para Dibujar Objetos */

class IDraw {

public:

//! Metodo para Dibujar el contenedor

virtual void Draw()=0;

};

Es interesante analizar que esta pasando detrás de los bastidores cuando declaramos una interface.

Si nos remitimos a nuestras primeras lecciones de C++, recordaremos que cuando un método de una clase, es definido virtual. El compilador crea en lugar donde iría el método en memoria, un puntero (vPtr) que apunta a alguna posición de la tabla de todas las funciones virtuales del objeto vTable que finalmente contiene las direcciones de memoria de las implementaciones de todas las funciones virtuales del objeto.

Entonces para la interface IDraw definida anteriormente, la estructura en memoria de una instancia de la interface sería la siguiente:

Un dato un tanto trivial al tener en cuenta es que la palabra interface no es una palabra del lenguaje c++ sino que es un typedef de windows, para ello deberemos incluir en nuestro código el header <windows.h>. Ademas es muy importante tener en cuenta que la definición de una interface nunca trae aparejada una implementación de los metodos sino que la misma se dejará para la clase que implemente la misma.

¿Por Que Utilizar Interfaces?

Una de las principales ventajas de utilizar interfaces es el polimorfismo ya que separamos la definicion de los metodos de su implementación. Ademas cabe notar que nuestro objeto ira cobrando forma a partir de la herencia de distintas interfaces que el mismo deberá ir implementando a su debido Tiempo.

A su vez al no definir ningún tipo de implementación a priori en la definición de una interface tenemos un grado extra de aislación entre la declaración de los metodos que tendra un determinado objeto y sus implementaciones. También es de remarcar que todas las variables del objeto quedarán del lado de la implementación con lo que tendremos un grado de encapsulación extra al utilizar interfaces.

Ademas de todo esto algo muuy importante es la reutilización de codigo. Con el uso de Interfaces (mas algún truquito extra) podremos hacer que los objetos que diseñemos tengan nombres de parámetros estandarizados, lo que permite la portabilidad entre lenguajes. Es decir con el uso de Interfaces y arquitecturas como COM, COM+ podremos diseñar la parte de nuestro proyecto que requiera de procesamiento eficiente en C++ u Assembler y encapsular todas esas funcionalidades en objetos que se puedan cargar desde Visual Basic, Java , HTML o cualquier lenguaje de alto nivel y utilizar las bondades de los mismos para realizar las tareas que mejor se adaptan a ellos.

Conclusión

Hemos visto un primer pantallazo de que se tratan las interfaces y como se definen en C++. Para una segunda entrega que estaré lanzando en breve,  hablare de la arquitectura COM, del lenguaje de definicion de Interfaces MIDL (aka IDL) y de la potencia que subyace debajo de estas herramientas, un poco complicadas de entender al principio, pero que nos permitirán juntar lo mejor de los mundos de bajo y alto nivel en nuestros proyectos