The FIX Protocol: Syntax, Session and Semantics Session 1: Syntax

Conferencia de FPL para
comercialización electrónica en
América Latina 2009
Technical Stream
Presentation Guide
Sponsored by:
El Protocolo FIX: La
Sintaxis, La Sesión y La
Semántica.
Sesión 1: La Sintaxis
El Protocolo FIX: La Sintaxis, La Sesión y La
Semántica. Sesión 1: La Sintaxis
Jochen Mielke de Lima
FPL Comité de Bolsas Mundiales y Mercados
Coordinador de Interfazes de Comercio, BM&FBovespa
Jim Northey
FPL Americas co-director de comité regional,
FPL Liaison de las normas de la industria
Co-propietario, The LaSalle Technology Group, LLC
Agenda

Los Elementos Básicos de FIX
 Campos

Enumeraciónes
Mensajes
 Componentes
La sintaxis Tag=Value de FIX
 Formato
 Orden de campos
 Grupos repetitivos
 Campos de dato
La Sintaxis de FIXML
 Reglas de Diseño
 Ejemplos



2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
4
Los Elementos Básicos de FIX

Campos
 Elementos de datos que suelen contener un único valor
 Identificados por un Numero de etiqueta de FIX





1 to 5000 – Numeros de Etiqueta de FIX estándar
5000-9999 – Campos personalizados– públicamente identificados
10000+ - Campos Privados definidos por el usuario
Cada campo tiene un tipo de dato de FIX
ASCII data solo no puede contener el <SOH> carácter 0x01

a excepción de determinados campos de tipo de dato data de FIX
Componentes
 Grupas de Campos
Mensajes
 Campos
 Componentes


2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
5
Etiqueta = Valor
Versiónes

FIX4.0


FIX.4.1


Ampliamente utilizado
FIX5.0 (SP2 acaba de publicar)


NO UTILICE
FIX4.4


Ampliamente utilizado
FIX.4.3


Todavía en uso
FIX.4.2


NO UTILICE
Adopción inicial en curso por las bolsas
FIXT1.1

Solo nivel de sesión
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
6
La Sintexis Etiqueta = Valor de FIX

Compuesto de cuatro partes
 Etiqueta

Numero de etiqueta de campo de FIX

=

Valor
Delimitador




ETIQUETA=VALOR^
No imprimible ASCII carácter conocido como Start of Header (SOH)
carácter 0x01 muestra en la computadora como ^A
A menudo aparece en la documentación usando uno de los siguientes :
|
^
<SOH>

Ejemplo del primero campo en un mensaje
8=FIX.4.1<SOH>

<SOH>
BeginString – identifica la versión del mensaje de FIX
44=100.5<SOH>

Price – identifica el precio
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
7
No Campos Vacíos




No se permite campos vacíos
Todos los campos deben tener un valor
Los campos opcionales sin valores no están incluidos
Mensajes con los campos vacíos deben ser rechazados
 Envie un Rechazo de nivel de sesión en la respuesta
<SOH>
2009-05-11 Sao Paolo, BR
40=1<SOH>44=<SOH>
Copyright (c) FIX Protocol Ltd.
8
Reglas de Orden de Etiqueta = Valor


Un campo(etiqueta) sólo puede aparecer en un mensaje uno vez
EXCEPTO:
 Dentro un grupo repetivo (siguiente diapositiva)
Campos dentros un mensaje de FIX pueden aparecer en cualquier orden
EXCEPTO:
 Inicio de un Mensaje
8=FIX.4.2<SOH>9=182<SOH>35=D<SOH>…

Los tres campos primeros en la cabecera estándar




Fin de un Mensaje
....



BeginString (tag 8)
BodyLength (tag 9)
MsgType (tag 35)
<SOH>
10=xxx<SOH>
El ultimo campo en el trailer estándar es CheckSum (tag 10)
Aviso de ultimo carácter <SOH>
Grupos repetivos

El orden de los campos dentro los grupos repetivos debe ser preservado.
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
9
Contenido de Dato

ASCII Carácteres
 campo no debe contener
<SOH>
<SOH>
58=12345
Carácter 0x01
<SOH>
7890
<SOH>
Dato con <SOH> carácteres
incorporados en el campo Text (tag
58)
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
10
Soporte para datos binarios

FIX provee un tipo de dato data





Puede contener datos binarios incluso
tiene un campo correspondiente Longtitud
<SOH>
Deberá ser inmediatamente precedida por su campo Longtitud
El campo puede contener un
Carácter 0x01
Ejemplo:
<SOH>


EncodedTextLen(tag 354) tipo de dato es Longtitud
EncodedText(tag 355) tipo de dato es data
<SOH>
354=10<SOH>355=12345<SOH>7890<SOH>10=123<SOH>
Campo de Longtitud
2009-05-11 Sao Paolo, BR
Dato con <SOH> incorporado
propiamente dentro el
campo data
Copyright (c) FIX Protocol Ltd.
11
Grupos repetitivos


Grupos repetitivos permiten un conjunto de campos que se repita
dentro de un mensaje
Notables usos:





Bloque de Parties
alternativa de identificación de valores
Legs of a multileg instrument
Individual allocations for an order
Ejemplo – El Bloque Parties
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
12
Reglas de grupos repetitivos

Comenza con campo NumInGroup NoXxxxx
 Donde “No” es la abreviatura de “Numero”
 Ejemplos:




El primero campo enumerado después de campo NoXxxx DEBE
SER previsto
 Actúa como un delimitador para cada grupo repetivo
 Ejemplo:



NoPartyIDs(tag 453)
NoMiscFees(tag 136)
NoLegs(tag 555)
PartyID(tag 448) debe ocurrir después de NoPartyIDs(tag 453)
No incluya el campo NoXxxx si hay cero entradas
 NoXxxx=0 se permite– NO se recomienda
Campos deben ocurrir en orden dentro de un grupo repetivo
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
13
Repeating Group Example

Identify the executing broker and the clearing firm on a FIX.4.4 order
NoPartyIDs(tag 453)=2
PartyID(tag 448)=DEUTDEFF500
PartyIDSource(tag 447)=B note: Bank Identifier Code (BIC) ISO 9362
PartyRole(tag 452)=1 note: Executing Firm
PartyID(tag 448)=GSILGB2XHUL
PartyIDSource(tag 447)=B note: Bank Identifier Code (BIC) ISO 9362
PartyRole(tag 452)=4 note: Clearing Firm
453=2<SOH>448=DEUTDEFF500<SOH>447=B<SOH>452=1<SOH>448=GSILGB2XHUL<SOH>447=B<SOH>452=4<SOH>
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
14
Ejemplo de Grupos Repetivos Anidados


FIX permite grupos repetivos anidados
 PartySubGrp es un grupo repetivo anidado dentro el grupo Parties
Ejemplo:
NoPartyIDs(tag 453)=2
PartyID(tag 448)=DEU
PartyIDSource(tag 447)=B note: Bank Identifier Code (BIC) ISO 9362
PartyRole(tag 452)=1 note: Executing Firm
PartySubID(tag 523)=A1
PartySubIDType(tag 803)=10 note: Securities account number
PartyID(tag 448)=GSI
PartyIDSource(tag 447)=B note: Bank Identifier Code (BIC) ISO 9362
PartyRole(tag 452)=4 note: Clearing Firm
PartySubID(tag 523)=C3
PartySubIDType(tag 803)=10 note: Securities account number
453=2<SOH>448=DEU<SOH>447=B<SOH>452=1<SOH>523=A1<SOH>803=10<SOH>448=GSI<SOH>447=B<SOH>452=4<SOH>23=A1<SOH>803=10<SOH>
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
15
FIX Checksum




Añada cada byte en el mensaje de FIX hasta pero sin incluir el
campo checksum
Calcule modulo 256 de la suma
Almacene el valor en el campo CheckSum (10=nnn)
No se olvide el
carácter final
2009-05-11 Sao Paolo, BR
<SOH>
Copyright (c) FIX Protocol Ltd.
16
Estructura de mensajes de FIX
Cabecera Estándar
Identifica el tipo de mensaje, la longitud del mensaje,
remitente o destino, número de orden, tiempo del envío, etc
8=FIXT.1.1<SOH>9=70<SOH>35=A<SOH>49=JPMC1<SOH>56=LSE
<SOH>34=1<SOH>52=20090310-10:23:01.093<SOH>
Cuerpo
del Mensaje
Contiene el contenido concreto de los mensajes de sesión o de
aplicación
98=0<SOH>108=30<SOH>1137=9
Contiene la firma digital opcional y el checksum
Trailer Estándar
<SOH> 10=247<SOH>
Copyright (c) FIX Protocol Ltd.
Un Ejemplo de New Order Single Mensaje de FIX
8=FIX.4.2<SOH>9=0235<SOH>35=D<SOH>34=10<SOH>43=N<SOH>49=VENDOR<SOH>50=CUSTOMER<SOH>56=BR
OKER<SOH>52=19980930-09:25:58GMT<SOH>1=XQCCFUND<SOH> 11=10<SOH>21=1<SOH>
55=EK<SOH>48=277461109<SOH>22=1<SOH>54=1<SOH>38=10000<SOH>40=2<SOH>44=76.750000<SOH>59=0<
SOH>10=165
Cabecera
8=FIX.4.2
9=235
35=D
34=10
43=N
49=VENDOR
115=CUSTOMER
56=BROKER
52=19980930-09:25:58 GMT
Begin String
Body Length
MsgType
MsgSeqNum
PossDupFlag
SenderCompID
OnBehalfOfCompID
TargetCompID
Sending Time
Trailer
10=165
2009-05-11 Sao Paolo, BR
Cuerpo
1=XQCCFUND
11=10
21=1
55=EK
48=277461109
22=1
54=1
38=10000
40=2
44=76.750000
59=0
Account (optional)
ClOrdID
HandInst
Symbol
SecurityID (optional)
IDSource (optional)
Side
OrderQty
OrdType
Price
(optional)
TimeInForce (optional)
Checksum
Copyright (c) FIX Protocol Ltd.
18
Tipos de Dato

