MEFFGate Liquidación

MEFFGate Liquidación ESPECIFICACIONES DE LA INTERFAZ FIX

Versión C1.5

9 de diciembre de 2013

La información contenida en este documento está sujeta a modificaciones sin previo aviso. A menos que se indique lo contrario, las compañías, los nombres y los datos utilizados en los ejemplos son ficticios. Ninguna parte de este documento puede ser reproducida o transmitida de ninguna forma, ni por cualquier medio, ya sea electrónico o mecánico, con ningún propósito, sin la previa autorización por escrito.

© 2013 BME. Todos los derechos reservados.

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 1. Introducción

9 de diciembre de 2013 © BME 2013 1

Modificaciones realizadas en la última revisión

A continuación se detallan las principales modificaciones realizadas en la versión C1.5 (respecto de la versión C1.4 del 2 de abril de 2013):

Nuevo bloque RegulatoryTradeIDGrp para identificar el UTI de cada operación (mensaje Trade Capture Report)



Tabla de Contenidos

1. Introducción ................................................................................................................................... 6 1.1 Ámbito de este manual .......................................................................................................................... 6 1.2 Información pública e información privada ............................................................................................ 7 1.3 Organización del manual ....................................................................................................................... 8 1.4 Formato de las tablas de definición de mensajes .................................................................................. 9 1.5 Documentos relacionados ..................................................................................................................... 9

2. Decisiones de Implementación ..................................................................................................10 2.1 Descripción .......................................................................................................................................... 10 2.2 Campos ignorados .............................................................................................................................. 10 2.3 Campos no soportados ....................................................................................................................... 10 2.4 Longitud del tipo String ........................................................................................................................ 10 2.5 Máxima longitud de mensaje ............................................................................................................... 10 2.6 Encriptación ......................................................................................................................................... 10 2.7 Identificación del protocolo MEFFGate FIX ......................................................................................... 10

3. Sesión FIX .....................................................................................................................................12 3.1 Introducción ......................................................................................................................................... 12 3.2 Sesión FIX y sesión de comunicación ................................................................................................. 12 3.3 Identificación de la sesión FIX ............................................................................................................. 12 3.4 Software cliente y sesiones FIX .......................................................................................................... 13 3.5 Sincronización de la sesión FIX .......................................................................................................... 13 3.6 Sincronización a nivel de aplicación .................................................................................................... 15 3.7 Alta disponibilidad ............................................................................................................................... 16 3.8 Campo PossResend ........................................................................................................................... 16 3.9 Mensajes administrativos que el cliente FIX debe gestionar ............................................................... 16 3.10 Lista de mensajes ............................................................................................................................... 16 3.11 Flujo de mensajes ............................................................................................................................... 17 3.12 Acotaciones y adaptaciones de FIX 4.4 .............................................................................................. 19 3.13 Definición de mensajes ....................................................................................................................... 20

3.13.1 Standard Message Header ...................................................................................................... 20 3.13.2 Standard Message Trailer ........................................................................................................ 22 3.13.3 Logon (Msg Type = A) ............................................................................................................. 23 3.13.4 Logout (Msg Type = 5) ............................................................................................................. 24 3.13.5 Heartbeat (Msg Type = 0) ........................................................................................................ 25 3.13.6 Test Request (Msg Type = 1) .................................................................................................. 26 3.13.7 Resend Request (Msg Type = 2) ............................................................................................. 27 3.13.8 Sequence Reset (Msg Type = 4) ............................................................................................. 28 3.13.9 Reject (Msg Type = 3) .............................................................................................................. 29

4. Convenciones generales en los mensajes de aplicación .......................................................30 4.1 Identificación de operaciones .............................................................................................................. 30

4.1.1 SecondaryExecID .................................................................................................................... 30 4.1.2 SecondaryTradeReportID ........................................................................................................ 30

4.2 Bloque Parties ..................................................................................................................................... 30 4.3 Symbol y SecurityID ............................................................................................................................ 32 4.4 Bloque Instrument ............................................................................................................................... 33

4.4.1 CFICode................................................................................................................................... 33 4.4.2 Activo subyacente (campo SecurityID) .................................................................................... 33 4.4.3 Vencimiento (campo MaturityMonthYear) ................................................................................ 34 4.4.4 Código de contrato (campo Symbol) ........................................................................................ 34 4.4.5 Combinación de criterios de selección ..................................................................................... 34

4.5 Formato de Error (Campo Text) .......................................................................................................... 34

5. Mensajes Genéricos del Nivel de Aplicación ............................................................................35 5.1 Introducción ......................................................................................................................................... 35 5.2 Estado de la comunicación .................................................................................................................. 35 5.3 Cambio de password de conexión al MEFFGate ................................................................................ 35 5.4 Rechazo de mensajes de aplicación ................................................................................................... 35 5.5 Lista de mensajes ............................................................................................................................... 35 5.6 Flujo de mensajes ............................................................................................................................... 36 5.7 Acotaciones y adaptaciones de FIX 4.4 .............................................................................................. 36 5.8 Definición de mensajes ....................................................................................................................... 37



5.8.1 Network Counterparty System Status Request (Msg Type = BC) ............................................ 37 5.8.2 Network Counterparty System Status Response (Msg Type = BD) ......................................... 38 5.8.3 User Request (Msg Type = BE) ............................................................................................... 39 5.8.4 User Response (Msg Type = BF) ............................................................................................ 40 5.8.5 Business Message Reject (MsgType = j) ................................................................................. 41

6. Información de Contratos ...........................................................................................................42 6.1 Introducción ......................................................................................................................................... 42 6.2 Información estática de contratos ........................................................................................................ 43

6.2.1 Descripción .............................................................................................................................. 43 6.2.2 Solicitud de información de contratos ...................................................................................... 43 6.2.3 Recepción de la definición de contratos .................................................................................. 43 6.2.4 Finalización de las suscripciones ............................................................................................. 43 6.2.5 Lista de mensajes .................................................................................................................... 43 6.2.6 Flujo de mensajes .................................................................................................................... 44 6.2.7 Acotaciones y adaptaciones de FIX 4.4 ................................................................................... 45

6.3 Información dinámica de contratos ...................................................................................................... 46 6.3.1 Descripción .............................................................................................................................. 46 6.3.2 Solicitud de información ........................................................................................................... 46 6.3.3 Recepción de información........................................................................................................ 46 6.3.4 Lista de mensajes .................................................................................................................... 46 6.3.5 Flujo de mensajes .................................................................................................................... 47 6.3.6 Acotaciones y adaptaciones de FIX 4.4 ................................................................................... 48

6.4 Definición de mensajes ....................................................................................................................... 49 6.4.1 Security List Request (Msg Type = x) ...................................................................................... 49 6.4.2 Security List (Msg Type = y) .................................................................................................... 50 6.4.3 Market Data Request (Msg Type = V) ...................................................................................... 53 6.4.4 Market Data Request Reject (Msg Type = Y) .......................................................................... 54 6.4.5 Market Data Snapshot Full Refresh (Msg Type = W)............................................................... 55

7. Seguimiento y Gestión de la Posición ......................................................................................56 7.1 Introducción ......................................................................................................................................... 56 7.2 Consulta de posición abierta ............................................................................................................... 56 7.3 Consulta por miembro negociador y/o liquidador ................................................................................ 56 7.4 Ajustes de posición ............................................................................................................................. 57 7.5 Lista de mensajes ............................................................................................................................... 58 7.6 Flujo de mensajes ............................................................................................................................... 58 7.7 Acotaciones y adaptaciones de FIX 4.4 .............................................................................................. 61 7.8 Definición de mensajes ....................................................................................................................... 62

7.8.1 Request For Positions (Msg Type = AN) .................................................................................. 62 7.8.2 Request For Positions Ack (Msg Type = AO) .......................................................................... 64 7.8.3 Position Report (Msg Type = AP)............................................................................................. 65 7.8.4 Trade Capture Report (Msg Type = AE) .................................................................................. 68 7.8.5 Position Maintenance Request (Msg Type = AL) ..................................................................... 73 7.8.6 Position Maintenance Report (Msg Type = AM) ...................................................................... 75

8. Consulta de operaciones ............................................................................................................78 8.1 Introducción ......................................................................................................................................... 78 8.2 Consulta por miembro negociador y/o liquidador ................................................................................ 78 8.3 Lista de mensajes ............................................................................................................................... 80 8.4 Flujo de mensajes ............................................................................................................................... 80 8.5 Acotaciones y adaptaciones de FIX 4.4 .............................................................................................. 81 8.6 Definición de mensajes ....................................................................................................................... 82

8.6.1 Trade Capture Report Request (Msg Type = AD) .................................................................... 82 8.6.2 Trade Capture Report Request Ack (Msg Type = AQ)............................................................. 83

9. Gestión de Operaciones .............................................................................................................84 9.1 Introducción ......................................................................................................................................... 84 9.2 Asignación de cuenta diaria y traspaso ............................................................................................... 84 9.3 Give-up (Miembro Origen) ................................................................................................................... 84 9.4 Give-up (Miembro Destino) ................................................................................................................. 85 9.5 Give-up (Liquidador de la cuenta destino) ........................................................................................... 85 9.6 Campo AllocID .................................................................................................................................... 85 9.7 Campo SecondaryAllocID ................................................................................................................... 87 9.8 Seguimiento de operaciones mediante los mensajes Trade Capture Report ...................................... 87 9.9 Lista de mensajes ............................................................................................................................... 88 9.10 Flujo de mensajes ............................................................................................................................... 89



9.11 Acotaciones y adaptaciones de FIX 4.4 .............................................................................................. 95 9.12 Definición de mensajes ....................................................................................................................... 96

9.12.1 Allocation Instruction (Msg Type = J) ....................................................................................... 96 9.12.2 Allocation Instruction Ack (Msg Type = P) ............................................................................... 98 9.12.3 Confirmation (Msg Type = AK) ................................................................................................. 99 9.12.4 Confirmation Ack (Msg Type = AU)........................................................................................ 102 9.12.5 Business Message Reject (MsgType = j) ............................................................................... 102

10. Petición de Ejercicio ..................................................................................................................103 10.1 Introducción ....................................................................................................................................... 103 10.2 Escenario 1: Opciones americanas, antes del día de vencimiento ................................................... 103 10.3 Escenario 2: Día de vencimiento ....................................................................................................... 103 10.4 Lista de mensajes ............................................................................................................................. 104 10.5 Flujo de mensajes ............................................................................................................................. 105 10.6 Acotaciones y adaptaciones de FIX 4.4 ............................................................................................ 107 10.7 Definición de mensajes ..................................................................................................................... 108

11. Comunicación de Eventos ........................................................................................................109 11.1 Introducción ....................................................................................................................................... 109 11.2 Lista de mensajes ............................................................................................................................. 109 11.3 Flujo de mensajes ............................................................................................................................. 109 11.4 Acotaciones y adaptaciones de FIX 4.4 ............................................................................................ 110 11.5 Definición de mensajes ..................................................................................................................... 111

11.5.1 News (Msg Type = B) ............................................................................................................ 111

12. Gestión de Referencias y Filtros de Give-up ..........................................................................112 12.1 Introducción ....................................................................................................................................... 112 12.2 Campo RegistID ................................................................................................................................ 112 12.3 Mantenimiento de referencias de Give-out por Miembro Origen ....................................................... 114

12.3.1 Descripción ............................................................................................................................ 114 12.3.2 Lista de mensajes .................................................................................................................. 114 12.3.3 Flujo de mensajes .................................................................................................................. 114 12.3.4 Acotaciones y adaptaciones de FIX 4.4 ................................................................................. 115 12.3.5 Definición de mensajes .......................................................................................................... 116

12.4 Mantenimiento de referencias de Give-in por Miembro Destino ........................................................ 118 12.4.1 Descripción ............................................................................................................................ 118 12.4.2 Lista de mensajes .................................................................................................................. 118 12.4.3 Flujo de mensajes .................................................................................................................. 118 12.4.4 Acotaciones y adaptaciones de FIX 4.4 ................................................................................. 119 12.4.5 Definición de mensajes .......................................................................................................... 120

12.5 Mantenimiento de filtros de Give-in por Miembro Destino ................................................................. 122 12.5.1 Descripción ............................................................................................................................ 122 12.5.2 Lista de mensajes .................................................................................................................. 122 12.5.3 Flujo de mensajes .................................................................................................................. 122 12.5.4 Acotaciones y adaptaciones de FIX 4.4 ................................................................................. 123 12.5.5 Definición de mensajes .......................................................................................................... 124

12.6 Mantenimiento de filtros de Give-in por Miembro Liquidador ............................................................ 128 12.6.1 Descripción ............................................................................................................................ 128 12.6.2 Lista de mensajes .................................................................................................................. 128 12.6.3 Flujo de mensajes .................................................................................................................. 128 12.6.4 Acotaciones y adaptaciones de FIX 4.4 ................................................................................. 129 12.6.5 Definición de mensajes .......................................................................................................... 130

12.7 Mantenimiento de peticiones automáticas de Give-out ..................................................................... 133 12.7.1 Descripción ............................................................................................................................ 133 12.7.2 Lista de mensajes .................................................................................................................. 133 12.7.3 Flujo de mensajes .................................................................................................................. 133 12.7.4 Acotaciones y adaptaciones de FIX 4.4 ................................................................................. 134 12.7.5 Definición de mensajes .......................................................................................................... 135

12.8 Consulta de referencias y filtros de Give-up ...................................................................................... 137 12.8.1 Descripción ............................................................................................................................ 137 12.8.2 Lista de mensajes .................................................................................................................. 137 12.8.3 Flujo de mensajes .................................................................................................................. 137 12.8.4 Acotaciones y adaptaciones de FIX 4.4 ................................................................................. 138 12.8.5 Definición de mensajes .......................................................................................................... 139

13. Entregas de Futuros sobre Bono .............................................................................................141 13.1 Introducción ....................................................................................................................................... 141



13.2 Lista de entregables .......................................................................................................................... 141 13.3 Notificación de entregas .................................................................................................................... 141 13.4 Operaciones de compra-venta a realizar........................................................................................... 142 13.5 Lista de mensajes ............................................................................................................................. 142 13.6 Flujo de mensajes ............................................................................................................................. 143 13.7 Acotaciones y adaptaciones de FIX 4.4 ............................................................................................ 145 13.8 Definición de mensajes ..................................................................................................................... 146

Apéndice A Campos de Usuario ................................................................................................ A-1



1. Introducción

1.1 Ámbito de este manual

Este documento contiene la definición de la interfaz ofrecida por MEFF para el desarrollo de aplicaciones relacionadas con el ámbito de liquidación. Dicha interfaz está basada en el estándar FIX Protocol (Financial Information eXchange), en su versión 4.4. Para una información detallada del estándar, consúltese el documento de referencia 1 (ver 1.5) o la página www.fixprotocol.org.

La interfaz sigue, tanto como es posible, las especificaciones de FIX 4.4. En la mayoría de los casos la estructura y semántica de los mensajes es idéntica al estándar.

En algunos casos se han realizado extensiones del protocolo, por ejemplo para cubrir funcionalidades que no han sido consideraras por el estándar. Dichas extensiones están claramente detalladas en el documento.

En otros casos el estándar es ambiguo, o indica que los detalles deben ser acordados mutuamente entre las partes. Es estos casos el manual contiene una descripción detallada que elimina las posibles ambigüedades.

Todas las acotaciones y adaptaciones del estándar se han llevado a cabo siguiendo las recomendaciones especificadas por el propio estándar.

Para evitar posibles duplicidades como fuente de información, este documento no incluye explicaciones de aquellos aspectos que cumplen exactamente con el estándar. Para cualquier tema que no esté explícitamente detallado en este manual, debe considerarse la documentación del estándar como fuente de información.

El propósito de este documento es servir de base para los Miembros e ISVs que deseen desarrollar software que se comunique con la Cámara mediante la interfaz FIX del servidor MEFFGate.

http://www.fixprotocol.org/



1.2 Información pública e información privada

Las funcionalidades cubiertas por MEFFGate se agrupan en información pública e información privada.

En la siguiente tabla se presentan las funciones públicas y los mensajes relacionados.

Función pública Mensajes relacionados Msg Type

Obtención de información de contratos

Security List Request x

Security List y

Market Data Request V

Market Data Request Reject Y

Market Data – Snapshot / Full Refresh W

En la siguiente tabla se presentan las funciones privadas y los mensajes relacionados.

Función Privada Mensajes relacionados Msg Type

Seguimiento y gestión de la posición Request For Positions AN

Request For Positions Ack AO

Position Report AP

Trade Capture Report AE

Position Maintenance Request AL

Position Maintenance Report AM

Consulta de operaciones Trade Capture Report Request AD

Trade Capture Report Request Ack AQ


Gestión de operaciones Allocation Instruction J

Allocation Instruction Ack P

Confirmation AK

Confirmation Ack AU


Petición de ejercicio Position Maintenance Request AL

Position Maintenance Report AM

Request For Positions AN

Request For Positions Ack AO

Position Report AP


Envío de mensajes al supervisor de la cámara y recepción de mensajes del mismo

News B

Gestión de referencias y filtros de Give-up Registration Instructions o

Registration Instructions Response p



1.3 Organización del manual

El presente manual está organizado en dos partes diferenciadas. En la primera parte, formada por los primeros cuatro capítulos, se describen aspectos genéricos de esta interfaz.

Éste, el primer capítulo, describe el ámbito del documento, presenta la estructura del mismo e introduce los documentos relacionados.

En el capítulo 2 “Decisiones de Implementación”, se presentan aquellas acotaciones o restricciones derivadas de la implementación del protocolo que define este manual.

El capítulo 3 “Sesión FIX” describe aquellos aspectos relacionados con el nivel de sesión, incluyendo la descripción detallada de los mensajes correspondientes.

El capítulo 4 “Convenciones generales en los mensajes de aplicación” describe con detalle aspectos concretos que afectan a la mayoría de mensajes descritos en este manual.

Dado su contenido genérico, que afecta a todos los mensajes, se recomienda una lectura previa de los capítulos 2, 3 y 4 antes de pasar al resto de capítulos.

La segunda parte del manual, formada por el resto de capítulos, describe las diferentes funcionalidades soportadas por MEFFGate. En cada uno de estos capítulos se trata una funcionalidad concreta, describiendo aquellos aspectos particulares que son de interés.

En cada uno de estos capítulos están presentes, entre otros, los siguientes apartados:

Introducción. Presenta una breve descripción de la funcionalidad abordada en el capítulo

Lista de mensajes. Relaciona los diferentes mensajes que implementan la funcionalidad tratada en el capítulo

Flujo de mensajes. Describe los diferentes escenarios de intercambio de mensajes que se pueden dar. Incluye los correspondientes diagramas de flujo de mensajes

Acotaciones y adaptaciones de FIX 4.4. Detalla las acotaciones y adaptaciones del protocolo estándar para adaptarlo a sus requerimientos

Definición de mensajes. Contiene una tabla para cada mensaje del capítulo, que describe de forma detallada los campos que lo conforman

Finalmente, y a modo de apéndice, se presenta una tabla donde se describen los campos de usuario de FIX usados en el protocolo.



1.4 Formato de las tablas de definición de mensajes

Tal y como se explica en el apartado anterior, en los capítulos en que sea necesario se incluye una tabla por cada mensaje, que describe de forma detallada los campos que lo conforman.

Estas tablas contienen un campo por fila y presentan las siguientes columnas:

Columna Significado

Tag Número de campo. Los campos añadidos al mensaje en esta implementación presentan un asterisco (“*”) a continuación de este número

Nombre Nombre del campo según el estándar FIX

Req “S” indica que el campo es requerido, “N” significa que el campo es opcional. “S*” significa que el campo es requerido en esta implementación, pero opcional en el estándar FIX 4.4

Valores válidos Valores válidos del campo en el contexto del mensaje. Puede ser una lista de valores, o un rango de valores numéricos, p.ej. “>=3, <= 10”. En esta columna también se indica el valor por defecto del campo.

Para evitar confusiones con los términos, en los valores asociados a códigos se ha respetado la descripción del valor original de FIX, y por tanto no se ha traducido

Formato Tipo de dato del campo. Es uno de los tipos definidos por FIX, o uno de estos tipos con alguna restricción adicional. String(n) es un tipo String con un máximo de n caracteres, o en algunos casos con exactamente n caracteres. Para más información sobre el tipo String consúltese 2.4

Descripción Descripción del campo en el contexto del mensaje

1.5 Documentos relacionados

# Título Autor Versión

1 Financial Information Exchange Protocol (FIX) 4.4 with errata 20030618 FIX Committee 18 junio 2003

2 Financial Information Exchange Protocol (FIX) 5.0 Service Pack 2 FIX Committee Abril 2009

3 HF MEFFGate - Especificaciones de la interfaz FIX T3.3 BME 25 octubre 2012

4 HF MEFFGate - Especificaciones de la interfaz FIX M3.3 BME 30 agosto 2012

5 MEFFGate Liquidación – Especificaciones de la interfaz FIX C1.4 BME 2 abril 2013

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 2. Decisiones de Implementación


2. Decisiones de Implementación

2.1 Descripción

En este capítulo se presentan las decisiones de implementación tomadas por MEFF. Aquí se detallan aquellos aspectos que el estándar deja abiertos y que han sido definidos en esta implementación.

2.2 Campos ignorados

En algunos casos, el contenido de ciertos campos de los mensajes de entrada pueden ser ignorados por MEFFGate. Cuando éste es el caso, está claramente explicitado en la descripción del campo.

2.3 Campos no soportados

Los campos que no están soportados en un mensaje no se han incluido en la descripción del mismo.

Los mensajes enviados a MEFFGate no deben contener campos no soportados. Los mensajes enviados por MEFFGate nunca contienen campos no soportados.

Ningún campo requerido ha sido declarado no soportado.

2.4 Longitud del tipo String

El estándar FIX no impone ninguna restricción de longitud máxima sobre el tipo String. En esta implementación la longitud máxima es de 255 caracteres.

En algunos campos se ha fijado una longitud máxima inferior a este valor. En estos casos el tipo se presenta como String(n), donde “n” es el número máximo de caracteres del campo. En ciertos casos “n” indica la longitud exacta del campo, en dicho caso será explícitamente mencionado en la columna de valores válidos.

2.5 Máxima longitud de mensaje

La longitud máxima de los mensajes enviados o recibidos por MEFFGate es de 4096 bytes.

2.6 Encriptación

MEFFGate no usa la encriptación que define el estándar FIX (mediante los campos SecureData and SecureDataLen de la cabecera del mensaje). La encriptación está implementada mediante el uso de SSL (Secure Socket Layer).

2.7 Identificación del protocolo MEFFGate FIX

MEFFGate implementa una funcionalidad adicional que permite que ambas partes se pongan de acuerdo en la versión de MEFFGate FIX que van a usar.

No debe confundirse la versión del protocolo FIX (en este caso “4.4”), con la versión del protocolo MEFFGate FIX (“C1.5” en esta edición).

El protocolo MEFFGate FIX es la acotación y adaptación que MEFF realiza del estándar para cubrir las necesidades concretas de su negocio. Todas las acotaciones y adaptaciones realizadas por MEFF se han llevado a cabo siguiendo las recomendaciones especificadas por el propio estándar.

Podrá existir más de una versión del protocolo MEFFGate FIX dentro de una misma versión de FIX. Asimismo, podrá darse que una versión del protocolo MEFFGate FIX sea conforme con más de una versión del protocolo FIX.

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 2. Decisiones de Implementación


En la configuración de usuarios MEFFGate se puede indicar cuál es la versión del protocolo MEFFGate FIX que proporcionará MEFFGate por defecto. El cliente también puede indicar en el campo ProprietaryFixProtocolVersion, del mensaje Logon, la versión del protocolo MEFFGate FIX que desea usar. Este campo es una adición de MEFF y se ha implementado como opcional.

