Cómo utilizar la API de FIX con FXMacroData para el enrutamiento de órdenes de FX Macro-Aware

Protocolo FIX es el estándar de mensajes de comercio electrónico compartido detrás de muchos flujos de trabajo de enrutamiento de órdenes institucionales. Los operadores a menudo lo llaman una API FIX porque la aplicación se conecta a un corredor, proveedor de liquidez o lugar a través de una sesión FIX y envía mensajes como órdenes, cancelaciones, informes de ejecución y solicitudes de datos de mercado. El valor de la moneda de referencia contexto, Sesiones de divisas, y ventanas de eventos que deben comprobarse antes de que un mensaje de orden salga de su sistema.

El valor no es que los datos macro reemplacen los controles previos a la negociación de un corredor. Es que un flujo de trabajo de ejecución puede dejar de tratar todos los tickets técnicamente válidos como igualmente enrutados. Indicador de precios de los Estados Unidos o un Reserva Federal La decisión corresponde a un estado diferente del mismo orden durante la liquidez normal.

Por qué FIX se ajusta a las puertas de macro

FIX Trading Community describe FIX como un protocolo de capa de aplicación: define la información comercial intercambiada en los mensajes comerciales, como órdenes, ejecuciones y datos de mercado, mientras permanece independiente de la red o pila de tecnología subyacente. Esa separación es útil. FIX no debería necesitar saber por qué una política macro bloquea una orden; solo necesita recibir órdenes que el flujo de trabajo de arriba haya decidido que son elegibles para enviar.

FIX también está diseñado en torno a campos estructurados, tipos de mensajes y sesiones específicas de contraparte. Un candidato de orden de FX simple puede ser representado antes de convertirse en un mensaje de FIX, verificado con evidencia macro, luego enviado como una orden, retrasado, reducido o enviado a revisión humana.

La opción de diseño más importante es la ubicación. La puerta macro pertenece antes de que el pedido entre en el motor FIX. 35=D Si el mensaje ha sido enviado, ya está en el territorio del flujo de trabajo del corredor o del lugar: acuse de recibo, informes de ejecución, cancelaciones, reemplazos y rechazos. FXMacroData debe influir en si se envía el mensaje, no parchear la decisión después del hecho.

Qué cambios para el escritorio

Un router de orden FIX normal puede ser excelente en conectividad y aún así ciego al riesgo de macro programado. Un router con macro-consciente registra no solo el informe de orden y ejecución, sino también el estado de macro que permitió, retrasó o bloqueó el mensaje saliente.

Este es un proceso de revisión más limpio que simplemente decir "el sistema fue cauteloso con las noticias". El diario puede mostrar exactamente qué órdenes fueron bloqueadas, qué eventos estaban activos, qué contrapartes se vieron afectadas y qué sucedió con el mercado después de que se cerró la ventana.

Forma del flujo de trabajo

Dónde pertenece cada capa

Los requisitos previos

• Una contraparte de corredores, proveedores de liquidez, locales o simulación que proporciona una sesión FIX y una especificación de mensaje.
• Detalles de la sesión como la versión del protocolo, SenderCompID, TargetCompID , host, puerto, intervalo de latidos cardíacos y requisitos de inicio de sesión.
• Un motor de FIX como QuickFIX, QuickFix/J, Quick FIX/n, o un motor de proveedor administrado que se ajuste a su pila.
• Una clave de la API FXMacroData se mantiene en el lado del servidor y se pasa como ?api_key=YOUR_API_KEY en ejemplos.
• Una política de enrutamiento de macro escrita para pares, monedas, indicadores, ventanas de liberación, comportamiento de datos faltantes y estados de revisión manual.

Paso 1: Define la política de enrutamiento de macro

Una política debe definir la exposición a la moneda, los indicadores bloqueados, las ventanas de tiempo y el comportamiento de datos faltantes antes de que se construya cualquier orden FIX.

route: LP_FIX_PRIMARY
pair: EUR_USD
macro_currency: USD
block_before_minutes: 45
block_after_minutes: 20
events:
  - inflation
  - non_farm_payrolls
  - policy_rate
missing_data_decision: review
normal_decision: allow

Mantenga la primera política limitada. Añadir más monedas, contrapartes, tipos de órdenes e indicadores sólo después de que el escritorio puede medir cuántos tickets cambia la puerta y si esas decisiones mejoraron la calidad de ejecución.

Paso 2: Obtener el contexto de FXMacroData

La aplicación puede entonces devolver una pequeña decisión de política en lugar de obligar al motor FIX a analizar las cargas útiles de macro completas.

curl "https://api.fxmacrodata.com/v1/calendar/usd?api_key=YOUR_API_KEY"
curl "https://api.fxmacrodata.com/v1/announcements/usd/inflation?api_key=YOUR_API_KEY"
curl "https://api.fxmacrodata.com/v1/forex/eur/usd?api_key=YOUR_API_KEY"
curl "https://api.fxmacrodata.com/v1/market_sessions?api_key=YOUR_API_KEY"

import os
import requests