Cadenas
 La longtitud no se especifica
 MultipleCharValue


Campo de cadena que contiene uno o más valores de carácter únicos
Ejemplo:
ExecInst(Tag 18) Instrucciones de ejecución

<SOH>
18=2 A F
<SOH>
MultipleStringValue


Campo de cadena que contiene uno o más valores de carácter múltiples
delimitados de espacio.
<SOH>
<SOH>
Ejemplo:
277=AV AN A
TradeCondition(Tag 277) Trade Conditions

Fechas – variantes en YYYYMMDD-HH:MM:SS.sss

durante un inserción del segundo de un año bisiesto, un campo UTCTimestamp
puede contener "19981231-23:59:59", "19981231-23:59:60", "19990101-00:00:00"
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
19
Componentes




Grupos de campos que se usan junto
Ejemplos
 Instrument
 Parties
Introducido en FIX.4.3
No influye el formato de alambre
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
20
Componentes
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
21
Componentes
Tag
12
13
479
497
Nombre de Campo
Commission
CommType
CommCurrency
FundRenewWaiv
Req'd
N
N
N
N
Tag
453
Nombre de Campo
NoPartyIDs
Req'd
N








2009-05-11 Sao Paolo, BR
Comentarios
Para CIV – Opcional
Para CIV – Opcional
Comentarios
El grupo repetivo abajo debe contener combinaciones
únicas de PartyID, PartyIDSource, y PartyRole
448 PartyID
N
Se utiliza para identificar la fuente de PartyID. Requerido
si PartyIDSource está especificado. Requerido si
NoPartyIDs > 0.
447 PartyIDSource
N
Se utiliza para identificar la fuente del clase del valor de
PartyID (e.g. BIC). Requerido si PartyID está
especificado. Requerido si NoPartyIDs > 0.
452 PartyRole
N
Identifica el tipo de PartyID (e.g. Executing Broker).
Requerido si NoPartyIDs > 0.
Start of Component block, expanded in line < PtysSubGrp >
802 NoPartySubIDs
N

523 PartySubID
N

803 PartySubIDTy
N
pe
End of Component block, expanded in line < PtysSubGrp >
Copyright (c) FIX Protocol Ltd.
22
Versión del Esquema de FIXML


El esquema fue publicado para FIX.4.4, FIX.5.0, SP1, SP2
Mensajes de FIX y Componentes de FIX están representados como
elementos de XML
<TrdCaptRpt/>

Campos de FIX están representados como Atributos de XML
TradeReportID(Tag 571) se convierte @RptID

Utiliza los nombres abreviados de campos de FIX
35=D 1=A
<SOH>
<SOH>
9 bytes para FIX
<Order Acc="A"/>
2009-05-11 Sao Paolo, BR
16 bytes para FIX
Copyright (c) FIX Protocol Ltd.
23
Reglas de Diseño de FIXML







Abreviaturas para reducir el tamaño de los mensajes
 Price = Px, Currency = Ccy, etc.
Mensajes de FIX están implementados como Elementos de XML
Campos de FIX no repetivos están implementados como Atributos
de XML del Elemento de XML de Mensaje de FIX
Componentos de FIX están implementados como Elementos de
XML
 Campos de FIX dentros Componentos de FIX están
implementados como Atributos de XML
Los grupos repetivos de FIX deben ser componentos de FIX
Tipos de Dato de FIX están asignados al más cercano Tipo de Dato
del Esquema de XML
Campos de FIX están identificados por sus nombres abreviados de
campos de FIX
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
24
Abreviaturas Contextuales de Campos de FIXML

Campos de FIX pueden tener un nombre abreviado contextual de FIX en
algunos casos
 Campos de FIX a menudo tienen prefijos que se asocian el campo a
uno o más mensajes dentro de una Categoría de Mensaje de FIX
 Dentro de esa Categoría de Mensaje de FIX el campo de FIX puede ser
asignado a Nombre Abreviado Contextual de campo de FIX
 Ejemplos:



ListID(Tag 66) Abreviatura estándar : ListID Abreviatura Contextual : ID en la
Categoría Allocation
AllocID(tag 70) Abreviatura estándar : AllocID Abreviatura Contextual : ID en la
Categoría Allocation
Campos múltiples de FIX pueden compartir el mismo nombre abreviado de
FIX

Ejemplos:



ID para PartyID(tag 448), NestedPartyID(tag 524), Nested2PartyID(tag 757),...
R para PartyRole(tag 452), NestedPartyRole(tag 538) Nested2PartyRole(tag 759)…
Src para PartyIDSource(tag 447), NestedPartyIDSource(tag 525) ,. …
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
25
Etiqueta = Valor en comparación con FIXML

Etiqueta = Valor
8=FIX.4.1<SOH>9=154<SOH>35=6<SOH>49=BRKR<SOH>56=INVMGR<SOH>34=236<SOH>52=1998060407:58:48<SOH>23=115685<SOH>28=N<SOH>55=SPMI.MI<SOH>54=2<SOH>27=200000<SOH>44=10100.000000
<SOH>25=H<SOH>10=159<SOH>

FIXML
<FIXML>
<IOI IOIID="115685" TransTyp="N" Side="2" Qty="200000"
Px="10100.000000" QltyInd="H">
<Hdr SeqNum="236" SndgTm="1998-06-04T07:58:48">
<Snd ID="BRKR" />
<Tgt ID="INVMGR" />
</Hdr>
<Instrmt Sym="SPMI.MI" />
</IOI>
</FIXML>
2009-05-11 Sao Paolo, BR
Copyright (c) FIX Protocol Ltd.
26
El Protocolo FIX: Sintaxis,
sesión y semántica Sesión
2:
La capa de sesión
El Protocolo FIX: Sintaxis, sesión y
semántica Sesión 2 : La capa de sesión
Ryan Pierce, Director técnico de FPL, Co-presidente
del grupo de trabajo de implementación y optimización,
FIX Protocol Ltd
Mateus Bertti, Coordinador de TI – Sistemas de comercialización
BM&FBovespa
Agenda


Capa de sesión FIX (FIX 4.0 - 4.4 y FIXT.1.1)

Panorama general

Anatomía y funciones del motor FIX

Mensajes y uso del nivel de sesión
FIXT.1.1

Paquetes de extensión y paquetes de servicio

Independencia de transporte

Independencia de versión de aplicación
Derechos de autor (c) FIX Protocol Ltd.
Capas de sesión y aplicación FIX
Aplicación de comercialización
Capa de sesión
•Establecimiento y finalización de la conexión
•Entrega de mensajes, integridad de datos, secuencia
Capa de aplicación
Contenido relacionado con el negocio
Orden, ejecución, IOI, etc.
Protocolo FIX
Derechos de autor (c) FIX Protocol Ltd.
Anatomía de un motor FIX
Sistema de comercialización
Sistema de gestión de órdenes
Sistema de gestión de ejecuciones
Sistema de administración
Aplicación de generación de mercados
Su
Aplicación
Interfaz/ Interfaces de
programas de aplicación
Motor FIX
Analizador de
mensajes
Contraparte 2
FIX
Gestión de
Sesión
…
Estado de
Sesión
Diccionario
de mensajes
FIX
(Repositorio)
Configuración
de sesión
Contraparte 1
FIX
Registro de
mensajes
(Mínimo
saliente)
Estad de
Sesión
Derechos de autor (c) FIX Protocol Ltd.
Contraparte N FIX
Número entrante de secuencia
Número saliente de secuencia
Motor FIX - Funciones clave


Inicio de sesión
 Obtener detalles de configuración de la Configuración de Sesión (ej.: dirección IP, Puerto
TCP, CompIDs, etc.)
 Determinar los últimos números de secuencias entrantes/salientes o configurar a 1 si es la
primera sesión del día
 Conectar a "manejadores" internos de mensajes de negocios vía un API
 Conectar con la contraparte de la sesión FIX
 Enviar inicio de sesión y realizar el apretón de manos de inicio de sesión
Funciones continuas
 Atender mensajes entrantes FIX
 Descifrar (opcional), analizar y almacenar con seguridad todos los mensajes
 Responder mensajes de nivel administrativo
 Convertir y reenviar los mensajes de negocios a “manejador” vía un API
 Validar núm de sec., enviar solicitud de reenvío si se detecta una brecha
 Atender solicitudes entrantes de "manejadores" internos
 Interpretar un mensaje FIX, encriptar (opcional), almacenar en forma segura y
enviar por sesión FIX a contraparte
 Funciones administrativas
 Enviar pulsaciones, solicitudes de pruebas, condición del sistema
 Terminar la sesión en el momento de "finalización" de sesión
Derechos de autor (c) FIX Protocol Ltd.
Funciones de nivel de sesión





Inicio de una sesión (logon)
Validación de mensaje
Secuencia de mensaje
Pulsación
Finalización de sesión (Logout)
Derechos de autor (c) FIX Protocol Ltd.
Inicio de una sesión (Logon MsgType[35]=A)

La empresa del lado comprador inicia (el Iniciador) una conexión con una
empresa del lado vendedor (el Aceptador) usando el mensaje de nivel de inicio
de sesión
BeginString[8]=FIX.4.2<SOH>
BodyLength[9]=92<SOH>
MsgType[35]=A<SOH>
SenderCompID[49]=BUYSIDE1<SOH>
TargetCompID[56]=SELLSIDEA<SOH>
SenderSubID[50]=MSO:MSO<SOH> [Opcional]
TargetSubID[57]=TEST<SOH> [Opcional]
MsgSeqNum[34]=106<SOH>
PossDupFlag[43]=N<SOH> [Optional]
SendingTime[52]=20010822-13:06:42<SOH>
EncryptMethod[98]=0<SOH>
HeartBtInt[108]=30<SOH>
CheckSum[10]=021<SOH>
Derechos de autor (c) FIX Protocol Ltd.
Comienzo del día escenario nominal de inicio de
sesión
Logon MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=1
SenderCompID válido
El número entrante de secuencia corresponde con el
valor esperado
Iniciador
de Logon
(inicio de
sesión)
Logon MsgType[35]=A TargetCompID[56]=CBOE1 Aceptador
de Logon
SenderCompID[49]=MM1 MsgSeqNum[34]=1
El número entrante de secuencia corresponde con el
valor esperado
Esto es el
reconocimiento del
Logon (inicio de
sesión)
o Logon Ack
¡Hemos
establecido una
sesión FIX!
Derechos de autor (c) FIX Protocol Ltd.
Validación de mensaje


