Especificación BMV Multicast para Market Data

(1)

1

Especificación BMV Multicast para

Market Data

Versión 2.2

(2)

2

Índice

Índice ... 2 1.0 Introducción ... 4 1.1 Propósito ... 4 1.2 Historia de versiones ... 4 2.0 Conectividad ... 6 2.1 Estándares de transmisión ... 6 2.1.1 Canales Multicast ... 6 2.1.2 Canales Unicast ... 6 2.1.3 Homologación de conceptos ... 7

3.0 Servicio información en línea (Real Time Channel) ... 7

3.1 Heartbeat... 8

4.0 Recuperación ... 8

4.1 Pérdida de mensajes del flujo en línea ... 8

4.2 Estableciendo una conexión... 9

4.3 Servicio de retransmisiones (Replay Channel) ... 13

4.3.1 Solicitando mensajes perdidos ... 15

4.3.2 Respuesta a una solicitud de retransmisión ... 16

4.3.3 Terminar conexión ... 16

4.4 Servicio de snapshots (Recovery Channel)... 16

4.4.1 Solicitando un snapshot ... 19

4.4.2 Lista de instrumentos. ... 20

4.4.3 Respuesta a un snapshot de profundidad completa de un solo instrumento ... 20

4.4.4 Respuesta a un snapshot de profundidad completa de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast ... 20

4.4.5 Respuesta a un snapshot de niveles de precio de un solo instrumento ... 21

4.4.6 Respuesta a un snapshot de niveles de precio de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast ... 21

4.4.7 Respuesta a un snapshot de hechos de un solo instrumento... 21

4.4.8 Respuesta a un snapshot de hechos de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast ... 22

4.4.9 Respuesta a un snapshot de mejores posturas de un solo instrumento ... 22

4.4.10 Respuesta a un snapshot de mejores posturas de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast ... 22

5.0 Recuperación de servicios en la recepción y solicitud de mensajes. ... 23

5.1 Fallos en distribución y recepción sobre el Servicio de información en línea ... 23

5.1.1 Fallo de una de las aplicaciones encargada de distribuir uno de los dos feeds que envían la información de alguno de los productos ofrecidos vía multicast... 23

(3)

3

5.1.2 Fallo en la recepción de ambos feeds que se encargan de difundir la información por completo de alguno de los productos que se ofrecen vía

multicast ... 24

5.2 Fallo en el servicio de retransmisiones ... 24

5.3 Fallo en el servicio de snapshots ... 25

5.4 Cambio de sesión y reinicio de secuencias en los diferentes canales de comunicación ... 26

6.0 Mensajes ... 26

6.1 Encabezado. ... 26

6.2 Bloque de mensajes. ... 27

En la siguiente imagen se puede apreciar una representación de los bits en un ejemplo con dos mensajes en un paquete. El primer mensaje con 10 bytes de longitud y el segundo con 5 bytes. ... 27

6.3 Números de secuencia. ... 28 6.4 Tipos de datos. ... 28 6.5 Mensajes administrativos ... 30 6.5.1 Heartbeat ... 30 6.5.2 Inicio de sesión ... 30 6.5.3 Solicitud de retransmisión ... 30 6.5.4 Solicitud de snapshot ... 31

6.5.5 Solicitud de fin de sesión ... 31

6.5.6 Respuesta de inicio de sesión ... 32

6.5.7 Respuesta de retransmisión ... 32 6.5.8 Respuesta de snapshot. ... 33 6.5.9 Snapshot Terminado ... 34 6.6 Mensajes de aplicación. ... 35 6.6.1 Eventos de sistema ... 35 6.6.2 Hechos de capitales ... 35

6.6.3 Hechos del mercado de derivados ... 36

6.6.4 Hechos de sociedades de inversión ... 36

6.6.5 Cancelación de Hecho ... 37 6.6.6 Hechos virtuales ... 37 6.6.7 Alta de orden ... 38 6.6.8 Modificación de órdenes ... 39 6.6.9 Ejecución de órdenes ... 39 6.6.10 Disminución de volumen ... 40 6.6.11 Cancelación de órdenes ... 40 6.6.12 Profundidad ... 41

6.6.13 Precio probable de asignación ... 41

6.6.14 Inicio de subastas continuas ... 42

6.6.15 Cambios de estado ... 42

6.6.16 Estadísticas de los instrumentos ... 42

6.6.17 Catálogos de instrumentos ... 43

(4)

4

6.6.19 Precio Promedio Ponderado / Precios de liquidación ... 48

6.6.20 Mejor Postura ... 48 6.6.21 INAV ... 49 6.6.22 Índices generales ... 49 6.6.23 Índices principales ... 50 6.6.24 Interés Abierto ... 50 6.6.25 Operaciones de registro ... 51 6.6.26 Ofertas Públicas ... 51 Apéndice A Catálogos ... 52 Tipo de Operación ... 52 Tipo de Concertación ... 52 Bursatilidad ... 55 Referencia ... 55

Estado del instrumento ... 55

Estados del Índice ... 56

Muestras de Índices generales. ... 56

Tendencia ... 57

Muestra de Índices principales. ... 57

Códigos de evento del sistema ... 58

Catálogo de Tipos de Oferta Pública ... 58

Catálogo de Tipos de Liquidación ... 59

Catálogo de Grupos de Market Data ... 59

1.0 Introducción

1.1 Propósito

El propósito de este documento es proveer los detalles por completo del servicio de BMV Multicast para market data.

1.2 Historia de versiones

Este documento ha sido modificado de acuerdo a la siguiente tabla:

Versión Fecha Descripción

1 16 de diciembre de 2015 Primera versión de este documento para ser distribuida a los consumidores. 1.1 8 de abril de 2016 Se agregan campos en formato P de

hechos:

(5)

5

 Vende  Liquidación

1.2 8 de abril de 2016 Se agrega el campo PPP a formato “a” 1.3 8 de abril de 2016 Se ajusta clave del formato de difusión del

valor teórico de los Tracs durante el remate.

1.4 8 de abril de 2016 Se agregan campos al formato “U” de Índices.

1.5 8 de abril de 2016 Se agregan campos en formato V de hechos virtuales:

 Compra  Vende

1.6 8 de abril de 2016 Se agrega VIMEX al catálogo de muestras de Índices

1.7 12 de abril de 2016 Se actualiza definición y clave para el formato de estadísticas de derivados. 1.8 12 de abril de 2016 Se agrega formato de hechos de

sociedades de inversión.

1.9 19 de abril de 2016 El identificador del instrumento será único y se incrementará a 4 bytes en todos los formatos.

1.10 20 de abril de 2016 Se ajusta catálogo de estados del instrumento.

1.11 20 de abril de 2016 Se agrega el campo de bursatilidad numérica al formato “a”.

1.12 20 de abril de 2016 Se corrigen los valores de la

representación hexadecimal del campo de formato en los mensajes administrativos. 1.13 22 de abril de 2016 Se ajusta la petición de hechos en el canal

de recuperación de Snapshots para

indicar que se pueden recuperar todos los hechos por producto o por instrumento. 1.14 22 de abril de 2016 Se agrega campo calificación en formato f

de sociedades de inversión.

2.0 22 de abril de 2016 Se ajustan descripciones de los mensajes de órdenes para profundidad completa. 2.1 3 de mayo de 2016 Se agrega campo de mercado en formatos

a y b.