Si la versión solicitada por el cliente no está disponible en el servidor MEFFGate en uso, éste responde con un mensaje Logout con el correspondiente mensaje explicativo.

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 3. Sesión FIX


3. Sesión FIX

3.1 Introducción

El nivel de sesión FIX garantiza la entrega de mensajes, entre ambas partes, de forma completa y sin errores. MEFFGate implementa la mayoría de las funcionalidades del nivel de sesión definidas en el estándar FIX 4.4.

3.2 Sesión FIX y sesión de comunicación

Tal y como se explica en el estándar, existen dos tipos de sesión:

Sesión de comunicación. Se inicia cuando una petición de inicio de sesión (mensaje Logon) es aceptada. Termina cuando finaliza la comunicación, preferiblemente con el intercambio de mensajes Logout

Sesión FIX. Está compuesta por un conjunto de mensajes bidireccionales identificados por una secuencia de números consecutivos. Una sesión FIX se inicia cuando la secuencia de números de ambas partes se reinicia con el valor 1. No existe una forma explícita de finalizar una sesión FIX; una sesión se acaba cuando se inicia una nueva. Una sesión FIX puede abarcar más de una sesión de comunicación

Además de los dos tipos de sesión enumerados, debe considerarse el concepto de sesión de Cámara. Una sesión de Cámara empieza cada día en el momento en que el servidor MEFFGate, siguiendo el procedimiento definido por MEFF, carga de nuevo los datos y acepta conexiones para dicha sesión de Cámara.

El cliente debe iniciar una nueva sesión FIX en la primera conexión de la sesión de Cámara.

Dado que MEFFGate no soporta el servicio 24 horas, el campo ResetSeqNumFlag no es necesario en el mensaje Logon.

3.3 Identificación de la sesión FIX

Una vez se ha establecido una sesión de comunicación, MEFFGate identifica la sesión FIX asociada a partir de cuatro campos del mensaje de Logon enviado por el iniciador:

SenderCompID

SenderSubID

TargetCompID

TargetSubID

SenderCompID identifica al miembro y SenderSubID identifica al operador. TargetCompID junto con TargetSubID identifican al Grupo de contratos de liquidación..

No puede existir más de una sesión FIX concurrente con los mismos valores en estos cuatro campos.

Los campos SenderCompID, SenderSubID, TargetCompID y TargetSubID están presentes en todos los mensajes FIX. Todos los mensajes pertenecientes a una misma sesión FIX deben mantener los mismos valores en estos campos. Si se recibe un mensaje cuyos valores no se corresponden con los de la sesión, será rechazado con un mensaje Reject.



Hay que tener en cuenta que los valores de estos campos se invierten, respecto a los enviados por el cliente, cuando el mensaje es enviado por MEFFGate. Supongamos que el operador “001” perteneciente al miembro “A001” tiene establecida una sesión con la cámara de Renta Variable de MEFF. Los valores serán los que se muestran a continuación:

Mensaje del cliente a MEFFGate:

o SenderCompID = “A001”

o SenderSubID = “001”

o TargetCompID = “XMEF”

o TargetSubID = “C2” *

Mensaje de MEFFGate al cliente:

o SenderCompID = “XMEF”

o SenderSubID = “C2”

o TargetCompID = “A001”

o TargetSubID = “001”

Si un mismo cliente desea trabajar con dos cámaras simultáneamente, o desea realizar dos conexiones diferentes con la misma cámara, deberá establecer varias conexiones tal y como se explica en 3.4

3.4 Software cliente y sesiones FIX

Un cliente de MEFFGate es un desarrollo software que se conecta a MEFF mediante el servidor MEFFGate.

Tal y como se vio en 3.3, una sesión FIX queda limitada a un operador y una cámara. Un cliente podrá establecer varias sesiones FIX simultáneas, para acceder a más de una cámara u operar en una cámara con varios códigos de operador.

Un servidor MEFFGate puede dar servicio a varias sesiones simultáneamente, ya sean de un mismo cliente o de varios.

Cuando un cliente FIX intenta conectar con una cámara que no está disponible, su mensaje de Logon es contestado con un mensaje Logout con la explicación pertinente.

3.5 Sincronización de la sesión FIX

Al iniciar una sesión de comunicación (envío de mensaje Logon), el cliente puede optar por iniciar una nueva sesión FIX o continuar con una sesión previa de la misma sesión de cámara. A continuación se describe el procedimiento a seguir en cada caso.

Inicio de nueva sesión FIX. Para iniciar una nueva sesión FIX se deberá usar el número 1 en el campo MsgSeqNum del mensaje Logon.

Continuación de sesión FIX previa. Para continuar una sesión FIX previa se deberá usar en el campo MsgSeqNum el número consecutivo al usado en el último mensaje de la sesión que se va a continuar.

Téngase en cuenta que al iniciar una nueva sesión FIX, la sesión iniciada sustituye a la anterior y por tanto esta última no podrá ser continuada posteriormente.

Una aplicación cliente sólo puede continuar con una sesión FIX previa si se conecta al mismo servidor MEFFGate. En caso de que deba conectarse a otro servidor MEFFGate sólo podrá iniciar una nueva sesión FIX.

* Para más detalle sobre los códigos de cámara, véase Tabla 18 en documento “Tablas de Codificación”



Cuando se envía un mensaje Logon con MsgSeqNum diferente de 1, el número enviado puede no coincidir con el número que MEFFGate estaba esperando para esa sesión (MEFFGate espera el número consecutivo al número del último mensaje recibido de dicha sesión). A continuación se presentan las diferentes situaciones que se pueden dar respecto al número de secuencia del mensaje Logon y el mensaje esperado por MEFFGate.

MsgSeqNum igual al número esperado por MEFFGate. No hay discrepancia y MEFFGate acepta la conexión.

MsgSeqNum inferior al número esperado por MEFFGate. MEFFGate rechaza la conexión con un mensaje Logout con número de secuencia igual a 1. En este caso la conexión no puede ser aceptada ya que el número de secuencia usado en el mensaje Logon ya fue usado previamente por otro mensaje de la misma sesión.

MsgSeqNum superior al número esperado por MEFFGate. MEFFGate acepta la conexión, y solicita el envío de los mensajes que faltan entre el número de secuencia que el estaba esperado y el número usado por el cliente. La solicitud de envío de dichos mensajes se realizará con uno de los siguientes mecanismos:

o Mensaje Logon con NextExpectedMsgSeqNum. Este método se usará siempre y cuando el cliente haya usado el campo NextExpectedMsgSeqNum en su mensaje Logon

o Mensaje Resend Request. En el caso que el cliente no haya usado el campo NextExpectedMsgSeqNum (mensaje Logon), el servidor tampoco hará uso de él. En este caso el servidor, después del mensaje de Logon de respuesta, notificará al cliente el error de secuencia mediante el mensaje Resend Request

Cuando se continúa con una sesión FIX es aconsejable usar el campo NextExpectedMsgSeqNum (mensaje Logon), indicando el número de mensaje esperado, para facilitar la sincronización entre ambas partes. De esta forma el servidor puede detectar si el cliente dejó de recibir alguno de los mensajes, y proceder a su reenvío. Cuando no se especifica este valor, el servidor continúa el envío de mensajes a partir del último número de secuencia enviado.

MEFFGate usa el campo NextExpectedMsgSeqNum en el mensaje Logon de contestación, siempre y cuando el cliente lo haya usado en su mensaje de inicio.

MEFFGate sólo usa el mensaje Resend Request tal y como se ha descrito anteriormente, es decir, inmediatamente después de una petición de Logon. En cualquier otro caso, cuando se produzca discrepancia entre el número de secuencia esperado y el recibido, MEFFGate asume que existe algún problema grave y finaliza la conexión con el envío de un mensaje Logout.

Cuando MEFFGate solicita al cliente un número de secuencia inferior al que éste proponía, queda a decisión del cliente repetir los mismos mensajes que envió con los números de secuencia que faltan, enviar uno o más GapFills, o simplemente darles un nuevo uso. En cualquier caso el cliente debe tener en cuenta que los mensajes serán procesados por MEFFGate en el momento de su recepción como cualquier otro mensaje. Se recomienda implementar controles para no enviar órdenes que podían haber quedado obsoletas durante el periodo que duró la desconexión.

Al igual que MEFFGate, el cliente sólo puede hacer uso del mensaje Resend Request en el caso de detectar que el mensaje Logon que le ha enviado el servidor está fuera de secuencia y no contiene el campo NextExpectedMsgSeqNum. Si MEFFGate recibe un mensaje Resend Request en cualquier otro momento será considerado como un error y procederá a finalizar la conexión.

Independientemente de si fue solicitada mediante el mensaje Resend Request o con el campo NextExpectedMsgSeqNum del mensaje Logon, la repetición de mensajes por parte del servidor está limitada a los mensajes pertenecientes a la Sesión de Cámara en curso. El servidor repite todos los mensajes solicitados, excepto los de información pública. Dado el volumen que puede representar la información pública, ésta no es repetible y será sustituida por mensajes GapFill. El cliente debe usar las funcionalidades de consulta disponibles para ponerse al día de esta información. Consúltese el apartado 3.6 para más información al respecto.



- Escenarios de continuación de una sesión FIX -

Cuando un inicio de sesión de comunicaciones es rechazado, el servidor responde con un mensaje Logout. La aplicación cliente debe tener en cuenta que este mensaje Logout puede venir con número de secuencia 1, o con el número de secuencia correspondiente a su última comunicación. El número de secuencia usado por el cliente en su mensaje Logon no es tenido en cuenta por MEFFGate y por tanto no altera el número de secuencia esperado en próximas comunicaciones.

3.6 Sincronización a nivel de aplicación

Cuando un cliente inicia una sesión de comunicación (mensaje Logon aceptado), recibe un conjunto de información relacionada con la Sesión de Cámara actual. El conjunto de información a recibir depende de si se trata del inicio de una nueva sesión o una reconexión a una sesión FIX existente.

Inicio de una sesión FIX. El cliente recibe todos los mensajes privados, no asociados a suscripciones, correspondientes a toda la sesión de Cámara en curso. El total o parte de estos mensajes podrían haber sido recibidos previamente en una sesión FIX anterior.

Reconexión a una sesión FIX existente. El cliente recibe todos los mensajes privados, no asociados a suscripciones, correspondientes a la sesión de Cámara en curso y que no haya recibido anteriormente. En este caso MEFFGate asegura que no se produce ninguna duplicidad de mensaje (excepto cuando es solicitada explícitamente).

Los mensajes que provienen de una solicitud explícita de repetición (solicitada con un mensaje Resend Request o un mensaje Logon con NextExpectedMsgSeqNum inferior al último mensaje recibido) contendrán el valor “Y” en el campo PossDupFlag indicando dicha situación. Este caso no aplica cuando se trata de una nueva sesión FIX (inicio de la sesión con número de secuencia 1).

En ambos casos, tanto la información privada asociada a suscripciones, como la información pública, puede ser solicitada mediante los mensajes que implementan las funcionalidades correspondientes.

Debe tenerse en cuenta que cualquier suscripción a información es cancelada al finalizarse la sesión de comunicación. Si al reconectar una sesión FIX se desea este servicio, debe volver a solicitarse.

Los mensajes privados no asociados a suscripciones que se mencionan en este apartado se corresponden con los siguientes mensajes:

News

1

1

2

2 3 4

3

5 6 7

4 5

8

···n

m

m +

1

···n+1 Logon NextExpectedMsgSeqNum=m+1

n +

2

m +

2

n +

1

m +

3m

+ 4

n +

3

m +

5m

+ 6

m +

7n

+ 4

n +

5

A) Se continua la sesión FIX sin petición de

repetición de mensajes

1

1

2

2 3 4

3

5 6 7

4 5

8

···n

m -

50

···n+1 Logon NextExpectedMsgSeqNum=m-50

n +

1

m -

49m

- 48

m -

17m

- 16

m - 2

m - 1

m

m +

1n

+ 2

m +

2m

+ 3

m +

4n

+ 3

B) Se continua la sesión FIX con petición de

mensajes

m -

50

m - 2

m - 1

m

Mensaje del servidor al cliente

Mensaje del cliente al servidor

Mensaje SequenceReset-GapFill enviado del servidor al

cliente para saltar los mensajes públicos (no repetibles)



Confirmation con SecondaryConfirmStatus [5683] con valor distinto a “P” (Pending)

Position Maintenance Report con PosTransType = 4 (Delivery)

3.7 Alta disponibilidad

Para mejorar la disponibilidad de acceso a MEFF se dispondrá de varias instancias del servidor MEFFGate ejecutándose en equipos diferentes en las instalaciones del miembro.

Todas las instancias de MEFFGate estarán conectadas con los sistemas centrales de MEFF. Por tanto, dispondrán de toda la información necesaria.

Cuando falla el servidor MEFFGate, el cliente puede continuar trabajando con otro MEFFGate. En este caso, el cliente debe iniciar una nueva sesión FIX (empezando por el número de secuencia 1), ya que el estado de las sesiones no se replica entre los diferentes servidores MEFFGate. El cliente debe realizar los procesos necesarios para sincronizarse a nivel de aplicación (ver 3.5).

Cuando falla una aplicación cliente que tenía establecida una sesión FIX, la aplicación cliente puede reiniciarse en otro equipo que continúe la misma sesión (usando el mismo servidor MEFFGate). En este caso, es responsabilidad del cliente recuperar el estado de la aplicación fallida. Si no fuese posible recuperar este estado, lo más recomendable es iniciar una nueva sesión FIX, si bien es posible mantener la sesión actual y consultar a nivel de aplicación todos los datos necesarios para reconstruir el estado.

3.8 Campo PossResend

La implementación FIX de MEFF no permite el uso del campo PossResend (ver 2.3 para más información sobre campos no soportados).

3.9 Mensajes administrativos que el cliente FIX debe gestionar

El cliente FIX debe ser capaz de gestionar todos los mensajes administrativos tal y como se describen en este capítulo, incluyendo el mensaje Resend Request. Es decisión del cliente el responder a éste mediante el reenvío de mensajes o simplemente enviando un GapFill (mensaje Sequence Reset).

3.10 Lista de mensajes

La funcionalidad de nivel de sesión se implementa en FIX 4.4 mediante siete mensajes administrativos. Todos ellos están completamente soportados por el protocolo FIX de MEFFGate.



Mensaje Descripción

Logon (Msg Type = A) Solicitud o confirmación del inicio de una sesión de comunicación

Logout (Msg Type = 5) Solicitud o confirmación de la finalización de una sesión de comunicación

Heartbeat (Msg Type = 0) Notificación periódica de que la conexión permanece viva

Test Request (Msg Type = 1) Solicitud de envío de un mensaje Heartbeat para confirmar que la conexión permanece viva

Resend Request (Msg Type = 2) Solicitud de reenvío de mensajes que no han sido recibidos

Sequence Reset (Msg Type = 4) Rellenar un hueco de mensajes restableciendo un número de secuencia superior

Reject (Msg Type = 3) Rechazo de mensaje a nivel de sesión

3.11 Flujo de mensajes

Inicio de sesión de comunicación e inicio de sesión FIX

Una petición de inicio de sesión de comunicación (mensaje Logon) aceptada, es contestada por el receptor con otro mensaje Logon. El iniciador no debe enviar ningún otro mensaje hasta que haya recibido esta confirmación de aceptación.

Inicio de sesión de comunicación y continuación de sesión FIX

Una petición de inicio de sesión de comunicación (mensaje Logon) aceptada, es contestada por el receptor con otro mensaje Logon. El iniciador no debe enviar ningún otro mensaje hasta que haya recibido esta confirmación de aceptación.

MEFFGate Client MEFFGate Server

Logon (“A”)

Logon (“A”)

MsgSeqNum [34] = 1

MsgSeqNum [34] = 1


Logon (“A”)

Logon (“A”)

MsgSeqNum [34] = m

NextExpectedMsgSeqNum [789] = n

MsgSeqNum [34] = n

NextExpectedMsgSeqNum [789] = m+1



Inicio de sesión de comunicación rechazado

Cuando un inicio de sesión de comunicación (mensaje Logon) no es aceptado, MEFFGate contestará con un mensaje Logout.

Para más detalle sobre el comportamiento de los números de secuencia de ambas partes consultar el apartado 3.5.

Finalización de la sesión de comunicación iniciada por el emisor

El cliente puede, en cualquier momento, finalizar la sesión de comunicación mediante el envío de un mensaje Logout.

Finalización de la sesión de comunicación iniciada por el receptor

En situaciones excepcionales el servidor puede terminal la sesión de comunicación mediante un mensaje Logout.


Logon (“A”)

Logout (“5”)


Logout (“5”)

Logout (“5”)


Logout (“5”)

Logout (“5”)



Envío de mensaje con los campos de identificación de sesión (SenderCompID, SenderSubID, TargetCompID y TargetSubID) con valores diferentes a los asociados a la sesión FIX actual

Todos los mensajes asociados a una sesión FIX deben incluir los mismos valores identificadores de sesión (SenderCompID, SenderSubID, TargetCompID y TargetSubID). Si un mensaje difiere con los valores indicados en el Logon de la sesión, es rechazado mediante con Reject.

3.12 Acotaciones y adaptaciones de FIX 4.4

Se ha añadido el campo opcional ProprietaryFixProtocolVersion al mensaje Logon para identificar la versión del protocolo particular de MEFF

Se ha añadido el campo opcional FixEngineName al mensaje Logon. Contiene un texto descriptivo de la aplicación software

Cuando una petición de inicio de sesión (mensaje Logon) es rechazada, el receptor (MEFF) siempre enviará un mensaje Logout como contestación

Los campos SenderSubID y TargetSubID en la cabecera de los mensajes (Standard Message Header) dejan de ser opcionales y pasan a ser requeridos

El campo PossResend no está soportado

No se soporta el método de encriptación de FIX

MEFFGate sólo acepta el mensaje ResendRequest después del mensaje Logon

Los valores válidos del campo ResetSeqNumFlag del mensaje Logon quedan limitados al valor “N”


Any message with wrong ID

Reject (“3”)

SessionRejectReason [373] = 9 (CompID problem)



3.13 Definición de mensajes

3.13.1 Standard Message Header

Cabecera que contienen todos los mensajes FIX.

Tag Nombre Req Valores válidos Formato Descripción

8 BeginString S FIX.4.4 String Indica el inicio de un nuevo mensaje. Contiene la versión del protocolo FIX. Siempre es el primer campo del mensaje

9 BodyLength S Int Longitud del mensaje en bytes, desde la finalización de este campo hasta, e incluyendo, el delimitador previo al campo CheckSum. Siempre es el segundo campo del mensaje

35 MsgType S Todos los tipos de mensajes soportados por MEFF

String Identifica el tipo de mensaje. Siempre es el tercer campo del mensaje

49 SenderCompID S String Identificador de la entidad que envía el mensaje. Contiene “XMEF” cuando el mensaje es enviado por MEFFGate. Debe contener el código del miembro en los mensajes enviados por la aplicación cliente

56 TargetCompID S String Identificador de la entidad a la que va destinado el mensaje. Debe contener “XMEF” cuando el mensaje es enviado a MEFFGate. Contiene el código del miembro en los mensajes enviados por MEFFGate

34 MsgSeqNum S Int Número de secuencia del mensaje dentro de la sesión FIX actual

50 SenderSubID S* Para más detalle sobre los códigos de grupos de contratos, véase Tabla 18 en documento “Tablas de Codificación”

String En los mensajes enviados por MEFFGate contiene el código asignado al Grupo de contratos con el que se estableció la conexión. En mensajes enviados a MEFFGate debe contener el código de operador con el que se inició la sesión FIX

57 TargetSubID S* Para más detalle sobre los códigos de grupos de contratos, véase Tabla 18 en documento “Tablas de Codificación”

String En los mensajes enviados por MEFFGate contiene el código de operador al que va destinado. En mensajes enviados a MEFFGate debe contener el código de Grupo de contratos con el que se estableció la conexión

43 PossDupFlag N N = Envío del mensaje original (valor por defecto) Y = Posible duplicado

Boolean Indica si se trata de la primera vez, dentro de una sesión FIX, que se envía un mensaje (“N”) o si se está enviado de nuevo el mismo mensaje (“Y”), ya sea por una petición explicita de la otra parte o por la duda de la recepción del mensaje original

52 SendingTime S UTC Timestamp

Hora de envío del mensaje




122 OrigSendingTime N UTC Timestamp

Hora en que se envió el mensaje original. Requerido en un reenvío. Un mensaje es considerado un reenvío si el campo PossDupFlag = “Y” y el campo MsgType no es “4” (Sequence Reset)



3.13.2 Standard Message Trailer

Parte final de todos los mensajes FIX.


10 CheckSum S String(3) Checksum del mensaje, calculado según lo descrito en el estándar. Siempre es el último campo del mensaje y su longitud es exactamente de 3 bytes



3.13.3 Logon (Msg Type = A)

El mensaje Logon es usado para iniciar una sesión por el cliente y para aceptarla por el servidor.


Standard Header S MsgType = A

98 EncryptMethod S 0 = None Int Ignorado por MEFFGate

108 HeartBtInt S >= 5 Int Intervalo de envío de mensajes de verificación de conexión (mensaje Heartbeat) expresado en segundos.

141 ResetSeqNumFlag N N Boolean Sólo permite el valor “N”, ya que en la implementación del protocolo no es necesario

789 NextExpectedMsgSeqNum

N Int Indica el siguiente número de secuencia (MsgSeqNum) que se espera recibir

464 TestMessageIndicator

N Y = Test N = Producción

Boolean Indica cuando se trata de una sesión de pruebas o de producción. El cliente puede usarlo opcionalmente para indicar si desea conectarse a producción o a pruebas. El inicio de sesión se acepta si MEFFGate atiende ese entorno. Si el cliente no indica nada, no se tiene en cuenta este parámetro y MEFFGate siempre informa este campo.

553 Username N String Identificador de usuario asignado por MEFF. Requerido cuando el mensaje es enviado por la aplicación cliente. Actualmente está formado por la combinación de código de miembro y de operador asignados por MEFF

554 Password N String Password de usuario. Requerido cuando el mensaje es enviado por la aplicación cliente

5680* ProprietaryFixProtocolVersion

N C1.5 String Identificación exacta de la versión del protocolo usado y esperado por el cliente. MEFFGate siempre cumplimenta este campo, independientemente de si la aplicación cliente lo informó o no.

5679* FixEngineName N String Campo opcional, donde el cliente puede incluir la denominación del software usado para la conexión FIX. Sólo usado a modo informativo. MEFFGate nunca envía este campo

Standard Trailer S



3.13.4 Logout (Msg Type = 5)

El mensaje Logout es usado por ambas partes tanto para solicitar o notificar la finalización de la sesión de comunicación como para aceptar dicha solicitud.


Standard Header S MsgType = 5

58 Text N String Texto explicativo

Standard Trailer S



3.13.5 Heartbeat (Msg Type = 0)

El mensaje Heartbeat es usado por ambas partes para indicar que la conexión se mantiene activa.



112 TestReqID N String Si el mensaje es la respuesta a un mensaje Test Request, debe contener el mismo valor que contenía el campo TestReqID original. En cualquier otro caso, este campo debe omitirse.

Standard Trailer S



3.13.6 Test Request (Msg Type = 1)

El mensaje Test Request es usado por ambas partes para solicitar el envío de un mensaje Heartbeat.



112 TestReqID S String Identificador de la petición. Debe ser incluido en el mensaje Hearbeat de respuesta

Standard Trailer S



3.13.7 Resend Request (Msg Type = 2)

El mensaje Resend Request puede ser usado por ambas partes para solicitar el reenvío de mensajes que no se han recibido.

MEFFGate sólo hace uso de esta funcionalidad después de un mensaje Logon. En cualquier otro caso la recepción de un mensaje fuera de secuencia es considerado un error grave y se cierra la conexión.

MEFFGate sólo acepta el envío de este tipo de mensaje inmediatamente después de un mensaje Logon en el que no se haya especificado el campo NextExpectedMsgSeqNum.



