Qué significa “calidad de ejecución” para el acceso API
La calidad de ejecución es qué tan bien una orden enviada a través de una API produce el resultado previsto en comparación con lo que esperaba en el momento en que la envió. En la práctica, usted juzga la calidad de ejecución utilizando el comportamiento observable del sistema: tiempos, manejo de órdenes, la correspondencia entre las ejecuciones solicitadas y las reales, y la frecuencia con la que ocurren errores o eventos inesperados.
El acceso API cambia el lugar donde pueden aparecer los problemas de ejecución. En lugar de observar únicamente el comportamiento del mercado y de la estrategia, también debe considerar la “infraestructura” que rodea el envío de órdenes y el ciclo de vida de la orden: cómo recibe la API su solicitud, cómo confirma la aceptación, cómo actualiza el estado de la orden y cómo reporta las operaciones de vuelta a su sistema.
Mecánica central: qué puede medir
Para evaluar la calidad de ejecución, primero defina algunos términos.
- Hora de solicitud: cuándo su aplicación envía un mensaje de orden.
- Confirmación/aceptación: cuándo la API confirma que la orden fue aceptada para su procesamiento.
- Hora del evento de ejecución: cuándo ocurren las ejecuciones o cancelaciones (según lo reportado por la API).
- Resultados esperados vs. reales: si el precio, la cantidad o el momento de la ejecución coinciden con lo que su sistema asumió.
Una evaluación medible generalmente incluye:
- Distribución de latencia (no solo un promedio). Realice un seguimiento del tiempo desde la solicitud hasta la confirmación, y desde la confirmación hasta la primera ejecución. Considere percentiles (por ejemplo, con qué frecuencia es “lo suficientemente rápido”).
- Fiabilidad. Mida las tasas de órdenes rechazadas, tiempos de espera agotados, solicitudes duplicadas y actualizaciones de estado faltantes.
- Precisión del resultado de la orden. Compare el precio/tamaño/restricciones solicitados con lo que finalmente se ejecutó o confirmó (incluyendo ejecuciones parciales).
- Integridad del evento. Verifique si la secuencia de estados de orden que recibe (aceptada → parcialmente ejecutada → ejecutada/cancelada) es consistente y completa.
- Transparencia de costos. La calidad de ejecución no puede separarse de los costos totales de transacción (spreads, comisiones, tarifas y cualquier deslizamiento implícito en las diferencias de ejecución). Solo puede evaluarla utilizando los precios y tarifas realmente aplicados.
Una idea clave es comparar su ejecución observada con un punto de referencia que usted controle. Su punto de referencia puede ser una prueba controlada que utilice órdenes pequeñas en condiciones consistentes, con sellos de tiempo y datos de entrada claramente registrados.
Evidencia y ejemplo: una prueba de estilo verificación
Suponga que realiza una prueba en la que envía órdenes límite idénticas a través de la API y registra:
- la marca de tiempo exacta de la solicitud desde su aplicación,
- la marca de tiempo de aceptación de la API,
- la marca de tiempo de la primera ejecución y de la ejecución completa,
- el precio ejecutado y la cantidad ejecutada,
- cualquier código de error o actualizaciones faltantes.
Luego calcula algunos resúmenes en múltiples pruebas:
- Retraso de confirmación = hora de aceptación − hora de solicitud.
- Tiempo hasta la primera ejecución = hora de la primera ejecución − hora de solicitud (o − hora de aceptación, siempre que elija una definición).
- Desviación de ejecución = diferencia entre su precio límite y el precio ejecutado (direccionalmente y en términos absolutos).
- Integridad de la ejecución = (cantidad ejecutada ÷ cantidad solicitada) para cada orden, y la proporción de órdenes que terminan parcialmente ejecutadas.
Debido a que las condiciones del mercado pueden cambiar rápidamente, separe dos capas de evidencia:
- Evidencia del comportamiento del sistema: si los retrasos, rechazos y actualizaciones faltantes ocurren a tasas predecibles o estables bajo condiciones comparables.
- Evidencia de mercado y costos: si las diferencias de ejecución pueden explicarse por la liquidez cambiante y los costos de transacción, en lugar del manejo de la API.
También debe mantener explícitas las suposiciones. Por ejemplo, si su prueba utiliza la misma configuración de tiempo en vigor o el mismo tipo de orden, anótelo; de lo contrario, la interpretación de la aceptación y las ejecuciones parciales se vuelve ambigua.
Limitaciones y modos de fallo a considerar
Incluso cuando las mediciones se ven bien, la calidad de ejecución no es totalmente predecible. Las limitaciones materiales comunes incluyen:
- Modo de fallo: órdenes rechazadas o con tiempo de espera agotado. Un sistema puede ser rápido cuando funciona, pero aun así tener tasas de rechazo inaceptables cuando cambian la carga o la conectividad. - Modo de fallo: datos de mercado obsoletos o inconsistentes. Si su aplicación basa sus decisiones en datos que se retrasan respecto al momento de la colocación de la orden, puede ver ejecuciones peores que no son solo un problema de “latencia”. - Modo de fallo: ejecuciones parciales y actualizaciones posteriores a la ejecución. Las ejecuciones parciales pueden ser precisas, pero si su aplicación rastrea incorrectamente la cantidad restante o maneja mal las secuencias de estado, su “calidad” de ejecución medida puede reflejar errores de lógica de software. - Limitación de medición: alineación de sellos de tiempo. Si compara sus sellos de tiempo locales con los sellos de tiempo reportados por la API sin comprender la sincronización del reloj, sus conclusiones sobre latencia pueden estar sesgadas. - Limitación de evidencia: el historial no garantiza el futuro.