Se agrega catálogo de mercados.

(6)

6

2.0 Conectividad

2.1 Estándares de transmisión 2.1.1 Canales Multicast

Multicast es el envío de la información en múltiples redes a múltiples destinos simultáneamente.

Antes del envío de la información, deben establecerse una serie de parámetros. Para poder recibirla, es necesario establecer lo que se denomina "grupo

multicast". Ese grupo multicast tiene asociado una dirección de internet. La versión actual del protocolo de internet, conocida como IPv4, reserva las direcciones de tipo D para la multidifusión.

Una dirección multicast está asociada con un grupo de receptores interesados. De acuerdo al RFC 3171 las direcciones desde la 224.0.0.0 a la

239.255.255.255 están destinadas para ser direcciones de multicast. Este rango se llama formalmente "Clase D". El emisor envía un único datagrama (desde la dirección unicast del emisor) a la dirección multicast y el router se encargará de hacer copias y enviarlas a todos los receptores que hayan informado de su interés por los datos de ese emisor.

El canal multicast utiliza UDP sobre IPv4. Cada datagrama UDP contendrá solo un Encabezado BMV Multicast.

2.1.2 Canales Unicast

Los servicios de retransmisión y de snapshots utilizan TCP sobre IPv4.

Cada cliente que desee conectarse a estos servicios deberá avisar previamente al grupo de Market Data para que su IP, usuario y password sea registrado. El mismo usuario y password será utilizado para el inicio de sesión en los servicios de retransmisión y snapshots.

En la siguiente imagen se puede apreciar una diferencia entre Multicast y Unicast.

(7)

7

2.1.3 Homologación de conceptos

En lo sucesivo se usará el término paquete para referirnos a la información de Market Data que fluye a través de UDP y de TCP/IP.

3.0 Servicio información en línea (Real Time Channel)

Este canal de transmisión se encarga de enviar la información de Market Data de BMV en línea, vía multicast, como se muestra en el Diagrama 1.

(8)

8

Diagrama 1: Información en línea.

Los receptores multicast tendrán acceso a dos feeds idénticos: Feed A y Feed B. Los receptores se encargaran de recibir ambos feeds y descartar entre ellos para minimizar la pérdida de mensajes.

La información que viaja a través del feed A y el feed B se envía al mismo tiempo pero puede llegar a los destinatarios con una pequeña diferencia de tiempo entre ellos, no se puede garantizar que la información llegue primero en un canal de distribución que en otro o que llegue al mismo tiempo.

3.1 Heartbeat

Existirán mensajes de Heartbeat que indican la última secuencia que se ha enviado en ese grupo y puerto multicast. Estos mensajes solo se difundirán en caso de inactividad dentro del emisor y se enviarán cada cinco segundos.

4.0 Recuperación

4.1 Pérdida de mensajes del flujo en línea

Si una pérdida de mensajes es detectado en el canal multicast, el receptor deberá iniciar alguno de los procesos de recuperación que se describen en el Diagrama 2 y que son detallados más adelante en el documento.

(9)

9

Diagrama 2 Validación de secuencias.

Nota: Se considera una pequeña pérdida de mensajes cuando la cantidad que se ha perdido es menor al límite que se establece para la retransmisión, en este caso es de 20 mil mensajes.

4.2 Estableciendo una conexión

El receptor deberá usar la correspondiente dirección IP y puerto para establecer una sesión TCP/IP con cualquiera de los dos canales unicast. El consumidor debe iniciar una sesión enviando un mensaje de Solicitud de inicio de sesión. El servidor del canal unicast valida usuario, contraseña y dirección IP del

(10)

10

Una vez que el consumidor es autenticado de manera exitosa, el servidor responderá con un mensaje de Respuesta de inicio de sesión con el campo de estatus igual a “A”.

Existen casos en los que el inicio de sesión no es exitoso pero sí se envía una respuesta como se puede apreciar en el Diagrama 3:

 Si un consumidor excede el número permitido de intentos de sesión para el día en curso, el servidor rechazará algún nuevo intento de sesión con un mensaje de Respuesta de inicio de sesión y terminará la conexión TCP/IP. El valor del campo estatus de tal mensaje será “b”.

 Un intento de inicio de sesión al canal unicast hecha a una sesión de un receptor ya iniciada vía la misma conexión TCP/IP recibirá un mensaje de Respuesta de Retransmisión o Respuesta de snapshot con estatus igual a “e”.

 Si un receptor quien ya inició una sesión envía otro inicio de sesión vía una conexión TCP/IP diferente a la actual, el sistema responde con un mensaje de Respuesta de inicio de sesión con estatus igual a “e” y cierra la segunda conexión TCP/IP. La primer conexión no es cerrada en este caso.

(11)

11

Diagrama 3 Inicio de sesión no exitoso con respuesta.

También existen casos en los que el inicio de sesión no es exitoso y no se envía una respuesta como se puede ver en el Diagrama 4:

 Si un intento de inicio de sesión falla porque no es válido el usuario, la contraseña o la dirección IP del consumidor o si un mensaje es enviado al servidor antes de que el inicio de sesión sea establecido, el servidor acabará la conexión TCP/IP con el receptor sin enviar un mensaje de Respuesta de inicio de sesión.

(12)

12

 Si un mensaje de Solicitud de retransmisión o Solicitud de snapshot no es recibido dentro de los 5 segundos posteriores a un satisfactorio inicio de sesión, el servidor finalizará la conexión TCP/IP con el receptor sin enviar un mensaje notificando el motivo.

 Si un mensaje de Solicitud de inicio de sesión no es recibido dentro de los 5 segundos posteriores a la conexión TCP/IP establecida el servidor finalizará la conexión TCP/IP sin enviar un mensaje avisando el motivo.

(13)

13

Diagrama 4 Inicio de sesión no exitoso sin respuesta.

4.3 Servicio de retransmisiones (Replay Channel)

El canal TCP para Retransmisión debe ser usado por los destinatarios para recuperarse de una pérdida de datos a pequeña escala. Éste permite a los consumidores solicitar retransmisión de un limitado número de mensajes que ya han sido publicados por el canal multicast. El canal está configurado para

soportar la retransmisión de los últimos 20,000 mensajes publicados. El flujo completo del servicio de retransmisiones se puede apreciar en el Diagrama 5.

(14)

14

Diagrama 5. Flujo de mensajes en el servicio de retransmisión.

Cada receptor puede iniciar sesión en el canal de retransmisión y solicitar el envío de una cierta cantidad de mensajes que se han difundido por un cierto grupo y puerto multicast, pero las solicitudes solo podrán realizarse un limitado número de ocasiones cada día. Los destinatarios pueden solicitar al

(15)

15

sobre el canal de retransmisión, ésta funcionalidad intenta ayudar a manejar una situación de emergencia y no debería ser empleada como una práctica normal.

Si un mismo consumidor envía múltiples solicitudes sobre el canal de

retransmisión, ellas serán procesadas secuencialmente (es decir una a la vez). No se puede cancelar una solicitud de retransmisión.

En caso de un problema en el sitio primario en el que no se pueda restablecer la operación, las peticiones de retransmisión tendrán que hacerse en el sitio de respaldo como se puede observar en el Diagrama 6. BMV será el encargado de notificar el momento en el que se migrarán los servicios al sitio de respaldo.

Diagrama 6. Servicio de retransmisiones.