7 BeginSeqNo S Número de secuencia válido

Int Número de secuencia del primer mensaje del rango de mensajes del que se solicita el reenvío. Debe contener un valor inferior al último número de secuencia recibido

16 EndSeqNo S 0 = Infinito Número de secuencia válido

Int Número de secuencia del último mensaje del rango de mensajes del que se solicita el reenvío. Debe contener un valor inferior al último número de secuencia recibido. Si la petición es únicamente de un mensaje EndSeqNo = BeginSeqNo Si la petición es de todos los mensajes a partir de uno dado EndSeqNo = 0

Standard Trailer S



3.13.8 Sequence Reset (Msg Type = 4)

El mensaje Sequence Reset es usado por ambas partes para rellenar un hueco en los mensajes que se están enviando, mediante la reasignación del número de secuencia (ver 3.5). El estándar FIX permite otros usos de este mensaje que no están soportados por MEFF (nótese que el campo GapFillFlag se ha hecho requerido y siempre debe contener el valor “Y”).


Standard Header S MsgType = 4 Téngase presente que PossDupFlag debe contener el valor “Y”

123 GapFillFlag S* Y = Indica que el mensaje es para rellenar un hueco

Boolean Para más información consultar la documento de especificaciones de FIX 4.4

36 NewSeqNo S Int Número de secuencia del mensaje que se enviará a continuación

Standard Trailer S



3.13.9 Reject (Msg Type = 3)

El mensaje Reject es usado por MEFFGate para rechazar un mensaje que no cumpla el protocolo FIX especificado por MEFF.



45 RefSeqNum S Int Número de secuencia del mensaje rechazado

373 SessionRejectReason

N 0 Invalid tag number

1 Required tag missing

2 Tag not defined for this message type

3 Undefined Tag

4 Tag specified without a value

5 Value is incorrect (out of range) for this tag

6 Incorrect data format for value

9 CompID problem

11 Invalid MsgType

13 Tag appears more than once

14 Tag specified out of required order

15 Repeating group fields out of order

16 Incorrect NumInGroup count for repeating group

17 Non "data" value includes field delimiter (SOH character)

99 Other

Int Código que indica el motivo de rechazo

58 Text N String Contiene una descripción más específica de la razón de rechazo

Standard Trailer S

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 4. Convenciones generales en los mensajes de aplicación


4. Convenciones generales en los mensajes de aplicación

4.1 Identificación de operaciones

4.1.1 SecondaryExecID

El campo SecondaryExecID contiene el número de registro de negociación. Este es el código asignado por el sistema central de negociación a la operación o aplicación referenciada en el mensaje. El periodo en que se garantiza la unicidad de este campo viene determinada por cada sistema central de negociación.

4.1.2 SecondaryTradeReportID

El campo SecondaryTradeReportID contiene el número de registro de liquidación. Este es el código asignado por el sistema central de liquidación de MEFF a la operación referenciada en el mensaje. Ambas partes de una operación reciben el mismo identificador.

Cada operación del sistema de negociación tiene su correspondiente operación del sistema de liquidación, sin embargo algunos tipos de operaciones son específicos del sistema de liquidación, como las operaciones de asignaciones, operaciones de traspaso, operaciones de ejercicio, etc.

Los campos SecondaryTradeReportRefID y TrdMatchID también contienen un número de registro de liquidación y son usados para referirse a la operación original e inicial respectivamente.

4.2 Bloque Parties

El bloque Parties (o el bloque NestedParties) es usado en varios mensajes de aplicación para identificar a las partes que intervienen en la transacción.

En la definición detallada de los mensajes que contienen este bloque, se incorpora el bloque tal y como se muestra a continuación. La lista de valores posibles está restringida según las características particulares del mensaje.


Start <Parties>

453 NoPartyIDs N NumInGroup 448

PartyID N String Código de miembro asignado por MEFF

447

PartyIDSource N D = Proprietary/ Custom code

Char Indica la codificación seguida en el campo PartyID. Siempre se usa codificación propia de MEFF

452

PartyRole N Int Indica el rol que toma la parte referenciada en el campo PartyID

End <Parties>

En los mensajes de este manual se usan varios roles. La interpretación del campo PartyID depende del valor PartyRole tal y como se explica a continuación:

1 (Executing Firm)

o Envío. El protocolo implementado no permite el uso de este rol en envíos

o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con el código de miembro origen del Give-up del que se está tratando

3 (Give-out Internal Reference)

o Envío. Cuando se especifica este valor, el campo PartyID se corresponde con la referencia de Give-out asignada por el Miembro Origen para uso interno



o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con la referencia interna de Give-out

4 (Clearing Firm)

o Envío. Usado como criterio de selección. Cuando se especifica este valor, se está indicando que se desea información relacionada con todas las cuentas que son liquidadas por el miembro que se indica en el campo PartyID

o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con el código de miembro que actúa como liquidador de la cuenta de la que se está tratando

12 (Executing Trader)


o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con el usuario que solicitó el traspaso o Give-up al que se refiere en el mensaje

13 (Order Origination Firm)

o Envío. Usado como criterio de selección. Cuando se especifica este valor, se está restringiendo la solicitud a las cuentas que pertenecen al miembro al que se refiere en el campo PartyID

o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con el código del miembro al que pertenece la cuenta de la que se está tratando.

14 (Give-up Clearing Firm)

o Envío. Cuando se especifica este valor, el campo PartyID se corresponde con el código de miembro destino del Give-up solicitado

o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con el código de miembro destino del Give-up del que se está tratando

24 (Give-up Reference)

o Envío. Cuando se especifica este valor, el campo PartyID se corresponde con la referencia de Give-up

o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con la referencia de Give-up



33 (Give-up Mnemonic)

o Envío. Cuando se especifica este valor, el campo PartyID se corresponde con el mnemotécnico de Give-out definido por el Miembro Origen o con el mnemotécnico de Give-in definido por el Miembro Destino

o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con el mnemotécnico de Give-Out o de Give-in

36 (Clearing Broker Trader)


o Recepción. Cuando se especifica este valor, el campo PartyID se corresponde con el usuario del Miembro Destino que aceptó o rechazó el Give-up

4.3 Symbol y SecurityID

El significado de los campos Symbol y SecurityID de los bloques Instrument, UnderlyingInstrument y InstrumentLeg, varía dependiendo de cómo haya sido configurado el usuario asociado al cliente FIX.

Las dos posibles configuraciones son:

Tipo de Configuración Significado de Symbol Significado de SecurityID

Por contrato Código de contrato MEFF Activo subyacente del contrato (véase Tabla 21 en documento “Tablas de Codificación”)

Por activo Activo subyacente del contrato (véase Tabla 21 en documento “Tablas de Codificación”)

Código de contrato MEFF

Hay que tener presente que todos los apartados y mensajes descritos en este manual se refieren al tipo de configuración “Por contrato”.



4.4 Bloque Instrument

En algunas peticiones, el cliente FIX puede especificar criterios de selección de contratos. En estos casos, sólo se devuelve la información relacionada con los contratos que cumplen estos criterios. Los posibles criterios de selección se corresponden con campos del bloque Instrument.

En la siguiente tabla se indican cuáles son los campos aceptados por MEFF y el tipo de petición en que pueden intervenir.

Campo Significado Petición de informa-ción de contratos

Petición de informa-ción de precios

CFICode Codificación de instrumentos financieros según el estándar ISO 10962

X X

SecurityID Activo Subyacente del contrato MEFF X X

MaturityMonthYear Vencimiento del contrato X X

Symbol Código de contrato MEFF - X

En los siguientes subapartados se explica detalladamente el uso de estos campos.

4.4.1 CFICode

El campo CFICode es el menos selectivo de los criterios. Representa un tipo de contrato, por ejemplo todos los futuros, o todas las opciones. Los valores permitidos para el campo CFICode están basados en el estándar ISO 10962. El carácter “X” actúa como comodín. Ejemplos de aplicación del campo CFICode como criterio de selección se presentan en la siguiente tabla.Téngase en cuenta que los valores deben ser de exactamente 6 caracteres.

CFICode Significado

XXXXXX Todos los contratos soportados por MEFF

FXXXSX Todos los futuros

FFSPSX Todos los futuros con entrega física

FFSCSX Todos los futuros con liquidación por diferencias

OXXXXS Todas las opciones

OCXXXS Todas las opciones call

OPXXXS Todas las opciones put

MRXXXX Contratos definidos por MEFF a efectos de la entrega de subyacentes. No son negociables

La lista de valores usados por MEFF se halla en la Tabla 16 del documento “Tablas de Codificación”. Para más información sobre el mensaje SecurityList consulte el capítulo 6 Información de Contratos.

4.4.2 Activo subyacente (campo SecurityID)

Este código identifica el activo subyacente de un contrato (véase Tabla 21 en documento “Tablas de Codificación”).



4.4.3 Vencimiento (campo MaturityMonthYear)

Para los contratos con vencimientos estándar, indica el mes y año de vencimiento de un contrato. En este caos, el formato para este campo es YYYYMM (p.ej. 200812).

Para los contratos con vencimientos no estándar, indica la fecha de vencimiento de un contrato. En este caos, el formato para este campo es YYYYMMDD (p.ej. 20081219).

Para contratos con vencimiento semanal estándar, el formato posible de este campo es YYYYMMwW (p.ej. 200312w3)

4.4.4 Código de contrato (campo Symbol)

Éste es el más selectivo de los criterios, ya que refiere a un contrato específico. Sólo puede ser usado en la petición de información de contratos. Cuando no se desee especificar un contrato concreto y usar el resto de criterios, este campo debe cumplimentarse con el valor “[N/A]”, tal y como se indica en las especificaciones del estándar FIX. Este campo es de uso obligatorio en el bloque Instrument.

4.4.5 Combinación de criterios de selección

Cuando se combinan varios criterios de selección, sólo se consideran seleccionados los contratos que cumplen todos los requerimientos. Cuando no se especifica un campo de selección se entiende que no se desea usar este criterio y ningún contrato es descartado por el mismo.

En la siguiente tabla se presentan algunos ejemplos de selección para el grupo de contratos financieros de MEFF.

CFICode SecurityID MaturityMonthYear Symbol Significado

FXXXSX FIE (omitido) [N/A] Todos los futuros sobre el índice IBEX

FFSPXX BBVA (omitido) [N/A] Todos los futuros sobre BBVA con entrega física

(omitido) FIE 200703 [N/A] Todos los contratos con el índice IBEX como subyacente, con vencimiento marzo de 2007

OCXXXS (omitido) 200606 [N/A] Todas las opciones call con vencimiento junio de 2006

(omitido) (omitido) (omitido) <contrato específico>

El contrato especificado

(omitido) (omitido) (omitido) [N/A] Todos los contratos

4.5 Formato de Error (Campo Text)

El campo Text es usado en varios mensajes para incluir la descripción de un error. En esos casos el formato del campo es:

%MFsXXXXXX-Texto descriptivo

Donde s indica la severidad del error (I: information, W: warning, E: Error), XXXXXX es el código de error, al cual le sigue un texto explicativo. El texto “%MF” es fijo.

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 5. Mensajes Genéricos del Nivel de Aplicación


5. Mensajes Genéricos del Nivel de Aplicación

5.1 Introducción

En este capítulo se presentan algunos mensajes del nivel de aplicación destinados a cubrir dos funcionalidades: el control del estado de la comunicación y el rechazo de mensajes por parte de MEFFGate.

5.2 Estado de la comunicación

MEFFGate incluye un mecanismo para informar a la aplicación cliente sobre el estado de la comunicación entre el propio MEFFGate y los sistemas centrales. Esta funcionalidad se implementa mediante los mensajes Network Status de FIX.

La solicitud puede ser realizada de forma puntual o usando el método de suscripción.

5.3 Cambio de password de conexión al MEFFGate

Mediante esta funcionalidad se permite que la aplicación cliente puede cambiar su password de conexión al MEFFGate.

La nueva password es válida para todas las futuras sesiones de comunicaciones que se establezcan.

5.4 Rechazo de mensajes de aplicación

Cuando MEFFGate recibe un mensaje soportado y sintácticamente correcto, en una situación no soportada, y no existe un mensaje específico de rechazo, se usa el mensaje genérico Business Message Reject. En particular es usado para el rechazo de los mensajes Network Counterparty System Status Request y Confirmation Ack.



Network Counterparty System Status Request (Msg Type = BC)

Solicitud del estado de conexión entre MEFFGate y los sistemas centrales

Network Counterparty System Status Response (Msg Type = BD)

Informe del estado de conexión entre MEFFGate y los sistemas centrales

User Request (Msg Type = BE) Solicitud de cambio de la password de conexión entre la aplicación cliente y MEFFGate

User Response (Msg Type = BF)User Response (Msg Type = BF)

Informe del estado de la solicitud de cambio de password

Business Message Reject (MsgType = j)Business Message Reject (MsgType = j)

Rechazo de mensaje a nivel de aplicación (usado en caso de que no exista un mensaje específico)




Consulta puntual del estado de la conexión

Suscripción al estado de la conexión

Cambio de password de conexión al MEFFGate


En el mensaje User Request, los campos Password [554] y NewPassword [925] han pasado a ser requeridos.


Network CounterParty System Status Request (“BC”)

Network CounterParty System Status Response (“BD”)

NetworkRequestType [935] = 1 (Snapshot)


Network CounterParty System Status Request (“BC”)

Network CounterParty System Status Response (“BD”)

...

NetworkRequestType [935] = 2 (Subscribe)


User Request (“BE”)

User Response (“BF”)




5.8.1 Network Counterparty System Status Request (Msg Type = BC)

Mensaje enviado por la aplicación cliente para solicitar información sobre el estado de conexión entre MEFFGate y los sistemas centrales de MEFF.


Standard Header S MsgType = BC

935 NetworkRequestType S 1 = Snapshot 2 = Subscribe 4 = Stop subscribing

Int

933 NetworkRequestID S String(10) Identificador del mensaje

Standard Trailer S



5.8.2 Network Counterparty System Status Response (Msg Type = BD)

Mensaje enviado por MEFFGate como respuesta a un mensaje Network Counterparty System Status Request Message.

Contiene información acerca del estado de la conexión de MEFFGate con los sistemas centrales de MEFF.


Standard Header S MsgType = BD

937 NetworkStatusResponseType

S 1 = Full

Int

933 NetworkRequestID S String Identificador del mensaje Network Counterparty System Status Request

932 NetworkResponseID S String Identificador único del mensaje

936 NoCompIDs S 1 NumInGroup

930 RefCompID N MEFF String Contiene el mismo valor que el campo SenderCompID de la cabecera (véase 3.3) Este campo siempre está presente en el mensaje

931 RefSubID N Para más detalle sobre los códigos de grupo de contratos, véase Tabla 18 en documento “Tablas de Codificación”

String Contiene el mismo valor que el campo SenderSubID de la cabecera (véase 3.3) Este campo siempre está presente en el mensaje

928 StatusValue N 1 = Connected 2 = Not connected – down expected up 3 = Not connected – down expected down

Int Estado de la conexión Este campo siempre está presente en el mensaje. El valor 3 indica que ha finalizado la sesión de liquidación, pero que MEFFGate se halla disponible para continuar realizando consultas. En este caso el campo StatusText contiene el texto “%MFI – End of session”

929 StatusText N String Información adicional

Standard Trailer S



5.8.3 User Request (Msg Type = BE)

Mensaje enviado por el cliente para modificar su password de conexión al MEFFGate


Standard Header S MsgType = BE

923 UserRequestID S String (10) Identificador único para cada mensaje User Request

924 UserRequestType S 3 = Change Password For User

Int

553 Username S String Identificador de usuario asignado por MEFF. Actualmente está formado por la combinación de código de miembro y de operador

554 Password S* String (10) Password anterior

925 NewPassword S* String (10) Nueva Password

Standard Trailer S



5.8.4 User Response (Msg Type = BF)

Mensaje usado por MEFFGate para indicar el estado de la petición iniciada con un mensaje User Request.

Este mensaje sólo es enviado al operador que realizó la solicitud relacionada.


Standard Header S MsgType = BF

923 UserRequestID S String Identificador asignado por el cliente en el mensaje User Request

553 Username S String Identificador de usuario

926 UserStatus N 5 = Password Changed 6 = Other

Int Estado de la petición del mensaje User Request. En caso de rechazo (valor 6), el campo UserStatusText contiene un texto explicativo

927 UserStatusText N String Cuando UserStatus = 6, contiene una descripción específica del motivo de rechazo

Standard Trailer S



5.8.5 Business Message Reject (MsgType = j)

Mensaje enviado por MEFFGate cuando recibe un mensaje soportado y sintácticamente correcto en una situación no soportada, para la que no existe un mensaje de rechazo específico. En particular es usado para el rechazo de los mensajes Network Counterparty System Status Request y Confirmation Ack.


Standard Header S MsgType = j

45 RefSeqNum S Int MsgSeqNum del mensaje rechazado

372 RefMsgType S . String MsgType del mensaje rechazado

379 BusinessRejectRefID N String Identificador opcional del mensaje rechazado. Para un mensaje Confirmation Ack (MsgType = AU) rechazado, este campo contiene el valor del tag ConfirmID [664.]

380 BusinessRejectReason S 0 = Other 3 = Unsupported Message Type

Int Motivo de rechazo.

58 Text N String Texto explicativo

Standard Trailer S

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 6. Información de Contratos


6. Información de Contratos

6.1 Introducción

En este capítulo se distingue entre la información estática y la información dinámica de un contrato.

Información estática de contratos. Definición de los contratos

Información dinámica de contratos. Precio de liquidación, volumen negociado y open interest

Cada uno de estos grupos es tratado en un apartado independiente de este capítulo. En el apartado 6.4 se detalla el formato de los mensajes correspondientes.



6.2 Información estática de contratos

6.2.1 Descripción

Esta funcionalidad permite obtener la información estática de los contratos definidos en el grupo de contratos.

6.2.2 Solicitud de información de contratos

La solicitud de definición de los contratos se realiza con el mensaje Security List Request, tal y como se muestra en la siguiente tabla:

Contratos

Snapshot

Contratos

Actualización

Security List Request X

Security List Request

NewSecuritySubscription = 1

X X

A continuación se detalla el significado de cada una de las columnas:

Contratos - Snapshot. Se obtienen uno o más mensajes Security List con la descripción de los contratos disponibles, que cumplan los criterios de selección indicados en la solicitud

Contratos - Actualización. Se obtiene un mensaje Security List con la información de un nuevo contrato, cuando éste es dado de alta en el sistema. Sólo se recibe la información de nuevos contratos que cumplan con los criterios de selección indicados en la solicitud

Nótese que el campo NewSecuritySubscription ha sido añadido por MEFF al mensaje Security List Request para permitir la suscripción a la definición de contratos creados durante la sesión, típicamente nuevos strikes de opciones.

6.2.3 Recepción de la definición de contratos

La información de definición de contratos se recibe mediante el mensaje Security List. Este mensaje informa de un contrato a la vez. El campo TotNoRelatedSym informa del total de contratos que cumplen los criterios de selección y el campo NoRelatedSym informa del número de contratos contenidos en el mensaje en cuestión.

6.2.4 Finalización de las suscripciones

Para finalizar una suscripción a la definición de contratos, se usa el mensaje Security List Request con el campo NewSecuritySubscription = 2.

6.2.5 Lista de mensajes


Security List Request (Msg Type = x) Enviado por el cliente para solicitar la definición de contratos.

Security List (Msg Type = y) Enviado por el servidor para informar de la definición de contratos. También es usado para informar el rechazo de la solicitud de dicha información



6.2.6 Flujo de mensajes

Solicitud de definición de contratos sin actualización

Después de la solicitud de definición de contratos se recibe uno o más mensajes Security List. Cada uno de estos mensajes indica el total de contratos que cumplen los criterios de selección en el campo TotNoRelatedSym y el número de contratos contenidos en el mensaje en cuestión en el campo NoRelatedSym.

Solicitud de definición de contratos con actualización

Cuando la solicitud de definición de contratos incluye la actualización de los mismos (NewSecuritySubscription = 1) además de los mensajes explicados en el caso anterior, cuando un nuevo contrato es dado de alta en el sistema se recibe un mensaje Security List conteniendo la información de este contrato.


Security List Request (“x”)

Security List (“y”)

...

SubscriptionRequestType [263] = 1 (Snapshot + Update)

Unsolicited Indicator [325] = N

TotalNoRelatedSym [393] = 350

NoRelatedSym [146] = 1





...

SubscriptionRequestType [263] = 1 (Snapshot + Update)

Unsolicited Indicator [325] = N




Unsolicited Indicator [325] = Y



Symbol [55] = New Symbol

For every

new contract



Solicitud de definición de contratos, sin contratos que cumplan los criterios de selección

Cuando no existen contratos que cumplan los criterios de selección indicados en una solicitud de definición de contratos, MEFFGate contesta con un mensaje Security List con el campo SecurityRequestResult = 2. Téngase en cuenta que en este caso, si la solicitud se realizó con suscripción, dicha suscripción queda activa y por tanto si se dan de alta contratos que cumplan los criterios de selección se recibirán los correspondientes mensajes.

Solicitud de definición de contratos fallida

Cuando una solicitud de definición de contratos es errónea, es contestada con un mensaje Security List con el campo SecurityRequestResult = 1.

6.2.7 Acotaciones y adaptaciones de FIX 4.4

Se ha añadido el campo de usuario NewSecuritySubscription (5682) al mensaje Security List Request, para soportar la funcionalidad de recibir la definición de contrato cuando un nuevo contrato es dado de alta en el sistema

Se han añadido los campos UnsolicitedIndicator [325] y AccruedInterestAmt [159] al mensaje Security List




SecurityRequestResult [560] =

2 (No instruments found that match selection criteria)




SecurityRequestResult [560] =

1 (Invalid or unsupported request)



6.3 Información dinámica de contratos

6.3.1 Descripción

Esta funcionalidad permite solicitar la información dinámica de un conjunto de contratos.

6.3.2 Solicitud de información

La solicitud de información dinámica se realiza mediante el mensaje Market Data Request.

Se puede seleccionar un conjunto de contratos mediante la combinación de campos del bloque Instrument tal y como se explica en 4.3. Como se puede ver en la descripción detallada del mensaje se puede incluir varios bloques Instrument para hacer más de una selección simultánea. Un contrato se considera seleccionado si cumple alguno de los criterios de selección.

A continuación se relacionan los tipos de información que MEFF ofrece. Un cliente puede solicitar una combinación de estos tipos en una misma solicitud.

Precio de liquidación

Volumen negociado

Posición abierta al final de la sesión anterior

La información suministrada como precio de liquidación (Settlement Price) durante la sesión contiene el precio de liquidación del contrato en la sesión previa. Una vez se ha fijado el precio de liquidación de la sesión actual, se pasa a informar de este valor. El campo OpenCloseSettleFlag permite determinar cuando se ha fijado el precio de cierre.

La solicitud puede ser, sólo de la situación actual (snapshot), o incluir las actualizaciones (snapshot + update).

6.3.3 Recepción de información

MEFFGate devuelve la información solicitada mediante mensajes Market Data Snapshot Full Refresh.

Si se ha solicitado la actualización de la información, cada vez que se produce un cambio se recibe un nuevo mensaje Market Data Snapshot Full Refresh. Este mensaje contiene tanto la información que ha variado como el resto de campos solicitados en la suscripción.



Market Data Request (Msg Type = V) Enviado por el cliente para solicitar información de precios

Market Data Snapshot Full Refresh (Msg Type = W) Enviado por el servidor para devolver información de precios

Market Data Request Reject (Msg Type = Y) Enviado por el servidor para notificar que una solicitud Market Data Request ha sido rechazada




Solicitud de información dinámica de contratos sin actualización

Una solicitud de información dinámica de contratos, sin actualización, es contestada por MEFFGate con un mensaje para cada uno de los contratos.

Solicitud de información dinámica de contratos con actualización

