HF MEFFGate GUÍA DE PRUEBAS DE CONFORMIDAD

Transcripción

1 HF MEFFGate GUÍA DE PRUEBAS DE CONFORMIDAD PARA APLICACIONES DE TRADING Fecha: 9 de Octubre 2012 Versión: 1.1

2 La información contenida en este documento puede ser modificada en cualquier momento sin previo aviso. A menos que se indique lo contrario, las empresas, nombres y datos de los ejemplos son ficticios. Ninguna parte de este documento puede ser reproducida, almacenada en un sistema de distribución o transmitida de ninguna manera y por ningún medio (electrónico, mecánico, fotocopiado, grabado o cualquier otro) sin previo permiso por escrito MERCADO ESPAÑOL DE FUTUROS FINANCIEROS SERVICES, S.A. Todos los derechos reservados.

3 Historia de versiones Versión Fecha Descripción Autor Oct 2012 Primera Edición Garry O Reilly Oct 2012 Errata Corregida Garry O Reilly i

4 Tabla de contenido 1. Introducción Entorno de Simulación Infraestructura Disponibilidad del entorno de simulación Códigos de miembros y operadores Operadores privilegiados Terminales MEFFStation Contratos Preguntas sobre pruebas Contactos Detalles que deben ser tenidos en cuenta al conectar con el HF MEFFGate Tratamiento del heartbeat Pérdida de conexión con los Sistemas centrales Pérdida de conexión con el HF MEFFGate Cancelación automática de órdenes Suscripciones a FIX Recepción de la actividad efectuada por terminales de Supervisión Bloques de pruebas Casos de prueba HC Comunicaciones HI Definición de instrumentos HO Gestión de órdenes HQ Gestión de quotes HB Gestión de Bloques HP y HF Protección del Mercado y Filtros ii

5 1. Introducción Este documento está dirigido a Miembros e ISV. Explica las pruebas que deben efectuarse para asegurar que sus Aplicaciones de Trading o Market Data funcionan correctamente conectadas al HF MEFFGate del SMART versión Este documento explica varios conjuntos de pruebas que deben efectuarse dependiendo del uso que el Miembro o ISV hagan de las funcionalidades ofrecidas por el sistema. Algunas pruebas están señaladas como obligatorias porque se consideran necesarias para garantizar el funcionamiento correcto del sistema. Las aplicaciones que no hayan realizado las pruebas de homologación para el SMART versión 9.50 no les será permitido conectar al HF MEFFGate en producción. N.B. Las Aplicaciones que conectan al actual MEFFGate no están obligadas a realizar las pruebas de conformidad y se les permitirá conectar al MEFFGate hasta que los MEFFGates sean descontinuados. 1

6 2. Entorno de Simulación 2.1 Infraestructura MEFF pone a disposición de sus Miembros y Proveedores de Aplicaciones Externas que lo soliciten un entorno de simulación que les permita probar sus Aplicaciones. Para más información, for favor, consulte el documento Conexión al Interfaz de Simulación FIX. 2.2 Disponibilidad del entorno de simulación. El entorno de simulación está disponible para aquellos miembros e ISV que desean verificar el correcto funcionamiento de sus Aplicaciones preparando su uso para producción. Los test de conformidad deben efectuarse con la intervención del departamento de TechServices. 2.3 Códigos de miembros y operadores. Los miembros del Mercado son identificados en el entorno de producción por un código de cuatro dígitos como por ejemplo A123. En el entorno de simulación el código del miembro se forma del mismo modo cambiando la A inicial por una T. A los ISV se les asigna un código ficticio. Cada entidad puede pedir los códigos de miembro que estimen necesarios para simular la configuración que tendrán en producción. 2.4 Operadores privilegiados. El sistema SMART permite que los operadores sean definidos como privilegiados. Los operadores privilegiados reciben los Execution Report de todas las operaciones de todos los operadores de la entidad. Las entidades que desees configurar un operador (cliente HF MEFFGate) como operador privilegiado deben contactar con el Departamento de TechServices. 2.5 Terminales MEFFStation. Las entidades pueden solicitar terminales MEFFStation de negociación, liquidación o supervision de miembro conectadas al entorno de simulación. El software, que corre sobre Windows, se instala en equipos propiedad de la entidad y se conectan a los servidores MEFFAccess. Para solicitar uno de estos terminales, por favor contacte con TechServices. 2.6 Contratos El entorno de simulación tendrá habitualmente los mismos contratos que el entorno de producción de MEFF. 2.7 Preguntas sobre pruebas. Cualquier pregunta referida al entorno de simulación de MEFF o al interfaz FIX HF MEFFGate debe ser dirigida a TechServices. 2.8 Contactos. TechServices puede ser contactado en techservices@grupobme.es. 2

