Cómo evaluar una FIX API antes de comprometer tu integración

"Soportamos FIX 4.4 y 5.0" no dice nada. Es como decir que un coche tiene ruedas. Lo que determina si una integración va a funcionar son cosas mucho menos glamurosas: qué mensajes cubren, qué pasa cuando la sesión se cae, y si el sandbox se comporta como producción.

Esta es la lista que debería revisar tu equipo técnico antes de comprometer semanas de trabajo.

Lo que la versión no te dice

FIX es un protocolo, no una implementación. Dos venues que dicen soportar 4.4 pueden diferir en:

Qué tipos de mensaje implementan y cuáles ignoran
Qué tags son obligatorios en cada mensaje
Cómo manejan los campos personalizados
Qué códigos de rechazo devuelven y qué significan
Cómo gestionan la numeración de secuencia tras una desconexión

Ninguna de esas diferencias aparece en "FIX 4.4". Todas aparecen en la certificación, que es cuando ya invertiste tiempo.

La documentación de mensajes debería estar disponible antes de firmar nada. Si te la dan solo después del contrato, estás comprando a ciegas.

Cobertura de mensajes: qué preguntar

Como mínimo, necesitás claridad sobre cuatro flujos:

Cotización. ¿Streaming de precios o request/response? ¿Suscripción por instrumento o por lista? ¿Qué profundidad envían y con qué frecuencia?

Entrada de órdenes. ¿Qué tipos soportan — mercado, límite, stop, IOC, FOK? ¿Órdenes de modificación y cancelación? ¿Cuál es el comportamiento cuando se rechaza una modificación de una orden ya parcialmente ejecutada?

Reportes de ejecución. ¿Envían ejecuciones parciales? ¿Con qué granularidad? ¿Cómo se identifica la relación entre la orden original y sus fills?

Drop-copy. ¿Existe una sesión separada que replique tu actividad para reconciliación y compliance? Para fondos y firmas con obligaciones de reporting, no es opcional.

Pedí esto: la especificación completa de mensajes y tags, incluidos los códigos de rechazo, antes de la certificación.

El comportamiento en reconexión, que es donde se rompe todo

Esta es la parte que separa una integración que sobrevive de una que te despierta de madrugada.

Las preguntas concretas:

¿Qué pasa con las órdenes en vuelo cuando cae la sesión? ¿Se cancelan automáticamente, quedan vivas, o depende de la configuración? Las tres respuestas son defendibles; no saber cuál es la tuya no lo es.

¿Cómo se maneja el sequence reset? Cuando reconectás, ¿esperan que retomes la numeración donde quedaste, que la reinicies, o negocian? Un desajuste de secuencia mal gestionado puede bloquear la sesión entera.

¿Hay recuperación de mensajes perdidos? Si estuviste desconectado 30 segundos, ¿podés pedir los mensajes de ese intervalo o se perdieron?

¿Cuál es el timeout de heartbeat y qué pasa al superarlo?

Si alguna de estas respuestas es "eso lo vemos en la certificación", tomalo como información: significa que no está documentado.

Mapeo de símbolos: tedioso y crítico

Cada venue nombra sus instrumentos a su manera. El oro puede ser XAUUSD, GOLD o XAU/USD, con diferencias en tamaño de contrato, número de dígitos y horarios de sesión.

El mapeo de tu catálogo completo debería acordarse antes de la certificación, no durante. Es la causa más común de retrasos, y es completamente evitable.

Puntos que suelen morder:

Instrumentos con el mismo nombre y distinto tamaño de contrato
Diferencias en el número de decimales, que rompen los cálculos de pip
Horarios de sesión que no coinciden con los que espera tu plataforma
Instrumentos que existen en tu catálogo y no en el suyo

Pedí esto: el mapeo acordado de tu catálogo entero, no de una muestra representativa.

El sandbox: la única prueba que vale

Un sandbox que no se comporta como producción traslada el descubrimiento de los bugs a tu primera sesión en vivo. Es la diferencia entre un entorno de pruebas y un decorado.

Paridad de producción significa concretamente:

Los mismos tipos de mensaje y los mismos códigos de rechazo
Comportamiento de rechazo realista, no aceptación universal
Latencia representativa, no instantánea
Los mismos horarios de sesión y las mismas reglas de instrumento

Y críticamente: credenciales antes del compromiso comercial. Un venue que te pide firmar para darte acceso al sandbox está invirtiendo el orden correcto.

Lo que deberías probar ahí:

El ciclo completo de orden: envío, ejecución parcial, ejecución total, cancelación
Una desconexión forzada a mitad de una orden viva
Un sequence reset
Rechazos: provocarlos deliberadamente y verificar que los códigos son los documentados
Tu catálogo completo de instrumentos
Comportamiento durante una ventana de alta volatilidad simulada

Cuánto debería tardar la certificación

Con el onboarding completo y el mapeo acordado, días, no semanas.

Lo que estira los plazos casi nunca es la tecnología: es la espera. Por eso conviene tener un contacto técnico nombrado de tu lado desde el principio, con capacidad de decisión, en lugar de una cadena de aprobaciones.

Si un venue te da un plazo de certificación de varias semanas sin explicar qué lo justifica, preguntá qué parte del proceso es la lenta. La respuesta te dice mucho sobre cómo va a ser la relación operativa después.

Cuándo FIX no es la respuesta

Vale la pena decirlo, porque hay una tendencia a asumir que FIX es siempre superior:

Si corrés una correduría sobre MetaTrader con clientes minoristas o profesionales sobre esa plataforma, el puente MT5 es el camino correcto. FIX añadiría complejidad sin beneficio.

Si tu stack es HTTP-first y moderno —típico en prop firms recientes y venues cripto-adyacentes— REST más un WebSocket de baja latencia con documentación OpenAPI puede ser mejor encaje que FIX, y bastante más rápido de integrar.

FIX es el camino cuando tu OMS o EMS lo habla de forma nativa, cuando necesitás drop-copy para compliance, o cuando el volumen y la latencia justifican la inversión de integración.

Muchas firmas empiezan con el puente y añaden FIX al escalar. Es una progresión sensata, no una derrota.

Preguntas frecuentes

¿FIX 5.0 es mejor que 4.4? No para la mayoría de casos. 4.4 sigue siendo el estándar de facto en FX institucional y está mejor soportado en toda la cadena. 5.0 introduce mejoras estructurales, pero si tu contraparte y tu OMS hablan 4.4 sin problemas, no hay razón para complicarse.

¿Necesito drop-copy? Si tenés obligaciones de reporting, un administrador de fondo que debe reconciliar, o auditores que van a pedir trazabilidad, sí. Si sos un broker pequeño sin esas obligaciones, es un lujo. Preguntá igualmente si está disponible: que exista dice algo sobre la madurez del venue.

¿Puedo usar mi propio motor FIX? Normalmente sí, y es lo habitual. Lo que necesitás verificar es que tu motor y su implementación coincidan en los detalles que importan — sobre todo el manejo de secuencia y los campos personalizados.

¿Qué hago si el sandbox no tiene paridad de producción? Pedirlo explícitamente. Si la respuesta es que no lo tienen, es un dato relevante sobre cómo va a ser la puesta en producción, y deberías presupuestar tiempo de estabilización que no habías previsto.

El detalle técnico de nuestra implementación está en FIX API: sesiones, cobertura de mensajes, sandbox con paridad y comportamiento de reconexión documentado antes de la certificación. Los clientes se incorporan y ejecutan a través nuestro; las credenciales de sandbox se emiten antes de cualquier compromiso comercial.

Para el marco general: cómo elige liquidez un broker.