4.3.1 Solicitando mensajes perdidos

Una vez conectado al canal de retransmisión, los consumidores pueden usar el mensaje de Solicitud de retransmisión para pedir los mensajes perdidos. La

(16)

16

solicitud deberá incluir el número de secuencia del primer mensaje en el rango a ser retransmitido, junto con el número de mensajes a ser retransmitidos. La petición será atendida desde el servidor de caché de los últimos mensajes publicados en el canal multicast. Si la solicitud de retransmisión incluye uno o más mensajes que no están el Servidor de caché, la solicitud entera será rechazada con un mensaje de Respuesta de snapshot y ningún mensaje será retransmitido.

4.3.2 Respuesta a una solicitud de retransmisión

El servidor responderá a un mensaje de Solicitud de retransmisión con un mensaje de Respuesta de retransmisión para indicar si la retransmisión es satisfactoria o no. Un valor diferente de “A” en el campo status indicará que la solicitud ha sido rechazada.

En el caso de una solicitud satisfactoria, el servidor retransmitirá los mensajes solicitados inmediatamente después del mensaje de Respuesta de

retransmisión. Los números de secuencia de los mensajes retransmitidos serán los mismos como cuando ellos fueron transmitidos por el canal multicast.

4.3.3 Terminar conexión

Si el receptor no envía una solicitud de Finalización de sesión y no termina la conexión durante los siguientes 5 segundos posteriores al momento del envío del último mensaje perdido, el servidor finalizará la conexión TCP/IP.

4.4 Servicio de snapshots (Recovery Channel)

El canal TCP para Snapshots debe ser usado por los destinatarios para recuperarse de una pérdida de datos a gran escala (es decir a una conexión tardía al mercado o a una gran interrupción).

En el Diagrama 7 se puede ver la secuencia que sigue el flujo de información en el servicio de snapshots.

(17)

17

Diagrama 7. Secuencia del servicio de snapshots.

Los servicios ofrecidos por el canal de distribución de acuerdo al producto asociado son los siguientes:

(18)

18

• Este servicio será ofrecido en todos los grupos y puertos multicast y se encargará de distribuir los Catálogos de instrumentos. • Si tiene asociado profundidad completa

• El sistema tendrá la opción de enviar las órdenes activas de un instrumento o de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast.

• Si tiene asociado un producto en el que se envíen solo unos cuantos niveles de precio.

• El sistema almacenará en cache el último mensaje de profundidad enviado por instrumento y el consumidor podrá solicitar el último mensaje de un instrumento o de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast.

• Si tiene asociado algún producto en el que se difundan hechos: • El sistema mantendrá en cache todos los hechos generados

durante el día. Enviará tanto las altas como las bajas que se hayan generado al momento de la solicitud.

• Existirá la opción de pedir los hechos de un instrumento o de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast.

• Si tiene asociado algún producto con el mejor precio de compra o venta.

• El sistema almacenará en cache el último mensaje de mejor postura enviado por instrumento y el receptor podrá solicitar el último mensaje de un instrumento o de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast.

Cada consumidor puede iniciar sesión en el canal de snapshots y solicitar él envió de un cierto snapshot, pero las solicitudes solo podrán realizarse un limitado número de ocasiones cada día. Los destinatarios pueden solicitar al Administrador de Market Data en la BMV reiniciar su contador de peticiones sobre este canal, ésta funcionalidad intenta ayudar a manejar una situación de emergencia y no debería ser empleada como una práctica normal.

Si un receptor envía múltiples solicitudes sobre este canal, serán procesadas secuencialmente (es decir una a la vez). No se puede cancelar una solicitud.

(19)

19

En caso de un problema en el sitio primario en el que no se pueda restablecer la operación, las peticiones de snapshots tendrán que hacerse en el sitio de respaldo como se puede observar en el Diagrama 8.

Diagrama 8. Servicio de snapshots. 4.4.1 Solicitando un snapshot

Cuando el inicio de sesión ha sido aceptado entonces los receptores podrán usar el mensaje de Solicitud de snapshot para descargar la lista de los

instrumentos activos, solicitar las órdenes activas, los niveles de precio, mejores posturas o algunos de los últimos hechos que han ocurrido al momento de la petición.

Dentro del mensaje de Solicitud de snapshot existe un campo requerido en donde envían el identificador del producto del cual requieren el snapshot, en caso de no enviar el producto la solicitud es rechazada con el mensaje Respuesta de Snapshot.

(20)

20

También existe un campo de tipo de snapshot en donde es requerido indicar uno de los 5 tipos de snapshots que existen, en caso de no enviar el tipo de snapshot la solicitud es rechazada con el mensaje Respuesta de Snapshot. El campo identificador del instrumento dentro del mensaje Solicitud de snapshot no es requerido y en caso de que no se envíe, la solicitud será atendida con la información de todos los instrumentos del producto del que se está solicitando el snapshot.

4.4.2 Lista de instrumentos.

Una petición de la lista de instrumentos aceptada genera un mensaje de

Respuesta de snapshot indicando que la solicitud será atendida. Posterior a la respuesta se enviaran los Catálogos de instrumentos que fueron difundidos al inicio del día por el grupo y puerto multicast de la solicitud.

No se puede solicitar el detalle de un solo instrumento, en este caso siempre se enviará un grupo completo.

Al finalizar de enviar los mensajes de Catálogos de instrumentos se enviará un mensaje de Snapshot terminado indicando que la solicitud ha sido

completada. En este caso el mensaje de fin no incluirá la secuencia con la cual se sincroniza con respecto al flujo en línea debido a que son mensajes que están almacenados y en un día normal de operación solo se difunden una sola vez por el canal multicast.

4.4.3 Respuesta a un snapshot de profundidad completa de un solo instrumento Una petición aceptada de un snapshot de profundidad completa sobre un instrumento genera un mensaje de Respuesta de snapshot indicando que la solicitud será procesada. Después de eso se enviará un mensaje de Estado del instrumento seguido de las órdenes que están activas dentro del libro principal y al final un mensaje de Snapshot terminado con la secuencia con la que se sincroniza con respecto al canal que distribuye la información en línea.

4.4.4 Respuesta a un snapshot de profundidad completa de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast

Una petición aceptada de un snapshot de profundidad completa sobre un grupo y puerto multicast genera un mensaje de Respuesta de snapshot indicando que la solicitud será procesada. Después se enviaran los mensajes en bloques separados por instrumento. Lo primero que se enviará será un mensaje de Estado del instrumento seguido de las órdenes que están activas dentro del

(21)

21

libro principal para ese instrumento. Cuando termine de difundir las órdenes del instrumento se enviará otro mensaje de Estado del instrumento con el

siguiente instrumento a ser enviado seguido de sus posturas.

Al finalizar con todos los instrumentos se enviará un mensaje de Snapshot terminado con la secuencia con la que se sincroniza con respecto al canal que distribuye la información en línea.

4.4.5 Respuesta a un snapshot de niveles de precio de un solo instrumento Una petición aceptada de un snapshot de niveles de precio sobre un

instrumento genera un mensaje de Respuesta de snapshot indicando que la solicitud será procesada. Después de eso se enviará un mensaje de Estado del instrumento seguido del último mensaje de profundidad que ha sido enviado para ese instrumento y al final un mensaje de Snapshot terminado con la secuencia con la que se sincroniza con respecto al canal que distribuye la información en línea.