Los motores FIX validan que los mensajes se formen correctamente
y rechazarán el mensaje usando un mensaje de rechazo al nivel de
sesión si el mensaje es inválido
Las validaciones pueden incluir, entre otras:
 Estructura del mensaje (Tag=Value[SOH]) y CheckSum[10]
 Orden del campo (ej. BeginString[8] es primero, Encabezado /
Cuerpo/ orden de seguimiento, grupos repitentes)
 MsgType[35] es válido y apoyado
 Se especifican todos los campos requeridos
 El formato de campo corresponde con el tipo especificado de
datos
 Etiquetas especificadas sin valores (ej. Etiqueta=[SOH] no está
permitida)
 SenderCompID[49] y TargetCompID[56] apropiados
Derechos de autor (c) FIX Protocol Ltd.
Secuencia de mensaje
La sesión FIX garantiza que se entreguen los mensajes en el orden en que se
envían
 Una sesión FIX puede definirse como

“una corriente bidireccional de mensajes ordenados entre dos partes
dentro de una serie continua de números de secuencia"
Se espera que cada motor FIX mantenga el rastro de dos números de secuencia
 El número de secuencia entrante esperado de mensajes entrantes recibidos
de la contraparte
 El número de secuencia saliente para enviarse a la contraparte
 La capa de sesión FIX proporciona un método de recuperación de mensajes
perdidos, o mensajes recibidos fuera de orden
 Las aplicaciones FIX pueden sincronizar nuevamente números de secuencia
entre motores que usan la capa de sesión FIX

Derechos de autor (c) FIX Protocol Ltd.
Reenviar solicitud (MsgType[35]=2)




Utilizado para solicitar a la contraparte que reenvíe un conjunto de mensajes
FIX
Decirle a la contraparte el rango de mensajes que no recibió

BeginSeqNo[7]

BeginSeqNo[16]
Puede pedir un rango específico, o puede solicitar todos los mensajes desde
BeginSeqNo[7] a infinito (recomendado)

Para FIX 4.2 y superior, infinito es EndSeqNo[16]=0

Para FIX 4,0 y 4.1, infinito es EndSeqNo[16]=999999
Respuestas aceptables:

Reenviar el mensaje en cuestión con PossDupFlag[43]=Y, o

Enviar restablecimiento de secuencia – Cumplimiento de brecha
(MsgType[35]=4 con GapFillFlag[123]=Y)
Derechos de autor (c) FIX Protocol Ltd.
Escenario de inicio de sesión excepcional
Número de secuencia demasiado alto
Login MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=3
SenderCompID válido
Número de secuencia > Valor
esperado
Iniciador
de
sesión
Entrante
Esperado=1
Login MsgType[35]=A TargetCompID[56]=MM1
SenderCompID[49]=MM1 MsgSeqNum[34]=1
El número entrante de secuencia corresponde con el
valor esperado
ResendRequest MsgType[35]=2 TargetCompID[56]=MM1
SenderCompID[49]=MM1 MsgSeqNum[34]=2
BeginSeqNo[7]=1 EndSeqNo[16]=0
Reenvía mensajes o envía un cumplimiento de brecha
Derechos de autor (c) FIX Protocol Ltd.
Aceptador
de sesión
Escenario de inicio de sesión excepcional
Número de secuencia demasiado bajo
Logon MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=1
SenderCompID válido
Número de secuencia < Valor
esperado
Iniciador
de
sesión
¿Por qué
detenemos el
establecimiento de
la sesión?
Logon MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=418
Text[58]=Número de secuencia entrante < Esperado =
220
Desconecte cerrando el
puerto virtual
Derechos de autor (c) FIX Protocol Ltd.
Entrante
Esperado=220
Aceptador
de sesión
Restablecimiento de secuencia (MsgType[35]=4)



Para reducir la comunicación innecesaria, FIX permite a las empresas saltear o
completar brechas sobre mensajes administrativos (tales como pulsaciones y
solicitudes de pruebas)
Esto también puede usarse para saltear mensajes pasados tales como órdenes
Esto se logra usando el Mensaje Restablecer secuencia

BeginSeqNo[123]
 GapFillFlag[123]=Y debe procesarse en orden secuencial, y se
recomienda para la recuperación normal del mensaje
 GapFillFlag[123]=N fuerza un cambio en un número de secuencia y
está previsto para emergencias o intervención manual

BeginSeqNo[36]
 Este es el siguiente mensaje que el destinatario debe esperar
Derechos de autor (c) FIX Protocol Ltd.
Pulsación (MsgType[35]=0)
permite a cada lado saber si la conexión está activa
Inicio de sesión MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=1
Inicio de sesión MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=1
Iniciador Pulsación MsgType[35]=0 TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=2
de
sesión
Aceptador
de sesión
Pulsación MsgType[35]=0 TargetCompID[56]=MM1
SenderCompID[49]=MM1 MsgSeqNum[34]=2
…
No se muestra el recordatorio de
sesión
Cierre de sesión MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=200
Derechos de autor (c) FIX Protocol Ltd.
¿Con qué frecuencia debemos enviar mensajes de
pulsaciones?



Configurable

Originalmente muchos sitios usaban 30 segundos

Muchas empresas están usando 15 segundos
“Negociado” en tiempo de inicio de sesión (Logon)

HeartBtInt [108] – valor entero en segundos

Ambos lados deben acordar el Intervalo de pulsaciones
Optimización

Sólo enviar Pulsaciones cuando la sesión esta inactiva
Derechos de autor (c) FIX Protocol Ltd.
Solicitud de prueba (MsgType=1)






Cada una de las partes en la conexión FIX puede enviar un mensaje de
solicitud de Prueba en cualquier momento durante la sesión FIX
El destinatario del mensaje de Solicitud de prueba debe responder con un
mensaje de Pulsaciones
La solicitud de prueba contiene un campo TestReqID[112] requerido
El mensaje de respuesta de pulsaciones debe contener el TestReqID[112] de la
Solicitud de prueba
Se envía una Solicitud de prueba si no se reciben mensajes en más de
HeartBtInt[108] segundos
La falta de respuesta a la Solicitud de prueba causa un cierre de sesión y
desconexión
Derechos de autor (c) FIX Protocol Ltd.
Escenario de solicitud de prueba normal
TestRequest MsgType[35]=1 TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 TestReqID[112]=AnyString
Iniciador
de
solicitud
de
prueba
Pulsación MsgType[35]=0 TargetCompID[49]=MM1
SenderCompID[49]=CBOE1 TestReqID[112]=AnyString
Derechos de autor (c) FIX Protocol Ltd.
Destinatario
de solicitud
de prueba
Escenario de excepción de solicitud de prueba
Sin respuesta de la contraparte
TestRequest MsgType[35]=1 TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 TestReqID[112]=AnyString
Sin respuesta del destinatario
Iniciador
para
de
Destinatario
Intervalo de 2 x Pulsaciones
de solicitud
solicitud
Cierre de sesión MsgType=5 TargetCompID[56]=CBOE1 de prueba
de
prueba SenderCompID[49]=MM1 Text[58]=Tiempo final de
solicitud de prueba
Desconecte cerrando el puerto virtual
Derechos de autor (c) FIX Protocol Ltd.
Finalización de sesión(Logout MsgType=5)

Cada lado envía un mensaje de cierre de sesión
8=FIX.4.2<SOH>
9=82<SOH>
35=5<SOH>
49=CBOE1<SOH>
56=MM1<SOH>
34=483<SOH>
52=20010822-14:05:34<SOH>
10=176<SOH>
Derechos de autor (c) FIX Protocol Ltd.
Procesamiento normal de cierre de sesión
Cierre de sesión MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=50
Empresa
inicia
cierre de
sesión
Se considera mala
manera cerrar la
conexión antes de
recibir la
confirmación de
cierre de sesión
Aguardar un breve período de tiempo (intervalo de
pulsación) para que el otro lado envíe el cierre de
sesión; esto se hace en caso de que el otro lado
necesite hacer procesamiento de reenvío
Logon MsgType[35]=A TargetCompID[56]=CBOE1
SenderCompID[49]=MM1 MsgSeqNum[34]=103
Ambos lados se desconectan cerrando el
puerto virtual
Derechos de autor (c) FIX Protocol Ltd.
Destinatario
de cierre de
sesión
FIX 5.0 y FIXT.1.1 - Cambios clave

En realidad 2 Protocolos:
FIX 5.0 – Protocolo de nivel de aplicación, incluyendo apoyo para nueva
funcionalidad de negocios

FIXT.1.1 – Protocolo de nivel de sesión
Independencia de transporte
Independencia de versión de aplicación
Primera versión impulsada completamente desde el repositorio

Representación XML del protocolo FIX

Legible por máquina, reduciendo el costo de la construcción de reglas de
validación en motores FIX

El Repositorio genera la especificación del documento Word, FIXimate, y el plan
FIXML.
Primera versión donde se publicó toda la documentación al mismo tiempo
Primera versión usando la nueva arquitectura de „paquete de servicios‟

Los usuarios preparan paquetes de extensión y GTC los aprueba

GTC empaqueta los paquetes de extensión con los paquetes de servicios

GTC puede presentar Paquetes de extensión independientemente de las
presentaciones de paquete de servicios, permitiendo la adopción rápida de los
cambios propuestos






Derechos de autor (c) FIX Protocol Ltd.
Independencia de transporte






FIX 5.0 es la primera versión que desacopla los mensajes de aplicación FIX de
la sesión FIX
FIXT.1.1 es una especificación diferenciada que no cambia con la versión FIX
Se puede usar FIX 5.0 sobre otros transportes:
 Series MQ
 Servicios Web
 HTTP
 Bus mensaje
 Capa de sesión FIX (FIXT.1.1)
