Quieres tu propia plataforma de trading: por dónde empezar y quién la construye

Cuando alguien dice «quiero construir mi propia plataforma de trading», esa frase suele referirse a uno de tres productos distintos. Uno es un terminal al que entran tus propios clientes. Otro es el conjunto completo de sistemas que un bróker opera detrás de ese terminal. Otro es un exchange, con un matching engine en el centro. Comparten vocabulario y casi nada más, y el trabajo que implican difiere enormemente entre ellos.

Así que el primer paso no es elegir una tecnología, un lenguaje o un proveedor. Es decidir cuál de los tres necesitas primero y qué personas lo usarán el primer día. Todo lo demás —el presupuesto, los plazos, la forma del equipo, el tipo de empresa que debería construirlo— se deriva de esa única decisión.

¿Qué se quiere decir en realidad con «nuestra propia plataforma de trading»?

Detrás de esa frase se esconden tres productos. Nombrar el tuyo en voz alta es la decisión más barata que vas a tomar, porque cambia el tamaño del proyecto más que ninguna otra.

• Un terminal de trading. La pantalla que usan tus clientes: precios, gráficos, boleta de órdenes, posiciones, saldos, histórico. Se conecta a un bróker, a un mercado o a un exchange que ya existe. Estás construyendo la experiencia, no el mercado
• Un stack de bróker. Todo lo que hay detrás de esa pantalla: cuentas de clientes, entradas y salidas de dinero, límites de riesgo, enrutamiento de órdenes a los mercados a los que tienes acceso, conciliación al cierre del día y los informes que pide tu regulador. El terminal es solo una parte
• Un exchange. No envías órdenes a ningún otro sitio: eres el lugar donde se cruzan. Eso significa un matching engine, el software que empareja una orden de compra con una de venta. A su alrededor: el order book en vivo con las órdenes que esperan ejecución, los precios y las operaciones que se difunden a las firmas conectadas contigo, un mecanismo para mover el dinero y los activos una vez cerrada la operación, una forma de detectar prácticas abusivas y un reglamento que publicas y haces cumplir

En las conversaciones que mantiene amBrain, «exchange» acaba significando muchas veces el primer o el segundo punto. No es un fallo de vocabulario: las palabras se usan con ligereza en todas partes. Pero un terminal y un exchange son negocios distintos con licencias distintas, y construir primero el equivocado es el error más caro disponible en esta fase.

También existe un caso intermedio frecuente: ya usas una plataforma de terceros como MetaTrader y quieres pasar a tus clientes a algo propio. Eso suele ser el caso del terminal con una migración encima: cuentas existentes, hábitos existentes y un periodo con los dos sistemas en el aire a la vez.

Un exchange de cripto es el tercer producto, con un conjunto distinto de problemas alrededor. El matching engine, el libro de órdenes y el feed de datos de mercado son el mismo tipo de trabajo. Lo que cambia es todo lo que los rodea: guardar el dinero de los clientes en wallets en lugar de en un banco, mover activos hacia y desde cadenas que tienen sus propias caídas y comisiones, y un panorama de licencias que cambia según el país y según el año. Quien haya construido un matching engine puede construir el tuyo; pregunta aparte quién se ocupa de la custodia y de la parte on-chain.

¿Cómo sé cuál de los tres necesito primero?

Respóndelo por usuario, no por funcionalidad. Escribe quién será la primera persona que use el sistema, un día concreto, para hacer algo concreto. Si esa persona es tu cliente lanzando una operación, necesitas un terminal. Si es tu propio equipo de operaciones recibiendo dinero, comprobando límites y enrutando órdenes, necesitas el stack de bróker. Si es otra firma que se conecta contigo para operar contra otros miembros, necesitas un exchange.

Casi nadie necesita los tres a la vez, y casi todo el mundo acaba creciendo a partir de uno de ellos. Empezar por la pieza que toca antes a un usuario real te da algo que probar y que vender mientras el resto sigue siendo un plan.

¿Qué hay que decidir antes de que nadie escriba código?

Cinco preguntas. No son preguntas técnicas y no hace falta formación en ingeniería para responderlas. Una empresa que empieza a construir sin tenerlas por escrito está adivinando, y esa adivinanza la pagas tú más adelante.