7 3. Detalles que deben ser tenidos en cuenta al conectar con el HF MEFFGate. 3.1 Tratamiento del heartbeat. El HF MEFFGate solo envía heartbeats (35=0) respondiendo a peticiones TestRequest (35=1). La aplicación cliente que desee recibir heartbeats puede enviar TestRequest que serán respondidos de forma inmediata por el HF MEFFGate. En cualquier caso la aplicación cliente debe enviar heartbeats en los intervalos previstos o el HF MEFFGate finalizará la sesión. 3.2 Pérdida de conexión con los Sistemas centrales. Cuando el HF MEFFGate detecta una pérdida de conexión con el Sistema Central de MEFF, enviará un mensage Network Counterparty System Status a la aplicación cliente para notificárselo. En este escenario es necesario esperar una cantidad de tiempo razonable que permita al HF MEFFGate buscar una ruta alternativa. Durante ese tiempo la aplicación cliente no debe enviar ningún mensaje al HF MEFFGate porque este rechazará todos los mensajes que le lleguen que vayan destinados a los Sistemas Centrales, pero responderá a los mensajes TestRequest. Pasado ese tiempo y mientras no se reciba la recuperación de la conexión, la aplicación cliente intentará el establecimiento de la conexión a través del HF MEFFGate de backup cada minuto. 3.3 Pérdida de conexión con el HF MEFFGate. Si, por cualquier motivo, la aplicación cliente se desconecta del Servidor FIX HF MEFFGate o si no se recibe ningún mensaje durante 2 ó 3 veces el período de heartbeat será necesario establecer una nueva sesión con el HF MEFFGate de backup comenzando con el tag 34 igual a 1. La aplicación cliente podrá seleccionar a partir de qué mensaje desea recibir la información usando los tags 1180 y Las reconexiones con 34 igual a1 implican que se recibirán todos los ExecutionReports generados en la sesión desconectada (a partir del mensaje indicado mediante los tags 1180 y 1181). Eso significa que si, por ejemplo, una aplicación cliente ha entrado 100 órdenes desde el HF MEFFGate FIX primario, cuando se conecte al HF MEFFGate FIX de back-up, si no utiliza los tags 1180 y 1181, recibirá los Execution Report asociados a las 100 órdenes entradas por ese Operador (excluyendo los estados de tramitación Pending ). En el caso de desconexiones voluntarias, podrá iniciarse una sesión FIX contra el mismo HF MEFFGate Server, y en ese caso la aplicación cliente deberá iniciar una nueva sesión FIX (34=1) pudiendo especificar el número de mensaje a partir del cual queremos recibir información mediante los tags 1180 y Cancelación automática de órdenes. Al introducir una orden se puede indicar la persistencia o no de la orden en caso de desconexión (ExecInst). A partir del momento en que el Sistema Central detecta la desconexión de algún Usuario de HF MEFFGate, el Sistema Central espera un tiempo razonable para dar opción a que se subsane la desconexión. Si pasado ese tiempo, el Sistema Central no ha detectado la reconexión, se eliminan las órdenes quote y las que lleven desactivado el indicador de persistencia. 3.5 Suscripciones a FIX Debe tenerse en cuenta que cualquier suscripción a información es cancelada cuando se produce una desconexión de la aplicación cliente. Si, tras establecer de nuevo una sesión FIX, se desea mantener la suscripción, debe volver a solicitarse. 3