Permite mayor retorno sobre la inversión sobre inversiones existentes de FIX
Reduce gastos para agregar nueva funcionalidad FIX
Ofrece oportunidad de elegir transporte apropiado para las circunstancias
Derechos de autor (c) FIX Protocol Ltd.
Independencia de versión de aplicación




Mensajes de nivel de aplicación desde cualquier versión FIX que pueda
mandarse sobre FIXT.1.1
Responde a las preocupaciones sobre el número de versiones FIX al permitir a
las empresas que se mezclen y correspondan, todo en la misma sesión
Capacidad de agregar mayor funcionalidad con desarrollo creciente,
ej. puede agregar ahora asignaciones FIX 4.4 a un sistema existente de
órdenes y ejecuciones de la siguiente manera:

Reemplazar la sesión FIX 4.2 con una sesión FIXT.1.1 predeterminada a
FIX 4.2

Escribir código para manejar las asignaciones FIX 4.4

El sistema de órdenes y ejecuciones FIX 4.2 no cambia.
Sin FIXT.1.1:

Esfuerzo adicional de costos, tiempos y pruebas para mejorar las órdenes y
ejecuciones para FIX 4.4

Desarrollo y certificación adicional para todas las contrapartes para mejorar
sus sistemas de órdenes y ejecuciones para FIX 4.4
Derechos de autor (c) FIX Protocol Ltd.
FIXT.1.1 e Independencia de versión de aplicación




Versión de aplicación controlada por campos nuevos:

DefaultApplVerID[1137] – Solicitado en el inicio de sesión

ApplVerID[1128] – Aparece en el encabezamiento, modifica
DefaultApplVerID

Campos adicionales agregados para apoyar los paquetes de extensión y las
versiones de aplicación personalizadas
El apoyo completo para muchas versiones de aplicaciones requiere trabajo
importante de un motor FIX

Ver especificaciones de FIXT.1.1
Muchos usuarios sólo requieren apoyo de FIX 5.0 o de un paquete de servicios
de FIX 5.0
Enfoque:

Usar FIXT.1.1 para apoyar sólo una versión

Especificar la versión usando DefaultApplVerID[1137]

El motor y aplicación sólo necesitan estar conscientes de una versión FIX y
un diccionario de datos.
Derechos de autor (c) FIX Protocol Ltd.
El Protocolo FIX: Sintaxis,
Sesión y Semántica
Sesión 3 :
Semántica
El Protocolo FIX: sintaxis, sesión y
semántica sesión 3: semántica
Jim Northey, Co-presidente del Comité Regional de las Américas de
FPL,
Enlace de estándares de la industria de FPL, FIX Protocol Ltd.,
Co-fundador, The LaSalle Technology Group LLC
Ryan Pierce, Director técnico de FPL, Co-presidente
del grupo de trabajo de implementación y optimización,
FIX Protocol Ltd
¿Por qué hablar de Semántica FIX?
La semántica es el impulsor principal de costos para el
desarrollo de aplicaciones que procesan los mensajes de
la interfaz.
Las diferencias de semántica pueden necesitar traducciones
complejas entre las representaciones diferentes (no el nivel de
sintaxis)
 Las traducciones complejas agregan esfuerzo y latencia

Las diferencias en semántica pueden necesitar mantener estado a
nivel de la puerta de enlace mediante una base de datos
 Mantener estado agrega esfuerzo y latencia

 FIX define una semántica estándar para la industria
para reducir el costo de desarrollo y latencia
11 de mayo de 2009
Conferencia de comercialización de América Latina
3
Semántica, Sintaxis, Sesión FIX
Semántica FIX
Concepto
Concepto
Concepto
Concepto
Concepto
Concepto
Concepto
Sintaxis FIX
FIXatdl
PRINCIPIOS

La capa de semántica FIX (aplicación) consiste
en uno o más conceptos para cada funcionalidad
de negocio

La capa de sintaxis FIX representa la
codificación de la semántica FIX
El sintaxis FIX puede comenzar con FIXatdl,
Tag=Value (Etiqueta=Valor) o FIXML
Tag=Value puede convertirse opcionalmente en
FAST
Tag=Value puede convertirse opcionalmente en
FIXML
Se provee uno de Tag=Value, FIXML o FAST a
la capa de sesión
Concepto
FIX sobre
FAST
Tag=Value
(etiqueta=valor)
FIXML


FAST


Sesión [FIX]
Producto
Comercial
FIXT
Implementación
registrada


Red
TCP/IP
Multicast
La capa de sesión (transporte) incluye
protocolos que no son FIX
Las versiones FIX anteriores a FIX 5.0 usan el
Protocolo de Transporte FIX estándar
...
Usualmente se usa TCP/IP para las
transacciones

Multicast se adapta bien a la distribución de
datos
Conferencia de comercialización de América Latina

11 de mayo de 2009
4
Semántica FIX – Elementos clave
 Modelo de transacción




Modelo de estados



¿Cuáles estados pueden tener las entidades tales como pedidos y
cotizaciones?
¿Qué transiciones de estados son posibles y cómo se desencadenan?
Modelo de identificación



¿Cuál es el propósito de un mensaje dado?
¿Cuál es el flujo de mensajes para determinada transacción de negocios?
¿Cuántos mensajes se intercambian y en qué secuencia?
¿Cómo se identifican las órdenes, las cotizaciones y las operaciones y quién
lo hace?
¿Cómo se integra el estándar de identificación ISO?
Campos clave



¿Cuáles campos permiten unir solicitudes y respuestas?
¿Qué campos impulsan el comportamiento de un mensaje?
¿Cómo se informan los errores al nivel de la aplicación?
11 de mayo de 2009
Conferencia de comercialización de América Latina
5
Semántica FIX – Modelo de transacciones:
Cotización masiva
Emisor de
cotización
mercado
Envía un conjunto de
cotizaciones
Las interpreta y las aplica al mercado
cotización masiva
Si se encuentra error
rec. de cotización masiva
Cuando se cumplimenta una
Orden
Execution Report
11 de mayo de 2009
Conferencia de comercialización de América
Latina
6
Semántica FIX – Modelo de transacciones:
Entrada de orden
I.1.b – Inmediata o cancelar orden que no puede alcanzarse completamente en forma inmediata
Hora
Mensaje
recibido
(ClOrdID,
OrigClOrdI
D)
1
Nueva
orden(X)
Mensaje enviado
(ClOrdID,
OrigClOrdID)
Ejec
Tipo
OrdStatus
(Condición
de la orden)
Orden
Cant.
Cum
Cant.
Parte
Cant.
Última
Cant.
10000
Comentario
La orden es IOC
2
Ejecución(X)
Rechazado
Rechazado
10000
0
0
0
Si el lado vendedor (corredor, la bolsa, redes de
comunicación electrónica) rechaza la orden
2
Ejecución(X)
Nueva
Nueva
10000
0
10000
0
Si no se agrupan los mensajes
3
Ejecución(X)
Operación
Completada
parcialmente
10000
1000
9000
1000
Ejecución para 1000
4
Ejecución(X)
Cancelada
Cancelada
10000
1000
0
0
Si no se puede alcanzar la orden por completo
inmediatamente
5
Nueva
orden(Y)
10000
La orden es IOC
6
Ejecución(Y)
Rechazada
Rechazada
10000
0
0
0
Si el lado vendedor (corredor, la bolsa, redes de
comunicación electrónica) rechaza la orden
6
Ejecución(Y)
Operación
Cancelada
10000
1000
9000
1000
Si se usa la agrupación de mensajes y la ejecución
de 1000 ocurre inmediatamente al alcanzar el libro
 FIX soporta más de un solo concepto donde esto sea garantizado por el
grupo de usuarios (lado comprador versus lado vendedor versus bolsas) o
clase de activos.
11 de mayo de 2009
Conferencia de comercialización de América Latina
7
Semántica FIX – Modelo de estados para Bolsas
Aceptar orden con
Vencimiento inmmediato (FOK, IOC)
Aceptar orden con cumplimiento completo inmediato
rechazada
vencimiento
rechazar al entrar
cumplimentad
a
(Reject of
acc’d order)
ejecución completa
vencimiento
Cancelar del libro
cancelada
ejecución completa
vencimiento
Campo FIX
OrdStatus
(39)
Nueva
suspendida
reembolso
ejecución parcial o Cancelar del libro
reembolso
Almacenaje durante la
Noche (órdenes GT)
ejecución parcial
Aceptar orden
Con cumplimiento parcial inmediato
Parcialmente
cumplimentad
a
Almacenaje durante la
Noche (órdenes GT)
Cancelar ej.
Start of Day
Debido a acción empresarial
Activation
(GT orders)
Terminado
por el día
Start of Day
Activation
(GT orders)
11 de mayo de 2009
Conferencia de comercialización de América Latina
8
Semántica FIX – Modelo de Identificación (1)



Órdenes (de etapa simple, de estapas múltiples)
 ClOrdID como identificador de entidad y mensajes del lado emisor de la orden
 El concepto de ClOrdID como identificador de mensajes requiere un nuevo
identificador para transacciones en órdenes existentes y una referencia (OrigClOrdID)
 OrderID como identificador de la entidad del lado que recibe la orden
Cotizaciones (cotización única, cotización masiva)
 Entidades usualmente identificadas implícitamente por instrumento (campos
múltiples)
 Identificador explícito de cotizaciones (QuoteID) sólo necesario si se permite al emisor
de la cotización tener muchas cotizaciones por instrumento (derivados: por series)
 Identificador de cotización masiva (QuoteID, QuoteSetID, QuoteEntryID)
Órdenes cumplidas/Operaciones
 Identificador de ejecución (ExecID, FillExecID) para cumplimientos de órdenes y
cotizaciones
 Identificador de operaciones (FirmTradeID, TradeID, SideTradeID) para nivel de
entidad
 Identificador de informe de operaciones (TradeReportID, SideTradeReportID) para
nivel de mensaje
11 de mayo de 2009
Conferencia de comercialización de América Latina
9
Semántica FIX – Modelo de Identificación (2)
 Instrumentos







Mercados y segmentos de mercado