Una solicitud de información dinámica de contratos, con actualización, inicialmente recibe un conjunto de mensajes para los contratos seleccionados en el momento de la solicitud. A partir de este punto se reciben mensajes notificando los cambios que se producen.

Téngase en cuenta que una petición de finalización de la suscripción, sólo es contestada en caso de error.


Market Data Request (“V”)

Market Data - Snapshot / Full refresh (“W”)

SubscriptionRequestType [263] = 0 (Snapshot)

(One message for every contract requested)




SubscriptionRequestType [263] = 1 (Snapshot + Updates)

(One message for every contract requested)


...

Snapshot

Updates


SubscriptionRequestType [263] = 2 (Unsubscribe)



Solicitud de información dinámica de contratos errónea

Cuando una solicitud de información dinámica de contratos es errónea es contestada con un mensaje Market Data Request Reject.


No está soportado el refresco incremental

En el mensaje Market Data Request Reject, se ha ampliado el significado del valor 0 (invalid symbol) del campo MDReqRejReason para indicar un criterio de selección inválido



Market Data Request Reject (“Y”)




6.4.1 Security List Request (Msg Type = x)

Usado por el cliente para solicitar la definición de los contratos.


Standard Header S MsgType = x

320 SecurityReqID S String(10) Identificador único para cada mensaje Security List Request Si SubscriptionRequestType = 2 o NewSecuritySubscription = 2, debe contener el valor de la solicitud original

559 SecurityListRequestType S 0 = Symbol 1 = Security type and/or CFICode

Int Criterio de selección usado

Start <Instrument>

55 Symbol S [N/A] o código de contrato

String(22) Código de contrato si SecurityListRequestType = 0, [N/A] si SecurityList-RequestType = 1

48 SecurityID N Para más detalle sobre los activos subyacentes, véase Tabla 21 en documento “Tablas de Codificación”

String Activo subyacente del contrato No permitido si SecurityListRequestType = 0

22 SecurityIDSource N 8 = Exchange Symbol String Requerido si SecurityID está presente. No permitido si Security-ListRequestType = 0

461 CFICode N Longitud exacta. Consúltese 4.4.1 para una lista de valores posibles

String(6) Tipo de contrato No permitido si SecurityListRequestType = 0

200 MaturityMonthYear N YYYYMM o YYYYMMDD o YYYYMMwW

Month-Year

Vencimiento del contrato No permitido si SecurityListRequestType = 0

End <Instrument>

5682*

NewSecuritySubscription N 0 = Snapshot 1 = Updates (Suscribir) 2 = Unsubscribe

Char Indica el tipo de solicitud

Standard Trailer S



6.4.2 Security List (Msg Type = y)

Mensaje enviado por el servidor para informar de la definición de uno o más contratos.


Standard Header S MsgType = y

320 SecurityReqID S String Identificador del mensaje Security List Request al que se está respondiendo

322 SecurityResponseID S String Identificador único para cada mensaje Security List

560 SecurityRequestResult S 0 = Valid request 1 = Invalid or unsupported request 2 = No instruments found that match selection criteria 4 = Instrument data temporarily unavailable 5 = Request was rejected because the CFICode specified is not supported

Int Resultado de la solicitud identificada por SecurityReqID. En caso de rechazo (>0) el campo 58 Text contiene un texto explicativo

325* UnsolicitedIndicator N N = El mensaje es parte de un snapshot Y = El mensaje es enviado como resultado de una suscripción (nuevo contrato)

Boolean Contiene “Y” cuando el mensaje es enviado como resultado de una suscripción

393 TotNoRelatedSym N Int Número total de contratos que cumplen los criterios de selección de la solicitud. El número de contratos que contiene el mensaje se indi-ca en el campo NoRelated-Sym. Este campo siempre está presente cuando SecurityRequestResult = 0

893 LastFragment N Boolean Indica cuando el mensaje es el último en una secuencia de respuesta a una única solicitud. Este campo siempre está presente cuando SecurityRequest-Result = 0

146 NoRelatedSym N 1 NumInGroup

Indica el número de elementos contenidos en este mensaje.

Start <Instrument>

55 Symbol N [N/A] o código de contrato

String(22) Código de contrato. Presente si se ha especificado NoRelatedSym y SecurityRequestResult [560] = 0

48 SecurityID N Para más detalle sobre los activos subyacentes , véase Tabla 21 en documento

String Activo subyacente del contrato




“Tablas de Codificación”

22 SecurityIDSource N 8 = Exchange Symbol

String

454 NoSecurityAltID N 1

455 SecurityAltID N String Código de contrato ISIN

456 SecurityAltIDSource N 4 = ISIN number String

461 CFICode N Longitud exacta. Consúltese la Tabla 16 en documento “Tablas de Codificación” para una lista de los valores posibles

String(6) Tipo de contrato según el estándar ISO 10962


Month-Year

Vencimiento del contrato

541 MaturityDate N LocalMktDate

Fecha de vencimiento

225 IssueDate N UTCDate Fecha de emisión del contrato

202 StrikePrice N Price Precio de ejercicio. Sólo presente en opciones

231 ContractMultiplier N Float Indica el ratio o factor multiplicativo para convertir de unidades de “nominal” (p.ej. contratos) a unidades totales (p.ej. acciones)

107 SecurityDesc N String Descripción del activo subyacente del contrato. Consúltese la Tabla 21 en documento “Tablas de Codificación”

969 MinPriceIncrement N Float Cantidad mínima permitida en el cambio de precio. Este campo siempre está presente en el mensaje

End <Instrument>

711 NoUnderlyings N 1 NumInGroup

Presente si el contrato tiene como subyacente a otro contrato

Start <UnderlyingInstrument>

311 UnderlyingSymbol S String(22) Símbolo del contrato que actúa como subyacente

End <UnderlyingInstrument>

15 Currency N Currency Código de divisa. Expresada según estándar ISO 4217

555 NoLegs N NumInGroup

Presente si el contrato tiene contratos entregables

Start <InstrumentLeg>

600 LegSymbol N String Símbolo del contrato entregable

604 NoLegSecurityAltID N 1

605

LegSecurityAltID N String Código ISIN code del contrato entregable

606

LegSecurityAltIDSource N 4 = ISIN number String

253 LegFactor N Float Factor de conversión del contrato entregable




599 LegInstrRegistry N 1 = IBERCLEAR String Código del Depositario Central del contrato entregable

159* AccruedInterestAmt N Amt Cupón corrido del contrato entregable

End < InstrumentLeg >

58 Text N String Si SecurityRequestResult [560] > 0 contiene una explicación del error

Standard Trailer S



6.4.3 Market Data Request (Msg Type = V)

Usado por el cliente para solicitar información de precios.


Standard Header S MsgType = V

262 MDReqID S String(10) Identificador único para cada mensaje Market Data Request. Si SubscriptionRequestType = 2 debe contener el identificador de la solicitud original

263 SubscriptionRequestType S 0 Snapshot 1 = Snapshot + Updates 2 = Unsubscribe

Char

264 MarketDepth S Int Ignorado por MEFFGate

265 MDUpdateType N 0 = Full refresh Int Requerido si SubscriptionRequestType = 1

267 NoMDEntryTypes S NumInGroup

Número de campos MDEntryType que contiene el mensaje

269

MDEntryType S 6 = Settlement Price B = Trade Volume (total volume for contract in session) C = Open Interest

Char Tipo de información solicitada

146 NoRelatedSym S 1 NumInGroup

Número de criterios de selección

Start <Instrument>

55

Symbol S [N/A] o código de contrato

String(22) Código de contrato

48

SecurityID N Para más detalle sobre los activos subyacentes, véase Tabla 21 en documento “Tablas de Codificación”


22

SecurityIDSource N 8 = Exchange Symbol

String Requerido si se ha especificado SecurityID

461

CFICode N Longitud exacta. Consúltese 4.4.1 para una lista de valores posibles

String(6) Tipo de contrato

200

MaturityMonthYear N YYYYMM o YYYYMMDD o YYYYMMwW

Month-Year

Vencimiento del contrato

End <Instrument>

Standard Trailer S



6.4.4 Market Data Request Reject (Msg Type = Y)

Usado por MEFFGate para rechazar una solicitud Market Data Request.


Standard Header S MsgType = Y

262 MDReqID S String Identificador de la solicitud que se está rechazando

281 MDReqRejReason N 0 = Invalid selection criteria 1 = Duplicate MDReqID 4 = Unsupported SubscriptionRequestType 5 = Unsupported MarketDepth 6 = Unsupported MDUpdateType 8 = Unsupported MDEntryType

Char Motivo de rechazo. Este campo siempre está presente en el mensaje

58 Text N String Texto explicativo del motivo de rechazo

Standard Trailer S



6.4.5 Market Data Snapshot Full Refresh (Msg Type = W)

Usado por MEFFGate para comunicar la información de precios solicitada con un mensaje Market Data Request.


Standard Header S MsgType = W

262 MDReqID S String Identificador del mensaje Market Data Request al que se está contestando

Start <Instrument>

55 Symbol S Código de contrato


End <Instrument>

268 NoMDEntries S NumInGroup Número de entradas que siguen

269 MDEntryType S 6 = Settlement Price B = Trade Volume (total volume for contract in session) C = Open Interest

Char Tipo de información que contiene la presente entrada.

270 MDEntryPx N Price Precio. Presente cuando MDEntryType es igual a 6 En el caso en que no esté presente debe entenderse que el precio es 0

271 MDEntrySize N Qty Volumen. Presente cuando MDEntryType es igual a B o C

286 OpenCloseSettleFlag N 1 = Session Open / Close / Settlement entry 4 = Entry from previous business day 5 = Theoretical Price Value

MultipleValue String

Cuando MDEntryType = 6, los valores 1 y 4 se usan para indicar si el precio de cierre es el de la sesión anterior (valor 4) o el de la sesión actual (valor 1)

811 PriceDelta N float Puede estar presente si MDEntryType = 6

Standard Trailer S

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 7. Seguimiento y Gestión de la Posición


7. Seguimiento y Gestión de la Posición

7.1 Introducción

En este capítulo se cubren las funcionalidades relacionadas con la posición abierta. Esto incluye tanto la consulta, como la modificación mediante ajuste de posición.

7.2 Consulta de posición abierta

La aplicación cliente puede solicitar la posición abierta por cuenta y contrato, mediante el envío de un mensaje Request For Positions.

La posición abierta para una cuenta y contrato refleja la situación de dicha cuenta, en el momento de la solicitud, respecto al contrato en cuestión. MEFF proporciona esta información separada en dos partes:

La posición abierta a principio de día

El conjunto de operaciones realizadas desde el principio de día hasta el momento de la consulta

La posición abierta a principio de día es la que se tuvo en cuenta para la valoración a precio de mercado y el cálculo de garantías diarias de la sesión previa. Sólo se suministra información en aquellas combinaciones de cuenta/contrato que tengan una posición distinta de cero.

La posición abierta a principio de día es informada mediante el mensaje Position Report.

La información de las operaciones realizadas desde el inicio de día hasta el momento de la solicitud es reportada mediante mensajes Trade Capture Report.

Además de la posición en el momento de la solicitud, el mensaje Request For Positions permite realizar una suscripción, solicitando la actualización de información respecto a la posición abierta. La actualización de dicha información se realiza mediante la notificación de las operaciones realizadas con mensajes Trade Capture Report. Téngase en cuenta que al realizar la solicitud de actualización, se recibirán las operaciones de todas las cuentas, tuviesen o no posición en el momento de la solicitud.

La solicitud puede incluir un conjunto de criterios de selección, como pueden ser el miembro liquidador, el tipo de contrato, el instrumento concreto, etc. La información recibida como respuesta sólo es la correspondiente a los pares cuenta-contrato que cumplen los criterios especificados en la solicitud.

En caso de que la solicitud se haya hecho con suscripción, una vez se ha llegado al fin de día y la posición es definitiva, MEFFGate envía un mensaje Position Report, para cada cuenta incluida en la solicitud, informando de la posición abierta en dicho momento. Este mismo mensaje también será incluido en la respuesta a una solicitud sin suscripción realizada después del fin de día.

7.3 Consulta por miembro negociador y/o liquidador

El mensaje Request For Positions permite realizar la consulta por miembro negociador y/o miembro liquidador usando el bloque Parties.

Que un usuario de un liquidador tenga la capacidad de ver la operativa de un miembro al que liquida dependerá de los permisos vigentes.

Cuando en una solicitud no se especifiquen estos campos se considera que la solicitud sólo refiere a todas las cuentas del miembro al que pertenece el operador que realiza la consulta.



Cuando un liquidador desee consultar la posición de las cuentas que él liquida deberá incluir su propio código de miembro en el campo PartyID asociado al PartyRole 4 (Clearing Firm). Si además se desea restringir esta consulta por miembro negociador se puede usar el campo PartyID asociado al PartyRole 13 (Order Origination Firm).

En la siguiente tabla se presentan diferentes ejemplos de selección y su interpretación. En estos ejemplos el Miembro A es un miembro liquidador que realiza la consulta y el Miembro B es un miembro negociador liquidado por A.

Miembro Negociador

(bloque parties con PartyRole = 13)

Miembro Liquidador


Interpretación

- - Selección de cuentas del Miembro A

Miembro A - Selección de cuentas del Miembro A

- Miembro A Selección de cuentas liquidadas por el Miembro A, pertenecientes a cualquier miembro negociador al que liquida, incluidas las suyas

Miembro B Miembro A Selección de cuentas liquidadas por el Miembro A, pertenecientes al miembro B

Miembro B - Consulta errónea. Si se especifica un código diferente al propio como negociador, deberá especificarse el código de liquidador

- Miembro B Consulta errónea. Si se especifica un código diferente al propio como liquidador, deberá especificarse el código propio como negociador

En la siguiente tabla se presentan ejemplos en que la consulta es realizada por el Miembro B, que es un miembro negociador, donde algunas de sus cuentas son liquidadas por el Miembro liquidador A.

Miembro Negociador


Miembro Liquidador


Interpretación

- - Selección de cuentas propias del Miembro B

Miembro B - Selección de cuentas propias del Miembro B

Miembro B Miembro A Selección de cuentas propias del Miembro B que son liquidadas por el Miembro A

- Miembro A Consulta errónea. Si se especifica un código diferente al propio como liquidador, deberá especificarse el código propio como negociador

7.4 Ajustes de posición

Para solicitar un ajuste de posición, la aplicación cliente debe enviar un mensaje Position Maintenance Request indicando la cuenta y contrato que se desea ajustar y el número de contratos en que se desea reducir la posición.

MEFFGate responde a esta solicitud con un mensaje Position Maintenance Report informando de la aceptación o rechazo de la solicitud. Independientemente de si se trata de una aceptación o rechazo, este mensaje informa de la posición para la cuenta y contrato de referencia en el momento de emisión del mensaje.



En MEFF, el ajuste de posición se implementa mediante dos operaciones de cierre de posición, de signo contrario y volumen igual al del ajuste. Los usuarios suscritos a los mensajes Trade Capture Report recibirán los mensajes correspondientes a estas operaciones.



Request For Positions (Msg Type = AN) Solicitud de información de la posición abierta

Request For Positions Ack (Msg Type = AO) Acuse del mensaje Request For Positions

Position Report (Msg Type = AP)Position Report (Msg Type = AP)

Información de la posición abierta en la cámara para un contrato y cuenta

Trade Capture Report (Msg Type = AE) Información de una operación registrada en la cámara

Position Maintenance Request (Msg Type = AL) Solicitud de ajuste de posición

Position Maintenance Report (Msg Type = AM)Position Maintenance Report (Msg Type = AM)

Informe de aceptación o rechazo de un ajuste de posición


Solicitud de posición abierta sin actualización.

En el ejemplo se presentan los mensajes correspondientes a una combinación cuenta-contrato. Si los criterios de selección se refieren a más de una combinación, se recibirán los mismos mensajes para cada una de ellas.

FIX serverFIX client

Position variations during the

current session

Start of day open position

Sn

ap

sh

ot

...

Trade Capture Report (“AE”)

Request For Positions (“AN”)

PosReqType [724] = 0


Position Report (“AP”)

PosType [703] = SOD

LongQty [704] = Long quantity at the start of the day

ShortQty [705] = Short quanitty at the start of the day



Solicitud de posición abierta con actualización.

En el ejemplo se presentan los mensajes correspondientes a una combinación cuenta-contrato. Si los criterios de selección se refieren a más de una combinación, se recibirán los mismos mensajes para cada una de ellas.


Position variations during the

current session

Start of day open position

Future position variations during

the current session

Sn

ap

sh

ot

Up

da

te

...

...



PosReqType [724] = 0

SubscriptionRequestType [263] = 1 (Snapshot +

Update)


PosType [703] = SOD

LongQty [704] = Long quantity at the start of the day

ShortQty [705] = Short quanitty at the start of the day



PosType [703] = FIN

LongQty [704] = long quantity at the end of the day

ShortQty [705] = short quantity at the end of the day

End of day open position



Solicitud de ajuste de posición aceptada

Solicitud de ajuste de posición por n contratos. En el momento de proceso del mensaje por el sistema la cuenta tenía L y N contratos comprados y vendidos respectivamente.

Solicitud de ajuste de posición rechazada


PosTransType [709] = 3 (Position Adjustment);

PosMaintStatus [722] = 0 (Accepted)

PosType [703] = PA (Adjusment Qty)

LongQty [704] = n

PosType [703] = TOT

LongQty [704] = L - n

ShortQty [705] = S - n


PosType [703]= PA (Adjusment Qty);

LongQty [704] = n

Position Maintenance Request (“AL”)

Position Maintenance Report (“AM”)

LastQty [32] = n

Side[54] = 1 (Buy)

PositionEffect[77] = “C” (Close)


LastQty [32] = n

Side[54] = 2 (Sell)

PositionEffect[77] = “C” (Close)




PosType [703] = PA (Adjusment Qty);

LongQty [704] = n




PosMaintStatus [722] = 2 (Rejected)




Se ha añadido el campo de usuario ExchangeTradeType [5681] al mensaje Trade Capture Report

Se han añadido los campos LeavesQty [151] y PosReqID [710] al mensaje Trade Capture Report

Se ha añadido el campo LegSymbol [600] a los mensajes Position Maintenance Request y Position Maintenance Report

El mensaje Trade Capture Report sólo informa de una de las partes que intervienen en la operación. Concretamente, la parte a la que se está enviando el mensaje

En el mensaje Request For Positions se permite que no esté presente el bloque Parties. En tal caso se considera seleccionado el código de miembro negociador propio.




7.8.1 Request For Positions (Msg Type = AN)

Mensaje enviado por el cliente para solicitar la posición abierta, con o sin actualización.

También puede ser usado para solicitar el estado de las peticiones de ejercicio (ver capítulo 10).


Standard Header S MsgType = AN

710 PosReqID S String Identificador de la solicitud asignado por el usuario. Debe ser un valor único cuando se trate de una petición nueva, y el valor asignado previamente cuando se trate de una finalización de suscripción

724 PosReqType S 0 = Positions 2 = Exercises

Int Indica el tipo de solicitud de la transacción

263 SubscriptionRequestType N 0 = Snapshot (valor por defecto) 1 = Snapshot + Updates 2 = Unsubscribe

Char Tipo de solicitud

Start <Parties>

453

NoPartyIDs S >0,<=2 NumInGroup El bloque Parties es requerido por el estándar. MEFFGate acepta que este bloque no esté presente. En tal caso se considera seleccionado código de miembro negociador propio.

448

PartyID S String Código MEFF de miembro

447

PartyIDSource S D = Proprietary / Custom code

Char Requerido si se ha especificado NoPartyIDs

452

PartyRole S 13 = Order Origination Firm 4 = Clearing Firm

Int Indica el rol que toma el código especificado en PartyID. Requerido si se ha especificado NoPartyIDs

End <Parties>

1 Account S Longitud exacta String(5) Código de cuenta. El uso del carácter comodín “?” para la selección múltiple, sólo está permitido en las cinco posiciones a la vez o en las dos últimas posiciones, caso en el cual debe ser usado en ambas a la vez

581 AccountType S 1 Int Ignorado por MEFFGate

Start <Instrument>




55 Symbol S [N/A] o código de contrato

String(22) Código de contrato (Cuando PosReqType = 2 debe referir a una opción)

48 SecurityID N Para más detalle sobre los activos subyacentes, véase Tabla 21 en documento “Tablas de Codificación”


22 SecurityIDSource N 8 = Exchange Symbol

String Requerido si se ha especificado SecurityID

461 CFICode N Longitud exacta. Consúltese 4.4.1 para una lista de valores posibles

String(6) Tipo de contrato


Month-Year Vencimiento del contrato

End <Instrument>

715 ClearingBusinessDate S LocalMktDate Ignorado por MEFFGate

60 TransactTime S UTCTimestamp

Hora en que se ha generado la petición

Standard Trailer S



7.8.2 Request For Positions Ack (Msg Type = AO)

Usado por el servidor para notificar el resultado de una petición Request For Positions de consulta de la posición abierta. Precede a la información de la posición en sí.

Dado que el mensaje Request For Positions puede ser usado para solicitar el estado de las instrucciones de ejercicio, este mensaje también es usado para contestar a esta petición (ver capítulo 10 para más información sobre petición de ejercicio).


Standard Header S MsgType = AO

721 PosMaintRptID S String Identificador único para cada mensaje Request For Positions Ack

710 PosReqID N String Identificador del mensaje de solicitud Request For Positions, tal y como se especificó en éste. Este campo siempre está presente en el mensaje

727 TotalNumPosReports

N Int Número de mensajes que se van a recibir, como respuesta a la solicitud Request For Positions correspondiente

728 PosReqResult S 0 = Valid Request 1 = Invalid or unsupported Request 2 = No positions found that match criteria 4001 = Duplicate PosReqID 4002 = Invalid Account or Symbol

Int Resultado de la solicitud Request For Position

729 PosReqStatus S 0 = Completed 2 = Rejected

Int Estado de la solicitud

1 Account S Longitud exacta String(5) Contiene el mismo valor que se indicó en la solicitud

581 AccountType S 1 Int Contiene el mismo valor que se indicó en la solicitud

58 Text N String Texto explicativo en caso de error

Standard Trailer S



7.8.3 Position Report (Msg Type = AP)

Mensaje que informa de la posición abierta para una cuenta y contrato, como respuesta a un mensaje Request For Positions con el campo PosReqType = 0 (consulta de posición abierta).

Este mensaje también es usado para informar de las peticiones de ejercicio, como respuesta a un mensaje Request For Positions con el campo PosReqType = 2 (consulta de peticiones de ejercicio). Consúltese el capítulo 10 para más información sobre peticiones de ejercicio.


Standard Header S MsgType = AP

721 PosMaintRptID S String Identificador único para cada mensaje Position Report

710 PosReqID N String Identificador del mensaje de solicitud Request For Positions, tal y como se especificó en éste. Este campo siempre está presente en el mensaje

724 PosReqType N 0 = Positions 2 = Exercises

Int Contiene el mismo valor que se indicó en la solicitud

325 UnsolicitedIndicator N N = El mensaje es parte de un snapshot Y = El mensaje es enviado como resultado de una suscripción


727 TotalNumPosReports N Int Número de pares cuenta-contrato de los que se está informando. Téngase presente que no se informa de las cuentas sin posición o sin peticiones de ejercicio

728 PosReqResult S 0 = Valid Request Int Resultado del Request For Positions. Téngase en cuenta que las peticiones erróneas se contestan con el mensaje Request For Positions Ack

715 ClearingBusinessDate S LocalMktDate El contenido de este campo no debe ser tenido en cuenta, está presente por requerimiento del estándar

Start <Parties>

453 NoPartyIDs N NumInGroup Número de participantes que se van a informar

448

PartyID N String Código del Miembro

447


Char

452

PartyRole N 13 = Order Origination Firm

Int Indica el rol que toma el código especificado en PartyID