4.4.6 Respuesta a un snapshot de niveles de precio de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast

Una petición aceptada de un snapshot de niveles de precio sobre un grupo y puerto multicast genera un mensaje de Respuesta de snapshot indicando que la solicitud será procesada. Después se enviaran los mensajes en bloques separados por instrumento. Lo primero que se enviará será un mensaje de Estado del instrumento seguido del último mensaje de profundidad que ha sido enviado para ese instrumento. Cuando termine de difundir el mensaje de profundidad del instrumento se enviará otro mensaje de Estado del

instrumento con el siguiente instrumento a ser enviado seguido de su mensaje de profundidad.

4.4.7 Respuesta a un snapshot de hechos de un solo instrumento

Una petición aceptada de un snapshot de hechos sobre un instrumento genera un mensaje de Respuesta de snapshot indicando que la solicitud será

procesada. Después de eso se enviará un mensaje de Estado del instrumento seguido de la cantidad de hechos que hayan sido generados. Las transacciones que se irán almacenando serán tanto las bajas como las altas de hechos. Al

(22)

22

terminar de enviarse los hechos se enviará un mensaje de Snapshot complete en donde se indica que ha terminado la transacción.

4.4.8 Respuesta a un snapshot de hechos de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast

Una petición aceptada de un snapshot de hechos sobre un grupo y puerto multicast genera un mensaje de Respuesta de snapshot indicando que la solicitud será procesada. Después se enviaran los mensajes en bloques separados por instrumento. Lo primero que se enviará será un mensaje de Estado del instrumento seguido de la cantidad de hechos que hayan sido generados. Cuando se terminen de difundir los hechos se enviará otro mensaje de Estado del instrumento con el siguiente instrumento a ser enviado seguido de sus correspondientes hechos.

Al finalizar con todos los instrumentos se enviará un mensaje de Snapshot terminado.

4.4.9 Respuesta a un snapshot de mejores posturas de un solo instrumento Una petición aceptada de un snapshot de mejores posturas sobre un

instrumento genera un mensaje de Respuesta de snapshot indicando que la solicitud será procesada. Después de eso se enviará un mensaje de Estado del instrumento seguido de dos mensajes que indican la mejor postura por lado del instrumento y al final un mensaje de Snapshot terminado con la secuencia con la que se sincroniza con respecto al canal que distribuye la información en línea.

4.4.10 Respuesta a un snapshot de mejores posturas de todos los instrumentos que se distribuyen a través de un grupo y puerto multicast

Una petición aceptada de un snapshot de mejores posturas sobre un grupo y puerto multicast genera un mensaje de Respuesta de snapshot indicando que la solicitud será procesada. Después se enviaran los mensajes en bloques separados por instrumento. Lo primero que se enviará será un mensaje de Estado del instrumento seguido de los mensajes de mejores posturas del instrumento. Cuando termine de difundir los mensajes de mejores posturas se enviará otro mensaje de Estado del instrumento con el siguiente instrumento a ser enviado.

(23)

23

5.0 Recuperación de servicios en la recepción y solicitud de

mensajes.

Visto de manera muy general, como ya se ha dicho el protocolo BMV Multicast para Market Data se compone de:

 Servicio de información en línea que distribuye la misma información por medio de dos aplicaciones (denominados Feeds) sobre canales multicast diferentes.

 Servicio de retransmisiones, destinado a la recuperación de una cantidad de mensajes menores a 20 mil.

 Servicio de snapshots, destinado a la recuperación ante una gran pérdida de mensajes o de una conexión a destiempo al mercado.

El siguiente apartado presenta la forma de actuar de cada uno de los componentes luego de algún fallo presentado en uno o más de ellos y que acciones podrían ejecutar los consumidores del Market Data.

5.1 Fallos en distribución y recepción sobre el Servicio de información en línea 5.1.1 Fallo de una de las aplicaciones encargada de distribuir uno de los dos feeds que envían la información de alguno de los productos ofrecidos vía multicast.

Existen dos aplicaciones distribuyendo la misma información, por canales multicast diferentes. Suponga el escenario de que uno de ellos falle por alguna razón, considere el Feed A por ejemplo:

Por un lado el Feed B, que permanece en servicio seguirá proporcionando mensajes de forma normal; es decir, se mantendrá el flujo y envío de mensajes que salen de él, sin alterar o perder la secuencia de los mismos.

Una vez restablecido el servicio en el Feed A, que presentó la falla, se continúa con el envío de mensajes en la misma secuencia en que se encuentre el Feed B al momento de dicho restablecimiento.

En resumen, ¿Cómo se vería éste escenario con un ejemplo?. Suponga al inicio que el Feed A y B están funcionando a la par enviando los mismos mensajes.

(24)

24

Ahora suponga que el Feed A falla luego del envío de la secuencia 1,000,000 durante la sesión 1. El Feed B continuará trabajando ininterrumpidamente. Posteriormente, el Feed A restablece su servicio cuando el Feed B se encuentra en la secuencia 1'500,000, el mensaje y secuencia con que iniciará ese Feed A será justo la correspondiente al mensaje 1'500,000 del Feed B.

Es importante señalar en éste punto que bajo el presente escenario, el valor del campo identificador de sesión que se envía en todos los encabezados de los mensajes enviados a través de los canales multicast y unicast seguirá siendo el mismo.

5.1.2 Fallo en la recepción de ambos feeds que se encargan de difundir la información por completo de alguno de los productos que se ofrecen vía multicast

La recepción de mensajes puede verse interrumpida de forma natural por espacios breves de tiempo si y sólo si durante ese lapso de tiempo no se han generado mensajes, pero como se señaló previamente en la documentación, existe un mensaje administrativo denominado Heartbeat que será difundido cada 5 segundos en periodos de inactividad. Derivado de lo anterior en cada uno de los canales multicast deberá fluir por lo menos un mensaje cada 5 segundos. Los periodos en los cuales se debe de distribuir por lo menos un mensaje cada 5 segundos es entre la recepción del mensaje de Eventos del sistema con código A, que denota las horas de inicio de los sistemas y con la recepción del mensaje de Eventos del sistema con código K, que significa que han terminado las horas en las que los sistemas permanecen en funcionamiento.

La no recepción de mensajes (incluido el de Heartbeat) es sinónimo de un problema en curso y para lo cual deben consultar al área de soporte Market Data para el apoyo en el diagnóstico del problema.

5.2 Fallo en el servicio de retransmisiones

El servicio de retransmisiones se compone de dos aplicaciones destinadas a la retransmisión de mensajes vía unicast. Una de ellas denominada primaria y una más secundaría o alterna. Todas las solicitudes de retransmisión deben ser dirigidas a la aplicación primaria.

Suponga el escenario donde no es posible establecer comunicación con la aplicación de retransmisión primaria, es decir no es posible realizar una solicitud de retransmisión. Después de tres intentos de conexión al servicio primario con un lapso entre intentos de conexión de 5 segundos deberá intentarse la

(25)

25

conexión con el servicio alterno. Si el servicio alterno contesta las peticiones entonces ahí se deberán seguir haciendo las solicitudes.

En el caso en el que no responda ni el servicio primario ni el servicio alterno, entonces deberá ponerse en contacto con el equipo de soporte de Market Data de la BMV para conocer el estatus del servicio.