• ¿Qué se opera y de dónde viene? Acciones, futuros, divisas, cripto o varias cosas a la vez. Nombra los brókeres, exchanges o proveedores de liquidez concretos a los que ya puedes conectarte, o aquellos con los que estás negociando. Esto decide más trabajo que cualquier otro punto de la lista
• ¿Quiénes son los usuarios y cuántos? Clientes retail desde el móvil, traders profesionales en mesa o tu propio personal. Cien personas o cien mil. Diez usuarios que operan constantemente son un sistema distinto de diez mil que operan una vez al mes
• ¿Cuánta velocidad necesita de verdad? Muchas plataformas solo tienen que parecer instantáneas para una persona, un objetivo cómodo. Unas pocas tienen que competir con otras máquinas, un objetivo mucho más difícil y más caro. Responde con honestidad: pagar por una velocidad que no necesitas es una forma clásica de quemar el presupuesto
• ¿Ante qué regulador respondes y dónde? El país en el que operas decide qué debes registrar, qué debes reportar, cuánto tiempo lo conservas y qué puedes mostrar a quién. Las licencias y los acuerdos de market data van a su propio calendario, y ningún equipo de ingeniería puede acelerarlos
• ¿Quién lo mantiene funcionando de noche? Un sistema de trading no se entrega una vez y se deja solo. Los mercados abren mientras duermes, los feeds se caen, los mercados cambian algo sin avisar. Decide ahora si eso es tu equipo, el desarrollador bajo un acuerdo de soporte o alguien a quien todavía no has contratado

Esas cinco respuestas son tu brief. Entregadas a tres empresas distintas, producirán tres propuestas comparables. Sin ellas, recibirás tres presentaciones comerciales que no se pueden comparar de ninguna manera.

¿Construirla, comprarla o alquilarla?

Hay tres caminos hasta una plataforma en funcionamiento, y el correcto depende de cuánto de tu negocio vive dentro del software. Esto es lo que te da cada uno, lo que te quita y cuándo es la decisión acertada.

• Alquilar una plataforma white-label. Ganas: el arranque más rápido, servidores que opera otro y un coste mensual conocido. Cedes: el aspecto y el flujo de trabajo están prácticamente fijados, tus datos viven en casa del proveedor y marcharte después es un proyecto en sí mismo. Es lo adecuado cuando: estás probando la demanda, necesitas estar en el aire pronto y nada de tu oferta depende de que el software sea distinto
• Comprar o licenciar una plataforma existente y configurarla. Ganas: un producto maduro con funcionalidades que tardarías años en escribir, y margen para ajustarlo. Cedes: vives dentro del roadmap de otro, la configuración es trabajo de verdad y la integración con tus propios sistemas suele ser la parte difícil. Es lo adecuado cuando: tu negocio es estándar para tu mercado y tu diferencia está en el precio, el servicio o el alcance
• Construir una plataforma a medida. Ganas: exactamente el flujo de trabajo que quieres, sistemas que encajan con tu forma real de operar y la propiedad del resultado. Cedes: tiempo hasta la primera versión y la obligación de mantenerla viva después. Es lo adecuado cuando: el software es el producto, una plataforma existente bloquea algo central de tu negocio, o tu velocidad, tus instrumentos o tus reglas no encajan con lo que hay en el mercado

Muchas plataformas acaban siendo mixtas. Un bróker alquila para lanzar y luego construye esa pieza por la que los clientes lo eligen de verdad. Un exchange licencia los sistemas periféricos y construye él mismo el matching engine, porque es la parte que no puede permitirse que se comporte como la de los demás. Dividir la decisión por componente suele ser más inteligente que responderla una sola vez para todo el proyecto.

¿Cuánto cuesta y cuánto tarda?

amBrain no pone precio a este tipo de trabajo antes de que exista el alcance, y un precio que se da sin haber escuchado tus respuestas a las cinco preguntas de arriba vale poco. La misma frase —«una plataforma de trading»— cubre productos que se diferencian en un orden de magnitud en tamaño. Una cifra dada antes de que exista el alcance es una cifra comercial, no una estimación.

Lo que sí es útil es saber qué decisiones mueven la cifra, porque son las palancas que de verdad controlas:

• Cuál de los tres productos es. Un terminal sobre un bróker existente, un stack de bróker completo y un exchange con matching engine son tres tamaños de proyecto distintos
• Cuántas conexiones externas. Cada bróker, mercado o proveedor de liquidez al que te conectas tiene su propio protocolo, sus propias rarezas y su propio proceso de certificación. La segunda conexión cuesta menos que la primera; la décima sigue costando
• Cuántas clases de activos. Añadir una segunda rara vez es un cambio pequeño. Otra clase de activo trae otros contratos, otras reglas sobre cuánto dinero debe mantener el cliente contra una posición y otro proceso para liquidar la operación una vez cerrada
• El objetivo de velocidad. Entre parecer instantáneo para una persona y competir con otras máquinas hay una enorme cantidad de ingeniería
• Regulación y reporting. Las pistas de auditoría, la conservación de registros, los informes a clientes y las evidencias que espera un regulador son parte real del desarrollo, no papeleo del final
• Cuántos usuarios y con qué horario de soporte. Atender una mesa de traders y atender cien mil cuentas retail son sistemas distintos y costes de operación distintos
• Qué clientes atiendes. Web, móvil, escritorio: cada uno es una superficie aparte que hay que construir y mantener actualizada
• Migración. Mover cuentas activas, saldos e histórico desde una plataforma existente sin interrupciones suele ser más grande que todas las funcionalidades nuevas que entusiasman a todo el mundo
• Derechos sobre el market data. Qué puedes mostrar, a quién y con cuánto retardo es un acuerdo comercial que condiciona el producto