End <Parties>

1 Account S Longitud fija String(5) Código de la cuenta de la que se está informando

581 AccountType S 1 Int Contiene el mismo valor que se indicó en la solicitud

Start <Instrument>

55 Symbol S Código de contrato String(22) Contrato del que se está informando

End <Instrument>

730 SettlPrice S Price Precio de cierre del contrato. Contiene el valor de la sesión previa hasta que se ha fijado el valor para la sesión actual. El




campo SettlPriceType permite diferenciar estos dos casos

731 SettlPriceType S 1 = Final 2 = Theoretical

Int Indica si el campo SettlPrice es de la sesión previa (valor 2) o de la sesión actual (valor 1)

734 PriorSettlPrice S Price Precio de cierre previo con respecto a SettlPrice

Start <PositionQty>

702 NoPositions S NumInGroup

703

PosType S SOD = Start of Day Position FIN = End-of-Day Qty EX = Option Exercise Qty TOT = Total Transaction Qty

String Se usa SOD y FIN cuando el mensaje es respuesta a una solicitud de informe de posiciones abiertas. Se usa EX y TOT conjuntamente cuando el mensaje es respuesta a una solicitud de informe de peticiones de ejercicio. SOD estará presente en el mensaje que reporta la posición abierta a principio de día. FIN estará presente en el mensaje que reporta la posición abierta a final de día.

704

LongQty N >= 0, sin decimales Qty Cuando PosType = SOD o FIN, indica el número de contratos que conforman la posición compradora de la posición que se está reportando. Cuando PosType = EX indica el número de opciones a ejercer. Cuando no está presente y PosType = EX el mensaje informa de la cancelación de una petición de ejercicio (vuelta al comportamiento por defecto). Cuando PosType = TOT, indica el número de contratos que conforman la posición compradora en el momento del envío del mensaje. Sólo presente si hay posición compradora

705

ShortQty N > 0, sin decimales Qty Cuando PosType = SOD o FIN, indica el número de contratos que conforman la posición vendedora de la posición que se está reportando. No usado cuando PosType = EX. Cuando PosType = TOT, indica el número de contratos que conforman la posición vendedora en el momento del envío del mensaje. Sólo




presente si hay posición vendedora

End <PositionQty>

Start <PositionAmountData>

El contenido de este bloque sólo debe ser tenido en cuenta si el contrato se liquida Mark-to-Market

753 NoPosAmt N NumInGroup

707

PosAmtType N SMTM = Start-of-Day Mark-to-Market Amount FMTM = Final Mark-to-Market Amount

String Se usa SMTM cuando PosType [703] = SOD Se usa FMTM cuando PosType [703] = FIN

708

PosAmt N Amt Importe Nominal/Efectivo del total de la posición (con signo) para esta combinación cuenta-contrato

End <PositionAmountData>

Standard Trailer S



7.8.4 Trade Capture Report (Msg Type = AE)

Mensaje que contiene los datos de una operación de cámara. Este mensaje puede ser respuesta a un mensaje Trade Capture Report Request o a un mensaje Request For Positions.

Cuando el mensaje es respuesta a una solicitud Request For Positions y se corresponde a una operación de una sesión de negociación previa, algunos de los campos obligatorios pueden contener valores no significativos si MEFFGate no dispone de dicha información. En dichos campos las explicaciones detalladas que se presentan a continuación advierten de tal situación.


Standard Header S MsgType = AE

571 TradeReportID S String Identificador único para cada mensaje Trade Capture Report

568 TradeRequestID N String Identificador de la solicitud. Presente cuando la solicitud es un mensaje Trade Capture Report Request

710* PosReqID N String Identificador de la solicitud. Presente cuando la solicitud es un mensaje Request For Positions

150 ExecType N F = Trade Char Tipo de operación

912 LastRptRequested N Boolean Indica si se trata del último mensaje del snapshot de respuesta

325 UnsolicitedIndicator N N = El mensaje es parte de un snapshot Y = El mensaje es enviado como resultado de una suscripción


881 SecondaryTradeReportRefID N String Contiene el número de registro de liquidación de la operación de procedencia

818 SecondaryTradeReportID N String Número de registro de liquidación. Este campo siempre está presente en el mensaje

820 TradeLinkID N String Referencia original primaria de la operación. En un repo, es la referencia común a las dos patas del miembro.

880 TrdMatchID N String Contiene el número de registro de liquidación de la operación inicial

17 ExecID N String Referencia original secundaria de la operación. En un repo, es la referencia correspondiente a una de las patas del miembro (la ida o la vuelta)

527 SecondaryExecID N String Número de registro de negociación de la operación inicial. Coincide con el campo SecondaryExecID del mensaje Execution Report.

5681* ExchangeTradeType N Para más String Tipo de operación.




detalle sobre los tipos de operación, véase Tabla 19 en documento “Tablas de Codificación”

Start <RegulatoryTradeIDGrp>

1907 NoRegulatoryTradeIDs NumInGroup

1903

RegulatoryTradeID N String Contiene el UTI de la operación

1905

RegulatoryTradeIDSource N BMCL-UTI String Identifica la entidad que origina el valor en RegulatoryTradeID [1903]

End <RegulatoryTradeIDGrp>

570 PreviouslyReported S Y Boolean Indica si la operación fue notificada a la contrapartida

Start <Instrument>


String(22) Código de contrato MEFF

864 NoEvents N NumInGroup

865

EventType N 101 = Nominal de la operación (Par amount) 102 = Código del Miembro en el mercado en el que se realiza la entrega 103 = Código del Miembro contrapartida en el mercado en el que se realiza la entrega

Int

868

EventText N String Si EventType = 101, contiene el Nominal de la operación (Par amount). Presente para las operaciones de contado tanto a nivel de titular como a nivel de miembro (entregas) Si EventType = 102, contiene Código del Miembro en el mercado en el que se realiza la entrega. Presente para las operaciones de contado a nivel de miembro (entregas) Si EventType = 103, contiene Código del Miembro contrapartida en el mercado en el que se realiza la entrega. Presente para las operaciones de contado a nivel de miembro (entregas)

End <Instrument>




32 LastQty S >= 0, sin decimales

Qty Volumen comprado/vendido en la operación que se describe

151* LeavesQty N Qty Volumen vivo de la operación. Sólo está presente cuando el mensaje es respuesta a una solicitud de operaciones con volumen vivo

31 LastPx S Price Precio de la operación que se describe

75 TradeDate S LocalMktDate

Fecha local del mercado en la que se negoció la operación.


Fecha y hora, en formato UTC, en que se realizó la transacción.

Start <TrdRegTimestamps>

768 NoTrdRegTimestamps N 1 NumInGroup

769

TrdRegTimestamp N UTCTimestamp

Día y hora de la operación inicial en el Sistema de Negociación

770

TrdRegTimestampType N 3 = Time Out Int

End <TrdRegTimestamps>

63 SettlType N 0 = Regular (valor por defecto) 2 = Next Day (T + 1)

Char Indica el tipo de liquidación de la operación

552 NoSides S 1 NumInGroup Siempre 1 ya que sólo se incluye la parte compradora o vendedora, según corresponda al destinatario del mensaje.

54 Side S 1 = Buy 2 = Sell

Char Posición que toma la parte en la operación.

37 OrderID S String Número de orden, único por operador de trading Contiene “NONE” cuando la operación no es resultado de la ejecución de una orden

198

SecondaryOrderID N String Identificador único de la orden de la operación inicial tal y como se asignó por los sistemas centrales de MEFF o de otro mercado.

Start <Parties>

453 NoPartyIDs N 1 NumInGroup Número de partes. Contiene 1, ya que siempre se informa del miembro al que pertenece la cuenta asociada

448

PartyID N String Código MEFF de miembro

447


Char Presente si se ha especificado NoPartyIDs

452

PartyRole N 13 = Order Origination Firm

Int Indica el rol que toma el código especificado en PartyID. Presente si se ha especificado NoPartyIDs




End <Parties>

1 Account N String(5)/(3) 5 caracteres: Cuenta asociada con la operación. Presente en suscripciones que no utilicen la opción especial TrdType [828] = 15 en el mensaje Trade Capture Report Request. 3 caracteres (sólo para entregas. Para más información ver el apartado 13.4): Titular de la operación de entrega. Se utliiza para las operaciones de contado a nivel de titular (entregas). Presente en suscripciones que utilicen la opción TrdType [828] = 15 en el mensaje Trade Capture Report Request. No informado (sólo para entregas. Para más información ver el apartado 13.4): Se utliiza para las operaciones de contado a nivel de miembro (entregas). Presente en suscripciones que utilicen la opción especial TrdType [828] = 15 en el mensaje Trade Capture Report Request.

381 GrossTradeAmt N Amt Importe Nominal/Efectivo de la transacción

77 PositionEffect N “O” = Open “C” = Close

Indica si la operación abre o cierra posición

58 Text N String Si es una operación procedente de una orden, contiene la referencia asignada en la orden. Si es una aplicación, es la referencia asignada por el intermediario. Si es una asignación de cuenta diaria o un traspaso, contiene la referencia de la operación de procedencia.

136 NoMiscFees N 0, 1, 2 NumInGroup

137

MiscFeeAmt N Amt Importe de la comisión. Contiene un valor positivo cuando se trata de un pago del Miembro al Mercado. Contiene un valor negativo si se trata de una pago del Mercado al Miembro (retrocesión)

138

MiscFeeCurr N Currency Divisa en que está expresada la comisión. Codificada según estándar ISO 4217

139

MiscFeeType N 4=Exchange Fees

Char Tipo de comisión. Contiene el valor 4 cuando




7=Other se trata de una comisión de negociación. Contiene el valor 7 cuando se trata de una comisión de liquidación

891

MiscFeeBasis N 0 = Absolute Int

Standard Trailer S



7.8.5 Position Maintenance Request (Msg Type = AL)

Mensaje usado por la aplicación cliente para realizar una petición de ajuste de posición sobre una cuenta y contrato.

Este mensaje también permite a la aplicación cliente realizar una petición de ejercicio sobre una cuenta y contrato, o cancelar una petición previa. El envío de una nueva petición puede ser usado para reemplazar una solicitud previa.

También es usado para realizar las peticiones de las notificaciones de entrega.


Standard Header S MsgType = AL

710 PosReqID S String Identificador único para cada mensaje Position Maintenance Request

709 PosTransType S 1 = Exercise 3 = Position Adjustment 4 = Delivery

Int Indica el tipo de operación sobre la posición

712 PosMaintAction S 1 = New 2 = Replace 3 = Cancel

Int En el caso de petición de ejercicio indica si se trata de una solicitud explícita (valor 1) o solicitud de vuelta al comportamiento automático (valor 3). En el caso de un ajuste de posición siempre debe contener 1. En el caso de entregas siempre debe contener 2 y debe tenerse en cuenta que el último mensaje reemplaza totalmente al que está siendo modificado.

713 OrigPosReqRefID N String Si PosTransType [709] = 4 (Delivery): PosReqID [710] de un Maintenance Request anterior que se va a modificar Si PosTransType [709] = 1 ó 3: Ignorado por MEFFGate

715 ClearingBusinessDate S LocalMktDate

Ignorado por MEFFGate

1 Account S String(5)/(3) Código de cuenta de la que se solicita el ajuste de posición o el ejercicio. Si entregas, sólo se informa el titular (3 primeras posiciones de la cuenta del miembro en MEFF)

581 AccountType S 1 Int Ignorado por MEFFGate

Start <Instrument>

55 Symbol S String(22) Código de contrato del que se solicita el ajuste de posición, ejercicio o notificación de entrega. En el caso de petición de ejercicio debe referirse a un contrato de opciones

End <Instrument>






Start <PositionQty>

702 NoPositions N NumInGroup

Este bloque es requerido, excepto cuando PosMaintAction [712] =3 (Cancel)

703

PosType N EX = Option Exercise Qty PA= Adjustment Qty DN = Delivery Notice Qty

String Debe contener “EX” cuando PosTransType = 1, “PA” cuando PosTransType = 3 y “DN” cuando PosTransType = 4. Requerido si se ha especificado NoPositions

704

LongQty N > 0, sin decimales Qty Cuando PosType=EX contiene el volumen máximo a ejercer. El valor especial 999999999 significa “ejercer todo” y éste es el valor por defecto. Cuando PosType=PA contiene el número de contratos en que se desea ajustar la posición.

705

ShortQty N > 0, sin decimales Qty Cuando PosType = DN, indica el número de contratos que se entregan

Start <NestedParties>

539

NoNestedPartyIDs N NumInGroup

Número de participantes que se van a informar

524

NestedPartyID N String Ver NestedPartyRole [538]

525

NestedPartyIDSource N D = Proprietary/ Custom code

Char

538

NestedPartyRole N 13 = Order Origination Firm 4 = Clearing Firm

Int Si 13 indica una notificación de entrega efectuada por el propio Miembro Negociador. Si 4 indica una notificación de entrega efectuada por el Liquidador del propio Miembro.

End < NestedParties >

600*

LegSymbol N String Símbolo del contrato entregable

End <PositionQty>

Standard Trailer S



7.8.6 Position Maintenance Report (Msg Type = AM)

Enviado por MEFFGate para informar del resultado de un mensaje Position Maintenance Request.

Este mensaje sólo es enviado al operador que realizó la solicitud. Para realizar un seguimiento, tanto de los ajustes de posición como de las peticiones de ejercicio y las notificaciones de entrega, se puede usar el mensaje Request For Positions con suscripción.


Standard Header S MsgType = AM

721 PosMaintRptID S String Identificador único para cada mensaje Position Maintenance Report

709 PosTransType S 1 = Exercise 3 = Position Adjustment 4 = Delivery

Int Contiene el mismo valor que se especificó en la solicitud

710 PosReqID S String Identificador asignado por el cliente en el mensaje Position Maintenance Request

712 PosMaintAction S 1 = New 2 = Replace 3 = Cancel

Int Contiene el mismo valor que se especificó en la solicitud

713 OrigPosReqRefID S String Contiene el mismo valor que se especificó en la solicitud

722 PosMaintStatus S 0 = Accepted 2 = Rejected

Int Estado de la petición del mensaje Position Maintenance Request. Si el valor es 2, PosMaintResult contiene un código más específico

723 PosMaintResult N 0 = Success 4001 = Duplicate PosReqID 4002 = Invalid Account or Symbol 4003 = Invalid quantity 4004 = Nothing to revoke (sólo para PosMaintAction = 3) 4005 = Action not allowed for this contract code 99 = Other

Int Resultado del mensaje Position Maintenance Request

715 ClearingBusinessDate S LocalMktDate Este campo no debe ser tenido en cuenta y está presente por requerimiento del estándar

1 Account S String(5)/(3) Contiene el mismo valor que se especificó en la solicitud

581 AccountType S 1 Int Este campo no debe ser tenido en cuenta y está presente por requerimiento del estándar

Start <Instrument>

55 Symbol S Código de contrato String(22) Contiene el mismo valor que se especificó en la solicitud




End <Instrument>


Este campo no debe ser tenido en cuenta y está presente por requerimiento del estándar

Start <PositionQty>

702 NoPositions S NumInGroup

703 PosType S EX = Option Exercise Qty PA = Adjustment Qty DN = Delivery Notice Qty DLV = Total Delivery Qty TOT = Total Transaction Qty

String El valor EX sólo está presente cuando se trata de una respuesta a una petición de ejercicio. El valor PA sólo está presente cuando se trata de una respuesta a una petición de ajuste de posición. Los valores DN y DLV sólo están presentes cuando se trata de entregas.

704 LongQty N Qty Cuando PosType=EX contiene el número de contratos que se solicitó ejercer. Cuando PosType=PA contiene el número de contratos que se solicitó ajustar. Cuando PosType=TOT contiene el número de contratos comprados que conforman la posición actual. En caso de una solicitud de ajuste de posición aceptada, éste es el valor después del ajuste

705 ShortQty N Qty Cuando PosType = DN, indica el número de contratos que se entregan. Cuando PosType = DLV, indica el número total de contratos a entregar. Cuando PosType=TOT. Contiene el número de contratos vendidos que conforman la posición actual. En caso de una solicitud de ajuste de posición aceptada, éste es el valor después del ajuste





539 NoNestedPartyIDs N NumInGroup Número de participantes que se van a informar

524

NestedPartyID N String Ver NestedPartyRole [538]

525


Char

538

NestedPartyRole N 13 = Order Origination Firm 4 = Clearing Firm 21 = Clearing Organization

Int Si 13 indica una notificación de entrega efectuada por el propio Miembro Negociador. Si 4 indica una notificación de entrega efectuada por el Liquidador del propio Miembro. Si 21 indica una notificación de entrega efectuada por la Cámara (MEFF)

End < NestedParties >

600* LegSymbol N String Símbolo del contrato entregable

End <PositionQty>

Start <PositionAmountData>

753 NoPosAmt S 0 NumInGroup Este campo no debe ser tenido en cuenta y está presente por requerimiento del estándar

End <PositionAmountData>

58 Text N Texto explicativo. Puede estar presente si PosMaintResult es diferente de 0

Standard Trailer S

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 8. Consulta de operaciones


8. Consulta de operaciones

8.1 Introducción

En este capítulo se describen los mecanismos ofrecidos por la interfaz FIX de MEFF para la consulta de las operaciones registradas en la Contrapartida Central.

La aplicación cliente puede solicitar la consulta de operaciones registradas mediante el mensaje Trade Capture Report Request.

El conjunto de operaciones que se reportan viene determinado por los siguientes criterios de selección:

Bloque Parties. Permite seleccionar por miembro liquidador y miembro negociador

Campo TradeDate. Permite discernir si se quieren consultar:

o Las operaciones de la sesión. En este caso el mensaje de solicitud no debe contener este campo

o Todas las operaciones vivas, independientemente de la fecha de liquidación. En este caso el mensaje debe contener el valor “19800101” en el campo TradeDate

Campo Side. Si este campo está presente en el mensaje de solicitud, su valor indica si se desean sólo las operaciones compradoras o las vendedoras

Como respuesta a esta petición se recibe un mensaje Trade Capture Report por cada operación que cumpla los criterios de selección. Si no hay ninguna operación que cumpla los criterios, se recibe un mensaje Trade Capture Report Request Ack informando de este hecho.

La petición se puede realizar en dos modalidades, según se indique en el campo SubscriptionRequestType:

SubscriptionRequestType = 0 (Snapshot). Se recibe un mensaje por cada operación, que cumpla los criterios de selección, registrada anteriormente al momento de la petición

SubscriptionRequestType = 1 (Snapshot plus update). Se reciben los mismos mensajes de la petición Snapshot y a partir de ese momento se recibe un mensaje nuevo por cada operación que se produce y que cumple con el criterio de selección

Cada mensaje recibido contiene un número de registro de liquidación único en el campo SecondaryTradeReportID. Cuando la operación de la que se está informando proviene de una operación previa, el campo SecondaryTradeReportRefID contiene el número de registro de liquidación de la operación original. El identificador de operación de liquidación es el mismo para las dos partes de una operación. Es decir, si se toma tanto el papel de comprador como vendedor, debe esperarse la recepción de dos mensajes Trade Capture Report con el mismo SecondaryTradeReportID.

Para las operaciones que son resultado de negociación, se dispone de los campos SecondaryExecID, OrderID y SecondaryOrderID para realizar la reconciliación front-to-back.

Cuando el mensaje Trade Capture Report es el resultado de la ejecución de una aplicación, puede relacionarse con el correspondiente mensaje Execution Report mediante el campo SecondaryExecID de ambos, que contendrá el mismo valor.

8.2 Consulta por miembro negociador y/o liquidador

El mensaje Trade Capture Report Request permite realizar la consulta por miembro negociador y/o miembro liquidador usando el bloque Parties.

Que un usuario de un liquidador tenga la capacidad de ver la operativa de un miembro al que liquida dependerá de los permisos vigentes.



Cuando en una solicitud no se especifiquen estos campos se considera que la solicitud sólo refiere a las operaciones de todas las cuentas del miembro al que pertenece el operador que realiza la consulta.

Cuando un liquidador desee consultar operaciones de las cuentas que él liquida deberá incluir su propio código de miembro en el campo PartyID asociado al PartyRole 4 (Clearing Firm). Si además se desea restringir esta consulta por miembro negociador se puede usar el campo PartyID asociado al PartyRole 13 (Order Origination Firm).

En la siguiente tabla se presentan diferentes ejemplos de selección y su interpretación. En estos ejemplos el Miembro A es un miembro liquidador que realiza la consulta y el Miembro B es un miembro negociador liquidado por A.

Miembro Negociador


Miembro Liquidador


Interpretación

- - Selección de las operaciones en cuentas del Miembro A

Miembro A - Selección de las operaciones en cuentas del Miembro A

- Miembro A Selección de las operaciones cuentas liquidadas por el Miembro A, pertenecientes a cualquier miembro negociador al que liquida, incluidas las suyas

Miembro B Miembro A Selección de las operaciones en cuentas liquidadas por el Miembro A, pertenecientes al miembro B

Miembro B - Consulta errónea. Si se especifica un código diferente al propio como negociador, deberá especificarse el código de liquidador

- Miembro B Consulta errónea. Si se especifica un código diferente al propio como liquidador, deberá especificarse el código propio como negociador

En la siguiente tabla se presentan ejemplos en que la consulta es realizada por el Miembro B, que es un miembro negociador, donde algunas de sus cuentas son liquidadas por el Miembro liquidador A.

Miembro Negociador


Miembro Liquidador


Interpretación

- - Selección de operaciones cuentas propias del Miembro B

Miembro B - Selección de operaciones cuentas propias del Miembro B

Miembro B Miembro A Selección de operaciones en cuentas propias del Miembro B que son liquidadas por el Miembro A

- Miembro A Consulta errónea. Si se especifica un código diferente al propio como liquidador, deberá especificarse el código propio como negociador





Trade Capture Report Request (Msg Type = AD) Solicitud de operaciones

Trade Capture Report Request Ack (Msg Type = AQ) Acuse del mensaje Trade Capture Report Request

Trade Capture Report (Msg Type = AE) Información de una operación registrada en la contrapartida central


Solicitud de operaciones de cámara con suscripción de actualización, seguido de una cancelación de la suscripción

Después de la solicitud se reciben los mensajes correspondientes a las operaciones que se habían registrado hasta el momento (snapshot) y a partir de este punto se reciben las nuevas operaciones según se vayan registrando.


...


Trade Capture Report Request (“AD”)

SubscriptionRequestType [263] = 1 (Snapshot + Updates)


... One message for every trade in the snapshot

One message for every update


SubscriptionRequestType [263] = 2 (Unsubscribe)



Solicitud de operaciones de cámara sin suscripción de actualización, sin operaciones que cumplan con los criterios de selección

Cuando no hay ninguna operación que cumpla los criterios de selección, el servidor envía un mensaje Trade Capture Report Request Ack para notificar el resultado de la petición, con un valor 0 en el campo TotNumTradeReports.

Solicitud de operaciones de cámara no válida

Cuando la solicitud de operaciones de cámara (mensaje Trade Capture Report Request) no es válida, la solicitud es rechazada mediante un mensaje Trade Capture Report Request Ack.


En el mensaje Trade Capture Report Request sólo se permiten algunos de los criterios de selección contemplados por el estándar




Trade Capture Report Request Ack (“AQ”)

TotNumTradeReports [748] = 0

TradeRequestStatus [750] = 1 (Completed)




Trade Capture Report Request Ack (“AQ”)

TradeRequestStatus [750] = 2 (Rejected)




8.6.1 Trade Capture Report Request (Msg Type = AD)

Mensaje enviado por el cliente para solicitar información de las operaciones de cámara. Permite la solicitud con o sin suscripción a nuevas operaciones.


Standard Header S MsgType = AD

568 TradeRequestID S String (10)

Identificador de la solicitud asignado por el usuario. Debe ser un valor único cuando se trate de una petición nueva, y el valor asignado previamente cuando se trate de una finalización de suscripción

