Interactivo Brokers TWS API FXMacroData se ajusta al lado de esa pila como la capa de riesgo macro: calendarios de lanzamiento, historial de anuncios, El valor de la moneda de referencia contexto, Sesiones de divisas, y ventanas de eventos que deben comprobarse antes de que una orden de divisas llegue a la API del corredor.
El problema práctico no es conectar a TWS. El problema es decidir si una señal debe ser permitida a comerciar ahora. Una configuración técnica limpia puede convertirse en una mala decisión de ejecución minutos antes. Indicador de precios de los Estados Unidos¿ Qué ? Pago de los trabajadores no agrícolas, o un Reserva Federal FXMacroData permite al servicio de ejecución hacer una segunda pregunta antes de llamar al corredor: ¿esta orden entra en una ventana de riesgo macro conocida?
En forma
Utilice esto para
Servicios de órdenes de cambio, enrutadores de señales y flujos de trabajo de investigación a ejecución que ya utilizan TWS o IB Gateway.
IBKR funciona mejor cuando
Es dueño de la conectividad del corredor, mientras que una aplicación separada es dueña de la política macro, credenciales, registros y decisiones de riesgo.
No lo hagas.
Dejar que un modelo, un cuaderno o una herramienta de chat realicen pedidos en vivo sin una puerta de pedidos determinista.
Por qué TWS API se ajusta a Macro Gates
Interactive Brokers documenta la API de TWS como una forma basada en sockets para que las aplicaciones de cliente se comuniquen con la estación de trabajo del comerciante o la puerta de enlace IB. La documentación actual del IBKR Campus describe la configuración de conexión de host, puerto y ID de cliente, con valores predeterminados como el comercio de papel de TWS en el puerto 7497 y el comercio de papel IB Gateway en puertos . 4002También se señala que una sola instancia de TWS o Gateway puede admitir múltiples aplicaciones de cliente, separadas por ID de cliente.
Eso hace que la API de TWS sea un destino natural para una puerta de macro. Su estrategia o servicio de señal puede producir un ticket de pedido, FXMacroData puede verificar el contexto de macro, y solo entonces la aplicación debe decidir si debe enviar, retrasar, reducir o registrar el pedido.
Qué cambios para el comerciante
El cambio importante es de la ejecución de primera señal a la ejecución consciente de la evidencia. Sin una puerta de macro, una estrategia puede tratar cada configuración válida como equivalente. Con una puerta macro, la misma configuración lleva un código de razón: condiciones normales, ventana de lanzamiento bloqueada, sesión delgada, revisión posterior al anuncio o datos faltantes.
Escenario de la mesa de negociación
El servicio de ejecución comprueba el FXMacroData calendario de liberación En lugar de llamar a TWS inmediatamente, escribe el boleto como waitEl operador puede comparar más tarde las órdenes permitidas con las órdenes retrasadas en lugar de depender de la memoria.
Este no es un motor de predicción. Es una capa de disciplina. La estrategia todavía posee la configuración, IBKR todavía poseen la conectividad del corredor, y FXMacroData suministra los hechos macro actuales que el servicio de órdenes debe inspeccionar antes de actuar.
Forma del flujo de trabajo
1. señal
Una estrategia, receptor de alertas o flujo de trabajo de analistas propone un ticket de pedido.
2. El contexto
El servicio recupera el calendario, anuncio, par y contexto de sesión de FXMacroData.
3. Puerta
La política convierte el ticket en permitir, esperar, reducir o revisar.
4. Presentar
Solo se envían tickets aprobados a la API de TWS o a la puerta de enlace IB.
5. Diario
Cada decisión se guarda con la evidencia macro y los detalles del boleto.
Dónde pertenece cada capa
| Capa | Usarlo para | No lo use para |
|---|---|---|
| Interactivo Brokers TWS API | Conexión a TWS o IB Gateway, recepción del estado de la cuenta y envío de órdenes aprobadas. | Decidir la verdad del evento macro o almacenar credenciales de datos externos. |
| El resto de datos de FXMacroData | Puertas de pedidos de producción que necesitan calendario actual, anuncio, cambio de moneda y contexto de sesión. | Envío de órdenes de corredor o gestión de cuentas. |
| El MCP de FXMacroData | Flujos de trabajo de asistentes de investigación, revisión de órdenes bloqueadas, explicaciones de estrategia y asistencia de código. | Enrutamiento de órdenes en vivo o autorización del lado del corredor. |
| AI o capa de portátil | Análisis, revisión de escenarios y borrador de explicaciones para los comerciantes. | Ejecución en vivo sin supervisión sin una puerta de política determinista. |
Los requisitos previos
- Una cuenta de Interactive Brokers con instalada la estación de trabajo del comerciante o la pasarela IB y configurado el acceso a la API.
- Una configuración de comercio de papel para las primeras pruebas de implementación y regresión.
- Un proceso de Python del lado del servidor que puede llegar tanto a TWS o Gateway y
https://api.fxmacrodata.com- ¿ Qué ? - Una clave de la API FXMacroData se mantiene en el lado del servidor y se pasa como
?api_key=YOUR_API_KEYen ejemplos. - Una política escrita para la cual las monedas, eventos, sesiones y estados de reserva deben bloquear o revisar órdenes.
Paso 1: Definir la política de riesgo macro
Comience con una pequeña política antes de escribir el código del corredor.
pair: EURUSD
macro_currency: USD
block_before_minutes: 30
block_after_minutes: 10
events:
- inflation
- non_farm_payrolls
- policy_rate
missing_data_decision: review
normal_decision: allowUtilice esta directiva para producir un código de razón, no sólo un booleano. wait Debería ser fácil distinguirlo de un boleto marcado. review porque la solicitud de macro falló.
Paso 2: Obtener el contexto de FXMacroData
Llame a FXMacroData desde su servicio de ejecución antes de la llamada de orden TWS. Comience con las filas del calendario, el historial de anuncios y el contexto del par actual. Añada más características solo cuando su hipótesis de negociación las necesite.
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"Una implementación de producción debe ocultar la clave, establecer un tiempo de espera, volver a intentar cuidadosamente y convertir las respuestas en bruto en una entrada de política compacta.
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 macro_context():
return {
"calendar": fxmd_get("/v1/calendar/usd"),
"cpi": fxmd_get("/v1/announcements/usd/inflation"),
"spot": fxmd_get("/v1/forex/eur/usd"),
}Paso 3: Envía la orden antes de TWS
Haga la decisión macro antes de crear o enviar la orden del corredor. Los nombres de las funciones a continuación son deliberadamente pequeños: la política de escritorio debe poseer lógica de ventana de eventos, comportamiento de datos faltantes y si una decisión se convierte en permitir, esperar, reducir o revisar.
def decide_order(context, policy):
if macro_data_missing(context):
return {"decision": "review", "reason": "Macro data unavailable"}
if has_blocked_event(context["calendar"], policy):
return {"decision": "wait", "reason": "Blocked macro window"}
return {"decision": "allow", "reason": "No blocked macro window"}Cuando la decisión sea allow, la aplicación puede enviar a la API de TWS. El ejemplo utiliza ¿Qué está pasando? La misma puerta pertenece al frente de la API Python nativa IBKR también.
from ib_insync import IB, Forex, MarketOrder
ib = IB()
ib.connect("127.0.0.1", 7497, clientId=7)
contract = Forex("EURUSD")
ticket = {"side": "BUY", "quantity": 20000}
decision = decide_order(macro_context(), policy)
if decision["decision"] == "allow":
order = MarketOrder(ticket["side"], ticket["quantity"])
trade = ib.placeOrder(contract, order)
else:
write_order_journal(contract.symbol, ticket, decision)Utilice el puerto de negociación de papel mientras valida el flujo de trabajo. 7497 como el puerto de papel TWS por defecto y 4002 como el puerto de papel por defecto de IB Gateway; confirme el puertos de enchufe en la configuración de su TWS o Gateway antes de conectarse.
Paso 4: Anotad cada decisión
La puerta solo es útil si produce evidencia. Guarde el ticket, la decisión macro, la ruta de origen, la marca de tiempo y la acción final. Eso permite al operador evaluar si la puerta macro realmente mejoró el comportamiento de ejecución.
Ejemplo de fila de diario
{
"symbol": "EURUSD",
"side": "BUY",
"quantity": 20000,
"decision": "wait",
"reason": "Blocked macro window",
"macro_currency": "USD",
"checked_paths": [
"/v1/calendar/usd",
"/v1/announcements/usd/inflation"
]
}| El método métrico | ¿Por qué es importante? | Cadencia de revisión |
|---|---|---|
| Entradas permitidas frente a entradas bloqueadas | Muestra si la puerta macro está cambiando de comportamiento. | Diario y semanal. |
| Deslizamiento posterior al evento | Muestra si las ventanas de eventos son demasiado anchas o demasiado estrechas. | Después de las liberaciones de alto impacto. |
| Tasa de anulación manual | Revela si los operadores confían en la póliza. | Semanal. ¿Qué es? |
| Decisiones por falta de datos | Evita el comercio silencioso cuando la evidencia es incompleta. | Cada carrera. |
Capa de investigación de MCP opcional
Conecte el MCP de FXMacroData en https://mcp.fxmacrodata.com Cuando un analista o asistente de codificación necesita inspeccionar órdenes bloqueadas, explicar ventanas de eventos o generar un primer borrador de pruebas de políticas.
{
"servers": {
"FXMacroData": {
"type": "http",
"url": "https://mcp.fxmacrodata.com?api_key=YOUR_API_KEY"
}
}
}Un buen asistente de instrucciones es estrecho: "Revisa los boletos de pedido EUR/USD de ayer que estaban marcados como espera, enumera los eventos macro involucrados y muestra si la misma estrategia se comportó mejor fuera de esas ventanas". Eso mantiene el modelo en la revisión de la evidencia, no en el control de ejecución.
Barreras de protección operativas
Control mínimo
- Prueba contra el comercio de papel antes de conectar la puerta a la presentación de órdenes en vivo.
- Mantenga FXMacroData y las credenciales del corredor en el lado del servidor.
- Utilice ID de cliente de API de TWS distintos para las herramientas de ejecución, monitoreo e investigación.
- No se puede revisar, no se permite, cuando no se puede recuperar el contexto macro.
- Registre cada orden de ID del corredor junto con la decisión macro que lo permitió.
- Separar a los asistentes de investigación de IA del proceso de envío de pedidos en vivo de TWS.
Preguntas frecuentes
¿Pueden los corredores interactivos llamar a FXMacroData directamente?
No. El patrón habitual es una aplicación que se conecta a TWS o IB Gateway y llama por separado FXMacroData REST antes de enviar un pedido. Esa aplicación es propietaria de la política y las credenciales.
¿Debería usar REST o MCP?
Utilice REST para la puerta de pedidos de producción porque es determinista, estrecha y fácil de registrar.
¿Esto reemplaza los controles de riesgo normales de los corredores?
No. Mantenga las precauciones de orden IBKR, los límites de cuenta, los limites de posición y la supervisión manual. FXMacroData agrega contexto macro externo; no reemplaza los controles del lado del corredor.
¿Qué debería bloquear la primera versión?
Comience con los principales eventos para la moneda de cotización, como la inflación del USD, los datos laborales y las ventanas de tasas de política para el EUR/USD.
Fuentes de información