8 HF MEFFGate server admite solo una suscripción activa de los grupos TradingSessionStatus y SecurityList y SecurityStatus y hasta 5 suscripciones de MarketData. El HF MEFFGate rechazará las peticiones de establecer nuevas suscripciones. 3.6 Recepción de la actividad efectuada por terminales de Supervisión Las Aplicaciones cliente conectadas al servidor FIX HF MEFFGate tienen asociado un código de operador. Estas aplicaciones cliente deben estar preparadas para manejar mensajes que podrían recibir debido a acciones efectuadas en su nombre por terceros. Estas acciones podrían ser efectuadas por terminales de supervision del miembro o por terminales del departamento de Servicios de Mercado. 4

9 4. Bloques de pruebas A continuación se definen diversos grupos de pruebas. El Miembro o ISV decidirán que bloques presentarán al test de conformidad de acuerdo con las funcionalidades empleadas por la aplicación cliente. HC Comunicaciones HI Definición de instrumentos H1 Operador privilegiado H2 Ordenes por cuenta de HO Ordenes HQ Quotes HB Bloques HF Filtros HP Protección de Mercado Conexión y reconexión a una nueva sesión FIX. Reconexión desde un punto intermedio. Detección de de la desconexión de un nodo de la red. Identificar los contratos listados por el Mercado. Identificar los cambios de estado de los contratos. Supervisar el estado de las órdenes y ejecuciones de la entidad. Supervisar el estado de las órdenes propias enviadas por un supervisor de la entidad o por un terminal de Servicios de Mercado. Entrada de órdenes limitadas. Cancelación de órdenes simples. Cancelación masiva de órdenes. Modificación de órdenes. Supervisar el estado de las órdenes. Registro de parámetros de los Quotes. Entrada de quotes. Entrada de quote masivas. Modificación de quotes. Cancelación de quotes. Supervisión del estado de los quotes. Notificación de operaciones de bloques. Aceptación de Bloques. Gestión de filtros.- Precio Volumen Gestión de la Protección de Mercado Precio Volumen Delta Protection 5

10 5. Casos de prueba 5.1 HC Comunicaciones Todas las Aplicaciones deben efectuar al menos las pruebas señaladas como obligatorias. Comunicaciones CNX01 Descripción: Conectar a una nueva sesión FIX Criterios de realización: Acción esperada y Mensajes 1 Conectar a una nueva sesión FIX Logon (Mensaje Tipo A ) Resultado esperado y Mensajes Logon aceptado y sesión FIX establecida. Logon (Mensaje Tipo A ) Comunicaciones CNX02 Descripción: Finalizar una sesión FIX 1 Finalizar una sesión FIX Logout (Mensaje tipo 5) Logout aceptado y sesión FIX finalizada. Logout (Mensaje tipo 5) Comunicaciones CNX03 Descripción: Conectar a una sesión FIX recibiendo mensajes desde un punto intermedio. Criterios de realización: Casos de prueba CNX01 y CNX02 realizados con éxito. 1 Conectar a una nueva sesión FIX Logon (Mensaje Tipo A ) usando los tags 1180 y 1181 Logon aceptado y sesión FIX establecida. Logon (Mensaje Tipo A ) con los tags 1180 y 1181 de acuerdo con el logon y todos los mensajes sucesivos. 6

11 Comunicaciones CNX04 Descripción: Detección de la desconexión de un nodo de la red. Acción esperada y Resultado esperado y Mensajes Mensajes 1 Suscripción al Network Counterparty Status. Network Counterparty Network Counterparty Request aceptado. Network Counterparty Status Response (Mensaje tipo BD ) con tag 928 = 1 Status Request (Mensaje tipo BC ) 2 MEFF simula un corte de red 3 Corte de red informado Network Counterparty Status Response (Mensaje tipo BD ) con tag 928 = 2 4 MEFF restablece las comunicaciones 5 Fin de corte de red informado Network Counterparty Status Response (Mensaje tipo BD ) con tag 928 = 1 Comunicaciones CNX05 Descripción: Cambio de conexión a un HF MEFFGate alternativo. Criterios de realización: Completados satisfactoriamente los casos de prueba CNX01 y CNX02 1 Establecer una nueva sesión FIX Logon (Mensaje Tipo A ) 2 Fin de la sesión FIX Logout (Mensaje Tipo 5 ) 3 Establecer una nueva sesión FIX con una dirección IP diferente Logon (Mensaje Tipo A ) Logon aceptado y sesión FIX establecida. Logon (Mensaje Tipo A ) Logoot aceptado y sesión FIX finalizada. Logout (Message Type 5 ) Logon aceptado y sesión FIX establecida. Logon (Mensaje Tipo A ) Comunicacciones CNX06 * Descripción: Identificar cambios en el estado de la sesión Acción esperada y Resultado esperado y Mensajes Mensajes 1 MEFF simula un cambio en el estado de la sesión 2 Trading Session Status (Message Type h ) con tag * Las aplicaciones que no reciban esta información a partir del HF MEFFGate de negociación han de ser capaces de obtenerla a través de otras fuentes. 7