569 TradeRequestType S 0 = All trades that match criteria

Int


Char Indica si la petición es solicitud, con o sin suscripción o si bien si trata de una cancelación de una petición previa

818 SecondaryTradeReportID N String Número de registro de liquidación

828 TrdType N 15 = Deliveries Int Sólo debe estar presente en la suscripción especial de las operaciones de compra-venta a realizar en IBERCLEAR como consecuencia del proceso de entrega

Start <Parties>

453 NoPartyIDs N >0,<=2 NumInGroup Número de criterios de selección definidos en el bloque Parties

448

PartyID N String Código MEFF de miembro Requerido si se ha especificado NoPartyIDs

447


Char Requerido si se ha especificado NoPartyIDs

452

PartyRole N 13 = Order Origination Firm 4 = Clearing Firm

Int Indica el rol que toma el código especificado en PartyID. Requerido si se ha especificado NoPartyIDs

End <Parties>

580 NoDates N 1 NumInGroup

75 TradeDate N “19800101” LocalMktDate

Sólo debe estar presente en la solicitud de todas las operaciones con volumen vivo diferente de 0. En dicho caso debe contener el valor especial “19800101”

54 Side N 1 = Buy 2 = Sell

Char Criterio opcional de selección. Permite obtener sólo operaciones en que se actúa como comprador o como vendedor

Standard Trailer S



8.6.2 Trade Capture Report Request Ack (Msg Type = AQ)

Mensaje usado por MEFFGate para notificar que un mensaje Trade Capture Report Request no es válido o que no hay ninguna operación que cumpla los criterios de selección.


Standard Header S MsgType = AQ

568 TradeRequestID S String Identificador especificado en el mensaje de solicitud Trade Capture Report Request correspondiente

569 TradeRequestType S Int Mismo valor que se especificó en la solicitud


Char El mismo valor que se especificó en la solicitud

748 TotNumTradeReports N 0 Int Número de operaciones que contiene la selección. Siempre es 0 ya que este mensaje sólo es enviado cuando la solicitud no es válida o no hay operaciones que cumplan los criterios de selección

749 TradeRequestResult S 0 = Successful 2 = Invalid TradeRequestType 99 = other

Int Resultado de la petición Cuando el valor es 99, el campo Text contiene un texto explicativo

750 TradeRequestStatus S 1 = Completed 2 = Rejected

Int Estado de la petición. Cuando se informa de un error el valor es 2, cuando no hay operaciones que cumplan los criterios el valor es 1

58 Text N String Contiene un texto explicativo del motivo de rechazo

Standard Trailer S

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 9. Gestión de Operaciones


9. Gestión de Operaciones

9.1 Introducción

En este capítulo se cubren las funcionalidades asociadas con el traspaso, total o parcial, de una operación de una cuenta a otra.

MEFF clasifica esta operativa según el tipo de las cuentas de origen y destino.

Término MEFF Origen Destino

Asignación de cuenta diaria Cuenta diaria Cuenta ordinaria

(mismo miembro)

Traspaso Cuenta ordinaria Cuenta ordinaria

(mismo miembro)

Give-up Cuenta diaria o oridinaria

Otro miembro

MEFF sólo permite el traspaso de órdenes ya ejecutadas, es decir operaciones.

En los siguientes apartados se describen las particularidades de las diferentes operativas.

9.2 Asignación de cuenta diaria y traspaso

Desde el punto de vista de la interfaz FIX, una asignación de cuenta diaria y un traspaso funcionan del mismo modo. La única diferencia es el tipo de la cuenta origen, y este atributo está implícito en la cuenta y por tanto no hay que especificarlo en el mensaje.

La solicitud se realiza mediante el mensaje Allocation Instruction, indicando los datos de la operación a transferir y la cuenta destino.

MEFFGate informa del estado de la solicitud, al operador que la realizó, mediante el mensaje Allocation Instruction Ack. Cuando la solicitud es aceptada y realizada todos los operadores del Miembro reciben un mensaje Confirmation con los datos del traspaso realizado.

9.3 Give-up (Miembro Origen)

La operativa de Give-up siempre es iniciada por el Miembro al que pertenece la cuenta asociada a la operación que se va a transferir. En este documento, dicha figura es referida como Miembro Origen.

El Miembro Origen puede solicitar la realización de un Give-up mediante el mensaje Allocation Instruction. Dicho mensaje debe contener los datos de la operación a transferir, el Miembro Destino y una referencia para el Miembro Destino.

Antes de que el Give-up sea aceptado por el Miembro Destino, cualquier operador del Miembro Origen puede cancelar la solicitud con un nuevo mensaje Allocation Instruction.

MEFFGate notifica los estados de la petición, al operador que la realizó, mediante mensajes Allocation Instruction Ack.

Por otro lado, MEFFGate informa a todos los operadores del Miembro Origen, incluido el que inició la actuación, de los datos del Give-up y los diferentes estados por los que va pasando mediante mensajes Confirmation.



9.4 Give-up (Miembro Destino)

El Miembro Destino es el seleccionado por el Miembro Origen, en su mensaje de solicitud, como receptor de la operación que se va a transferir.

Una vez la solicitud de Give-up es procesada por los sistemas centrales, ésta puede ser aceptada automáticamente o quedar pendiente de aceptación por parte de Miembro Destino.

El hecho de que un Give-up sea aceptado de forma automática dependerá de la normativa de la Cámara y los posibles filtros que el Miembro Destino tenga configurados.

En el caso de que el Give-up quede pendiente de aceptación, MEFFGate envía un mensaje Confirmation a todos los operadores del Miembro Destino informando de los datos del Give-up y solicitando la aceptación o rechazo del mismo. Si el Miembro Destino tiene definida una cuenta destino para la referencia introducida en el mensaje de solicitud, ésta cuenta estará presente en el mensaje.

La aceptación o rechazo de un Give-up se realiza con un mensaje Confirmation Ack. En caso de aceptación, en dicho mensaje debe indicarse la cuenta destino del Give-up, independientemente de si se recibió información de la cuenta asociada a la referencia.

Si el Miembro Destino es liquidador de la cuenta que ha elegido como destino, su aceptación es suficiente para la realización del Give-up. Si el Miembro Destino no es liquidador de dicha cuenta, será necesaria la aceptación del Miembro Liquidador para la realización del Give-up.

Si es necesaria la aceptación por parte del Miembro Liquidador de la cuenta destino, una vez éste se ha pronunciado, MEFFGate envía un mensaje Confirmation informando del estado en que queda el Give-up.

En caso de que el Miembro Liquidador rechace el Give-up, éste vuelve a quedar pendiente del Miembro Destino, que puede optar por rechazarlo definitivamente o volver a especificar una cuenta. Ambas actuaciones se llevan a cabo con el mensaje Confirmation Ack tal y como se ha descrito previamente en este mismo apartado.

9.5 Give-up (Liquidador de la cuenta destino)

Cuando el Miembro Destino de un Give-up no es liquidador de su operativa, será necesaria la aceptación del Miembro Liquidador de la cuenta destino para que se realice el Give-up.

Al igual que sucede en el caso del Miembro Destino, esta aceptación puede ser realizada de forma automática por los sistemas centrales de MEFF a partir de los posibles filtros que el Miembro Liquidador tenga definidos.

Cuando un Give-up queda pendiente de la aceptación por parte del Miembro Liquidador de la cuenta destino, MEFFGate envía un mensaje Confirmation a todos los operadores de este miembro, informando de los datos del Give-up y solicitando la aceptación o rechazo del mismo. Esta aceptación o rechazo se realiza con un mensaje Confirmation Ack.

Cuando el Give-up es rechazado por el Miembro Liquidador, éste queda pendiente de actuación por parte del Miembro Destino. El Miembro Liquidador sólo volverá a recibir un mensaje relacionado con este Give-up cuando el Miembro Destino opte por volver a seleccionar una cuenta que también sea liquidada por él.

9.6 Campo AllocID

El campo AllocID, presente en una solicitud iniciada con un mensaje Allocation Instruction, es el identificador que permite cancelar dicha petición (sólo Give-up), así como relacionar la petición con los mensajes Confirmation de notificación de estado de traspasos o Give-ups.



El campo AllocID asignado por el cliente debe ser de diez caracteres de longitud. Si la longitud fuese inferior, MEFFGate completa con espacios por detrás hasta llegar a dicha longitud. MEFFGate también acepta que los mensajes enviados por el cliente usen un AllocID de longitud 30, en este caso sólo las 10 últimas posiciones pueden ser fijadas libremente, ya que las 20 primeras deben coincidir con el formato que se presenta a continuación.

- Prefijado del identificador AllocID -

MEFFGate realiza un proceso de prefijado del campo AllocID para evitar duplicados en este identificador.

El AllocID asignado por MEFFGate en el mensaje de respuesta tiene el formato AAMMDDMmmmTttMmmmTttNnnnnnnnnn, formado con la siguiente codificación:

AAMMDD. Es la fecha de la sesión de cámara

MmmmTtt. Contiene el código de miembro y operador de conexión desde el que se realizó la solicitud

Nnnnnnnnnn. Es el valor asignado por la aplicación cliente a AllocID en el mensaje original

En el caso de los Give-up, este identificador también está presente en los mensajes Confirmation recibidos por el Miembro Origen, que se generan como resultado de la solicitud de Give-up.

Un operador del Miembro Origen que quiera cancelar un Give-up, debe usar este identificador en el campo RefAllocID del mensaje Allocation Instruction de solicitud.

10

20 10

AllocID =

AllocID =Allocation Instruction

Allocation

Instruction Ack

AllocID =

Allocation

Instruction Ack

...

Envío de mensaje sin especificar el prefijo

20 10

AllocID =

Allocation Instruction

Allocation

Instruction Ack

AllocID =

Allocation

Instruction Ack

...

Envío de mensaje especificando el prefijo

20 10

AllocID =

MEFFGateCliente

MEFFGateCliente



9.7 Campo SecondaryAllocID

El campo SecondaryAllocID es un identificador único para cada traspaso realizado en MEFF, sea éste un Give-up, una asignación de cuenta diaria o un traspaso propiamente dicho.

Este campo está presente en los mensajes Confirmation que las aplicaciones cliente reciben informando del estado de un traspaso.

De este modo todos los mensajes relacionados con un mismo Give-up contendrán el mismo valor en este campo, independientemente del papel que tome el receptor. Por ello, este valor permite identificar de forma unívoca el Give-up frente a la cámara y el resto de participantes.

9.8 Seguimiento de operaciones mediante los mensajes Trade Capture Report

En MEFF, la operativa de traspasar, total o parcialmente, una operación de una cuenta a otra se lleva a cabo mediante la realización de dos nuevas operaciones. La primera es sobre la cuenta origen y con signo opuesto a la operación original. La segunda es sobre la cuenta destino y con el mismo signo que la operación original. El volumen de ambas operaciones es el número de contratos que se transfieren de la operación original.

Una vez realizado el proceso de traspaso, sea éste una asignación de cuenta diaria, un traspaso o un Give-up, aquellos operadores que estén suscritos recibirán los mensajes Trade Capture Report de la operación u operaciones correspondientes.

En el caso de que la operación provenga de un traspaso, el mensaje Trade Capture Report contiene una serie de campos relevantes para la reconciliación de la información y el seguimiento de operaciones:

PositionEffect. Indica si la operación abre o cierra posición. De las operaciones derivadas de un traspaso, la realizada sobre la cuenta origen contendrá “C” (Close), y la realizada sobre la cuenta destino “O” (Open).

SecondaryTradeReportRefID. Contiene el número de registro de liquidación de la operación de procedencia.

SecondaryTradeReportID. Contiene el número de registro de liquidación de la nueva operación. Este mismo campo se encuentra en los mensajes Confirmation relacionados que informan de la aceptación.

TrdMatchID. Contiene el número de registro de liquidación de la operación inicial.





Allocation Instruction (Msg Type = J) Solicitud de un traspaso, una asignación de cuenta diaria o un Give-up

Allocation Instruction Ack (Msg Type = P) Acuse del mensaje Allocation Instruction. Contiene el estado de la solicitud relacionada

Confirmation (Msg Type = AK) Informe del estado de un traspaso, una asignación de cuenta diaria o Give-up. También usado para solicitar la aceptación o rechazo de un Give-up

Confirmation Ack (Msg Type = AU) Mensaje de aceptación o rechazo de un Give-up

Business Message Reject (MsgType = j) Mensaje usado por MEFFGate para el rechazo de un mensaje Confirmation Ack inválido

Trade Capture Report (Msg Type = AE) Informe de ejecución de una operación. Enviado a los clientes implicados que estén suscritos




Dado que respecto al flujo de mensajes su comportamiento es idéntico, en este apartado se usará el termino “asignación” para referir a la asignación de cuenta diaria y el traspaso propiamente dicho.

En los diagramas presentes en este apartado el uso de dos flechas indica que el mensaje va dirigido a todos los operadores del miembro en cuestión.

Solicitud de asignación aceptada

El cliente envía la solicitud mediante un mensaje Allocation Instruction. Primero recibe el mensaje Allocation Instruction Ack con el campo AllocStatus = 3, que indica que MEFFGate ha recibido el mensaje y lo ha enviado a los sistemas centrales. Posteriormente se recibe el mensaje Allocation Instruction Ack con el campo AllocStatus = 0, que indica que el mensaje ha sido aceptado por los sistemas centrales.

Cuando la asignación ha sido realizada, se envía un mensaje Confirmation a todos las aplicaciones cliente del Miembro para informar de los datos de la solicitud.

Además, se envía un mensaje Trade Capture Report por cada operación que se derive de la asignación realizada, a las aplicaciones cliente suscritas a este tipo de mensajes.


Allocation Instruction (“J”)

AllocID [70] = X

Allocation Instruction Ack(“P”)

AllocStatus [87] = 0 (Accepted)

AllocID = pref+X

Confirmation(“AK”)

ConfirmTransType [666] = 0 (New)

ConfirmType [773] = 1 (Status)

SecondaryAllocID[793] = idt

SecondaryConfirmStatus [5683] = ”A”

AllocID [70] = pref+X

SecondaryTradeReportID[818] = NReg

SecondaryTradeReportID[818] = NReg


AllocStatus [87] = 3 (Received)

AllocID = pref+X




Solicitud de asignación rechazada por los sistemas centrales

El cliente envía la solicitud mediante un mensaje Allocation Instruction. Primero recibe el mensaje Allocation Instruction Ack con el campo AllocStatus = 3, que indica que MEFFGate ha recibido el mensaje y lo ha enviado a los sistemas centrales. Finalmente recibe el mensaje Allocation Instruction Ack con el campo AllocStatus = 1, que indica que la asignación ha sido rechazada por los sistemas centrales.

Solicitud de asignación rechazada por el servidor MEFFGate

El cliente envía la solicitud mediante un mensaje Allocation Instruction. El mensaje es rechazado por MEFFGate que responde con el mensaje Allocation Instruction Ack con el campo AllocStatus = 1.


AllocID [70] = X


AllocStatus [87] = 3 (Received)

AllocID = pref+X


AllocStatus [87] = 1 (Rejected)

AllocID = pref+X




AllocStatus [87] = 1 (Rejected)

AllocID = pref+X


AllocID [70] = X



Solicitud de Give-up aceptada cuyo Miembro Destino no es liquidador de su propia operativa



ConfirmID [664] = n


SecondaryAllocID[793] = idg

SecondaryConfirmStatus [5683] = ”P”




ConfirmID [664] = m

ConfirmType [773] = 2 (Confirmation)



Confirmation ack (“AU”)

ConfirmID [664] = m

AffirmStatus [940] = 3 (Affirmed)

AllocAcount [79] = cuenta destino



ConfirmTransType [666] = 1 (Replace)

ConfirmID [664] = n’

ConfirmRefID [772] = n



SecondaryConfirmStatus [5683] = ”N”




ConfirmID [664] = m’

ConfirmRefID [772] = m






ConfirmID [664] = p




(continues on the next page ...)


AllocStatus [87] =0 (Accepted)

AllocID = pref+X

Executing Broker FIX Server

Clearing Broker

Clearing Member



AllocID [70] = X

AllocStatus [87] =3 (Received)





ConfirmID [664] = p

AffirmStatus [940] = 3 (Affirmed)




ConfirmID [664] = n’’

ConfirmRefID [772] = n’





SecondaryTradeReportID [818] = NReg



ConfirmID [664] = m’’

ConfirmRefID [772] = m’







ConfirmID [664] = p’

ConfirmRefID [772] = p









Servidor FIX

(… continues from previous page)



Executing Broker

Clearing Broker

Clearing Member



Cancelación del Give-out por parte del Miembro Origen



ConfirmID [664] = n







ConfirmID [664] = m






ConfirmID [664] = n’

ConfirmRefID [772] = n



SecondaryConfirmStatus [5683] = ”C”

AllocID [70] = pref+X’



ConfirmID [664] = m’

ConfirmRefID [772] = m



SecondaryConfirmStatus [5683] = ”C”


AllocStatus [87] =0 (Accepted)

AllocID = pref+X

Executing Broker FIX Server

Clearing Broker

Clearing Member



AllocID [70] = X

AllocStatus [87] =3 (Received)



AllocID [70] = X’

RefAllocID [72] = pref+X

AllocTransType [71] = 2 (Cancel)



Solicitud de alta o cancelación de Give-up rechazada

Cuando una solicitud para dar de alta o cancelar un Give-up no sea válida, será rechazada mediante el correspondiente mensaje Allocation instruction Ack. En dicho caso no existe un mensaje Confirmation asociado ya que no se llega a procesar la solicitud.

Envío de mensaje Confirmation Ack rechazado

Cuando un mensaje Confirmation Ack no sea válido, ya sea por los datos o por el estado del Give-up de referencia, será rechazado con un mensaje Business Message Reject.

Servidor FIX


AllocID [70] = X


AllocStatus [87] =1 (Rejected)


Text [58] = rejection reason

Miembro Origen

Servidor FIX

Miembro Destino /

Miembro Liquidador de

la cuenta destino


MsgSeqNum [34] = numseq

ConfirmID [664] = m

Business Message Reject (“j”)

RefSeqNum [45] = numseq

RefMsgType [372] = AU

BusinessRejectRefID [379] = m

Text [58] = rejection reason




Sólo algunas de las funcionalidades definidas por FIX relacionadas con el mensaje Allocation Instruction están soportadas. Los traspasos sólo están permitidos post-trade, por tanto basados en operaciones y no en órdenes. Por ello, ciertos campos relacionados con órdenes que son requeridos por el estándar, son ignorados por MEFFGate.

FIX permite la asignación de varias operaciones en un único mensaje y permite la asignación a varias cuentas. Estas funcionalidades no están soportadas por MEFFGate. Un mensaje Allocation Instruction está relacionado con una única operación y cuenta destino.

Los campos NoExecs (124), LastQty (32), LastPx (31), AllocAccount (79) y AllocQty (80) han pasado a ser requeridos en el mensaje Allocation Instruction

Se ha añadido el campo SecondaryTradeReportID (818) al mensaje Allocation Instruction. Este campo es requerido en el mensaje.

Se han añadido los campos SecondaryTradeReportID (818) y SecondaryTradeReportRefID (881) al mensaje Confirmation

Se ha añadido el campo de usuario SecondaryConfirmStatus (5683) al mensaje Confirmation

Se han añadido los campos AllocAccount (79) y SecondaryAllocID (793) al mensaje Confirmation Ack




9.12.1 Allocation Instruction (Msg Type = J)

Mensaje enviado por el cliente para solicitar un traspaso, una asignación de cuenta diaria o una petición de Give-up.

El criterio usado por MEFFGate para diferenciar un Give-up de un traspaso o una asignación es la presencia del campo 538 en el mensaje.


Standard Header S MsgType = J

70 AllocID S String(30) Identificador único para cada mensaje Allocation Instruction

71 AllocTransType S 0 = New

2 = Cancel

Char Indica si el mensaje es de solicitud de traspaso o cancelación. La cancelación sólo puede realizarse sobre un traspaso de tipo Give-up que esté pendiente de aceptación por parte del destino

626 AllocType S 1 = Buyside Calculated

Int

72 RefAllocID N String(30) Identificador de la solicitud de Give-up a cancelar. Requerido cuando AllocTransType contiene 2.

796 AllocCancReplaceReason N 1 = Original details incomplete/incorrect

99 = Other

Int Requerido cuando AllocTransType contiene 2. Ignorado por por MEFFGate

857 AllocNoOrdersType S 0 = Not specified Int

124 NoExecs S* 1 NumInGroup

Indica el número de operaciones que se van a asignar

32 LastQty S* > 0, sin decimales Qty Volumen de la operación

31 LastPx S* Price Precio de la operación

818*

SecondaryTradeReportID S* String Número de registro de liquidación de la operación a traspasar


Char Indica si la operación a transferir es compradora o vendedora

Start <Instrument>



End <Instrument>

53 Quantity S > 0 Qty Cantidad de contratos a ser transferidos

6 AvgPx S Price Precio de la operación resultante. Debe contener el mismo valor que el campo LastPx



78 NoAllocs S* 1 NumInGroup

Número de destinos. MEFFGate sólo acepta un único destino

79

AllocAccount S* Longitud exacta String(5) Cuenta destino Ignorado por MEFFGate cuando la solicitud es de Give-up

AllocQty S* Qty Cantidad a ser transferida. Debe




80 ser igual al campo Quantity


539 NoNestedPartyIDs N NumInGroup

Requerido cuando la solicitud es de Give-up

524

NestedPartyID N String Referencia interna de Give-out, Código del Miembro Destino del Give-up, referencia de Give-up o mnemotécnico de Give-out. Para la referencia interna de Give-out (NestedPartyRole=3) este campo está limitado a 18 caracteres. Para el Miembro Destino del Give-up (NestedPartyRole=14) este campo tiene una longitud exacta de 4 caracteres alfanuméricos. Para la referencia de Give-up (NestedPartyRole=24) este campo está limitado a 18 caracteres. Para el mnemotécnico de Give-out (NestedPartyRole=33) este campo está limitado a 10 caracteres. Requerido si se ha especificado NoNestedPartyIDs

525


Char Requerido si se ha especificado NoNestedPartyIDs

538

NestedPartyRole N 3 = Give-out internal reference 14 = Give-Up Clearing Firm 24 = Give-up Reference 33 = Give-up mnemonic

Int Requerido si se ha especificado NoNestedPartyIDs. El valor 3 indica que el contenido de NestedPartyID corresponde a la referencia asignada por el Miembro Origen para uso interno y que se asocia al mnemotécnico de Give-out. Una misma referencia interna puede estar asociada a más de un mnemotécnico. Puede no estar informada. El valor 14 Indica que el contenido de NestedPartyID corresponde al Miembro Destino del Give-up. El valor 24 indica que el contenido de NestedPartyID corresponde a la referencia de Give-up. El valor 33 indica que el contenido de NestedPartyID corresponde al mnemotécnico de Give-out.

End <NestedParties>

Standard Trailer S



9.12.2 Allocation Instruction Ack (Msg Type = P)

Mensaje usado por MEFFGate para indicar el estado de la petición iniciada con un mensaje Allocation Instruction.



Standard Header S MsgType = P

70 AllocID S String(30) Identificador asignado por el cliente en el mensaje Allocation Instruction

75 TradeDate N LocalMkt Date

87 AllocStatus S 0 = Accepted 1 = Rejected 3 = Received not yet processed

Int Estado de la solicitud. El valor 0 indica que el mensaje ha sido aceptado por los sistemas centrales. El valor 1 indica que el traspaso o la asignación ha sido rechazada. El valor 3 indica que el mensaje ha sido recibido por el servidor MEFFGate

88 AllocRejCode N 0 = Unknown account 1 = Incorrect quantity 7 = Other 8 = Incorrect allocated quantity

Int Identifica la razón de rechazo. Sólo está presente cuando AllocStatus = 1 Si contiene el valor 7, el campo Text contiene un texto explicativo del motivo de rechazo