Respecto a la aplicación de retransmisión secundaria, ésta solo estará disponible a los usuarios sí la aplicación primaria no está disponible debido a un fallo. En el caso en el que se hagan peticiones el servicio alterno y el servicio primario esté disponible, entonces las solicitudes serán rechazadas.

5.3 Fallo en el servicio de snapshots

El servicio de snapshots se compone de dos aplicaciones destinadas al envío de mensajes vía unicast. Una de ellas denominada primaria y una más secundaría o alterna. Todas las solicitudes de snapshots deben ser dirigidas a la aplicación primaria.

Suponga el escenario donde no es posible establecer comunicación con la aplicación de snapshots primaria. Después de tres intentos de conexión al servicio primario con un lapso entre intentos de conexión de 5 segundos deberá intentarse la conexión con el servicio alterno. Si el servicio alterno contesta las peticiones entonces ahí se deberán seguir haciendo las solicitudes.

En el caso en el que no responda ni el servicio primario ni el servicio alterno, entonces deberá ponerse en contacto con el equipo de soporte de Market Data de la BMV para conocer el estatus del servicio.

Respecto a la aplicación de snpashots secundaria, ésta solo estará disponible a los usuarios sí la aplicación primaria no está disponible debido a un fallo. En el caso en el que se hagan peticiones el servicio alterno y el servicio primario esté disponible, entonces las solicitudes serán rechazadas.

(26)

26

5.4 Cambio de sesión y reinicio de secuencias en los diferentes canales de comunicación

Al ocurrir un problema en la difusión de la información de Market Data y por la cual se necesiten reiniciar las secuencias el procedimiento será el siguiente:

 Tanto los canales multicast como los canales unicast comenzaran a enviar un nuevo valor en el campo de Identificador de sesión en el encabezado comenzando de nuevo desde la secuencia uno.  Las peticiones de retransmisión se atenderán sobre este nuevo

secuenciador, perdiendo la historia de los mensajes que se hayan difundido con la sesión anterior.

 El servicio de snapshots no perderá la historia de los mensajes y podrá seguir atendiendo las peticiones, solo que ahora cuando mande el mensaje de Snapshot terminado informará la sesión y secuencias nuevas del flujo en línea.

Es de vital importancia que todos receptores del protocolo BMV Multicast para Market Data tengan presente dichas consideraciones en sus correspondientes desarrollos para consumir y solicitar la información contenida en los mensajes de forma adecuada.

6.0 Mensajes

Esta sección provee detalles del tipo de datos, encabezado, mensajes

administrativos y los mensajes de aplicación. A los campos de los mensajes se les agrega una pequeña descripción junto con el tipo de dato, longitud en bytes y offset.

6.1 Encabezado.

ElEncabezado BMV Multicast es utilizado para entregar todos los mensajes administrativos y los de aplicación en los tres diferentes canales. El

Encabezado BMV Multicast podría contener cero, uno o más mensajes. Mientras un Encabezado BMV Multicast podría contener múltiples mensajes de aplicación, nunca contendrá más de un mensaje administrativo y tampoco contendrá una mezcla de ambos.

Campo Offset Tamaño (byte)

(27)

27

Longitud 0 2 Int16 Longitud del paquete, incluye encabezado y todos los mensajes adheridos. Total Mensajes 2 1 Int8 Número de mensajes que

seguirán al encabezado. Grupo Market

data

3 1 Int8 Ver Catálogo de grupos de

Market Data

Sesión 4 1 Int8 Identificador de sesión

actual. Número

secuencia

5 4 Int32 Número de secuencia del

primer mensaje adherido al encabezado.

Fecha-hora 9 8 Timestamp Fecha y hora en que se crea el paquete.

6.2 Bloque de mensajes.

El primer campo de un bloque de mensajes es la longitud del mensaje. El primer bloque de mensaje comenzará inmediatamente después del

encabezado. Subsecuentes bloques de mensajes comenzaran después del último byte del bloque de mensaje previo.

En la Tabla 1 se puede apreciar como estarán estructurados los bloques de mensajes.

Tipo Descripción

Longitud del mensaje

* 2 Int16 Indica la longitud del

mensaje contenido en este bloque de mensaje.

Mensaje * * El contenido del mensaje

con longitud variable.

Tabla 1 Bloque de mensajes.

En la siguiente imagen se puede apreciar una representación de los bits en un ejemplo con dos mensajes en un paquete. El primer mensaje con 10 bytes de longitud y el segundo con 5 bytes.

(28)

28

6.3 Números de secuencia.

Todos los mensajes de aplicación transmitidos por el canal multicast y el de retransmisiones son secuenciados. El Encabezado BMV Multicast solo contiene el número de secuencia del primer mensaje y cada subsecuente mensaje tendrá una secuencia un número más grande que la anterior.

Los mensajes de aplicación enviados en el servicio de snapshots y todos los mensajes administrativos tendrán un valor cero para el campo de secuencia dentro del Encabezado BMV Multicast usado para transportar dichos

mensajes. El único mensaje administrativo que contendrá un valor en el campo de secuencia será el de Heartbeat.

6.4 Tipos de datos.

Todos los campos enteros están ordenados bajo el sistema big-endian y son con signo.

(29)

29

Todos los campos ALFA son ISO 8859-1 justificados a la izquierda y llenos a la derecha con espacios.

En la Tabla 2 se pueden apreciar los diferentes tipos de datos utilizados en BMV Multicast para Market data.

Tipo de dato Longit ud en bytes Rango inicial

Rango final Descripción

ALFA Variabl e Esos campos usan bytes de caracteres estándar ISO 8859-1. Justificados a la izquierda y llenos a la derecha por espacios. Timestamp 8 0 9223372036854775807 8 bytes para

representar la fecha y hora en milisegundos.

Int8 1 -128 127 8 bit enteros con

signo

Int16 2 -32768 32767 16 bit enteros con

signo.

Int32 4 -2147483648 2147483647 32 bit enteros con signo.

Int64 8

-92233720368 54775808

9223372036854775807 64 bit enteros con signo.

Precio(4) 4 -2147483648 2147483647 32 bit enteros con signo en donde las últimas 4 posiciones denotan la parte decimal. La parte decimal es la que está marcado con rojo.

Precio(8) 8

-92233720368 54775808

9223372036854775807 64 bit enteros con signo en donde las últimas 8 posiciones denotan la parte decimal. La parte decimal es la que está marcado con rojo.

(30)

30

6.5 Mensajes administrativos 6.5.1 Heartbeat

Indican la última secuencia que se ha enviado en ese grupo y puerto multicast. Estos mensajes solo se difundirán en caso de inactividad dentro del grupo y se enviarán cada cinco segundos.

El mensaje de Heartbeat solo contendrá el encabezado con el campo Número de mensajes igual a cero y con la secuencia del último mensaje que se ha enviado.

6.5.2 Inicio de sesión

Longitud 0 1 Int8 Longitud de mensaje incluyendo este campo.

Tipo Mensaje 1 1 ALFA Valor Valor en hexadecimal Significado ! 0x21 Inicio de sesión Grupo Market data

2 1 Int8 Ver Catálogo de grupos de Market Data

Usuario 3 6 ALFA Usuario asignado al receptor. Password 9 10 ALFA Contraseña asignada al receptor.

Total 19

6.5.3 Solicitud de retransmisión Campo Offset Tamaño

(byte)