FXMD_ROOT = "https://api.fxmacrodata.com"
FXMD_API_KEY = os.environ["FXMD_API_KEY"]

def fxmd_get(path):
    response = requests.get(
        f"{FXMD_ROOT}{path}",
        params={"api_key": FXMD_API_KEY},
        timeout=5,
    )
    response.raise_for_status()
    return response.json()

def load_macro_context():
    return {
        "calendar": fxmd_get("/v1/calendar/usd"),
        "spot": fxmd_get("/v1/forex/eur/usd"),
        "sessions": fxmd_get("/v1/market_sessions"),
    }

Paso 3: Puerta del candidato de orden FIX

Representa el pedido como un candidato interno antes de que se convierta en un mensaje FIX. Eso hace que la decisión macro sea comprobable y evita que la construcción parcial de FIX se convierte en el objeto principal del negocio.

candidate = {
    "route": "LP_FIX_PRIMARY",
    "msg_type": "D",
    "symbol": "EUR/USD",
    "side": "buy",
    "quantity": 1_000_000,
    "ord_type": "market",
}

def gate_candidate(candidate, context, policy):
    if not context.get("calendar"):
        return {"decision": "review", "reason": "macro_data_missing"}
    if inside_blocked_window(context["calendar"], policy):
        return {"decision": "wait", "reason": "blocked_usd_event"}
    return {"decision": "allow", "reason": "no_blocked_event"}

{
  "route": "LP_FIX_PRIMARY",
  "msg_type": "D",
  "symbol": "EUR/USD",
  "decision": "wait",
  "reason": "blocked_usd_event",
  "checked_paths": ["/v1/calendar/usd"]
}

Paso 4: Envía sólo mensajes de corrección aprobados

Solo los candidatos aprobados deben convertirse en mensajes de aplicación FIX. El ejemplo legible por humanos a continuación utiliza caracteres de tubería como separadores de campos para su visualización; los mensajes FIX reales utilizan el delimitador estándar esperado por su motor y contraparte.

8=FIX.4.4|35=D|49=BUY_SIDE|56=LP_FIX_PRIMARY|
11=FXMD-20260712-0001|55=EUR/USD|54=1|
38=1000000|40=1|60=20260712-13:40:27|

La puerta de macro pertenece antes de que se envíe este mensaje. En el código de la aplicación, eso generalmente significa que la llamada de envío FIX se encuentra detrás de una rama de decisión clara.

decision = gate_candidate(candidate, load_macro_context(), policy)

if decision["decision"] == "allow":
    fix_message = build_new_order_single(candidate)
    fix_session.send(fix_message)
else:
    journal_blocked_candidate(candidate, decision)

El motor FIX debe manejar problemas normales de FIX: inicio de sesión, latidos cardíacos, números de secuencia, rechazos, informes de ejecución, cancelaciones y reemplazos.

Paso 5: Diario y música

Una puerta de macro debe medirse como cualquier otro control de ejecución. La primera versión no está terminada cuando bloquea un ticket. Está terminada quando el escritorio puede comparar tickets bloqueados, tickets permitidos, informes de ejecución y comportamiento del mercado después de la ventana de lanzamiento.

Capa de revisión de MCP opcional

¿ Cómo ? El MCP de FXMacroData ¿ Qué ? https://mcp.fxmacrodata.com Cuando un flujo de trabajo de investigación compatible debe inspeccionar tickets bloqueados, explicar ventanas de macro o ayudar a redactar pruebas de políticas.

{
  "servers": {
    "FXMacroData": {
      "type": "http",
      "url": "https://mcp.fxmacrodata.com?api_key=YOUR_API_KEY"
    }
  }
}

Un útil aviso de revisión es estrecho: "Grupo de ayer FIX candidatos de orden marcado espera por macro razón, ruta y ventana de liberación". Que mantiene el trabajo habilitado modelo en el modo de investigación y auditoría en lugar de control de ejecución en vivo.

Barreras de protección operativas

Preguntas frecuentes

¿Puede una API de FIX utilizar FXMacroData?

El patrón limpio es llamar a FXMacroData desde el servicio de ejecución antes de construir y enviar el mensaje de orden FIX saliente.

¿Se debe llamar FXMacroData dentro del motor FIX?

Por lo general no. Mantenga las devoluciones de llamadas de FIX enfocadas en la sesión y el manejo de mensajes. Llame a FXMacroData antes de que el candidato de orden se convierta en un mensaje de Fix.

¿Qué mensaje de FIX afecta primero una puerta macro?

El primer control es generalmente antes de 35=D Las versiones posteriores también pueden influir en la política de reemplazo, cancelación y selección de rutas, pero comienzan con la elegibilidad de nuevos pedidos.

¿Debería usar REST o MCP?

Utilice REST para la puerta de macro de producción porque es estrecha, determinista y fácil de registrar.

¿Sustituye FXMacroData a los controles de riesgo de los corredores o de los centros de operaciones?

No. FXMacroData agrega contexto macro antes de la enrutamiento de la orden. El corredor, el lugar, la contraparte, el crédito, la posición y los controles de interruptor de eliminación siguen siendo requisitos separados.