Valores: Símbolo o SecurityID + SecurityIDSource
Futuros: agregar CFICode (Código CFI) y Mes año de vencimiento
Opciones: agregar StrikePrice (precio de ejercicio), opcionalmente también
PutOrCall (Compra o venta)
SecurityIDSource=M (mercado-asignado) para identificadores sintéticos
Listas: SecurityListID, por ej., para clasificaciones del sector
Grupos: SecurityGroup, por ej., para particiones específicas de bolsa
MarketID definido como MIC (ISO 10383)
MarketSegmentID definido como cadena arbitraria
Sesiones de comercialización


TradingSessionID: Día (1), medio día (2), mañana (3), tarde (4), tarde noche
(5), fuera de horario comercial (6)
TradingSessionSubID: Precomercialización (1), apertura (2), comercialización
(3), cierre (4), después de la comercialización (5), subasta dentro del día (6),
Inactivo (7)
11 de mayo de 2009
Conferencia de comercialización de América Latina
10
Semántica FIX – Modelo de Identificación (3)

Identificación ISO en FIX

Instrumentos: ISIN (ISO 6166), Código CFI (ISO 10962)

Partes: BIC (ISO 9362)

Mercados: BIC (ISO 10383)

Divisas: 3 caracteres (ISO 4217)

Países: 2 caracteres (ISO 3166)

Idiomas: 2 caracteres (ISO 639)

Marcas de tiempo: UTC (ISO 8601)
11 de mayo de 2009
Conferencia de comercialización de América Latina
11
Semántica FIX – Campos clave

¿Cuáles campos unen solicitudes y respuestas?

FIX ofrece identificadores explícitos, distintivos en el cuerpo del mensaje

xxxReq[uest]ID identifica un mensaje de solicitud y se devuelve en la respuesta

xxxRptID o xxxReportID identifica informes (no solicitados)

Excepción: manejo de órdenes (solicitud: ClOrdID, informe: ExecID)

Application Sequencing (Secuencia de aplicaciones) ofrece campo genérico
ApplSeqNum para informes

Los mensajes xxxAck reproducen los campos de entrada para permitir copias a otras
sesiones

¿Qué campos impulsan el comportamiento de un mensaje?

Campos como ExecInst, TradeReportTransType, MDUpdateAction dicen al destinatario
qué hacer con la entidad descrita en el mensaje


Campos como ExecType, OrdStatus, TrdRptStatus dicen al remitente qué ha hecho el
destinatario con la entidad descrita en el mensaje
¿Cómo se informan los errores del nivel de la aplicación?

xxxStatus (con excepciones), xxxResult, xxxRej[ect]Reason confirman el éxito o fracaso
y explican por qué no se aceptó una solicitud de aplicación

El campo de texto es una dirección predeterminada para información de texto libre que
puede usarse también para transmitir errores
11 de mayo de 2009
Conferencia de comercialización de América Latina
12
Semántica FIX – Ejemplo: Cantidad de órdenes (1)
¿Cómo transmito la información de cantidad cuando
quiero modificar una orden existente?

Campo FIX: OrderQty, tipo de dato int

Opción 1: Cantidad Delta


No FIX
Agregar cierta cantidad a la cantidad de la orden actual al receptor
Opción 2: Cantidad restante

No FIX
Asegurarse de que la orden ha dado cantidad después de la modificación
por el receptor
FIX

Opción 3: Cantidad total

Calcular compensación para la cantidad total previa y aplicar delta
 Sólo la opción 3 cumple con la semántica FIX
11 de mayo de 2009
Conferencia de comercialización de América Latina
13
Semántica FIX – Ejemplo: Cantidad de órdenes (2)
¿Qué mensaje/s uso cuando quiero aumentar o disminuir
la cantidad de una orden existente?

Opción 1: Dos mensajes diferentes
No FIX

Aumentar cantidad: usar cancelar/reemplazar orden

Disminuir cantidad: usar cancelar orden con un campo de cantidad
definido por el usuario
FIX

Opción 2: Un solo mensaje

Usar cancelar/reemplazar orden para aumentar o disminuir la cantidad

Usar cancelar orden sólo si disminuye la cantidad a cero (borrar orden)
 La opción 2 cumple con la semántica FIX*
*FIX 4.0 soportaba la opción 1 pero se cambió la semántica con la introducción de FIX 4.1 en abril de 1998
11 de mayo de 2009
Conferencia de comercialización de América
Latina
14
Semántica FIX – Ejemplo: Datos de mercado
¿Cómo transmito información de profundidad del libro de
órdenes que se agrega por nivel de precio?


Opción 1: Dos mensajes diferentes
FIX

Use MarketDataSnapshotFullRefresh para proporcionar precio y cantidad
para todos los niveles de precios disponibles (el destinatario puede
simplemente reemplazar su propia copia)

Use MarketDataIncrementalRefresh para instruir al destinatario que haga
cambios específicos a su copia (agregar, cambiar, borrar la oferta de nivel
de precio o preguntar)
No FIX
Opción 2: Un solo mensaje

Use MarketDataSnapshotFullRefresh para proporcionar precio y cantidad
para todos los niveles de precios donde haya cambiado algo (destinatario
para modificar información sólo para niveles de precios incluidos en el
panorama)
 La opción 1 cumple
con la semántica FIX
Conferencia de comercialización de América
11 de mayo de 2009
Latina
15
Semántica FIX – Datos de referencia con FIX 5.0 SP1

FIX 5.0 SP1 mejoró significativamente el área de Datos de Referencia

Mensajes de nivel de mercado (segmento) (MarketDefinition[Request][UpdateReport])