Tipo Mensaje 1 1 ALFA Valor Valor en hexadecimal Significado # 0x23 Solicitud de retransmisión Grupo Market data

(31)

31

Mensaje mensaje que se quiere recuperar.

Cantidad 7 2 Int16 Cantidad de mensajes solicitados.

Total 9

6.5.4 Solicitud de snapshot

Tipo Mensaje 1 1 ALFA Valor Valor en hexadecimal Significado $ 0x24 Solicitud de snapshot Grupo Market data

Id Instrumento 3 4 Int32 Identificador de Instrumento al que se relaciona la petición. El campo debería contener solo ceros en caso de que la petición no esté relacionada a un instrumento

Tipo snapshot 7 1 Int8 Valor Significado

0 Lista de instrumentos 1 Profundidad completa. 2 Niveles de precio 3 Mejores posturas 4 Hechos Total 8

6.5.5 Solicitud de fin de sesión Campo Offset Tamaño

(byte)

Tipo Mensaje 1 1 ALFA Valor Valor en hexadecimal Significado % 0x25 Solicitud de fin de sesión Total 2

(32)

32

6.5.6 Respuesta de inicio de sesión Campo Offset Tamaño

(byte)

Tipo Mensaje 1 1 ALFA Valor Valor en hexadecimal Significado & 0x26 Respuesta de inicio de sesión Estado 2 1 ALFA Valor Significado A Sesión aceptada a Usuario Inactivo/bloqueado b Grupo Market data

inválido

c Sesión iniciada en otro canal d Servicio no disponible (Intermitencia en el servicio solicitado, se sugiere contactar al equipo de soporte) 6.5.7 Respuesta de retransmisión Campo Offset Tamaño

(byte)

Tipo Mensaje 1 1 ALFA Valor Valor en hexadecimal Significado * 0x2A Respuesta de retransmisión Grupo Market data

2 1 ALFA Ver Catálogo de grupos de Market Data

Primer Mensaje

3 4 Int32 Número de secuencia del primer mensaje a ser transmitido. Éste será cero si la solicitud no fue aceptada. Cantidad 7 2 Int16 Número de mensajes a ser

retransmitidos. Éste será cero si la solicitud no fue aceptada.

Estado 9 1 ALFA Estado de la solicitud de retransmisión. Valor Significado

A Solicitud aceptada B Sesión no iniciada

(33)

33

C Sobrepasa límite de peticiones.

D Fuera de rango b Grupo Market data

inválido d Servicio no disponible (Intermitencia en el servicio solicitado, se sugiere contactar al equipo de soporte) Identificador de sesión

10 2 Int8 Identificador de sesión de la cual se están atendiendo los mensajes y que es la que está activa en el canal del flujo en línea. Éste será cero en caso de que la retransmisión no haya sido aceptada.

Total 12

6.5.8 Respuesta de snapshot. Campo Offset Tamañ

o (byte)

Tipo Mensaje 1 1 ALFA Valor Valor en hexadecimal Significado + 0x2B Respuesta de snapshot Cantidad mensajes.

6 4 Int32 Número de mensajes que serán

transmitidos para atender la solicitud de snapshot. En el conteo de mensajes también se incluyen los mensajes de Estado del instrumento y el mensaje final de Snapshot terminado. Éste será cero en caso de que la solicitud no haya sido aceptada.

Estado 10 1 ALFA Estado de la petición snapshot: Valor Significado A Solicitud aceptada B Sesión no iniciada C Sobrepasa límite de peticiones. E Tipo de SNAPSHOT inválido

b Grupo Market data inválido o

instrumento inválido.

(34)

34 d Servicio no disponible (Intermitencia en el servicio solicitado, se sugiere contactar al equipo de soporte) Identificador de sesión

11 2 Int8 Identificador de sesión de la cual se están atendiendo los mensajes y que es la que está activa en el canal del flujo en línea. Éste será cero en caso de que la solicitud no haya sido aceptada. Tipo Snapshot 13 1 Int8 Valor Significado

0 Lista de instrumentos 1 Profundidad completa. 2 Niveles de precio 3 Mejores posturas 4 Hechos Total 14 6.5.9 Snapshot Terminado

Campo Offset Tamaño (byte)

Tipo Mensaje 1 1 ALFA Valor Valor en hexadecimal Significado ? 0x3F Snapshot terminado Número de secuencia

2 4 Int32 Número de secuencia con el cual el snapshot está sincronizado con respecto al canal en línea.

Este valor será diferente de cero en las opciones de profundidad completa, niveles de precio y mejores posturas. Grupo Market

data

Tipo snapshot 7 1 Int8 Valor Significado

0 Lista de instrumentos 1 Profundidad completa. 2 Niveles de precio 3 Mejores

(35)

35

posturas

4 Hechos

Total 8

6.6 Mensajes de aplicación.

Mensajes que son enviados únicamente por la BMV a los diferentes consumidores.

6.6.1 Eventos de sistema

El mensaje de eventos de sistema es usado para informar de que ha ocurrido un evento, el cual necesita ser del dominio público para su atención.

Tipo de Información Offset Tamaño Valor Notas

Tipo de mensaje 0 1 "S" Evento del sistema Número de instrumento 1 4 Int32 Siempre será cero.

Código de evento 5 1 ALFA Ver Catálogo de eventos del sistema.

Total 6

6.6.2 Hechos de capitales

Se informa de cualquier operación que fue aceptada en BMV. Tipo de Información Offset Tamaño Valor Notas

Tipo de mensaje 0 1 "P" Hechos del Mercado de capitales

Número de instrumento

1 4 Int32 Código asignado diariamente al instrumento en su Mercado Hora del Hecho 5 8 Timestamp Hora en que se realizó la

operación.

Volumen 13 4 Int32 Acciones negociadas

Precio 17 8 Precio(8) Precio de la operación Tipo de Concertación 25 1 ALFA Consultar catálogo de Tipos

de Concertación. Folio del Hecho 26 4 Int32 Foliador por instrumento Fija Precio 30 1 ALFA En caso de que el valor sea

1, será tomado como true, en cualquier otro caso será falso.

Tipo de Operación 31 1 ALFA Consultar catálogo de Tipos de Operación.

Importe 32 8 Precio(8)

(36)

36

compradora

Vende 45 5 ALFA Clave corta de casa

vendedora

Liquidación 50 1 ALFA Consultar catálogo de Tipos de Liquidación.

Total 51

6.6.3 Hechos del mercado de derivados

Se informa de cualquier operación que fue aceptada en MexDer. Tipo de Información Offset Tamaño Valor Notas

Tipo de mensaje 0 1 "Q" Hechos del Mercado de derivados

Número de

instrumento 1 4 Int32 Código asignado diariamente al instrumento en su Mercado Hora del Hecho 5 8 Timestamp Hora en que se realizó la

operación.

Volumen 13 4 Int32 Contratos negociados

Precio / Tasa 17 8 Precio(8) Precio de la operación Tipo de Concertación 25 1 ALFA Consultar catálogo de Tipos

de Concertación. Folio del Hecho 26 4 Int32 Foliador por instrumento Fija Precio 30 1 ALFA En caso de que el valor sea 1,

será tomado como true, en cualquier otro caso será falso. Tipo de Operación 31 1 ALFA Consultar catálogo de Tipos

de Operación.

Importe 32 8 Precio(8)

Folio del hecho padre 40 4 Int32 Solamente contendrá un valor en caso de que sea pata de una estrategia.