Los plazos se mueven con las mismas palancas, más dos que no controlas: las licencias y las ventanas de certificación que fijan tus mercados y brókeres. Una propuesta que promete una fecha sin nombrar esas dependencias no las ha mirado.

La palanca más barata es el alcance. Recortar la primera versión a un mercado, una clase de activo y un grupo de usuarios suele ahorrar más dinero que cualquier decisión técnica posterior.

¿Qué empresas construyen matching engines y plataformas de trading, y cómo compruebo que una es seria?

Existen tres tipos de proveedores y es fácil confundirlos porque usan las mismas palabras. Los vendedores de plataforma te licencian su propio producto. Los proveedores white-label operan su plataforma para ti bajo tu marca. Las empresas de ingeniería construyen un sistema que pasa a ser tuyo. Los tres cogerán el teléfono cuando digas «quiero una plataforma de trading», y solo uno está respondiendo a la pregunta que hiciste.

Si quieres algo hecho a medida —un terminal, un stack de bróker o un matching engine— pide estas pruebas antes que nada:

• Un sistema construido por ellos que esté en producción con dinero real pasando por él, con el cliente identificado o una explicación de por qué no se puede nombrar
• Quién opera hoy ese sistema y qué pasa cuando se rompe a las tres de la madrugada
• Un recorrido por algo que funciona. Una demo en vivo de un sistema real dice más que cualquier diapositiva
• Qué te van a entregar: el código, las instrucciones de compilación, los pasos de despliegue, la documentación, y si algo del sistema sigue siendo suyo
• Cómo han gestionado la caída de un mercado o de un feed, con un incidente concreto descrito
• Quién de su equipo ha hecho esto antes, y si esas personas estarán en tu proyecto o solo en la propuesta

Después, escucha lo que te preguntan. Una empresa capaz de construir esto no aceptará tu brief tal cual: lo interrogará antes de presupuestar.

• A qué mercados, brókeres o proveedores de liquidez ya tienes acceso y en qué punto están los acuerdos
• Qué hacen tus usuarios durante el día y a cuál de los tres productos te refieres en realidad
• Qué significa velocidad para tu negocio, expresado como algo medible y no como «rápido»
• Ante qué regulador reportas y qué evidencias te exige
• Qué pasa cuando parte del feed de precios desaparece o un mercado rechaza una orden: los casos poco lucidos que deciden si una plataforma se gana la confianza
• Quién será el propietario del sistema y quién lo operará un año después del lanzamiento

Dónde encaja amBrain en todo esto

amBrain es una empresa de ingeniería en Ereván, Armenia. amBrain desarrolla software desde 2019.

amBrain construyó el terminal de trading de Spectre Trade.

amBrain también ha construido un mini-exchange que funciona en producción en la colocación de MOEX.

Si tu pregunta es qué empresas construyen matching engines, esta es la parte de la lista en la que trabaja amBrain: amBrain es una empresa de desarrollo de software especializada en plataformas de trading, matching engines, sistemas de real-time bidding y desarrollo de plataformas de casino.

Las partes donde la velocidad importa están escritas en Rust. Aquí hay dos números, medidos en las rutas que construye amBrain. Latencia de market data <5 ms: es lo que tarda un cambio de precio en llegar a la pantalla o al sistema que lo espera. Latencia de riesgo <1 ms: es lo que tarda la comprobación que decide si una orden puede pasar antes de salir al mercado. Ambas cifras describen las rutas que construimos, no ninguno de los sistemas mencionados arriba en concreto.

Trabajamos en tres formatos: entrega completa, donde construimos y entregamos el sistema terminado; un equipo dedicado que trabaja en tu producto y en nada más; o nuestros ingenieros integrados en un equipo que ya tienes. El producto y el código quedan en manos del cliente, salvo los componentes reutilizables propios de amBrain.

Si estás al principio de esto, el siguiente paso útil no es buscar proveedores. Es escribir en una sola página las respuestas a las cinco preguntas de arriba. Con esa página, la conversación con cualquier desarrollador —nosotros o quien sea— empieza por lo que necesitas y cómo se puede construir, en vez de por la demo de algo que se construyó para otro.