Definir el producto y el ciclo de la orden
Determine primero a quién sirve la plataforma y qué pasos realiza. Un terminal informativo, un producto de entrada de órdenes y un sistema que las dirige a una contraparte tienen fronteras diferentes. Siga la ruta desde la cotización hasta entrada, controles, envío, confirmación, ejecución parcial, modificación, cancelación y liquidación o exportación. Para cada estado indique quién puede crearlo y quién confirma que es definitivo. Aceptado no significa necesariamente ejecutado. Usuarios y soporte deben ver la diferencia, y el dueño del proceso de negociación ha de confirmar su significado. Incluya la interrupción de conexión cuando el resultado de la orden sigue desconocido.
Documente reglas para tipos de orden, vigencia, moneda, cantidad, redondeo y corrección. Las funciones y obligaciones normativas concretas dependen del producto, mercado y jurisdicción; no se deducen de una guía técnica general. Decida si la plataforma posee cartera, saldo disponible y libro interno o si los consulta en otro sistema. Una operación puede seguir abierta en varios sistemas a la vez. Por eso necesita un identificador estable y un estado explicable, no solo el último mensaje mostrado en el navegador. Nombre quién resolverá una discrepancia entre vista interna y contraparte.
Separar datos de mercado de decisiones de negociación
Un flujo de cotizaciones tiene fuente, licencia, frecuencia, marcas de tiempo y reglas para datos retrasados o inválidos. Los usuarios deben saber si el precio mostrado es actual o diferido. Defina qué ocurre si se pierde el flujo: detener la entrada de órdenes, mostrar el último valor claramente marcado o cambiar de fuente mediante una regla aprobada. No considere verdad comercial lo que el navegador consiguió dibujar. El servicio de datos debe detectar duplicados, errores de orden, intervalos ausentes y cambios sospechosos que indiquen mala calidad. Asigne dueño y decisión de uso a cada advertencia de calidad.
Los datos históricos para gráficos y los utilizados al decidir pueden tener fuentes o necesidades de precisión distintas. Cuando el producto exija explicaciones, registre fuente y momento del valor relevante en una acción importante. Con varios proveedores establezca reglas para cambiar de uno a otro y resolver discrepancias. Sus licencias pueden limitar almacenamiento o visualización; compruebe el contrato antes de diseñar la caché. Pruebe un salto brusco, interrupción y corrección tardía. Un gráfico fluido no debe ocultar valores ausentes o estimados. Muestre la incertidumbre de forma comprensible en lugar de esconderla con continuidad visual.
Asignar dueño a los controles previos a negociar
Antes del envío indique los controles necesarios: autorización del cliente, disponibilidad del instrumento, límites de cantidad y valor, parámetros válidos y quizá cobertura suficiente. La lista exacta depende del producto y las responsabilidades de la empresa. Distinga el control realizado en su sistema de una regla de la contraparte; superar el primero no garantiza aceptación por la segunda. Estado y motivo de rechazo deben ser comprensibles y rastreables. Los controles no deberían leer copias desactualizadas del mismo límite sin decidir cuál es autoritativa. Las órdenes simultáneas requieren especial atención a reservar fondos o capacidad. Compruebe si dos operaciones pueden parecer válidas cuando solo una debería seguir.
Versione las reglas de riesgo y apruebe los cambios según su impacto. Si un operador modifica un límite, registre quién, por qué, cuándo y a qué casos afecta. Decida qué sucede si falla el servicio de control: según la política de seguridad elegida, detenga o aplace la acción en vez de saltarse silenciosamente la protección. Pruebe valores extremos, monedas, vigencias y solicitudes repetidas. Cambiar una regla puede afectar más al negocio que modificar una pantalla, así que necesita publicación y retorno propios. Conserve evidencia de qué versión evaluó cada orden.
Crear una integración que entienda orden y reintentos
Un protocolo con la contraparte puede tener identificadores, secuencias, confirmaciones y recuperación de conexión propios. FIX Trading Community describe la sesión FIX como una secuencia ordenada de mensajes que puede reanudarse; el uso concreto depende de la entidad conectada. Separe el estado comercial de una orden del estado técnico de la conexión. Perder un socket no equivale automáticamente a rechazar una operación. Tras recuperar, compruebe qué mensajes recibió el otro lado y en qué orden. Vincular la acción del usuario a una sola respuesta sin registro interno crea incertidumbre peligrosa ante un timeout. Defina qué verá soporte durante ella.
Cada operación modificadora debe tener un identificador estable para que un reintento no cree otra orden. El patrón de consumidor idempotente de Microsoft muestra por qué la entrega repetida no tiene por qué producir efectos repetidos. Guarde las relaciones entre ID interno, ID de la contraparte y mensajes de cambio de estado. Defina cómo gestionar confirmación tardía, ejecución duplicada y corrección manual. Un adaptador debe traducir el protocolo, no decidir silenciosamente su significado comercial. Si conecta varias contrapartes, convierta sus distintos estados en un modelo común sin perder los detalles originales. Concilie estas correspondencias con mensajes observados antes de declarar completa la interfaz.
Incluir auditoría y conciliación en el flujo
Conserve la secuencia necesaria para explicar una orden: instrucción inicial, parámetros aceptados, resultado de controles, mensaje enviado, confirmación, ejecuciones y correcciones. Cada registro de auditoría necesita tiempo, fuente y relación con el caso. Limite el acceso según rol y sensibilidad. No hace falta copiar todos los datos personales a cada registro técnico. Operaciones necesita conocer lo sucedido y el siguiente paso; auditoría, prueba del cambio y su aprobación. Ambas vistas pueden utilizar los mismos eventos sin exponer igual detalle. Verifique que diferencias de reloj entre sistemas no vuelvan engañosa la secuencia.
La conciliación compara el estado interno con registros de la contraparte y, si procede, la liquidación. Establezca frecuencia y tolerancia para diferencias de cantidad, importe o estado. Las excepciones no deben desaparecer en un número agregado. Cada una necesita responsable, plazo y corrección registrada. Vigile órdenes con resultado desconocido, ejecuciones parciales y cambios después del cierre. Una intervención manual debe generar un evento nuevo y rastreable, no sobrescribir la historia. Pruebe la conciliación con discrepancias introducidas deliberadamente, no espere a un defecto real. Informe cuántas siguen abiertas y desde cuándo.
Medir el rendimiento de todo el recorrido
Defina expectativas de respuesta separadas para mostrar datos, confirmar recepción de una orden y ofrecer resultado final. El tiempo en navegador, cola interna y contraparte se suma, pero cada parte tiene dueño distinto. OpenTelemetry describe trazas distribuidas que siguen una operación entre servicios. Conserve identificadores de correlación y diagnósticos depurados de información sensible. Observe percentiles, profundidad de colas y casos de estado desconocido, no solo promedios. Mejorar una respuesta de API aporta poco si el procesamiento posterior tarda minutos sin avisar. Explicite la frontera medida y el periodo de observación al hablar de latencia.
Pruebe picos previstos, fallo del flujo de precios, lentitud de la contraparte, reconexión y órdenes simultáneas frente al mismo límite. Bajo carga deben mantenerse correctos estado y auditoría; velocidad sin corrección no sirve. Separe trabajo que puede esperar de controles que deben detener otra acción. Defina límites de cola y un plan para procesar casos acumulados tras recuperarse. Ajuste la capacidad según medidas, no según impresiones de arquitectura. La vista de soporte debe mostrar si el problema afecta datos, controles, conexión o resultado. Un ensayo de incidente revelará métricas ausentes.
Hacer reversibles los lanzamientos y explicable la operación
Ensaye un cambio con un grupo limitado de usuarios, instrumentos u operaciones si las reglas lo permiten. Defina antes las condiciones de parada: estados incorrectos, diferencias inexplicadas, más rechazos o retraso. Volver a una versión anterior debe tener en cuenta datos y órdenes creados desde su despliegue. Ensaye la restauración y compruebe que los ID internos y de contraparte siguen relacionándose. Programe publicaciones fuera de periodos críticos cuando sea posible, pero el bajo volumen no sustituye las pruebas. Cambios de reglas y adaptadores necesitan aprobadores identificados. Registre qué versión trató cada orden durante una implantación gradual.
Una guía operativa debe explicar cómo seguir una orden, distinguir la desconexión del rechazo comercial y escalar diferencias. Supervise calidad de precios, edad de colas, resultados de controles, conexión y excepciones abiertas. Una alerta sin respuesta acordada es ruido. Durante un incidente conserve pruebas y comunique al usuario un estado legible. Tras recuperarse analice la causa y añada la prueba correspondiente. La arquitectura solo está lista cuando puede operarla un equipo ajeno a la implementación. Compruébelo pidiéndole que diagnostique un fallo simulado con las vistas e instrucciones disponibles.
Lista para decidir la arquitectura
Antes de construir confirme límites del producto, ciclo de orden, dueños de datos, reglas de riesgo, contratos de integración y fuente de datos de mercado. Para cada operación importante describa resultado desconocido, reintento y conciliación. Establezca medidas de corrección y respuesta, escenarios de prueba y condiciones de cambio. Comience con una ruta comprobable desde la entrada hasta el resultado registrado. Si la mayor incertidumbre está en la contraparte, pruebe primero su comportamiento real en lugar de construir una amplia interfaz interna alrededor de una hipótesis sin validar. El primer hito debe ser pequeño para descubrir pronto un modelo equivocado.
EXCOIN puede diseñar una plataforma o capa de integración concreta, pero no prometer latencia, cumplimiento normativo o resultados de negociación sin conocer mercado, producto y entidades conectadas. Un diseño sólido tiene límites claros y demuestra corrección tanto en órdenes fallidas como satisfactorias. El primer hito debe entregar modelo de estados, contratos de datos, pruebas y una ruta verificada. El alcance posterior sigue el rendimiento medido y las excepciones descubiertas. Así la inversión se basa en comportamiento real, no en una lista prematura de tecnologías. Registre los supuestos que obligarían a rediseñar si resultan falsos.