Tipo de pata 44 1 ALFA L – Pata larga C – Pata corta

X – Pata de Engrapado P – Indica que es la estrategia padre.

“ ” – Es un hecho que no fue generado a partir de una estrategia.

Total 45

6.6.4 Hechos de sociedades de inversión

(37)

37

Tipo de Información Offset Tamaño Valor Notas

Tipo de mensaje 0 1 "Y" Hechos de sociedades de inversión

Número de

instrumento 1 4 Int32 Código asignado diariamente al instrumento en su Mercado Hora del Hecho 5 8 Timestamp Hora en que se realizó la

operación.

Precio 13 8 Precio(8) Precio del mercado Valor contable 21 8 Precio(8) Valor contable por acción Número de

operaciones de venta 29 4 Int32 Volumen de venta 33 8 Int64 Número de

operaciones de compra

41 4 Int32

Volumen de compra 45 8 Int64

Total 53

6.6.5 Cancelación de Hecho

Este mensaje se envía cuando una operación es cancelada del sistema de BMV, se identifica la operación con los campos Instrumento y Folio.

Actualmente solo se puede enviar dentro de la sesión de remate. Tipo de Información Offset Tamaño Valor Notas

Tipo de mensaje 0 1 "H" Cancelación de hechos Número de

instrumento

1 4 Int32 Código asignado

diariamente al instrumento en su Mercado

Folio del Hecho 5 4 Int32 Foliador por instrumento

Total 9

6.6.6 Hechos virtuales

Cuando una operación ha sido pre asignada en los libros electrónicos al cierre y al Precio Promedio del Día se envía un mensaje de hecho virtual con el que se está avisando de esta operación. Al final de la sesión de remate se envía un mensaje P con el que se avisa que la operación deja de ser virtual.

Tipo de mensaje 0 1 "V" Hechos Virtuales del Mercado de Capitales y Global BMV

(38)

38

Instrumento diariamente al catálogo de

Instrumentos

Estado 5 1 ALFA Estado del hecho virtual: "A" - Alta

"B" - Baja

Tipo de Operación 6 1 ALFA Consultar catálogo de Tipos de Operación.

Folio 7 4 Int32 Folio del hecho virtual

Volumen 11 4 Int32 Títulos operados

virtualmente

Concertación 15 1 ALFA Consultar catálogo de Tipos de Concertación.

Compra 16 5 ALFA Clave de la casa

compradora

Vende 21 5 ALFA Clave de la casa vendedora

Total 26

6.6.7 Alta de orden

Al momento en que la orden es aceptada por el sistema central de la BMV, se difunde este mensajea los medios correspondientes.

La orden tiene una identificación única por: Instrumento, Fecha y Folio asignados por el sistema de BMV. El Sentido de la orden indica el lado del libro electrónico donde se colocará la postura.

El folio con el que se identifica la orden es único por instrumento y día. Es un consecutivo que se va asignando conforme van ingresando las ordenes. Es igual al folio SENTRA.

Solo se difunden las órdenes que ingresan al libro principal o de contado "CO". Tipo de Información Offset Tamaño Valor Notas

Tipo de mensaje 0 1 "A" Respuesta de Alta de órdenes

Fecha 5 8 Timestamp Tiempo en milisegundos del alta de la orden

Folio 13 4 Int32 Folio Asignado a la orden, cuando es registrada

Sentido 17 1 ALFA C - Compra

V - Venta

Volumen 18 4 Int32 Volumen de la orden

Precio 22 8 Precio(8) Precio de la orden

(39)

39

6.6.8 Modificación de órdenes

Mensaje enviado cuando la orden modifica alguno de sus datos, el sistema le asigna nueva prelación en el libro electrónico, la orden a sustituir se identifica con el Instrumento, Fecha y Folio original, la nueva asignación de prelación en el libro electrónico vienen en los campos Fecha y Folio Nuevos.

Por ejemplo:

 Incremento en el volumen de una orden.  Cambio de precio.

 Derivado de otras reglas señaladas en el manual operativo. Tipo de Información Offset Tamaño Valor Notas

Tipo de mensaje 0 1 "F" Respuesta de Modificación de órdenes

Número de instrumento 1 4 Int32 Código asignado diariamente al instrumento en su Mercado Fecha original 5 8 Timestamp Fecha en la que fue registrada

la orden

Folio original 13 4 Int32 Folio Asignado originalmente a la orden.

Nueva fecha 17 8 Timestamp Nueva fecha en la que fue registrada la orden. Folio nuevo 25 4 Int32 Folio Asignado a la nueva

orden.

Sentido 29 1 ALFA C - Compra

V - Venta

Precio 34 8 Precio(8) Precio de la orden

Total 42

6.6.9 Ejecución de órdenes

El mensaje es difundido al momento en que existe un calce o cierre en el sistema electrónico de la BMV. Por cada operación se generan dos mensajes, uno por la participación de venta y otro por la participación de compra.

La orden que está participando en la operación se identifica por el Instrumento, Fecha y Folio, el volumen cerrado de la orden, asociándose al folio del hecho y el precio al que se ejecutó la operación. Éste precio puede ser diferente al de la orden.

Este mensaje solo es difundido para las órdenes ejecutadas del libro principal o de contado "CO".

(40)

40

Tipo de mensaje 0 1 "C" Ejecución de una orden

Número de instrumento 1 4 Int32 Código asignado diariamente al instrumento en su Mercado Fecha 5 8 Timestamp Tiempo en milisegundos del

alta de la orden

Folio 13 4 Int32 Folio Asignado a la orden,

cuando es registrada

Folio del hecho 21 4 Int32 Folio del hecho con el que se ejecutó la orden

Precio de ejecución 25 8 Precio(8) Precio con el que se hizo el hecho.

Total 33

6.6.10 Disminución de volumen

Este mensaje se envía cuando ha ocurrido una disminución de volumen de la orden, pero que no se ha generado un nuevo folio y la orden sigue activa en el libro.

Tipo de mensaje 0 1 "X" Disminución de volumen de la orden

Número de instrumento 1 4 Int32 Código asignado diariamente al instrumento en su Mercado Fecha 5 8 Timestamp Fecha en la que fue registrada la

orden

Volumen cancelado 17 4 Int32 Volumen a cancelar de la orden.

Total 21

6.6.11 Cancelación de órdenes

Este mensaje elimina por completo la orden del corro.

Tipo de mensaje 0 1 "D" Notificación de la eliminación de orden

Número de instrumento 1 4 Int32 Código asignado diariamente al instrumento en su Mercado Fecha 5 8 Timestamp Fecha en la que fue registrada la

orden

(41)

41

6.6.12 Profundidad

El mensaje contiene los 20 mejores precios de venta y los 20 mejores precios de compra. Se envía al inicio del día con las posturas vigentes y se actualiza durante la sesión normal de operación.

Cada vez que se modifican los valores de alguno de los 20 niveles de cualquier lado, el mensaje es enviado. Pero no siempre se envían los 20 niveles, eso depende del número de niveles que existan para el instrumento pudiendo llegar a ser menor el número.

Los niveles están agrupados por precio con el número de órdenes y número de acciones a ese nivel de precio. Los Niveles de compra y venta indican cuantos precios se reciben en el mensaje.

Tipo de mensaje 0 1 "1" Profundidad del Mercado Número de instrumento 1 4 Int32 Código asignado diariamente al