(Posibilidad de definir las reglas de comercialización en el nivel de un mercado (segmento), sesión de
comercialización o instrumento individual





Reglas que definen tipos de órdenes disponibles, instrucciones de ejecución, valores de tiempo
en fuerza, algoritmos de correspondencia, suministros de datos de mercado
Reglas que definen señales, tipos de lotes, tipos de precios, límites de precios, cantidades
máximas/mínimas de órdenes
Reglas que definen incrementos y estilos de ejercicios por rango de precios de ejercicios como
también reglas de vencimiento
Modelo habilitado FIX 5.0 SP1 de jerarquías de mercado

Un mercado en el nivel superior es siempre un mercado definido por un MIC

Puede haber cero o más segmentos de mercado dentro de un mercado que represente agrupaciones
específicas de mercado de instrumentos que se ordenan como una jerarquía (mediante el campo
ParentMktSegmID)

Un segmento de mercado es un término genérico que necesita definirse por el mercado
FIX 5.0 SP1 introdujo un concepto para la propagación de Reglas de Comercialización

Una regla de comercialización definida en un nivel superior aplica a todas las entidades en niveles
inferiores

Una regla de comercialización definida en cualquier nivel modifica una regla de comercialización
definida en un nivel más alto

Las reglas específicas de implementación de compromiso necesitan diseñarse y definirse
bien
11 de mayo de 2009
Conferencia de comercialización de América Latina
16
Semántica FIX - Reglas de comercialización
Reglas de comercialización
de base
Grupo de reglas de sesión de
comercialización
<Base Trading Rules>
<Trading Session Rules Grp>
<TickRules>
---------------------------- NoTickRules
---------------------------- StartTickPriceRange
- EndTickPriceRange
- TickIncrement
- TickRuleType
TradingSessionID
TradingSessionSubID
<Trading Session Rules>
<OrdTypeRules>
---------------------------- NoOrdTypeRules
----------------------------- OrdType
<LotTypeRules>
---------------------------- NoLotTypeRules
----------------------------- LotType
- MinLotSize
<ExecInstRules>
---------------------------- NoExecInstRules
----------------------------- ExecInstValue
Conferencia de
<MarketData
FeedTypes>
---------------------------- NoMDFeedTypes
----------------------------- MDFeedType
- MarketDepth
- MDBookType
comercialización
de
- NoStrikeRules
---------------------------- StrikeRuleID
- StartStrikePxRange
- EndStrikePxRange
- StrikeIncrement
- StrikeExerciseStyle
<Secondary Price Limits>
<MatchRules>
---------------------------- NoMatchRules
----------------------------- MatchAlgorithm
- MatchType
ExpirationCycle
MinTradeVol
MaxTradeVol
MaxPriceVaration
ImpliedMarketIndicator
TradingCurrency
RoundLot
<Strike Rules>
<Maturity Rules>
---------------------------- NoMaturityRules
---------------------------- MaturityRuleID
- MMYFormat
- MMYIncrementUnitOfMeasure
- StartMMY
- EndMMY
- MMYIncrement
<TimInForceRules>
---------------------------- NoTimeInForceRules
----------------------------- TimeInForce
<PriceLimits>
---------------------------- PriceLimitType
- LowLimitPrice
- HighLimitPrice
- TradingReferencePrice
11 de mayo de 2009
Reglas de precio límite
- SecondaryPriceLimitType
- SecondaryLowLimitPrice
- SecondaryHighLimitPrice
- SecondaryTradingReferencePrice
América Latina
17
Semántica FIX – Nivel de mercado
Market Segment Request
Trading Session List Request
MarketID
MarketSegmentID
MarketID
MarketSegmentID
Market Segment /
Market Segment Update Report
Trading Session List /
Trading Session List Update Report
MarketID
MarketSegmentID
MarketID
MarketSegmentID
<Base Trading Rules>
<OrdTypeRules>
---------------------------- NoOrdTypeRules
----------------------------- OrdTypes
TradingSessionID
TradingSessionSubID
<Trading Session Rules>
<TimInForceRules>
---------------------------- NoTimeInForceRules
----------------------------- TimeInForce
<ExecInstRules>
---------------------------- NoExecInstRules
----------------------------- ExecInstValue
11 de mayo de 2009
Conferencia de comercialización de América
Latina
18
Semántica FIX - Nivel de instrumento
Security Defintion Request
Derivative Security List Request
Security List Request
MarketID
MarketSegmentID
MarketID
MarketSegmentID
MarketID
MarketSegmentID
<Instrument >
<Underlying Instrument >
<Instrument>
<Instrument Extension>
<Derivative Instrument >
<Instrument Extension>
Security Definition /
Security Definition Update Report
<Instrument>
<Instrument Extension>
Derivative Security List /
Derivative Security List Update Report
<Underlying Instrument>
<Derivative Security Definition>
<Market Segment Grp>
<Derivative Instrument>
MarketID
MarketSegmentID
<Derivative Instrument
Attribute>
Security List /
Security List Update Report
MarketID
MarketSegmentID
<Instrument>
<Instrument Extension>
<Security Trading Rules>
<Security Trading Rules>
<Market Segment Grp>
<Base Trading Rules>
MarketID
MarketSegmentID
<Trading Session
Rules Grp>
<Security Trading Rules>
<Nested Instrument
Attribute>
<Base Trading Rules>
<Trading Session
Rules Grp>
<Nested Instrument
Attribute>
<Base Trading Rules>
<Trading Session
Rules Grp>
<Strike Rules>
<Nested Instrument
Attribute>
<Underlyiing>
<Strike Rules>
<InstrumentLeg>
<Underlying>
<Strike Rules>
<InstrumentLeg>
<Instrument>
<Instrument Extension>
11 de mayo de 2009
<InstrumentLeg>
<SecondaryPriceLimits>
19
Semántica FIX – Datos de referencia con FIX 5.0 SP2

Modelo habilitado FIX 5.0 SP2 de partes y Datos de referencia de límites
de riesgo




Dos nuevos mensajes:

PartyDetailsListRequest [type „CF‟]

PartyDetailsListReport [type „CG‟]
Modos actuales de operación:

Solicitud/ Respuesta

Informes no solicitados
Puede usarse para modelar:

Un parte sola o lista de partes

Las relaciones entre partes, ej., Liquidaciones para, Operaciones mediante, Miembro de
Los usos incluyen:

Derechos (qué operadores pueden operar con qué cuentas, relaciones de
liquidaciones….)

11 de mayo de 2009
Límites de riesgo muy flexibles, incluyendo varios límites simultáneos

Tipos de límites: bruto, neto, de exposición, largo, corto

Alcance basado en Parte, Relación entre Partes o Instrumento
Conferencia de comercialización de América Latina
20
Semántica FIX
¿Preguntas?
11 de mayo de 2009
Conferencia sobre comercialización EMEA
21
Maximización del potencial
de su implementación de
FIX
Maximización del potencial de
su implementación de FIX
Ryan Pierce
Co-presidente del grupo de trabajo para la
implementación y optimización de FPL
Director técnico de FPL
FIX Protocol Ltd
Grupo de trabajo para la implementación y la
optimización



Grupo de trabajo formado para dar repuesta a las concepciones
erróneas de que FIX es lento, y para compartir mejores prácticas
 El protocolo FIX en sí mismo no es lento
 Las implementaciones y el software de la aplicaciones de FIX
pueden ser lentos
Co-presidentes:
 Ryan Pierce, Director técnico de FPL
 John Prewett, VP, Citi, Lava Trading
El compartir las mejores prácticas redunda en beneficio para la
industria
 Unos pocos sistemas FIX lentos pueden dar una mala
reputación a todos los que usan FIX
 Las empresas están comenzando a tomar la iniciativa y ofrecer
su asesoramiento para lograr un desempeño mejor
4/22/2009
Copyright (c) FIX Protocol Ltd.
2
Grupo de trabajo para la implementación y la
optimización



No podemos obligar a la implementación de las mejores prácticas

Se trata de un trabajo delicado; las opiniones personales sobre las mejores prácticas pueden
variar ampliamente

Las mejores prácticas pueden variar basándose en el hardware, el idioma y el sistema
operativo

Las mejores prácticas de hoy pueden ser obsoletas el próximo mes
El grupo de trabajo publicará una revista cuatrimestral revisada por colegas

Distribución: En línea (inicialmente)
Artículos para la 1ra edición:





C# Consejos de uso, Clive Browning, Rapid Addition
Mejora del desempeño de Java – Evitar la recolección de basura,
Mahesh Kumaraguru
Promoción de la seguridad de tipos en los programas Java, Mahesh
Kumaraguru
Resistencia, Cooper Noone, Counterparty Systems
Reducción de la latencia de FIX – De-Nagling, John Prewett, Citi, Lava
Trading

Temas de Windows – Modelos de E/S y Puerto finalización de E/S,
Qingjun Wei, Teraspaces Inc.
Grupo de trabajo para la implementación y la
optimización


Aceptamos de buen grado la participación, incluyendo:
 Artículos de autoría
 Revisión por colegas de artículos presentados
Para participar, mande un correo electrónico a fpl@fixprotocol.org
El FAST ProtocolSM
El FAST ProtocolSM
Antecedentes

Volúmenes incrementados de datos de mercado


FIX clásico



Ancho de banda grande y altos costos de procesamiento
Adopción difundida
Desempeño inadecuado para
 Datos de mercado
 Mercados manejados por cotizaciones
Alternativas privadas



Complica la integración (muchas interfaces diferentes)
No se comparten costos de desarrollo y mantenimiento
Adopción limitada
FAST Protocol
Factores que Influenciaron el diseño

Eficiencia
Cociente de compresión
 Consumo de recursos (CPU, memoria)
 Facilidad de uso (conceptual, implementación, operación)
Costos
 Implementación
 Validación
 Despliegue
 Operación
 Mantenimiento


FAST Protocol
Características

Conjunto de características básicas








Validado empíricamente




Optimizado para flujos de mensajes
Consciente del contenido (requiere conocimiento de la estructura del mensaje)
Representación binaria orientada al byte
Campos de longitud variable
Cada mensaje contiene uno o más campos
Un mapa de presencia capacita un uso eficaz de valores por defecto
Diversas maneras de obtener los valores por defecto
Muy rápido procesamiento (codificación / decodificación)
Altos cocientes de compresión en las alimentaciones de intercambio probadas
Implementación simple
Extendible
Capas del FAST Protocol
Mensajes de aplicación
Gestión
del patrón
Control de sesión
Codificación de campos
Codificación de transferencia
UDP
TCP
IP
Vocabulario FAST



Una corriente de datos consiste en una secuencia de mensajes.
Un mensaje consiste en una secuencia de uno o más campos.
Un campo consiste en una secuencia de uno o más bytes.

Formato cable se refiere a la representación en byte que se utiliza para
transferir datos por cable.

Codificación es el proceso de traducir al formato cable.
Decodificación es el proceso de traducir del formato cable.
Un CODEC (COdificador/DECodificador) proporciona apoyo para codificar
o decodificar una corriente de mensajes.





Un byte consiste en siete bits de datos y un bit de parada (el „SBIT‟) que
cuando está presente indica que el byte es el último byte de un campo.
Un mapa de presencia („PMAP‟) es un campo que se interpreta como un
vector de bits, un bit („PBIT‟) para cada campo en un mensaje.
Un operador de campo permite que se vuelvan a usar valores previos.
Codificación de transferencia FAST – Campos
7 bits
1 b b b b b b b
14 bits
0 b b b b b b b
1 b b b b b b b
21 bits
0 b b b b b b b
0 b b b b b b b
1 b b b b b b b
nn bits
Codificación de transferencia FAST – Detalle SBIT
•La codificación SBIT proporciona una eficiente delimitación espacial de campos
•Más compacto que un delimitador de byte para campos de menos de 7 bytes
•Datos empíricos muestran un tamaño promedio de los campos FAST de ~2 bytes
~33% más compacto que un delimitador de byte a 2 bytes
•La serialización de formato SBIT es simple y eficiente
•Hay casos excepcionales en los que la codificación SBIT es subóptima
Un vector de bytes puede utilizarse para esos casos
Codificación de transferencia FAST – Mensajes
pmap
field
field
field
pmap
pmap
field
field
Field: Campo
El número de campos en un mensaje depende del contenido del pmap
Se puede comprimir la cola de un pmap
Un mensaje puede ser tan breve como un byte (un pmap vacío)
Tipos de datos de campos de FAST







Entero sin signo
Entero con signo
Decimal (conocido también como, Número escalado compuesto)
String de caracteres ASCII
Vector de bits
Vector de bytes
Tipos de datos adicionales en FAST 1.0 que probablemente sean
desaprobados en una versión futura



Entero sin signo y sin nulo
Entero con signo y sin nulo
Número escalado
La representación de transporte FAST da apoyo a campos de tamaño
ilimitado.
Las implementaciones probablemente permitirán que el tamaño apoyado
se equipare a la representación nativa de datos en las aplicaciones.
Algunos recordatorios útiles


Algunos valores importantes para recordar
 0x80 = 128 decimal = b„10000000‟
 0x80 es un valor octeto de 0x00 con el SBIT (Bit de Parada) fijado
 0x7f = 127 decimal = b‟01111111‟
Operaciones
 & bitwise Y operación
 0x00 & 0x80 => 0x00
 0x7f & 0x80 => 0x00
 | bitwise O operación
 0x00 | 0x80 => 0x80
 0x7f | 0x80 => 0xff
Para FAST el tipo fundamental de datos es el bit
«datatype»
Bit
{documentation = b'0' or b'1'}
8
1
«type»
Octet
+Bits[8] : Bit
StopBit
+SBIT[1] : Bit = b'1' || b'0'


«type»
ContinuationByte
+SBIT[1] : StopBit = b'0'
+DBITS[7] : Bit
«type»
StopByte
+SBIT[1] : StopBit = b'1'
+DBITS[7] : Bit
SBIT – El Bit de Parada es el bit de orden alto en el byte fijado como b‟1‟ (8 °
byte) Bit 7 para indicar el final de un campo, b‟0‟ en otro caso
DBITS – Bits 6 a 0 contienen datos
¿Qué hay en el string?
0x54 0x68 0x61 0x6e 0x6b 0x20 0x59 0x6f 0x75 0x20 0x42 0x4d 0x46 0xa1
Más allá de la codificación de transferencia
Una compactación adicional requiere información sobre afinidad y
predictabilidad de los datos.
Afinidad
BeginStr SeqNum
SenderID
SendingTime
Price
Symbol
8=FIX.4.4|34=10000|49=CLIENT1|52=20060126-13:06:58.100|44=1200|55=FOO1
8=FIX.4.4|34=10001|49=CLIENT1|52=20060126-13:06:58.200|44=1210|55=FOO1
8=FIX.4.4|34=10002|49=CLIENT1|52=20060126-13:06:58.300|44=1190|55=BAR2
Predictabilidad
Patrones

Un patrón especifica como codificar un mensaje de la
aplicación en la codificación de transferencia

Un patrón acarrea
 Estructura del mensaje
 Tipos de datos
 Operadores de campo
Características de los patrones FAST

Semánticas definidas de manera formal e inambigua


Permite un comportamiento coherente y la interoperabilidad entre
implementaciones
Sintaxis concreta



Formato por defecto para crear, almacenar e intercambiar patrones
Leíble por humanos y máquinas
Sintaxis XML




Apoya la evolución de la especificación del patrón
Extensible – permite la inclusión de datos a la medida en los patrones
Ampliamente conocido y con un buen apoyo de la herramienta
Representaciones concretas alternativas
 Hard coded en el codificador y/o decodificador
 FAST codificado como lo especifica el Protocolo de Control de Sesiones
[Session Control Protocol (SCP)]
Data Types


Strings, Entero y números decimal, Booleano, Vector de Byte
Tipos restrictivos para números – tamaño de 8-bit hasta 64-bit
<template name="ExampleOrder">
<messageRef name="NewOrderSingle"/>
<string name="BeginStr"/>
<u32 name="SeqNum"/>
<string name="SenderID"/>
<string name="SendingTime"/>
<decimal name="Price"/>
<string name="Symbol"/>
</template>
BeginStr SeqNum
SenderID
SendingTime
Price
Symbol
8=FIX.4.4|34=10000|49=CLIENT1|52=20060126-13:06:58.100|44=1200|55=FOO1
8=FIX.4.4|34=10001|49=CLIENT1|52=20060126-13:06:58.200|44=1210|55=FOO1
8=FIX.4.4|34=10002|49=CLIENT1|52=20060126-13:06:58.300|44=1190|55=BAR2
Sz
44
44
44
Original Size: 71 bytes
Operadores de campo





Constante – Siempre el mismo valor
Incremental – Frecuentemente el valor previo incrementado en uno
Copia – Frecuentemente el mismo que el valor previo
Delta – Los valores pueden diferir ligeramente
Defecto – Frecuentemente un valor específico
Nombres


Los nombres identifican mensajes, patrones y campos
Los nombres de los mensajes son típicamente globales


Los nombres de los patrones son típicamente locales




Mantenidos por el dueño de un protocolo, por ejemplo FPL
Mantenidos localmente por empresas que usan o implementan FAST
Los patrones estándar pueden ser mantenidos por, por ejemplo, FPL
Se debe evitar conflictos de nombres
Los patrones usan el mismo método que en Java y XML

Los nombres pertenecen a un espacio de nombres basado en el nombre del dominio
de la empresa
La arquitectura técnica de
los sistemas de
comercialización con FIX
habilitado en América
Latina
Conferencia de FPL sobre comercialización
electrónica en América Latina
La arquitectura técnica
de sitios de comercialización habilitados para FIX
en América Latina
11 de mayo de 2009
Sitios de comercialización en Brasil que están habilitados para FIX:
•
BM&F Bovespa – segmento Bovespa – Valores y opciones en valores




•
•
•
•
Especificaciones de MultiGateway FIX: 4.0, 4.1, 4.2, 4.3 y 4.4, pero con etiquetas de 4.2.
Acceso y conectividad para las puertas de enlace 300, 310, 400, 500 y 510;
Alternativa para la conectividad API;
FIX a convertirse en la principal opción de conexión a la Bolsa
BM&F Bovespa – segmento de BM&F – Derivados
BM&F Bovespa – comercialización FX SPOT
BM&F Bovespa – Ingreso fijo – Mercado secundario para bonos del gobierno


Los tres siguen la misma especificación FIX – BELL – Enlace electrónico de BM&FBovespa
Por medio de la misma conexión, también es posible comercializar los productos de CME
GLOBEX

Listo para ir con conectividad a ROFEX.
No es el objetivo de esta presentación, pero vale la pena mencionar:


Varios corredores listos para FIX y un número de ellos en proceso;
Número creciente de comercializadores del lado comprador habilitados para FIX
Arquitectura de alto nivel – Segmento Bovespa
Arquitectura de alto nivel – Segmento Bovespa
CLIENTE DISTRIBUCIÓ
FINAL
N
INTERMEDIA
RIO
(CM/CORRED
OR)
ESTAÇÃO
MEGABOLSA
RCC
F
BVMTP
SNEG
TRANS
MISIÖN
SCOM
SCOT
MMTP RLC
GLWIN
GLTRADE
SLC
GL
Selector
SLE
ISV / Prop
FIX
HUB MMTP
FIX
FIX
Lado
comprador
Multi
Puerta de
enlace
ISV / Prop
FIX
Web
HomeBroker
(Corredor
desde el hogar)
Proveedor
es
Multi
Puerta de
enlace
MMTP RLC
NUEVO
HUB MMTP
NSC
Arquitectura de alto nivel – Segmento BM&F
Arquitectura de alto nivel – Segmento BM&F
Corredor
BM&F BOVESPA
Comercializador
<<Sistema>>
Motor de
comercialización
[HTTP-SOAP]
TCP/IP
Pantalla de
comercialización
(Client Win32)
[Protocolo FIX]
TCP/IP
<<Sistema>>
Estructuras de
comercialización
[Protocolo FIX]
TCP/IP
OMS
Conectividad FIX
Servidores de
motores
concordantes
EMS
<<Sistema>>
Planificador
CORTAFUEGOS
[Protocolo FIX]
TCP/IP
Conectividad FIX
Supervisor
Pantalla de
comercialización
(Client Win32)
DMZ
<<Sistema>>
Informe de orden
Servidores WEB
(Servicios Web)
<<Sistema>>
Conversor de
protocolo
LAN (“Firewalled”)
DMA FIX mediante la infraestructura del corredor
CLIENTE
DMA
SOCIEDAD
DE BOLSA
BM&FBOVESPA
FIX
RED
FIX
RCCF
Puerta de enlace múltiple
MegaBolsa
/
/
Puerta de enlace FIXGateway
GTS
DMA FIX mediante un proveedor de DMA
BM&FBOVESPA
SOCIEDAD
DE BOLSA
CLIENTE
DMA
FIX
FIX
RCCF
FIX
Puerta de enlace múltiple
MegaBolsa
/
/
Puerta de enlace FIXGatewayGTS
RED
Proveedor de DMA
DMA FIX para acceso al cliente (patrocinado por el corredor)
mediante Conexión Directa
CLIENTE
DE DMA
SOCIED
AD
DE
BOLSA
BM&FBOVESPA
FIX
FIX
RCCF
Puerta de enlace múltiple
MegaBolsa
/
/
Puerta de enlace FIXGateway
GTS
FIX
DMA FIX para co-ubicación (patrocinado por el corredor)
SOCIEDAD
DE BOLSA
CLIENTE
DE DMA
BM&FBOVESPA
FIX
Drop Copy
RCCF
FIX
Drop Copy
FIX
Puerta de enlace múltiple
MegaBolsa
/
/
Puerta de enlace FIXGateway
GTS
Aplicación para
co-ubicación en la Bolsa
Acceso remoto para supervisión
y mantenimiento
RED
Resumen
Capacidades de FIX
segmento Bovespa
segmento BM&F
Entrada de orden
4.0, 4.1, 4.2, 4.3, 4.4 (4.2 etiquetas) 4.4
Datos de mercado
N/C
En lugar de MMTP RLC
Disponible en FIX 4.4
Datos de mercado en formato FIX FAST
Q3/2009
Q3/2009
Preparación ISV
21 soluciones certificadas extra
Proceso de certificación ahora en
marcha
21 soluciones certificadas.
Vea en nuestro sitio web
DMA FIX mediante la infraestructura del
corredor
Disponible
Disponible
DMA FIX mediante un proveedor de DMA
Q3/2009
MarcoPolo, Bloomberg TradeBook,
GL NET
Acceso de cliente patrocinador de DMA FIX Q2/2009
Q2/2009
DMA FIX para co ubicación en la Bolsa
Q3/2009
Q3/2009
Objetivo para 2009 – Interfaz única FIX
Pantalla de comercialización
Entrada de orden /
Datos de mercado
Solución para el usuario
Conectividad FIX – Pedido (FIX 5.0) + Datos de mercado (FIX FAST)
Pedido encaminado hacia uno de los 3 motores de
correspondencia
MegaBolsa
GTS
Sisbex
Resumen de capacidad
Mercado y períodos
Operaciones
por día
Radio
RTT
(ms)
Eventos de
pedido por
segundo
agregado
Eventos de
pedidos por
segundo por
instrumento
Valores 2008
770,000
10
290
500
5
Valores 2009
1,500,000
15
8
4,000
125
Derivados 2008
200,000
4
25
3,750
40
Derivados 2009
200,000
15
8
4,000
125
Conceptos de capacidad
•
•
•
Planeamiento de capacidad diaria
utilización promedio del 10% de la mayor parte de la infraestructura
5 indicadores clave:





Operaciones por día
Proporción de eventos de órdenes (número de eventos de órdenes en relación con el número
de operaciones)
RTT – Tempo de ida y vuelta o tiempo de respuesta
Eventos de órdenes por segundo sobre utilización agregada
Eventos de órdenes por segundo por instrumento único
US
Pedido de compra por
un contracto de 500
futuros de S&P
RED DE
GLOBEX
COMUNICACIÓN
communicationDE
GLOBEX
network
CME
GROUP
GLOBEX
CORRESPONDENCIA
Orden de venta por un
contracto de 500
futuros de S&P
LIQUIDACIÓN EN USD
MEDIANTE COMPENSACIÓN DE CME
BRASIL
Pedido de venta por un
contrato de ID de
futuros
BM&FBOVES
PA GTS
GTS
COMMUNICATION
NETWORK
CORRESPONDENCIA
Orden de venta por un
contrato de ID de
futuros
LIQUIDACIÓN EN USD
MEDIANTE COMPENSACIÓN DE CME
US
Orden de compra por un
contrato de ID de
futuros
RED DE
COMUNICACIÓN DE
GLOBEX
BRASIL
CME
GROUP
GLOBEX
BM&FBOVES
PA GTS
RED DE
Enlace internacional
de alta velocidad y
gran capacidad
COMUNICACIÓN
GTS
CORRESPONDENCIA
Orden de venta por un
contrato de ID de
futuros
LIQUIDACIÓN EN BRL MEDIANTE
COMPENSACIÓN DE DERIVADOS DE
BM&FBOVESPA, QUE PUEDE
FACILITARSE POR EL BANCO DE
BM&FBOVESPA
US
GLOBEX
COMMUNICATION
NETWORK
BRASIL
CME
GROUP
GLOBEX
BM&FBOVES
PA GTS
Enlace internacional
de alta velocidad y
gran capacidad
CORRESPONDENCIA
Orden de venta por un
contracto de 500 futuros de
S&P
LIQUIDACIÓN EN USD MEDIANTE
COMPENSACIÓN DE CME GROUP, QUE
PUEDE FACILITARSE POR EL BANCO DE
BM&FBOVESPA
Pedido de compra por un
contracto de 500 futuros de
S&P
GTS
COMMUNICATION
NETWORK
GRACIAS!
THANK YOU!
Obrigado!
The Technical Architecture of FIX Enabled Trading
Venues in Latin America
Lunes 11 de Mayo de 2009
Agenda
• Acerca de ROFEX
• Servicios FIX actuales
• Arquitectura física
• Usuarios actuales
• Modelos DMA
• Certificación
• Cross listing ROFEX – BM&F
• Nueva plataforma ROFEX 2010
Acerca de ROFEX
• Mercados habilitados
• División derivados financieros
• División derivados agropecuarios
• Productos principales
• Futuros sobre tipo de cambio
dólar – peso argentino.
• Indice Soja Rosafe.
• Ventajas
Volumen (miles de contratos)
45,000
40,000
35,000
30,000
25,000
20,000
15,000
10,000
5,000
0
2003
2004
• Contraparte Central.
• Destacados plataforma electrónica
• Negociación electrónica desde 1997.
• Acceso vía Internet desde 2000.
• Módulo para asignaciones desde 2007.
• Módulo integrado para manejo de give ups 2007.
2005
2006
2007
2008
Servicios FIX actuales
• Lanzamiento
• Fecha: Julio 2007. Primera plataforma abierta de negociación
electrónica en Argentina.
• Destacados
• Versión: FIX 4.2
• Pre-Trade: Market Data
• Trade: Ordenes simples
• Tipos de órdenes y parámetros de tiempo soportados:
Standard Limit (day), Market to Limit (IOC)
• Productos: Derivados (futuros y opciones)
• Rendimiento
• Procesamiento de órdenes: 60/seg.
• Latencia media: 300 mseg.
Arquitectura física
Datacentre A
Datacentre B
Internet Clients
Private Proxy 1
Private Proxy
1
Public Proxy
4
Public Proxy
1
AGRO‟
AGRO
Public Proxy
2
Private Proxy 2
INTERNET
Firewall
Firewall
Private Proxy
2
Public Proxy
5
DDF‟
DDF
Private Proxy
3
Public Proxy
3
FIX Gateway
FIX Gateway
Public Proxy
6
FIX Gateway
|
Primary
A Network
B Network
Client 1
Client 2
Rosario
Client 9
Tolerancia a fallas. 99,9% disponibilidad.
Línea punto a punto, VPN sobre Internet.
Private Proxy
3
FIX Gateway
Usuarios actuales
• Vendedores de información.
• Bloomberg
• CMA
• Thomson Reuters (*)
• Vendedores independientes de Software
• Primary Brokers S.A.
• Agentes/Miembros
• Invertir Online (*)
• Unigrain
(*) Certificación/pruebas en curso.
Modelos DMA
• Modelo tradicional
• Clientes acceden al mercado utilizando
terminal del Agente
• Modelo de proveedor de software independiente
• Clientes acceden a través de pantallas de
negociación desarrolladas por terceros
• Monitoreo
• Acceso patrocinado
• Cliente accede directo al Mercado
• Monitoreo
• Administración de riesgo
Certificación ROFEX - FIX
• Cómo certificar:
1. Descargar ROFEX RoE.
2. Reuniones con equipo de soporte para
evacuar dudas relacionadas con RoE.
3. Armado de ambiente de pruebas.
4. Ejecución de diferentes casos de prueba.
• Rules of Engagement (http://fixhub.primary.com.ar/certificacion.html)
• Acceso flexibe tanto desde VPN como desde líneas punto a punto.
• Todo el proceso es soportado por nuestro departamento de TI.
• Usualmente el proceso dura seis semanas.
Cross listing ROFEX – BM&F
• Cross-listing de productos agropecuarios.
• Concepción previa a proyecto BM&F – CME.
• Integración FIX 4.2 (Rofex) – FIX 4.4 (BM&F).
• Fase técnica del proyecto terminada.
• Implementación temporariamente suspendida
debido a limitaciones regulatorias sobre el flujo de
capitales dentro-fuera de la Argentina.
Nueva plataforma e-Rofex
• Fecha estimada de lanzamiento. Abril 2010
• FIX 4.4-5.0 nativo plataforma Java/C++
• Rendimiento
• Latencia: < 20 msec
• Capacidad de procesamiento: 500 ordenes/seg/instrumento
• Funcionalidades
• Pre-Trade.
• Multi-instrumento
• Market Data
• Cotización masiva / RFQ
• Trade.
• Ordenes simples / Estrategias
• Order Crosses
• Post-trade.
• Give-ups
• Asignaciones
• Reportes de cartera/posición
11 de Mayo de 2009
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
11 de Mayo de 2009
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
La Arquitectura Técnica de las plataformas de trading
que implementan FIX en Latinoamérica
FPL Latin America
Electronic Trading Conference 2009
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
La Arquitectura Técnica de las plataformas de trading que implementan FIX en Latinoamérica
AGENDA
Antecedentes de MVM
Plataforma y servicios FIX actuales
Arquitectura Física
Usuarios y Acceso
DMA
Conectividad y Certificación
Mejoras planeadas
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
Antecedentes de MVM
 Mercado de Valores basado en Mendoza, Argentina
 Fundado en 1958
 Negocia acciones y bonos. Derivados sobre acciones en desarrollo.
 40 agentes (12 en 2007)
 Actualmente el único mercado de acciones que soporta FIX en Argentina
 15 % es el market share actual en el volumen negociado de las principales
acciones (medido en $)
 El volumen crece a un 50% mensual promedio acumulado desde el
lanzamiento de Oasis FIX.
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
SERVICIOS FIX ACTUALES
Nuevo sistema de negociación Oasis lanzado el 15 de Diciembre de 2008
Plataforma con API nativa FIX 4.4. implementada en Java y C++
Procesos de desarrollo, integración y operación certificados ISO 9001:2000
Amplia funcionalidad FIX
Pre-trade
Security List
Market data
Trade
SingleOrderHandling
Drop copies
Status /Mass Status Request
Post Trade
RequestForPosition / PositionReport
NMS like compliance check
Perfomance
35 msec RTT
250 ordenes x seg de capacidad actual instalada.
1,5 ordenes x seg y 25 ordenes x seg es la utilización media y pico actualmente
Versión actual escalable por hardware hasta 250 ordenes x seg x instrumento
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
ARQUITECTURA FISICA
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
USUARIOS ACTUALES
 100 % de los usuarios acceden via la interface nativa FIX
 El mercado provee una aplicación cliente FIX nativa
implementada en Java para ser utilizada como OMS
 Excel trading integrado al OMS
 Plataforma de distribución retail Web / Mobile trading es
provista a los agentes en un modelo ASP/SaaS.
 Próximos pasos:
Data vendors
ISV’s
Contraparte Central
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
DMA
DMA / Acceso esponsoreado
El cliente se conecta directamente al gateway FIX de Oasis
El agente monitorea la actividad del cliente via la funcionalidad nativa de drop copies
Se proveen herramientas de gestión de riesgo
DMA via ISV’s
El cliente se conecta a la red o el OMS del ISV
El monitoreo / gestión de riesgo actual es análoga al DMA Puro
Para Q4 2009 se planea incluir la opción de validación manual y control automático de
riesgo y compliance pre-aceptación de órdenes
DMA tradicional
El cliente se connecta al OMS del agente y tras su aceptación las órdenes son ruteadas
a Oasis
Para información sobre agentes que ofrecen DMA http://oasis.primary.com.ar/dma/index.html
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
CERTIFICACION Y CONECTIVIDAD
Información General http://oasis.primary.com.ar/certification/index.html
ROE http://oasis.primary.com.ar/docs/index.html
Fases y tiempos de realización estimados:
Solicitud, Conectividad y Setup inicial(1 semana)
Certificación de Market Data (3 semanas)
Certificación de Order management (4 semanas)
Alternativas de Conectividad
VPN
Líneas punto a punto
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
MEJORAS PLANEADAS DURANTE EL PROXIMO AÑO
Funcionalidad
Alinear fases de negociación de acuerdo estandares internacionales
Incluir funcionalidades de IOI/RFQ/MassQuote
Agregar órdenes de tipo conditional / reserve / pegged al motor de negociación
Permitir conectividad FIX 4.x. + 5.0
Mejorar gestión nativa de riesgo y compliance
Perfomance
Reducir latencia RTT a menos de 20 msegs
Incrementar capacidad de procesamiento a 1000 ordenes/segundo/instrumento
Acceso
Conectar OASIS a redes transaccionales internacionales (Radianz, Savvis, TNS)
Conectar OASIS a otros mercados locales y regionales
11 de Mayo de 2009
MERCADO DE VALORES DE MENDOZA
GRACIAS POR SU ATENCION
PyR
11 de Mayo de 2009