Guía del modelo operativo
¿Feed personalizado gestionado, fuente directa o sistema interno?
El modelo adecuado depende de las responsabilidades que quiera asumir su bróker. Una fuente directa aporta datos; la relación con un LP aporta precios y, posiblemente, liquidez; un sistema interno deja toda la operación en manos de su equipo; y un feed personalizado gestionado proporciona una capa de precios y entrega específica para el cliente.
- Compare la responsabilidad operativa, no solo la tarifa de conexión.
- Distinga los datos de origen de la política de precios y la entrega a plataformas.
- Considere con normalidad los diseños híbridos cuando encajen con el negocio.
No son opciones excluyentes
Tanto un feed gestionado como uno interno pueden utilizar API directas, precios de LP y fuentes del cliente como entradas.
La diferencia está en las responsabilidades
Decida quién construye, monitoriza, protege, modifica y verifica todo el recorrido.
Primero, la adecuación
El mejor modelo responde a su política de precios, equipo, plataformas, derechos sobre las fuentes y necesidades de continuidad.
En esta página
Un feed personalizado gestionado resulta especialmente útil cuando un bróker quiere controlar su política de precios sin tener que construir y operar por su cuenta todos los conectores, cálculos, protecciones, métodos de entrega, sistemas de respaldo y componentes de monitorización. Una API directa, el feed de un LP o un sistema interno pueden ser mejores opciones cuando el requisito es más limitado o el bróker decide asumir una parte mayor de ese trabajo.
Estas opciones pertenecen a capas diferentes
Estas alternativas suelen presentarse como productos de datos que compiten entre sí, pero no pertenecen al mismo nivel.
- Una API directa de un mercado o una fuente de referencia es una interfaz de entrada.
- El feed de un proveedor de liquidez forma parte de una relación comercial de precios y, posiblemente, de ejecución.
- Un sistema interno es un modelo operativo en el que el bróker construye y gestiona todo el recorrido de los precios.
- Un feed personalizado gestionado es un modelo operativo en el que un especialista gestiona una capa de precios y entrega específica acordada con el cliente.
Un sistema gestionado o interno puede consumir API directas y feeds de LP. El bróker también puede mantener una fuente o un cálculo propio en el centro de cualquiera de los dos modelos. Por tanto, la decisión consiste en definir límites y responsabilidades, no en declarar que un tipo de fuente es siempre mejor.
Una comparación neutral
Deslice o desplácese horizontalmente para ver todas las columnas
| Modelo | Encaja bien cuando | El bróker suele asumir | Principal aspecto que debe examinar |
|---|---|---|---|
| API directa o feed de un mercado | Una o varias fuentes deben incorporarse a una infraestructura técnica existente | Conector, normalización, reglas de precios, protección, entrega, monitorización y continuidad | Si el sistema interno ya cubre el resto del recorrido |
| Feed directo de un LP | El bróker quiere los precios del LP y, posiblemente, su liquidez ejecutable dentro de esa relación | Selección comercial, integración con la plataforma, políticas entre fuentes, controles posteriores y decisiones sobre el respaldo | Si la visión de un solo LP debe ser la base del precio para el cliente |
| Sistema de precios interno | El bróker quiere controlar por completo el diseño y la operación, y puede mantener el equipo necesario a largo plazo | Software, infraestructura, integraciones de fuentes, cambios, respuesta a incidentes, verificación y documentación | La responsabilidad total a largo plazo, incluido el trabajo rutinario y excepcional |
| Feed personalizado gestionado | El bróker necesita reglas específicas y varias opciones de entrega sin operar todo el servicio | Política de negocio, derechos sobre las fuentes, aprobaciones, plataforma del cliente y escalado interno | Adecuación del proveedor, transparencia, límites de los cambios, integración y soporte acordado |
| Híbrido | Los componentes internos o de proveedores existentes aportan valor, pero no cubren todo el requisito | El límite elegido para cada componente | Si las responsabilidades y el comportamiento ante fallos quedan claros entre los sistemas |
Ninguno de estos modelos garantiza por sí solo la calidad. En todos ellos hacen falta pruebas de que las fuentes, los precios, la protección, la entrega y el proceso operativo cumplen los requisitos del bróker.
Cuándo basta con una API directa
Una API directa puede ser una solución sencilla cuando el bróker ya dispone de un servicio que:
- se conecta y reconecta de manera segura;
- asigna instrumentos y estados de las fuentes;
- determina qué cotizaciones son válidas;
- forma el precio previsto para el cliente;
- aplica reglas comerciales y de protección;
- distribuye el resultado a cada plataforma de destino;
- proporciona monitorización y respaldo; y
- tiene personas responsables de los cambios e incidentes.
También puede ser adecuada para una necesidad limitada de datos de referencia, cuando el cliente no necesita un feed de salida gestionado.
La API no suele resolver por sí sola todas esas decisiones. Solo describe cómo recibir los datos. El bróker sigue necesitando el derecho contractual para utilizarlos con la finalidad prevista.
Cuándo basta con el feed de un proveedor de liquidez
El feed de un LP puede ser la fuente principal natural cuando el bróker quiere utilizar la visión de mercado de ese proveedor y, cuando se haya acordado, su liquidez ejecutable.
Usarlo directamente puede ser apropiado cuando:
- la relación con el LP está destinada a definir el precio;
- la plataforma ya lo integra bien;
- los símbolos y sesiones requeridos están cubiertos;
- la política comercial de spreads se gestiona en el sistema existente; y
- el bróker tiene un modelo aceptable de respaldo e incidentes.
El feed de un LP también puede ser una fuente dentro de una política más amplia. Por ejemplo, puede seguir siendo la entrada preferida mientras otras fuentes independientes, de referencia o de respaldo, cumplen una función distinta. La guía de agregación de datos de mercado explica estos modelos.
CoinPriceFeeds no sustituye las relaciones del cliente con los mercados o los proveedores de liquidez, ni concede derechos de acceso a datos de mercado.
Cuándo tiene sentido un sistema interno
Desarrollar el sistema internamente puede ser la decisión estratégica adecuada cuando el bróker quiere que la tecnología de precios sea una capacidad propia esencial.
El caso es más sólido cuando la organización cuenta con:
- ingenieros con experiencia en datos de mercado e integración de plataformas;
- cobertura operativa para incidentes de fuente, fijación de precios, entrega e infraestructura;
- una manera controlada para que el personal de dealing y riesgo revise los cambios de precios;
- tiempo para atender los cambios de los mercados y los nuevos requisitos de las plataformas;
- diseño primario y de respaldo independiente;
- pruebas, monitorización y verificación de versiones; y
- una razón clara para preferir la propiedad total sobre un límite gestionado.
Un sistema interno puede ofrecer un control profundo y una estrecha integración con los sistemas propios. También hace responsable al bróker del mantenimiento habitual, la continuidad del equipo, la documentación, las actualizaciones de seguridad y los fallos poco frecuentes, no solo de conseguir la primera conexión.
Esa responsabilidad no es necesariamente una desventaja. Es, simplemente, parte de la inversión elegida.
Cuando un feed personalizado gestionado encaja
Un feed personalizado gestionado encaja entre un feed de fuente inflexible y una plataforma completamente interna.
Con CoinPriceFeeds, el bróker puede definir una política de fuentes y precios específica para el cliente, mientras CoinPriceFeeds opera las conexiones, los cálculos, la protección, la entrega, el panel y las funciones de verificación acordadas para el feed.
Este modelo puede ser útil cuando el bróker necesita:
- varias entradas institucionales, de intercambio, de referencia o propiedad del cliente;
- diferentes políticas de fuente para diferentes símbolos;
- markups, controles de spread, precisión y políticas programadas;
- protección de cotizaciones con motivos visibles;
- entrega a más de un consumidor mediante streaming o FIX;
- endpoints principal y de respaldo simultáneos; o
- una vista operativa común para los equipos de dealing, riesgos y tecnología.
El bróker mantiene la responsabilidad sobre sus decisiones de negocio, los derechos de uso de las fuentes, las aprobaciones autorizadas, la plataforma de destino y el escalado interno. El servicio gestionado no asume las funciones de dealing, riesgos, centro de ejecución ni toma de decisiones regulatorias del cliente.
Consulte cómo funciona CoinPriceFeeds para ver el recorrido completo del producto.
Compare todo el trabajo operativo
El cargo visible por suscripción o infraestructura es solo una parte de la comparación.
Deslice o desplácese horizontalmente para ver todas las columnas
| Área de trabajo | Preguntas para incluir en la decisión |
|---|---|
| Acceso a las fuentes | ¿Quién contrata con los mercados, gestiona los derechos de acceso, renueva las credenciales y responde a los cambios de las fuentes? |
| Ingeniería | ¿Quién construye los conectores, las asignaciones, los cálculos y la entrega a plataformas, y quién realiza las pruebas y actualizaciones? |
| Cambios de precios | ¿Puede el personal de dealing y riesgo revisar y cambiar la política de manera segura sin editar el código de la aplicación? |
| Protección | ¿Quién define, implementa, explica y restablece los estados de cotización anómalos o no válidos? |
| Continuidad | ¿Son suficientemente independientes los feeds principal y de respaldo, y cómo se comparan? |
| Monitorización | ¿Quién puede distinguir entre un retraso de la fuente, el estado del cálculo y un problema en la entrega al destino? |
| Operaciones | ¿Quién recibe las alertas, investiga los incidentes y comparte las pruebas entre los equipos? |
| Continuidad del personal | ¿Está el conocimiento documentado y disponible cuando no están el desarrollador o el dealer originales? |
| Riesgo de los cambios | ¿Cómo se demuestra que una nueva regla o versión no sustituirá un feed operativo por otro no válido? |
En un sistema interno, estos costes aparecen en la ingeniería, la infraestructura, las operaciones y el tiempo de gestión. En un feed gestionado, parte de ellos pasa a la tarifa del servicio y a la relación con el proveedor. Una comparación justa debe utilizar el mismo alcance en ambos casos.
Defina qué significa «control»
«Necesitamos control» puede referirse a varias cosas:
Deslice o desplácese horizontalmente para ver todas las columnas
| Tipo de control | Forma posible de proporcionarlo |
|---|---|
| Control del negocio | El bróker define las funciones de las fuentes, el objetivo de los precios, los spreads, los horarios y los permisos de aprobación |
| Control técnico | El bróker es propietario del software y del despliegue |
| Control operativo | El bróker decide quién puede cambiar el estado, activar la conmutación por error o recibir alertas |
| Control de los datos | Los derechos sobre las fuentes, las entradas privadas, los límites de acceso y los usos permitidos están claramente definidos |
| Pruebas | Los equipos pueden ver qué política está activa, por qué una cotización está protegida y si el feed de respaldo coincide |
Un modelo gestionado puede ofrecer un control sólido del negocio y de las pruebas sin que el cliente sea propietario de cada componente interno del servicio. Un modelo interno puede dar plena propiedad técnica, pero aun así necesita una interfaz de control útil para los equipos de dealing y riesgos.
El equilibrio adecuado depende de por qué se necesita el control.
Plantee las mismas preguntas sobre las pruebas en cada modelo
Tanto si el feed es gestionado como si es interno, pruebe:
- qué ocurre cuando una fuente cancela o se congela silenciosamente;
- si una actualización tardía puede reemplazar a una más reciente;
- cómo se gestiona una salida imposible o anómala;
- qué regla de precios está activa ahora;
- cómo se valida un cambio propuesto;
- si un consumidor lento afecta a otros;
- si los feeds principal y de respaldo han cargado la misma política;
- cómo se activa y ensaya la conmutación por error; y
- qué equipo se responsabiliza de cada acción de recuperación.
La guía para evaluar un feed de precios ofrece una lista completa que sirve tanto para seleccionar un proveedor como para diseñar un sistema interno.
Un modelo híbrido puede conservar lo que ya funciona
Un bróker no necesita reemplazar todos los componentes existentes para usar un feed gestionado.
Los límites posibles incluyen:
- mantener una relación LP establecida como la entrada preferida;
- publicar un precio propio del cliente en el flujo gestionado;
- utilizar el bridge existente del bróker para la entrega específica a la plataforma;
- enviar la misma salida gestionada a un consumidor de riesgo o reconciliación;
- conservar la lógica de conmutación por error del lado del cliente mientras el proveedor mantiene preparados ambos endpoints; o
- utilizar una API directa para una finalidad separada y un feed gestionado para formar los precios del cliente.
Lo importante es dejar el límite por escrito. Cada conexión debe tener un responsable, una respuesta prevista ante fallos y una forma de verificar el resultado.
Elija a partir de un requisito real
Una matriz de funciones puede ocultar la decisión. Empiece, en cambio, por un feed representativo:
- ¿Qué entradas deberían dar forma a EURUSD, XAUUSD u otro símbolo importante?
- ¿Quién debería poder cambiar su precio comercial?
- ¿Qué debería suceder cuando la fuente preferida se vuelva inadecuada?
- ¿Qué plataformas y consumidores internos necesitan la salida?
- ¿Qué pruebas hacen falta antes de la conmutación por error?
- ¿Qué partes quiere operar genuinamente su equipo?
Estas respuestas aclaran mucho el límite adecuado. Si un feed personalizado gestionado parece relevante, el proceso de incorporación por escrito explica cómo comprobar si encaja sin preparar de antemano una especificación completa.
Un feed adaptado a su configuración
Compare los modelos con un requisito real de su feed.
Envíenos sus fuentes, los responsables de los precios, los sistemas de destino y las limitaciones operativas actuales. Le explicaremos por escrito dónde encaja un feed personalizado gestionado y dónde podría no hacerlo.