instrumento en su Mercado Niveles de compra 5 1 Int8 Número de niveles de compra a

enviarse

Niveles de venta 6 1 Int8 Número de niveles de venta a enviarse

Precio-1 7 8 Precio(8) Precio del primer nivel

Número de órdenes-1 15 2 Int16 Número de órdenes primer nivel Volumen-1 17 4 Int32 Volumen acumulado del primer

nivel ... ...

6.6.13 Precio probable de asignación

El mensaje es enviado durante cualquier tipo de subasta (Apertura, Continua, Volatilidad e Intradía) y únicamente en los instrumentos donde ya existe un calce virtual o pre asignación.

Contiene el precio probable y el volumen máximo que se asignaría el instrumento al finalizar la subasta. Se envía al instante en que se modifica alguno de esos 2 datos.

Tipo de mensaje 0 1 "2" Precio probable de asignación Número de instrumento 1 4 Int32 Código asignado diariamente al

(42)

42

instrumento en su Mercado Precio probable de

asignación

5 8 Precio(8)

Volumen 13 4 Int32 Volumen máximo a operar

Total 17

6.6.14 Inicio de subastas continuas

El mensaje es enviado al momento de generarse una de las subastas continuas, de volatilidad o del SIC.

Tipo de Información Offset Tamaño Valor Notas

Tipo de mensaje 0 1 "3" Inicio de subastas

Número de instrumento 1 4 Int32 Código asignado diariamente al instrumento en su Mercado Hora inicio de la

subasta

5 8 Timestamp Hora en milisegundos en los que inicia la subasta

Hora fin de la subasta 13 8 Timestamp Hora en milisegundos en los que concluye la subasta

Total 21

6.6.15 Cambios de estado

Todos los instrumentos se encuentran en algún estado antes y durante la sesión de remate. El mensaje del estado por instrumento se genera al inicio del día y cuando el instrumento entra a alguna fase del remate: Cancelación de Posturas, Subasta de Apertura, Negociación Continua o entra en alguna otra modalidad operativa, como por ejemplo: Subastas y Suspensiones.

Tipo de mensaje 0 1 "4" Cambio de Estado del Instrumento Número de instrumento 1 4 Int32 Código asignado diariamente al

instrumento en su Mercado Estado del Instrumento 5 1 ALFA Consultar catálogo de Estado del

instrumento.

Total 6

6.6.16 Estadísticas de los instrumentos

Mensaje de actualización de estadísticas de derivados que se envía cada que existe una actualización en los corros en cualquier nivel de precio.

(43)

43

Tipo de mensaje 0 1 "R" Estadística por Instrumento Número de

instrumento

Precio Liquidación anterior

5 8 Precio(8) Precio de liquidación del día anterior

Precio de apertura 13 8 Precio(8) 1er. precio del día o precio de la apertura

Precio máximo del día 21 8 Precio(8) Precio máximo registrado en el día

Precio mínimo del día 29 8 Precio(8) Precio mínimo registrado en el día

Precio último del día 37 8 Precio(8) Precio último registrado en el día

Total 45

6.6.17 Catálogos de instrumentos

Existen 6 catálogos de instrumentos que contienen la información de los diferentes mercados que se operan en la Bolsa Mexicana de Valores.

6.6.17.1 Catálogo para instrumentos que pertenecen al mercado accionario local y global BMV.

Tipo de información

Offset Tamaño Tipo Descripción

Tipo de mensaje 0 1 "a" Mercado accionario local y global.

1 4 Int32 Código asignado diariamente al instrumento

Tipo de Valor 5 2 ALFA Clave del Tipo de Valor

Emisora 7 7 ALFA Clave de la Emisora

Serie 14 6 ALFA Clave de la Serie

Último precio 20 8 Precio(8) Último precio de referencia

PPP 28 8 Precio(8) Precio promedio ponderado

Fecha de Referencia

36 8 Timestamp Fecha de última referencia Referencia 44 1 ALFA Consultar catálogo de

Referencia

Cupón vigente 45 1 Int8 Número de cupón vigente Bursatilidad 46 1 ALFA Consultar catálogo de

Bursatilidad Bursatilidad

numérica

47 4 Precio(4)

(44)

44

Mercado 63 1 ALFA Consultar Catálogo de Mercados

Total 64

6.6.17.2 Catálogo para instrumentos que pertenecen al mercado de Warrants capitales.

Tipo de información Offset Tamaño Tipo Descripción

Tipo de mensaje 0 1 "c" Catálogo de Warrants de capitales.

Tipo de Warrant 20 1 ALFA Tipo de Warrant: "C" - Compra "V" - Venta

Fecha de Vencimiento 21 8 Timestamp Fecha de Vencimiento del Warrant

Precio de Ejercicio 29 8 Precio(8) Precio para ejercer el warrant Precio de Referencia 37 8 Precio(8) Precio de última referencia Fecha de Referencia 45 8 Timestamp Fecha de última referencia Referencia 53 1 ALFA Consultar catálogo de

Referencia

Emisora Subyacente 54 7 ALFA Clave de la emisora subyacente

Serie Subyacente 61 6 ALFA Clave de la serie subyacente TV Subyacente 67 2 ALFA Clave del tipo de valor

subyacente

ISIN 69 12 ALFA Clave de ISIN del instrumento

Total 81

6.6.17.3 Catálogo enviado para instrumentos que pertenecen a los TRACS de capitales.

Tipo de información Offset Tamaño Tipo Descripción

Tipo de mensaje 0 1 "e" Carga de cartera de los TRACS de capitales.

Número del Trac 1 4 Int32 Código asignado diariamente a los TRACS

Nombre del Trac 5 8 ALFA Identifica el nombre del Trac Emisora subyacente 13 7 ALFA Clave de la emisora del valor

subyacente

Serie subyacente 20 6 ALFA Clave de la serie del valor subyacente

(45)

45

subyacente

Títulos Excluidos 34 8 Precio(8) Número de títulos excluidos del valor subyacente

Precio 42 8 Precio(8) Precio del valor subyacente Componente en

Efectivo

50 8 Precio(8) Componente de efectivo por unidad

Valor Excluido 58 8 Precio(8) Valor estimado de los activos excluidos por unidad

Número de Certificados

66 8 Int64 Número de Certificados por unidad

Precio Teórico 74 8 Precio(8) Precio Teórico por certificado

Total 82

6.6.17.4 Catálogo enviado para instrumentos que pertenecen a las Sociedades de inversión

Tipo de información Offset Tamaño Tipo Descripción

Tipo de mensaje 0 1 "f" Catálogo de sociedades de inversión.

Clasificación Sectorial 20 2 Int16 Consultar Clasificación sectorial Operadora 22 10 ALFA Clave de la operadora del

fondo de inversión

Precio de Referencia 32 8 Precio(8) Precio de última referencia Fecha de Referencia 40 8 Timestamp Fecha de última referencia Referencia 48 1 ALFA Consultar catálogo de

Referencia

ISIN 49 12 ALFA Clave de ISIN del instrumento

Calificación 61 25 ALFA

Total 86

6.6.17.5 Catálogo enviado para instrumentos que pertenecen al mercado de derivados de futuros, opciones y Swaps

Tipo de información Offset Tamaño Tipo Descripción

Tipo de mensaje 0 1 "d" Catálogo del mercado de derivados futuros, opciones y swaps.