58 Text N String Texto explicativo del motivo de rechazo

Standard Trailer S



9.12.3 Confirmation (Msg Type = AK)

Mensaje usado por MEFFGate para notificar el estado de una asignación de cuenta diaria, traspaso o Give-up. También usado para solicitar la aceptación o rechazo de un Give-up.

En la descripción de los campos de este mensaje se usará el término “traspaso” para referirse tanto a la asignación de cuenta diaria, el Give-up o el traspaso propiamente dicho.


Standard Header S MsgType = AK

664 ConfirmID S String Identificador único para cada mensaje Confirmation

772 ConfirmRefID N String Identificador del mensaje Confirmation que es reemplazado por este mensaje. Presente cuando ConfirmTransType = 1

666 ConfirmTransType S 0 = New 1 = Replace

Int

773 ConfirmType S 1 = Status 2 = Confirmation

Int Indica si el mensaje es una solicitud de aceptación de un Give-up (2=Confirmation) o una notificación del estado de un traspaso (1=Status)

665 ConfirmStatus S 1 = Received Int El contenido de este campo no debe ser tenido en cuenta, está presente por requerimiento del estándar

Start <Parties>

453 NoPartyIDs N NumInGroup

448

PartyID N String Código de miembro, Operador o referencia de Give-up

447

PartyIDSource N D = Proprietary / custom code

String Requerido si se ha especificado NoPartyIDs

452

PartyRole N 1 = Executing Firm 3 = Give-out internal reference 4 = Clearing Firm 12 = Executing Trader 14 = Give-up Clearing Firm 24 = Give-up Reference 33 = Give-up mnemonic 36 = Clearing Broker Trader

Int Requerido si se ha especificado NoPartyIDs. El valor 1 está presente en los mensajes destinados al Miembro Origen y al Miembro Destino de un Give-up informándoles del Miembro Origen. El valor 3, cuando está presente, informa de la referencia interna al Miembro Origen del Give-up. El valor 4 está presente en los mensajes destinados al Miembro Destino cuando el mensaje contiene una cuenta en el campo 79, informándole del Miembro Liquidador de dicha cuenta. Este valor también esta presenta en los mensajes enviados al Miembro Liquidador. El valor 12 está presente en los mensajes destinados a los usuarios del Miembro que realizó la solicitud de traspaso, así como a los usuarios del Miembro Destino del Give-up si es el caso, informándoles del operador que inició la solicitud. El valor 14 está presente en todos los mensajes relacionados con Give-up, informando del Miembro Destino. El valor 24, cuando está presente, informa de la referencia del Give-up. El valor 33, cuando esté presente, informa del mnemotécnico del Give-out al Miembro Origen y del




mnemotécnico del Give-in al Miembro Destino. El valor 36, cuando esté presente, informa del operador del Miembro Destino que realizó la aceptación o rechazo de un Give-up.

End <Parties>

70 AllocID N String(30) Identificador del mensaje Allocation Instruction relacionado. Sólo presente cuando el mensaje va destinado al Miembro del operador que inició la actuación

793 SecondaryAllocID N String(10) Identificador único del traspaso


Hora, en formato UTC, en que se realiza la transacción


Fecha en que se realiza la transacción

Start <Instrument>

55 Symbol S String(22) Código de contrato

End <Instrument>

711 NoUnderlyings S 0 NumInGroup


555 NoLegs S 0 NumInGroup


80 AllocQty S > 0, sin decimales Qty Volumen del traspaso


Char Indica el signo de la operación a traspasar

862 NoCapacities S 0 Int El contenido de este campo no debe ser tenido en cuenta, está presente por requerimiento del estándar

79 AllocAccount S String(5) Cuenta destino. En un Give-up sólo se informa de este campo cuando se recibe el mensaje como destino o liquidador (nunca como origen). En cualquier otro caso contiene “[N/A]”.

6 AvgPx S Price Precio de la operación

381 GrossTradeAmt S Amt Importe Nominal/Efectivo de la transacción

118 NetMoney S 0 Price El contenido de este campo no debe ser tenido en cuenta, está presente por requerimiento del estándar

818* SecondaryTradeReportID

N String Número de registro de liquidación de la nueva operación. Sólo está presente cuando SecondaryConfirmStatus = “A”.

881* SecondaryTradeReportRefID

N String Número de registro de liquidación de la operación a transferir. Sólo está presente cuando el mensaje va destinado a los usuarios del Miembro que solicito el traspaso

5683*

SecondaryConfirmStatus

N “P” = Pendiente “N” = Aceptado por Miembro Destino “”R” = Rechazado por Miembro Destino “A” = Aceptado por Liquidador de Miembro Destino “L” = Rechazado

Char Describe el estado en que se encuentra el traspaso




por Liquidador de Miembro Destino “C” = Cancelado por Miembro Origen “S” = Anulado por el sistema “H” = Petición solicitada no válida “X” = Petición rechazada

Standard Trailer S



9.12.4 Confirmation Ack (Msg Type = AU)

Mensaje usado por el cliente para aceptar o rechazar un Give-up.


Standard Header S MsgType = AU

664 ConfirmID S String(9) Identificador del mensaje Confirmation al que se está respondiendo


MEFFGate no procesa este campo y está presente por requerimientos del estándar

60 TransactTime S UTCTimeStamp

MEFFGate no procesa este campo y está presente por requerimientos del estándar

940 AffirmStatus S 2 = Confirm rejected, i.e. not affirmed 3 = Affirmed

Int

79* AllocAccount N Longitud exacta String(5) Cuenta destino del Give-in. Requerido cuando se trata de un mensaje de aceptación de Give-up por parte del Miembro Destino

793* SecondaryAllocID S String(10) Identificador único del Give-up al que se está refiriendo

Standard Trailer S

9.12.5 Business Message Reject (MsgType = j)

Este mensaje es enviado por MEFFGate para rechazar un mensaje Confirmation Ack inválido. La descripción de este mensaje se encuentra en el apartado 5.8.5.

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 10. Petición de Ejercicio


10. Petición de Ejercicio

10.1 Introducción

La funcionalidad de petición de ejercicio permite que un cliente FIX pueda solicitar el ejercicio a final de día, de un conjunto de opciones asociadas a una cuenta y contrato en concreto.

El cliente debe especificar el código de contrato de la opción a ejercer y la cuenta que tiene la posición. El código de contrato debe referir a un contrato de opción que acepte la petición de ejercicio, en caso contrario la petición será rechazada.

Una petición de ejercicio indica implícitamente que el resto de opciones no deben ser ejercidas.

MEFFGate no implementa un método para indicar el número de opciones que no deben ejercerse (entendiéndose que el resto debe ejercerse). Cuando un cliente desea especificar que no se debe ejercer ninguna opción de una posición (sólo permitido el día de vencimiento), debe enviar una petición de ejercicio con volumen 0.

La solicitud de ejercicio anticipado (antes de la fecha de vencimiento) puede ser revocada, de forma que se vuelve al estado original, es decir, no se ejercería ninguna opción.

Las solicitudes de ejercicio enviadas en la fecha de vencimiento, también pueden ser revocadas, de forma que se producirá el comportamiento por defecto (ejercicio sólo de las opciones in-the-money respecto al precio de cierre del subyacente distribuido en el mensaje Market Data).

Cuando se envía más de una petición de ejercicio para una misma cuenta y contrato, la última solicitud anula cualquier petición previa, quedando como volumen a ejercer el solicitado en esta última petición.

Existen dos escenarios para la petición de ejercicio dependiendo de la fecha de vencimiento, que son descritos en los siguientes apartados.

En ambos escenarios, el ejercicio de opciones se realiza al final de la sesión de negociación. Durante el día, un cliente FIX puede consultar mediante MEFFGate las peticiones de ejercicio pendientes para el final de este día. Esta consulta puede realizarse aplicando diversos criterios de selección tal y como se detalla en la descripción del mensaje correspondiente (Request For Positions).

Las operaciones que se generan por el ejercicio de opciones pueden ser consultadas mediante el mensaje Trade Capture Report Request, tal y como se describe en el capítulo 7 Seguimiento y Gestión de la Posición .

10.2 Escenario 1: Opciones americanas, antes del día de vencimiento

Una petición de ejercicio, en este escenario, pasa a ser efectiva al final de la sesión. Durante la sesión, la petición de ejercicio puede ser reemplazada mediante una nueva petición de ejercicio o cancelada con el correspondiente mensaje.

Si al llegar a final de sesión, la cuenta no dispone del número de contratos que se solicitó ejercer, entonces sólo los contratos disponibles serán ejercidos, quedando anulada el resto de la petición.

10.3 Escenario 2: Día de vencimiento

Este escenario incluye tanto las opciones americanas como las europeas. Durante el día de vencimiento existen tres opciones:

a. Enviar una petición de ejercicio tal y como se explica en el escenario 1. Esta petición puede ser reemplazada o revocada. A final de sesión se ejercerá todo el volumen disponible hasta llegar a la cantidad especificada. La posición restante no será ejercida y expirará. Si se revoca la petición se pasa al comportamiento por defecto como se explica en el punto c



b. Enviar una petición de ejercicio solicitando el ejercicio de 0 contratos. Al final de la sesión, no se ejercerá ninguna opción y todos los contratos expirarán. Esta petición puede ser reemplazada por otra o revocada, pasando al estado a ó c correspondientemente

c. No hacer nada y optar por el comportamiento por defecto. El comportamiento por defecto es ejercer la posición cuando está in-the-money y no ejercer cuando está at-the-money o out-of-the-money. Téngase en cuenta que el comportamiento por defecto sólo puede aplicarse a toda la posición a la vez. Para contratos que no permiten la petición de ejercicio, este es el único sistema posible



Position Maintenance Request (Msg Type = AL) Enviado por el cliente FIX para solicitar el ejercicio de un contrato

Position Maintenance Report (Msg Type = AM) Enviado por MEFFGate para indicar la aceptación o rechazo de una petición de ejercicio

Request For Positions (Msg Type = AN) Usado por el cliente FIX para solicitar sus peticiones de ejercicio

Request For Positions Ack (Msg Type = AO) Enviado por MEFFGate como respuesta al mensaje Request For Positions. Precede a los mensajes Position Report (si hay alguno)

Position Report (Msg Type = AP) Enviado por MEFFGate como respuesta a una petición Request For Positions aceptada. Informa de la petición de ejercicio activa (pero no realizada) para una cuenta y contrato en concreto

Trade Capture Report (Msg Type = AE) Enviado por MEFFGate para notificar que se ha realizado un ejercicio. Sólo enviado a los clientes relacionados suscritos a este tipo de mensaje




Petición de ejercicio anticipado

El cliente envía una petición de ejercicio para una opción americana, antes del día de vencimiento. MEFFGate contesta con un mensaje de aceptación de la solicitud. El siguiente envío de petición de ejercicio sobre la misma cuenta y contrato sustituye la orden previa. A final de día, el volumen indicado en la última petición, o el volumen disponible si es inferior, es ejercido y se recibe el correspondiente Trade Capture Report que así lo notifica, siempre y cuando se esté suscrito a este tipo de mensajes. Si no existe posición en la cuenta no se ejerce ninguna opción y por tanto no se genera ningún mensaje Trade Capture Report asociado.



PosMaintAction [712] = 1 (New)

Account [1] = X

Symbol [55] = Y





Account [1] = X

Symbol [55] = Y


.

.

.



Petición de ejercicio y posterior cancelación

Cualquier petición de ejercicio puede ser cancelada con un mensaje Position Maintenance Request con el campo PosMaintAction = 3. Una vez cancelada se vuelve al comportamiento por defecto, es decir, no ejercer anticipadamente y ejercer el día de vencimiento si la opción está in-the-money.

En el ejemplo que se presenta, las opciones se consideran in-the-money y se trata del día de vencimiento, por lo que se ejercen las opciones.

Petición de ejercicio rechazada por el sistema

Si el cliente FIX envía una petición de ejercicio no válida, por ejemplo sobre una opción europea antes del vencimiento, será rechazada con un mensaje Position Maintenance Report con el campo PosMaintStatus = 2. Una petición de ejercicio rechazada no altera la petición de ejercicio solicitada previamente.




Account [1] = X

Symbol [55] = Y




PosMaintAction [712] = 3 (Cancel)

Account [1] = X

Symbol [55] = Y


.

.

.







Solicitud del estado de las peticiones de ejercicio pendientes

El cliente puede solicitar el estado de la petición de ejercicio sobre un conjunto de cuentas y contratos. Como resultado obtendrá un mensaje Position Report por cada par cuenta-contrato sobre el que exista una petición de ejercicio.

Este sistema implementa el mecanismo de Snapshot y Update, y permite que el cliente, si lo desea, vaya recibiendo las modificaciones a medida que se producen.


No se han realizado acotaciones ni adaptaciones en los mensajes incluidos en este capítulo



Request For Positions Ack (“AO”)

Positions Report (“AP”)

...

PosReqType [724] = 2 (Exercises)




Los mensajes Position Maintenance Request y Position Maintenance Report mencionados en este capítulo también son usados para el ajuste de posición. Su definición se encuentra en los apartados 7.8.5 y 7.8.6 del capítulo 7.

Los mensajes Request For Positions, Request For Positions Ack, Position Report y Trade Capture Report mencionados en este capítulo también son usados para el seguimiento de la posición. Su definición se encuentra en los apartados 7.8.1, 7.8.2, 7.8.3 and 7.8.4.

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 11. Comunicación de Eventos


11. Comunicación de Eventos

11.1 Introducción

En este capítulo se describen dos funcionalidades basadas en el mensaje News:

Difusión de información del supervisor de la cámara

Envío de mensajes desde una aplicación cliente al supervisor de la cámara

La información transferida en ambos casos es un texto de formato libre.

Un programa cliente no tiene que suscribirse para recibir estos mensajes. Todo cliente queda implícitamente suscrito desde el inicio de sesión.

No existe ningún mecanismo para verificar si un mensaje ha sido entregado a sus destinatarios.

Al establecer una conexión de comunicación, si el cliente continúa la sesión FIX recibe todos los mensajes News que tenía pendientes desde el momento de la desconexión. Cuando el cliente opta por iniciar una nueva sesión FIX, recibe todos los mensajes News, destinados a él, que se han generado desde el inicio de sesión.



News (Msg Type = B) Usado para recibir mensajes de texto del supervisor de la cámara.

También usado para enviar mensajes de texto al supervisor de la cámara


Recepción de mensaje

Envío de mensaje


News (“B”)


News (“B”)




Sólo se permiten una línea de hasta 78 caracteres por mensaje




11.5.1 News (Msg Type = B)


Standard Header S MsgType = B

61 Urgency N 0 = Normal 1 = Flash 2 = Background

Char El valor por defecto es 0

148 Headline S String Encabezado del mensaje. Ignorado por MEFFGate

33 LinesOfText S 1 NumInGroup Número de líneas del texto. Sólo se permite una línea

58 Text S String(78) Una línea de texto

Standard Trailer S

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 12. Gestión de Referencias y Filtros de Give-up


12. Gestión de Referencias y Filtros de Give-up

12.1 Introducción

La funcionalidad de gestión de Referencias y Filtros de Give-up agrupa varias funciones. Desde el punto de vista del cliente FIX, éstas son las siguientes:

Mantenimiento de referencias de Give-out por Miembro Origen

Mantenimiento de referencias de Give-in por Miembro Destino

Mantenimiento de filtros de Give-in por Miembro Destino

Mantenimiento de filtros de Give-in por Miembro Liquidador

Mantenimiento de peticiones automáticas de Give-out

Consulta de referencias y filtros de Give-up

Cada una de estas funciones se trata en un apartado separado dentro de este capítulo. Para cada función se describe el método de uso, la lista de mensajes relacionados, los flujos de mensajes, las adiciones o acotaciones aplicadas en esta implementación y la descripción detallada de los mensajes.

12.2 Campo RegistID

El campo RegistID, presente en una solicitud iniciada con un mensaje Registration Instructions, es el identificador que permite relacionar la petición con los mensajes Registration Instructions Response de respuesta.

El campo RegistID asignado por el cliente debe ser de diez caracteres de longitud. Si la longitud fuese inferior, MEFFGate completa con espacios por detrás hasta llegar a dicha longitud. MEFFGate también acepta que los mensajes enviados por el cliente usen un RegistID de longitud 30, en este caso sólo las 10 últimas posiciones pueden ser fijadas libremente, ya que las 20 primeras deben coincidir con el formato que se presenta a continuación.



- Prefijado del identificador RegistID -

MEFFGate realiza un proceso de prefijado del campo RegistID para evitar duplicados en este identificador.

El RegistID asignado por MEFFGate en el mensaje de respuesta tiene el formato AAMMDDMmmmTttMmmmTttNnnnnnnnnn, formado con la siguiente codificación:

AAMMDD. Es la fecha de la sesión de cámara

MmmmTtt. Contiene el código de miembro y operador de conexión desde el que se realizó la solicitud

Nnnnnnnnnn. Es el valor asignado por la aplicación cliente a RegistID en el mensaje original

Un operador que quiera modificar o cancelar una referencia o un filtro de Give-up, debe usar este identificador en el campo RegistRefID del mensaje Registration Instructions de solicitud.

10

20 10

RegistID =

RegistID = Registration Instructions

Registration Instructions Response

RegistID = Registration Instructions Response

...

Envío de mensaje sin especificar el prefijo

20 10

RegistID =

Registration Instructions

Registration Instructions Response

RegistID = Registration Instructions Response

...

Envío de mensaje especificando el prefijo

20 10

RegistID =

MEFFGate Cliente

MEFFGate Cliente



12.3 Mantenimiento de referencias de Give-out por Miembro Origen

12.3.1 Descripción

El cliente FIX usa esta funcionalidad para realizar el mantenimiento de las referencias que el Miembro Origen utiliza en la solicitud de Give-outs.

Estas referencias son comunes para todos los operadores del Miembro y pueden ser modificadas en tiempo real.

En la solicitud de Give-out, el Miembro Ejecutor debe indicar una referencia que sirva al Miembro Destino para identificar únicamente (junto con el código de Miembro Ejecutor) el origen del Give-in. Es la “Referencia Give-up”.

Los Miembros Ejecutor y Destino deben ponerse de acuerdo para establecer esta referencia común a ambos.

Por otro lado, a fin de facilitar el envío del Give-out y la gestión interna, se puede crear una referencia mnemotécnica y una referencia interna, que son códigos que define el Miembro Ejecutor y que no requieren de acuerdo con el Miembro Destino.



Registration Instructions (Msg Type = o) Usado por el cliente para solicitar el mantenimiento de referencias de Give-out por Miembro Origen

Registration Instructions Response (Msg Type = p)

Enviado por MEFF para confirmar o rechazar el mantenimiento de referencias de Give-out por Miembro Origen


Solicitud correcta

Solicitud errónea

Executing Broker

Registration Instructions (“o”)

Registration Instructions Response (“p”)

RegistStatus[506] = A (Accepted)

MEFFGate Server

Executing Broker



RegistStatus[506] = R (Rejected)

MEFFGate Server




En el mensaje Registration Instructions, los campos NoPartyIDs (453) y NoPartySubIDs (802) han pasado a ser requeridos

Se ha añadido el campo Text (58) al mensaje Registration Instructions Response



12.3.5 Definición de mensajes

12.3.5.1 Registration Instructions (Msg Type = o)

Mensaje enviado por el cliente para gestionar las referencias de Give-out.


Standard Header S MsgType = o

513 RegistID S String (30) Identificador único para cada mensaje Registration Instructions

514 RegistTransType S 0 = New 1 = Replace 2 = Cancel

Char

508 RegistRefID N String (30) Identificador del mensaje Registration Instructions que es reemplazado o cancelado por este mensaje. Requerido cuando RegistTransType = 1 ó 2

Start <Parties>

453 NoPartyIDs S* NumInGroup

448

PartyID S String Código de miembro o referencia. Para la referencia interna de Give-out (PartyRole=3) este campo está limitado a 18 caracteres alfanuméricos. Para el Miembro Destino del Give-up (PartyRole = 14) este campo tiene una longitud exacta de 4 caracteres alfanuméricos. Para la referencia de Give-up (PartyRole = 24) este campo está limitado a 18 caracteres alfanuméricos. Para la referencia mnemotécnica de Give-out (PartyRole = 33) este campo está limitado a 10 caracteres alfanuméricos.

447


String

452

PartyRole S 3 = Give-out Internal Reference 14 = Give-up Clearing Firm 24 = Give-up Reference 33 = Give-up Mnemonic

Int El valor 3 es para la referencia interna de Give-out asignada por el Miembro Origen. El valor 14 es para el Miembro Destino del Give-up. El valor 24 es para la referencia de Give-up. El valor 33 es para la referencia mnemotécnica de Give-out.

802

NoPartySubIDs S* 1 NumInGroup

523

PartySubID S GOR = Give-out references

String

803

PartySubIDType S Int Este campo es requerido por el estándar. MEFFGate acepta que este campo no esté presente

End <Parties>

Standard Trailer S



12.3.5.2 Registration Instructions Response (Msg Type = p)

Mensaje usado por MEFFGate para indicar el estado de la petición iniciada con un mensaje Registration Instructions.



Standard Header S MsgType = p

513 RegistID S String (30) Identificador asignado por el cliente en el mensaje Registration Instructions


Char

508 RegistRefID N String (30) Identificador del mensaje Registration Instructions que es reemplazado o cancelado por este mensaje. Presente cuando RegistTransType = 1 ó 2

Start <Parties>


448

PartyID N String Código de miembro o de referencia

447 PartyIDSource N D = Proprietary / Custom code

String

452 PartyRole N 3 = Give-out Internal Reference 14 = Give-up Clearing Firm 24 = Give-up Reference 33 = Give-up Mnemonic

Int El valor 3 es para la referencia interna de Give-out asignada por el Miembro Origen. El valor 14 es para el Miembro Destino del Give-up. El valor 24 es para la referencia de Give-up. El valor 33 es para la referencia mnemotécnica de Give-out.

802

NoPartySubIDs N 1 NumInGroup

523

PartySubID S GOR = Give-out references

String

803

PartySubIDType S Int El contenido de este campo no debe ser tenido en cuenta, está presente por requerimiento del estándar

End <Parties>

506 RegistStatus S A = Accepted R = Rejected

Char Estado de la petición del mensaje Registration Instructions. En caso de rechazo (valor “R”), el campo Text contiene un texto explicativo

58* Text N String Cuando RegistStatus = “R”, contiene una descripción específica del motivo de rechazo

Standard Trailer S



12.4 Mantenimiento de referencias de Give-in por Miembro Destino

12.4.1 Descripción

El cliente FIX usa esta funcionalidad para realizar el mantenimiento de las referencias que el Miembro Destino utiliza en la aceptación de Give-ins.

Estas referencias son comunes para todos los operadores del Miembro y pueden ser modificadas en tiempo real.

En la solicitud de Give-out, el Miembro Ejecutor debe indicar una referencia que sirva al Miembro Destino para identificar únicamente (junto con el código de Miembro Ejecutor) el origen del Give-in. Es la “Referencia Give-up”.

Los Miembros Ejecutor y Destino deben ponerse de acuerdo para establecer esta referencia común a ambos.

Por otro lado, a fin de facilitar la aceptación del Give-in, se puede crear una referencia mnemotécnica que es un código que define el Miembro Destino y que no requiere de acuerdo con el Miembro Origen.



Registration Instructions (Msg Type = o)

Usado por el cliente para solicitar el mantenimiento de referencias de Give-in por Miembro Destino


Enviado por MEFF para confirmar o rechazar el mantenimiento de referencias de Give-in por Miembro Destino


Solicitud correcta

Solicitud errónea

Clearing Broker




MEFFGate Server

Clearing Broker




MEFFGate Server




En el mensaje Registration Instructions, los campos NoPartyIDs (453), NoPartySubIDs (802) y Account (1) han pasado a ser requeridos