12 5.2 HI Definición de instrumentos Las aplicaciones deben ejecutar al menos los test marcados como obligatorios. Definición de IDF01 * instrumentos Descripción: Solicitar la lista completa La aplicación cliente se suscribe a todos los instrumentos Criterios de realización: 1 Solicitar la definición y el estado de todos en el mensaje logon Recibir la definición y el estado los contratos seleccionados. Security List Request (Mensaje Tipo y ) Security Status (Mensaje Tipo f ) Bloque de prueba: IDF02 * Definición de instrumentos Descripción: Identificar cambios en el estado del contrato Criterios de realización: Caso de pruebas IDF01 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 MEFF cambia el estado del contrato 2 Se informa del cambio en el estado del contrato Security Status (Mensaje Tipo f ) con valor actualizado en el tag 326 e incluyendo tag 327 * Las aplicaciones que no reciban esta información a partir del HF MEFFGate de negociación han de ser capaces de obtenerla a través de otras fuentes. 8

13 5.3 HO Gestión de órdenes Las aplicaciones que envían órdenes al Mercado deben realizar al menos las pruebas marcadas como obligatorias. Gestión de órdenes ORD01 Descripción: Entrada de órdenes La aplicación cliente puede enviar varios tipos de órdenes de acuerdo con sus requerimientos. 1 Entrada de órdenes con distintas características New Order Single (Mensaje Tipo D ) Confirmación de cada nueva orden incluida en el libro. Execution Report (Mensaje Tipo 8 ) con tag 150=0 Gestión de órdenes ORD02 Descripción: Cancelación de órdenes Criterios de realización: Caso de pruebas ORD01 realizado con éxito. 1 Cancelación de orden Order cancel Request (Mensaje Tipo F ) Confirmación de la cancelación de la orden Execution Report (Mensaje Tipo 8 ) con tag 150=4 Gestión de órdenes ORD03 Voluntario Descripción: Cancelación masiva de órdenes La aplicación cliente pide la cancelación de varias de acuerdo con los criterios de selección admitidos en el mensaje Order Mass Cancel Request Criterios de realización: Caso de pruebas ORD01 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 Cancelación de varias órdenes Order Mass Cancel Request q ) (Mensaje Tipo Confirmación de la cancelación masiva de órdenes Order Mass Cancel Report (Mensaje Tipo r ) con tag 531=7 Execution Report (Mensaje Tipo 8 ) con tag 150=4 para cado orden cancelada de acuerdo con el criterio de selección 9

14 Gestión de órdenes ORD04 Descripción: Identificar negociaciones Criterios de realización: Caso de pruebas ORD01 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 Las órdenes introducidas anteriormente son negociadas total o parcialmente Confirmación de cada negociación Execution Report (Mensaje Tipo 8 ) con tag 150=F y el volumen pendiente en el tag 151. Gestión de órdenes ORD05 Descripción: Identificar el estado de las órdenes antes y después de una desconexión Criterios de realización: Caso de pruebas ORD01 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 La aplicación cliente introduce varias órdenes sin que tengan activada la cancelación por desconexión. 2 La aplicación cliente desconecta 3 Algunas de las órdenes son negociadas total o parcialmente 4 La aplicación cliente reconecta 5 Confirmación de cada negociación Execution Report (Mensaje Tipo 8 ) con tag 150=F Gestión de órdenes ORD06 Voluntario Descripción: Identificar las órdenes introducidas por un Terminal superusuario o por Servicios de Mercado Criterios de realización: Caso de pruebas ORD01 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 MEFF introduce órdenes por cuenta del miembro 2 Confirmación de cada orden introducida Execution Report (Mensaje Tipo 8 ) con tag 150=0 10

15 Gestión de órdenes ORD07 Descripción: Identificar las órdenes modificadas o canceladas por un Terminal superusuario o por Servicios de Mercado Si la aplicación cliente maneja quotes, estos se incluirán en esta prueba Criterios de realización: Caso de pruebas ORD01 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 Entrada de órdenes con distintas características New Order Single (Mensaje Tipo D ) Confirmación de cada orden introducida Execution Report (Mensaje Tipo 8 ) con tag 150=0 2 MEFF modifica o cancela las órdenes por cuenta del miembro 3 Confirmación de cada modificación o cancelación Execution Report (Mensaje Tipo 8 ) con tag 150=4 (cancelaciones) ó 150=5 (modificaciones) Gestión de órdenes ORD08 Voluntario Descripción: Identificar las órdenes y negociaciones de otros operadores de la misma entidad (Operador Privilegiado) Esta prueba solo se realizará si la entidad soporta Operadores Privilegiados. Si la aplicación cliente maneja quotes, estos se incluirán en esta prueba Criterios de realización: Acción esperada y Mensajes Resultado esperado y Mensajes 1 Otros operadores de la misma entidad introducen órdenes 2 Confirmación de cada orden introducida Execution Report (Mensaje Tipo 8 ) con tag 150=0 con el operador origen identificado en el Bloque Parties 3 Algunas de las órdenes son cruzadas total o parcialmente. 4 Confirmación de cada negociación Execution Report (Mensaje Tipo 8 ) con tag 150=F con el operador origen identificado en el Bloque Parties 11

16 5.4 HQ Gestión de quotes Todas las aplicaciones que envíen quotes deben realizar al menos las pruebas señaladas como obligatorias. Gestión de quotes QTE01 Descripción: Introducción de parámetros de quotes 1 Introducción de parámetros de quote Aceptación de los parámetros quote Envío de Quote Parameters Registration Instruction Response Registration (Mensaje Tipo o ) (Mensaje Tipo p ) con tag 506= A Gestión de quotes QTE02 Descripción: Introducción de quotes Criterios de realización: Caso de pruebas QTE01 realizado con éxito. 1 Introducción de quote Confirmación de cada quote enviado Quote (Mensaje Tipo S ) Quote Status Report (Mensaje Tipo AI ) con tag 297= 0 Bloque de prueba: QTE03 Gestión de quotes Descripción: Modificación de quotes Criterios de realización: Caso de pruebas QTE02 realizado con éxito. 1 Introducir quotes en el libro Modificación de quote Quote (Mensaje Tipo S ) Confirmación de cada modificación de quote enviada Quote Status Report (Mensaje Tipo AI ) con tag 297=0 12

17 Bloque de prueba: QTE04 Gestión de quotes Descripción: Cancelación de un quote Criterios de realización: Caso de pruebas QTE02 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 Introducir quotes en el libro Modificación de quote Quote (Mensaje Tipo S ) con tags 132, 133, 134 y 135 =0 Confirmación de cada modificación de quote enviada Quote Status Report (Mensaje Tipo AI ) con tag 297=4 Gestión de quotes QTE05 Descripción: Cancelación masiva de quotes Criterios de realización: Caso de pruebas QTE02 realizado con éxito. 1 Cancelación de quote Confirmación de cada quote cancelado Quote Cancel (Mensaje Tipo Z ) Quote Status Report (Mensaje Tipo AI ) con tag 39=4 13

18 5.5 HB Gestión de Bloques Todas las aplicaciones que envíen o acepten operaciones de Bloques en el Mercado deben realizar como mínimo las pruebas consideradas obligatorias. Bloque de prueba: BLK01 Gestión de Bloques Descripción: Notificación de existencia de un Bloque pendiente de aceptación Acción esperada y Resultado esperado y Mensajes Mensajes 1 MEFF introduce un Bloque en el que la entidad que realiza la prueba es al menos una de las partes 2 Recepción de la notificación de Block Trade con aceptación pendiente Trade Capture Report (Mensaje tipo AE ) con tag 574=0,1 ó 2 Bloque de prueba: BLK02 Gestión de Bloques Descripción: Aceptación o rechazo de un Bloque pendiente de aceptación por la contrapartida Criterios de realización: Caso de pruebas BLK01 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 Recepción de la notificación de Block Trade con aceptación pendiente Trade Capture Report (Mensaje tipo AE ) con tag 574=0,1 ó 2 2 Confirmación o rechazo del Block Trade Trade Capture Report (Mensaje tipo AE ) con tag 856=2 ó 3 Recepción de la confirmación o rechazo de Block Trade con aceptación pendiente Trade Capture Report (Mensaje tipo AE ) con tag 574=1, 2, 3, 5 ó 6 14

19 Bloque de prueba: BLK03 Gestión de Bloques Descripción: Aceptación y registro o rechazo de un Bloque por Servicios de Mercado Criterios de realización: Caso de pruebas BLK02 realizado con éxito. Acción esperada y Resultado esperado y Mensajes Mensajes 1 MEFF acepta o rechaza un Bloque pendiente de aceptación por Servicios de Mercado 2 Recepción de la aceptación o rechazo del Block Trade con aceptación pendiente Trade Capture Report (Mensaje tipo AE ) con tag 574=7,8 ó 9 Bloque de prueba: BLK04 Gestión de Bloques Descripción: Bloque comunicado al mercado Acción esperada y Resultado esperado y Mensajes Mensajes 1 Block Trade comunicado al mercado Trade Capture Report (Mensaje tipo AE ) con tag 856=0 Recepción de la notificación de Block Trade comunicado Trade Capture Report (Mensaje tipo AE ) con tag 574 distinto de B 15

20 5.6 HP y HF Protección del Mercado y Filtros Las pruebas incluidas en esta sección están marcadas como voluntarios. Las pruebas individuales deberían ser realizadas por las aplicaciones que desean usar la funcionalidad descrita. Nótese que cuando la aplicación cliente define un nuevo filtro, debe ser más restrictivo que el definido por Servicios de Mercado. Protección del MPF01 Voluntario Mercado y Filtros Descripción: Configuración de la Protección de Delta y de la cuenta para quotes 1 Introducción de parámetros Registration (Mensaje tipo o ) PartySubID [523] = DELTA Aceptación de los parámetros de quotes. Registration Instructions Response (Mensaje tipo p ) con tag 506=A Protección del MPF02 Voluntario Mercado y Filtros Descripción: Kill Button Comentariots: En esta prueba un GCM puede eliminar a un NCM o a un operador individual o bien un NCM puede eliminar a un operador individual 1 Introducción de parámetros Registration (Mensaje tipo o ) PartySubID [523] = KILL Aceptación del Kill Button Registration Instructions Response (Mensaje tipo p ) con tag 506=A Protección del Mercado y Filtros MPF03 Voluntario Descripción: Gestión de filtros de precios En esta prueba un NCM puede definir un filtro de precios máximos, para un subyacente específico y su familia de productos, para cada uno de sus operadores Acción esperada y Mensajes 1 Introducción de parámetros Registration (Mensaje tipo o ) PartySubID [523] = PRICE Resultado esperado y Mensajes Aceptación de los filtros de protección del mercado. Registration Instructions Response (Mensaje tipo p ) con tag 506=A 16

21 Protección del Mercado y Filtros MPF04 Voluntario Descripción: Gestión de filtros de volumen En esta prueba un GCM puede definir un tamaño máximo de orden para una familia de productos, para un NCM al que liquida o un NCM define el tamaño máximo de orden para una familia de productos para un operador individual. Acción esperada y Mensajes 1 Introducción de parámetros Registration (Mensaje tipo o ) PartySubID [523] = VOL Resultado esperado y Mensajes Aceptación de los filtros volumen Registration Instructions Response (Mensaje tipo p ) con tag 506=A Protección del Mercado y Filtros MPF05 Voluntario Descripción: Gestión del límite de posición intradía para futuros. En esta prueba un GCM puede definir el límite de posición intradía para una familia de futuros para una cuenta individual Acción esperada y Mensajes 1 Introducción de parámetros Registration (Mensaje tipo o ) PartySubID [523] = IFTL Resultado esperado y Mensajes Aceptación de los filtros de protección del mercado Registration Instructions Response (Mensaje tipo p ) con tag 506=A 17