Cómo evaluar un feed de precios para un bróker

Empiece por el precio, no por la lista de proveedores

La primera pregunta no es «¿Cuántas fuentes son compatibles?», sino «¿Cómo debe formarse el precio de este símbolo?».

Elija algunos casos representativos:

• un instrumento sencillo de una fuente institucional;
• un símbolo que requiere el consenso de varias fuentes;
• un instrumento con un orden estricto de fuentes de respaldo;
• un cruce sintético;
• un símbolo con precios especiales para fines de semana o sesiones; y
• un mercado en el que un tick anómalo tendría un coste elevado.

Para cada caso, describa el resultado esperado en lenguaje sencillo. Es una evaluación mucho más útil que marcar casillas en una larga lista de conectores.

1. Evalúe las entradas

Pregunte qué categorías de fuentes pueden incorporarse al mismo feed:

• liquidez institucional FIX;
• datos directos de mercados;
• mercados de referencia independientes;
• precios de su propia plataforma o puente; y
• fuentes propias o aportadas por el cliente.

Después, pregunte cómo se conserva la identidad de cada fuente. ¿Puede un símbolo usar una mediana mientras otro utiliza una fuente principal y otra de respaldo concretas? ¿Puede el mismo instrumento de mercado asignarse a los nombres de símbolos que ya emplean sus sistemas?

Confirme quién se responsabiliza de las cuentas de acceso a los mercados, las credenciales, los derechos de uso de los datos y la disponibilidad de los instrumentos. Disponer de un conector no concede permiso para utilizar los datos de un mercado.

Consulte cómo aborda CoinPriceFeeds las fuentes de datos de mercado .

2. Evalúe el control de precios

Pregunte quién puede cambiar:

• prioridad de las fuentes o método de agregación;
• márgenes;
• spreads mínimos y máximos;
• precisión y redondeo;
• la lista de símbolos publicados;
• horarios de días laborables o sesiones; y
• controles de movimiento o de huecos.

Compruebe si cada cambio requiere una solicitud de soporte o un despliegue de software. Si el cliente puede realizar cambios, confirme cómo se gestionan los datos no válidos y si la última configuración operativa permanece activa.

Pregunte también cómo puede el equipo confirmar qué reglas están activas en cada servidor. Una revisión anotada en una hoja de cálculo no sirve como prueba si el feed de producción ha cargado otra configuración.

Consulte el motor de precios controlado por el cliente .

3. Pruebe el comportamiento ante fallos

Una demostración con todas las fuentes operativas solo prueba el caso más sencillo.

Pida al proveedor que explique:

1. ¿Qué sucede cuando una fuente publica un salto anormal grande?
2. ¿Qué sucede cuando un mercado retira explícitamente una cotización?
3. ¿Qué ocurre cuando una conexión permanece abierta, pero dejan de llegar precios?
4. ¿Qué ocurre cuando una actualización antigua llega después de otra más reciente?
5. ¿Qué ocurre con los símbolos sintéticos o agregados que dependen de la entrada fallida?
6. ¿Puede salir del sistema una cotización con valor cero, negativo o no finito, o una cotización cruzada?
7. ¿Cómo puede un operador autorizado del cliente consultar y restablecer un estado protegido?

La respuesta debe distinguir entre estos casos. «Tenemos conmutación por error» es demasiado general.

Revise protección de cotizaciones antes de diseñar la prueba.

4. Evalúe la ruta de entrega

Elija el protocolo más sencillo que se adapte al sistema de destino.

Un flujo sencillo basado en líneas puede ser ideal para un bridge bajo su control. FIX puede encajar mejor con una plataforma o un flujo de liquidez que ya utilice sesiones de datos de mercado.

Confirme:

• quién inicia la conexión;
• cómo funcionan la autenticación y la rotación de credenciales;
• si las suscripciones son por consumidor;
• cómo se representa la señal de mantenimiento de la conexión;
• si un consumidor lento puede bloquear a otros;
• qué sucede después de reconectarse;
• cuántos consumidores concurrentes se esperan; y
• si los endpoints principal y de respaldo se comportan de la misma manera.

No se conforme con una afirmación genérica de «compatibilidad con la plataforma». Pregunte si el proveedor suministra un complemento nativo, se conecta a su bridge actual o facilita un protocolo para que su equipo realice la integración.

Vea opciones de entrega e integración .

5. Haga que la redundancia sea comprobable

Un segundo nombre de host no es suficiente.

Pregunte si los feeds principal y de respaldo:

• funcionan al mismo tiempo;
• consumen las mismas entradas efectivas;
• muestran la versión de las reglas de precios que han cargado;
• pueden ser comparados símbolo por símbolo;
• conservan el estado de precios durante los reinicios rutinarios;
• utilizan rutas de red y DNS suficientemente independientes; y
• se prueban antes de una conmutación por error en producción.

Decida quién realiza la conmutación por error y cómo se ensaya. El proveedor puede mantener ambos enlaces listos mientras el bridge del cliente decide cuándo cambiar.

Consulte el diseño de feeds redundantes .

6. Mire más allá de «en línea»

Una monitorización útil del feed debe responder a estas preguntas:

• ¿Están llegando las cotizaciones de las fuentes?
• ¿Se están produciendo los precios del cliente?
• ¿Cuándo fue la última entrega de cada feed?
• ¿Están conectados los consumidores?
• ¿El retraso está en las fuentes, en el procesamiento o en la ruta de envío?
• ¿Se están invalidando las fuentes?
• ¿Coinciden el feed principal y el de respaldo?
• ¿Es la actividad inusualmente baja para este momento de la semana?

Pregunte qué señales pueden incorporarse a su propia monitorización y cuáles permanecen visibles únicamente para el proveedor.

Consulte monitorización y verificación .

7. Revise el acceso del cliente y los límites de los cambios

Identifique a todas las personas que necesitan inspeccionar el feed y a quienes deben tener permiso para modificarlo.

Un modelo adecuado separa los permisos de lectura y escritura, protege las acciones en el navegador frente a solicitudes no autorizadas, registra los cambios con privilegios y permite al cliente retirar accesos cuando cambia su personal.

Pregunte si una interrupción en un servicio externo de permisos podría bloquear a todos los usuarios existentes y si las fuentes privadas están aisladas entre las cuentas de distintos clientes.

Lea la visión general de seguridad y acceso .

8. Acuerde el modelo operativo

Aclare las responsabilidades de ambas partes:

No utilice un porcentaje de disponibilidad sin contexto como sustituto de estas respuestas.

9. Solicite pruebas

Entre las pruebas útiles se encuentran:

• una vista representativa de las reglas;
• una vista del panel con una fuente protegida o no válida;
• una comparación de la configuración del feed principal y el de respaldo;
• muestras simultáneas de cotizaciones de ambos endpoints;
• un cliente de referencia que complete el handshake real;
• una desconexión y recuperación deliberada;
• un ejemplo de fallo de validación que deje las reglas antiguas activas; y
• un registro claro de cambios tras una acción privilegiada.

Un proveedor de calidad debe poder explicar qué demuestran esas pruebas, no limitarse a mostrar una pantalla en verde.

10. Defina el alcance con suficiente detalle y deténgase ahí

La fase de evaluación debe confirmar que el producto encaja. Los umbrales detallados, las asignaciones FIX, los parámetros de conexión, las credenciales y las condiciones del despliegue se acuerdan durante la incorporación técnica.

Ese límite protege a ambas partes: el cliente recibe los detalles necesarios para integrar el servicio, mientras que la información operativa sensible y específica del cliente no se convierte en una guía pública de implementación.