Mensaje enviado por el cliente para gestionar las referencias de Give-in.





Char


Start <Parties>

453 NoPartyIDs S* 3 NumInGroup

448

PartyID S String Código de miembro o de referencia. Para el Miembro Origen del Give-up (PartyRole = 1) este campo tiene una longitud exacta de 4 caracteres alfanuméricos. Para la referencia de Give-up (PartyRole = 24) este campo está limitado a 18 caracteres alfanuméricos. Para la referencia mnemotécnica de Give-in (PartyRole = 33) este campo está limitado a 10 caracteres alfanuméricos.

447


String

452

PartyRole S 1 = Executing Firm 24 = Give-up Reference 33 = Give-up Mnemonic

Int El valor 1 es para el Miembro Origen del Give-up. El valor 24 es para la referencia de Give-up. El valor 33 es para la referencia mnemotécnica de Give-in.

802


523

PartySubID S GIR = Give-in references

String

803


End <Parties>

1 Account S* String (5) Cuenta destino en la que debe registrarse el Give-in en caso de ser aceptado

Standard Trailer S










Char


Start <Parties>


448

PartyID N String Código de miembro o de referencia

447 PartyIDSource N D = Proprietary / Custom code

String

452 PartyRole N 1 = Executing Firm 24 = Give-up Reference 33 = Give-up Mnemonic

Int El valor 1 es para el Miembro Origen del Give-up. El valor 24 es para la referencia de Give-up. El valor 33 es para la referencia mnemotécnica de Give-in.

802


523

PartySubID S GIR = Give-in references

String

803


End <Parties>

1 Account N String Cuenta destino en la que debe registrarse el Give-in en caso de ser aceptado




Standard Trailer S



12.5 Mantenimiento de filtros de Give-in por Miembro Destino

12.5.1 Descripción

El cliente FIX usa esta funcionalidad para que el Miembro Destino del Give-in pueda configurar filtros que permitan la aceptación automática de las peticiones de Give-in.

La aceptación de Give-ins puede automatizarse mediante unos filtros definidos por los Miembros Destino y/o Liquidador, quedando pendiente de aceptación o rechazo manual todo aquello que no supere dichos filtros.



Registration Instructions (Msg Type = o) Usado por el cliente para solicitar el mantenimiento de filtros de Give-in por Miembro Destino


Enviado por MEFF para confirmar o rechazar el mantenimiento de filtros de Give-in por Miembro Destino


Solicitud correcta

Solicitud errónea

Clearing Broker




MEFFGate Server

Clearing Broker




MEFFGate Server





Mensaje enviado por el cliente para gestionar los filtros de Give-in por Miembro Destino.





Char


Start <Parties>


448

PartyID S String Código de miembro o de referencia. Para el Miembro Origen del Give-up (PartyRole = 1) este campo tiene una longitud exacta de 4 caracteres alfanuméricos. Para la referencia de Give-up (PartyRole = 24) este campo está limitado a 18 caracteres alfanuméricos.

447


String

452

PartyRole S 1 = Executing Firm 24 = Give-up Reference

Int El valor 1 es para el Miembro Origen del Give-up. El valor 24 es para la referencia de Give-up. El uso del carácter comodín “?” está permitido sólo si se utiliza en todas las posiciones tanto en el Miembro Origen del Give-up como en la referencia de Give-up (pero no en ambos campos a la vez)

802


523

PartySubID S GIF = Give-in filters

String

803


End <Parties>

Start <Stipulations>

232* NoStipulations S 2 NumInGroup

233*

StipulationType S TAL = Transaction Amount Limit SAL = Session Amount Limit

String

234*

StipulationValue S [N/A] o un valor numérico >=0 and <= 999999999

String Si StipulationType = TAL, es el importe máximo para un Give-in que será aceptado automáticamente para ese Miembro Origen del Give-up y referencia de Give-up. Si StipulationType = SAL, es el importe acumulado máximo por sesión




de Give-ins que serán aceptados automáticamente para ese Miembro Origen del Give-up y referencia de Give-up. Se informará a [N/A] cuando se desee que el filtro sea totalmente abierto, esto es, no haya un importe máximo específico a comprobar

End <Stipulations>

Standard Trailer S










Char


Start <Parties>


448

PartyID N String Código de miembro o de referencia. El valor comodín “?” significa “todo”.

447

PartyIDSource N D = Proprietary / Custom code

String

452

PartyRole N 1 = Executing Firm 24 = Give-up Reference

Int El valor 1 es para el Miembro Origen del Give-up. El valor 24 es para la referencia de Give-up.

802

NoPartySubIDs N NumInGroup

523

PartySubID S GIF = Give-in filters

String

803


End <Parties>


232* NoStipulations N NumInGroup

233*

StipulationType N TAL = Transaction Amount Limit SAL = Session Amount Limit

String

234*

StipulationValue N String Si StipulationType = TAL, es el importe máximo para un Give-in que será aceptado automáticamente para ese Miembro Origen del Give-up y referencia de Give-up. Si StipulationType = SAL, es el importe acumulado máximo por sesión de Give-ins que serán aceptados automáticamente para ese Miembro Origen del Give-up y referencia de Give-up. El valor [N/A] indica que el filtro es totalmente abierto, esto es, no hay un importe máximo específico a comprobar

End <Stipulations>


Char Estado de la petición del mensaje Registration Instructions. En caso de rechazo (valor “R”), el




campo Text contiene un texto explicativo


Standard Trailer S



12.6 Mantenimiento de filtros de Give-in por Miembro Liquidador

12.6.1 Descripción

El cliente FIX usa esta funcionalidad para que el Miembro Liquidador del Give-in pueda configurar filtros que permitan la aceptación automática de las peticiones de Give-in

La aceptación de Give-in puede automatizarse mediante unos filtros definidos por los Miembros Destino y/o Liquidador, quedando pendiente de aceptación o rechazo manual todo aquello que no supere dichos filtros.



Registration Instructions (Msg Type = o) Usado por el cliente para solicitar el mantenimiento de filtros de Give-in por Miembro Liquidador


Enviado por MEFF para confirmar o rechazar el mantenimiento de filtros de Give-in por Miembro Liquidador


Solicitud correcta

Solicitud errónea

Clearing Member




MEFFGate Server

Clearing Member




MEFFGate Server






Se ha añadido el bloque Stipulations al mensaje Registration Instructions Response





Mensaje enviado por el cliente para gestionar los filtros de Give-in por Miembro Liquidador.





Char


Start <Parties>


448

PartyID S String (4) Código de Miembro Destino del Give-up

447


String

452

PartyRole S 14 = Give-up Clearing Firm

Int

802


523

PartySubID S GIFCM = Give-in filters of clearing member

String

803


End <Parties>

1 Account S* String (5) Cuenta destino del Give-in. El uso del carácter comodín “?” está permitido sólo si se utiliza en todas las cinco posiciones a la vez.


232* NoStipulations S 2 NumInGroup

233*

StipulationType S TAL = Transaction Amount Limit SAL = Session Amount Limit

String

234*

StipulationValue S [N/A] o un valor numérico >=0 and <= 999999999

String Si StipulationType = TAL, es el importe máximo para un Give-in que será aceptado automáticamente para ese Miembro Destino del Give-up y cuenta. Si StipulationType = SAL, es el importe acumulado máximo por sesión de Give-ins que serán aceptados automáticamente para ese Miembro Destino del Give-up y cuenta. Se informará a [N/A] cuando se desee que el filtro sea totalmente abierto, esto es, no haya un importe máximo específico a comprobar

End <Stipulations>

Standard Trailer S










Char


Start <Parties>


448

PartyID N String Código de Miembro Destino del Give-up

447


String

452

PartyRole N 14 = Give-up Clearing Firm

Int

802


523

PartySubID S GIFCM = Give-in filters of clearing member

String

803


End <Parties>

1 Account N String Cuenta destino del Give-in. El valor comodín “?” significa “para todas las cuentas”.


232* NoStipulations N NumInGroup

233*

StipulationType N TAL = Transaction Amount Limit SAL = Session Amount Limit

String

234*

StipulationValue N String Si StipulationType = TAL, es el importe máximo para un Give-in que será aceptado automáticamente para ese Miembro Destino del Give-up y cuenta. Si StipulationType = SAL, es el importe acumulado máximo por sesión de Give-ins que serán aceptados automáticamente para ese Miembro Destino del Give-up y cuenta. El valor [N/A] indica que el filtro es totalmente abierto, esto es, no hay un importe máximo específico a comprobar

End <Stipulations>


Char Estado de la petición del mensaje Registration Instructions. En caso de rechazo (valor “R”), el




campo Text contiene un texto explicativo


Standard Trailer S



12.7 Mantenimiento de peticiones automáticas de Give-out

12.7.1 Descripción

El cliente FIX usa esta funcionalidad para configurar la solicitud automática de Give-outs para las operaciones procedentes del sistema de negociación (case de órdenes y aplicaciones) en base a la cuenta en la que se ha operado.



Registration Instructions (Msg Type = o) Usado por el cliente para solicitar el mantenimiento de peticiones automáticas de Give-out


Enviado por MEFF para confirmar o rechazar el mantenimiento de peticiones automáticas de Give-out


Solicitud correcta

Solicitud errónea

Executing Broker




MEFFGate Server

Executing Broker




MEFFGate Server





Mensaje enviado por el cliente para gestionar las peticiones automáticas de Give-out.





Char


Start <Parties>


448

PartyID S String(10) Código de referencia mnemotécnica de Give-out

447


String

452

PartyRole S 33 = Give-up Mnemonic

Int

802


523

PartySubID S AGR = Automatic Give-out request

String

803


End <Parties>

1 Account S* String (5) Cuenta origen del Give-out

Standard Trailer S










Char


Start <Parties>


448

PartyID N String Código de referencia mnemotécnica de Give-out

447


String

452

PartyRole N 33 = Give-up Mnemonic

Int

802


523

PartySubID S AGR = Automatic Give-out request

String

803


End <Parties>

1 Account N String Cuenta origen del Give-out




Standard Trailer S



12.8 Consulta de referencias y filtros de Give-up

12.8.1 Descripción

La aplicación cliente puede solicitar la consulta de referencias y filtros de Give-up mediante el mensaje Registration Instructions.

Como respuesta a esta petición se recibe un mensaje Registration Instructions Response por cada referencia y filtro disponibles en este momento en el sistema.



Registration Instructions (Msg Type = o) Usado por el cliente para solicitar la consulta de referencias y filtros de Give-up


Enviado por MEFF para confirmar o rechazar la consulta de referencias y filtros de Give-up


Solicitud correcta

Solicitud errónea

MEFFGate Client


SubscriptionRequestType = 0 (Snaphot)



MEFFGate Server

… One mensaje per every reference

and/or Give-up filter

MEFFGate Client




MEFFGate Server

SubscriptionRequestType = 0 (Snaphot)




Se ha añadido el campo SubscriptionRequestType (263) al mensaje Registration Instructions

Se han añadido los campos LastRptRequested (912) y Text (58) al mensaje Registration Instructions Response





Mensaje enviado por el cliente para consultar las referencias y filtros de Give-up.




514 RegistTransType S Char MEFFGate no tiene en cuenta el valor de este campo cuando viene informado el tag SubscriptionRequestType[263]

263* SubscriptionRequestType

N 0 = Snasphot Char Si se informa este campo, MEFFGate interpreta que se desea una consulta de todas las referencias y filtros de Give-up existentes y no va a tener en cuenta el resto de campos de este mensaje

Standard Trailer S








513 RegistID S String Identificador asignado por el cliente en el mensaje Registration Instructions

514 RegistTransType S 0 = New Char

912* LastRptRequested N Y = Last message N = Not last message

Boolean

… <Parties> Account <Stipulations> …

Información específica según el tipo de registro




Standard Trailer S

MEFFGate Liquidación - Especificaciones de la Interfaz FIX 13. Entregas de Futuros sobre Bono


13. Entregas de Futuros sobre Bono

13.1 Introducción

La funcionalidad de entregas permite que un cliente FIX pueda:

a) Conocer los entregables publicados, mediante el mensaje Security List en el bloque InstrumentLeg

b) Comunicar, dentro del periodo de notificación de entregas, qué referencias, dentro de los valores entregables, va a entregar por cada posición vendida. Esta comunicación se realiza mediante mensajes Position Maintenance Request

c) Saber las operaciones de compra-venta a realizar en IBERCLEAR. Estas operaciones se comunican mediante mensajes Trade Capture Report realizados a través de una suscripción especial utilizando un mensaje Trade Capture Report Request con la opción TrdType [828] = 15.

A continuación se describe con más detalle cada una de estas fases.

13.2 Lista de entregables

La relación de valores entregables y factores de conversión para los contratos de derivados se divulgan en el bloque InstrumentLeg del mensaje Security List. La información más relevante sería:

Contrato de derivados sobre el que se hace la entrega: Symbol [55]

Código del valor entregable: LegSymbol [600]

Código ISIN del entregable: LegSecurityAltID [605]

Factor de conversión: LegFactor [253]

Cupón Corrido: AccruedInterestAmt [159]

13.3 Notificación de entregas

La entrega se inicia por parte de los Miembros con posiciones vendidas, para los que MEFF habilita el periodo de notificación de entregas, en el que cada Miembro comunica a MEFF qué referencias, dentro de los valores entregables (ver 13.2 - Lista de entregables), va a entregar por cada posición vendida. Finalizado este periodo, si quedan posiciones vendidas para las que no se ha notificado la referencia a entregar, el Miembro Liquidador deberá realizar la notificación a MEFF. Por último, si quedaran posiciones para las que no se indicara qué referencia se va a entregar, MEFF asignaría la referencia, preferentemente el entregable más barato.

Esta comuniciación se realiza mediante el mensaje Position Maintenance Request. La información más relevante sería:

PosTransType [709] = 4 (Delivery)

Symbol [55] = Contrato de derivados sobre el que se hace la entrega

Account [1] = Titular sobre el que se hace la entrega

PosType [703] = DN (Delivery Notice Qty)

ShortQty [705]: Número de contratos a entregar

NestedPartyRole [538] = 13 (si la comunicación la realiza el Miembro Negociador) ó 4 (si la comunicación la realiza el Miembro Liquidador)

LegSymbol [600]: Referencia que se entrega

http://fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/tag159.html



Debe tenerse en cuenta que cada vez que se envía una modificación a un Position Maintenance Request enviado anteriormente, el último reemplaza totalmente al antiguo. O sea, cada vez hay que mandar toda la información de notificación de entregas.

Para más información ver el flujo de mensajes “13.3 – Notificación de entrega”.

13.4 Operaciones de compra-venta a realizar

Las operaciones de compra-venta a realizar en IBERCLEAR están disponibles mediante mensajes Trade Capture Report realizados a través de una suscripción especial utilizando un mensaje Trade Capture Report Request con la opción TrdType [828] = 15. Existen dos niveles de información:

Operaciones de contado a nivel de titular. El campo Account [1] tiene 3 posiciones (el titular de la operación)

Operaciones de contado a nivel de miembro. El campo Account [1] no viene informado



Security List (Msg Type = y) Enviado por MEFFGate para informar de la relación de valores entregables y factores de conversión

Position Maintenance Request (Msg Type = AL) Enviado por el cliente FIX para comunicar, dentro del periodo de notificación de entregas, qué referencias, dentro de los valores entregables, va a entregar por cada posición vendida

Position Maintenance Report (Msg Type = AM) Enviado por MEFFGate para indicar la aceptación o rechazo de una notificación de entregas

Trade Capture Report Request (Msg Type = AD) Solicitud especial de operaciones de entrega con la opción especial TrdType [828] = 15

Trade Capture Report Request Ack (Msg Type = AQ) Acuse del mensaje Trade Capture Report Request

Trade Capture Report (Msg Type = AE) Enviado por MEFFGate para saber las operaciones de compra-venta a realizar como resultado del proceso de entrega. Sólo enviado a los clientes relacionados suscritos a este tipo de mensaje con la opción especial TrdType [828] = 15




Solicitud de la lista de entregables

Notificación de entrega

Inicialmente, MEFFGate envía un mensaje Position Maintenance Report de forma no solicitada con PosTransType [709] = 4 (Delivery), PosMaintAction [712] = 1 (New), PosReqID [710] informado, PosType [703] = DLV (Total Delivery Qty) y ShortQty [705] informado con el número total de contratos a entregar.

A continuación, el cliente envía una petición de notificación de entrega usando el mensaje Position Maintenance Request con PosTransType [709] = 4 (Delivery), PosMaintAction [712] = 2 (Replace), PosType [703] = DN (Delivery Notice Qty) y ShortQty [705] informado con el número de contratos que se entregan.

MEFFGate contesta con un mensaje de aceptación de la solicitud. El siguiente envío de notificación de entrega sustituye completamente la orden previa.




Symbol [55] = ABC, …, NoLegs [555] = 2, LegSymbol1 [600] = A1,LegFactor1[253] = 0.96680,…, LegSymbol2 [600] = A2,LegFactor2[253] = 0.989058,…,



MEFFGate Client

MEFFGate Server


PosTransType [709] = 4 (Delivery), PosMaintAction [712] = 2 (Replace), PosReqID [710] = X2, OrigPosReqRefID [713] = X1, Symbol [55] = FB10U3, Account [1] = 00P

NoPositions [702] = 3 PosType [703] = DN (Delivery Notice Qty), ShortQty [705] = 80, LegSymbol [600] = 5,50/10 NestedPartyRole = 13, NestedPartyID = NNNN PosType [703] = DN (Delivery Notice Qty),ShortQty [705] = 75, LegSymbol [600] = 5,85/11 NestedPartyRole = 13, NestedPartyID = NNNN PosType [703] = DLV (Total Delivery Qty), ShortQty [705] = 175, NestedPartyRole = 13, NestedPartyID = NNNN


PosTransType [709] = 4 (Delivery), PosMaintAction [712] = 2 (Replace), PosReqID [710] = X2, OrigPosReqRefID [713] = X1, Symbol [55] = FB10U3, Account [1] = 00P NoPositions [702] = 3 PosType [703] = DLV (Total Delivery Qty), ShortQty [705] = 175, NestedPartyRole = 13, NestedPartyID = NNNN PosType [703] = DN (Delivery Notice Qty), ShortQty [705] = 80, LegSymbol [600] = 5,50/10 NestedPartyRole = 13, NestedPartyID = NNNN PosType [703] = DN (Delivery Notice Qty), ShortQty [705] = 75, LegSymbol [600] = 5,85/11 NestedPartyRole = 13, NestedPartyID = NNNN


PosTransType [709] = 4 (Delivery), PosMaintAction [712] = 1 (New), PosReqID [710] = X1, Symbol [55] = FB10U3, Account [1] = 00P

NoPositions [702] = 1, PosType [703] = DLV (Total Delivery Qty), ShortQty [705] = 175, NestedPartyRole = 13, NestedPartyID = NNNN

Clearing Member LLLL Trading

Member NNNN


PosTransType [709] = 4 (Delivery), PosMaintAction [712] = 2 (Replace),, PosReqID [710] = Y1, OrigPosReqRefID [713] = X2, Symbol [55] = FB10U3, Account [1] = 00P NoPositions [702] = 4 PosType [703] = DN (Delivery Notice Qty), ShortQty [705] = 20, LegSymbol [600] = 5,50/10 NestedPartyRole = 4, NestedPartyID = LLLL PosType [703] = DN (Delivery Notice Qty), ShortQty [705] = 80, LegSymbol [600] = 5,50/10 NestedPartyRole = 13, NestedPartyID = NNNN PosType [703] = DN (Delivery Notice Qty),ShortQty [705] = 75, LegSymbol [600] = 5,85/11 NestedPartyRole = 13, NestedPartyID = NNNN PosType [703] = DLV (Total Delivery Qty), ShortQty [705] = 175, NestedPartyRole = 13, NestedPartyID = NNNN


PosTransType [709] = 4 (Delivery), PosMaintAction [712] = 2 (Replace),, PosReqID [710] = Y1, OrigPosReqRefID [713] = X2, Symbol [55] = FB10U3, Account [1] = 00P NoPositions [702] = 4 PosType [703] = DN (Delivery Notice Qty), ShortQty [705] = 20, LegSymbol [600] = 5,50/10 NestedPartyRole = 4, NestedPartyID = LLLL PosType [703] = DN (Delivery Notice Qty), ShortQty [705] = 80, LegSymbol [600] = 5,50/10 NestedPartyRole = 13, NestedPartyID = NNNN PosType [703] = DN (Delivery Notice Qty),ShortQty [705] = 75, LegSymbol [600] = 5,85/11 NestedPartyRole = 13, NestedPartyID = NNNN PosType [703] = DLV (Total Delivery Qty), ShortQty [705] = 175, NestedPartyRole = 13, NestedPartyID = NNNN



Notificación de entrega rechazada por el sistema

Si el cliente FIX envía una notificación de entrega no válida, será rechazada con un mensaje Position Maintenance Report con el campo PosMaintStatus = 2. Una notificación de entrega rechazada no altera la Notificación de entregas solicitada previamente.

Operaciones de entrega

Las operaciones de compra-venta de entrega se reciben mediante mensajes Trade Capture Report realizados a través de una suscripción especial utilizando un mensaje Trade Capture Report Request con la opción TrdType [828] = 15. Existen dos niveles de información:

Operaciones de entrega a nivel de titular. El campo Account [1] tiene una longitud de 3 caracteres (Titular asociado con la operación)

Operaciones de entrega a nivel de titular. El campo Account [1] no se informa


Se ha añadido el campo LegSymbol [600] a los mensajes Position Report, Position Maintenance Request y Position Maintenance Report






...



TradeRequestID [568] = AA, TrdType [828] not informed or different than “15” (usual trades, see section “Trades Report” for more details)


...

TradeRequestID [568] = AA, Account [1] = 00P01, … (

TradeRequestID [568] = DD, Account [1] = 00P, … (Delivery spot trades broken down by holder)


TradeRequestID [568] = DD, TrdType [828] = “15” (Delivery trades)

...

TradeRequestID [568] = DD, Account [1] NOT informed, … (Delivery spot trades broken down by member)




El mensaje Security List mencionado en este capítulo también es usado en la información estática de contratos. Su definición se encuentra en el apartado 6.4.2 del capítulo 6.

Los mensajes Position Maintenance Request. Position Maintenance Report y Trade Capture Report mencionados en este capítulo también son usados para el seguimiento y gestión de posición. Su definición se encuentra en los apartados 7.8.5, 7.8.6 y 7.8.4 del capítulo 7.

Los mensajes Trade Capture Report y Request Trade Capture Report Request Ack mencionados en este capítulo también son usados para la consulta de posiciones. Su definición se encuentra en los apartados 8.6.1 and 8.6.2 del capítulo 8.

MEFFGate Liquidación - Especificaciones de la Interfaz FIX

¡Error! Utilice la pestaña Inicio para aplicar Título 1;Apéndice al texto que desea que aparezca aquí.. ¡Error! Utilice la pestaña Inicio para aplicar Título 1;Apéndice al

texto que desea que aparezca aquí.

9 de diciembre de 2013 © BME 2013 A-1

Apéndice A Campos de Usuario

En la siguiente tabla se presentan los campos de usuario usados en los mensajes de este manual

Tag Nombre Formato Descripción

5680 ProprietaryFixProtocolVersion

String Identificación exacta de la versión del protocolo usado y esperado por el iniciador.

5679 FixEngineName String Contiene una cadena descriptiva del software usado por el cliente para a conexión FIX. Sólo usado a modo informativo

5681 ExchangeTradeType String Tipo de operación del mercado (véase Tabla 19 en documento “Tablas de Codificación”)

5682 NewSecuritySubscription Char Campo para solicitar la suscripción a la definición de nuevos contratos

5683 SecondaryConfirmStatus Char Describe el estado en que se encuentra el Give-up de referencia

MEFFGate Liquidación

Documents

Transcript of MEFFGate Liquidación