Los módulos esenciales de un exchange de criptomonedas

El software de exchange de criptomonedas suele adquirirse como un único producto, pero lo que se entrega y se opera es un conjunto de módulos diferenciados, con modos de fallo distintos, exposición regulatoria distinta y consecuencias distintas en materia de propiedad. Tratar la plataforma como una compra indivisible tiende a ocultar las preguntas que más adelante determinan el coste, el control y la preparación para la autorización.

Este artículo expone los módulos que una plataforma de negociación necesita en la práctica, las preguntas que cada uno plantea a la dirección, la ingeniería y el área de cumplimiento, y los criterios que separan una arquitectura coherente de un simple conjunto de componentes. La perspectiva es de compra y planificación, no de implementación: qué debe existir, por qué importa y cómo se valora la integridad del alcance antes de seleccionar un proveedor.

Por qué el software de exchange se evalúa por módulos

Una plataforma de negociación es un negocio regulado sostenido por software, no una interfaz con precios. Cuando la plataforma se evalúa en bloque, las demostraciones se concentran en lo visible, mientras quedan sin examinar los componentes que determinan el resultado operativo y regulatorio. La evaluación por módulos invierte ese énfasis y pregunta qué partes existen, cuáles proceden de terceros y cuáles puede modificar el operador sin intervención del proveedor.

La distinción importa a cada responsable por un motivo diferente. Para la dirección general, las fronteras entre módulos determinan dónde se acumulan los costes recurrentes y qué relaciones con proveedores resultarán caras de abandonar. Para la dirección técnica, determinan qué puede modificarse, por parte de quién y con qué riesgo. Para cumplimiento, determinan dónde se originan los registros y si la evidencia puede presentarse cuando se solicita, en lugar de reconstruirse después.

El núcleo de negociación

El núcleo de negociación está formado por el motor de matching, la capa de gestión de órdenes y la distribución de datos de mercado que sostiene a ambos. El motor de matching aplica las reglas de prioridad de la plataforma y genera el registro de ejecución del que se deriva todo lo posterior. Su rendimiento y su comportamiento bajo carga fijan el techo de las ambiciones de producto, en especial si se contemplan derivados, ratios elevados de órdenes por operación o participantes profesionales.

La gestión de órdenes mantiene el estado de cada instrucción entre su recepción y su liquidación, aplica los límites de la plataforma y rechaza lo que debe rechazarse. La distribución de datos de mercado lleva el libro resultante y el flujo de operaciones a las interfaces y a los clientes de API. Estas tres partes se comentan a menudo como una sola, pero escalan de forma distinta y fallan de forma distinta, y en su frontera se resuelven la mayoría de las disputas de rendimiento.

Ledger y registro de saldos

El ledger es el registro fehaciente de lo que la plataforma debe a cada cliente y de lo que mantiene. Se distingue del saldo mostrado en la interfaz, que es una proyección del estado del ledger, y se distingue asimismo de las tenencias on-chain, que deben conciliarse contra él. Cuando estos tres niveles se confunden, las discrepancias se detectan tarde, normalmente en una conciliación o en una revisión y no en la operación ordinaria.

Una estructura de partida doble con asientos inmutables es la expectativa habitual, porque permite explicar cada saldo a partir de los asientos que lo produjeron. La pregunta útil en la compra no es qué tecnología de base de datos se emplea, sino si el ledger puede reconstruirse, conciliarse y evidenciarse con independencia de la aplicación que escribe en él.

Infraestructura de wallets y custodia

La infraestructura de wallets abarca la generación de direcciones de depósito, la construcción y difusión de transacciones, el seguimiento de confirmaciones y la separación entre tenencias calientes y frías. La aprobación de retiradas también pertenece aquí, y es un control operativo antes que una función técnica: quién aprueba, bajo qué condiciones y cómo queda registrada esa aprobación. Los esquemas multisig y la custodia de claves respaldada por hardware son las estructuras habituales, se operen internamente o a través de un custodio externo.

La elección entre operar wallets internamente o integrar un custodio modifica el perfil de riesgo, la posición aseguradora y la conversación regulatoria de la plataforma, y resulta difícil de revertir una vez que se mantienen activos de clientes. Es, por tanto, una decisión de arquitectura previa a la selección y no una opción de configuración aplazable a la fase de entrega.

Raíles fiat y conectividad de pagos

El depósito y la retirada en fiat conectan la plataforma con bancos y proveedores de pago, y es en este módulo donde los calendarios de lanzamiento se retrasan con más frecuencia. El requisito de software es comparativamente acotado: integración de proveedores de pago, asignación de depósitos, instrucción de retirada y conciliación entre los registros de pago y los asientos del ledger. El requisito comercial y regulatorio es mayor, porque las relaciones bancarias se conceden atendiendo al entorno de control de la plataforma y no a su tecnología.

Cuando una plataforma mantiene fondos de clientes en lugar de trasladarlos directamente a un socio de pagos, la normativa de servicios de pago y dinero electrónico pasa a afectar a la arquitectura y no solo a la solicitud de autorización; las cuestiones estructurales se detallan en la página de software de plataforma de dinero electrónico. Grumpio no salvaguarda fondos ni emite instrumentos de pago. La plataforma está estructurada para que las obligaciones del operador puedan evidenciarse.

Módulos de cumplimiento

Verificación de identidad, control AML y de wallets, mensajería de Travel Rule y monitorización de transacciones son módulos separados con flujos de datos separados, y son los que con más frecuencia se dan por supuestos en lugar de especificarse. La verificación decide quién es admitido. El control AML y de sanciones decide quién es admitido y en qué condiciones, y repite esa decisión de forma periódica. El tratamiento de Travel Rule regula qué acompaña a una transferencia entre proveedores. La monitorización observa el comportamiento tras la admisión, que es donde aparece la mayor parte de la actividad reportable.

El período transitorio de MiCA ha finalizado. Los nuevos proyectos de criptoactivos en la Unión Europea deben diseñarse desde el principio para un modelo operativo de CASP autorizado. En el Reino Unido, el registro MLR no equivale a la autorización FSMA: la FCA publicó sus normas definitivas para el régimen cripto entrante el 30 de junio de 2026, la ventana de solicitud va del 30 de septiembre de 2026 al 28 de febrero de 2027 y se espera que el régimen entre en vigor el 25 de octubre de 2027. La Travel Rule británica se aplica desde el 1 de septiembre de 2023. Ambas trayectorias sitúan los módulos de cumplimiento dentro del alcance técnico de la plataforma y no junto a ella.

Legichain, el producto de screening y verificación de Grumpio, cubre el control de personas y empresas, datos de PEP y sanciones, adverse media, control de riesgo de wallets en múltiples blockchains, puntuación de riesgo, informes de evidencia en PDF y rescreening periódico, mediante una API y un panel web, con almacenamiento dedicado cuando se requiere. Las funciones de identidad, incluido el software de verificación KYC con lectura NFC de documentos, liveness y comparación facial, se sirven desde el mismo pool de créditos. El detalle de producto y los precios se publican en legichain.com.

No emitimos dictámenes jurídicos ni garantizamos autorizaciones. Implementamos los requisitos regulatorios y de auditoría en la tecnología, la infraestructura y las operaciones.

Back office, roles y registros de auditoría

El back office es donde la plataforma se opera realmente: administración de clientes, tratamiento de depósitos y retiradas, configuración de comisiones y límites e investigación de excepciones. Su calidad determina la plantilla, y la plantilla determina el coste operativo con más fiabilidad que las tarifas de licencia. El diseño de roles y permisos pertenece a este módulo, junto con el registro de auditoría que muestra qué operador hizo qué, cuándo y con qué aprobación.

El registro de auditoría se trata con frecuencia como un asunto técnico secundario y después se reclama con urgencia durante una revisión. Cuando el registro se concibe como evidencia — completo, resistente a manipulaciones, exportable y legible por alguien que no es ingeniero —, la revisión se convierte en un ejercicio de recuperación y no en un proyecto de reconstrucción.

Mapa de módulos y preguntas de propiedad

El mapa siguiente resume los módulos descritos junto a la pregunta que con más utilidad pone a prueba cada uno durante la evaluación de proveedores. Las preguntas se refieren a propiedad y evidencia antes que a funcionalidades, porque las listas de funciones rara vez difieren mucho entre proveedores, mientras que las condiciones de propiedad casi siempre difieren.

Módulos de despliegue y resiliencia

El despliegue es un módulo por derecho propio, porque el lugar donde se ejecuta la plataforma determina quién puede alcanzarla, quién puede modificarla y qué ocurre cuando un componente falla. El despliegue dedicado u on-premises, los centros de datos primario y secundario, la gobernanza de releases y los objetivos de recuperación son decisiones de arquitectura con consecuencias regulatorias, en particular ante las expectativas de resiliencia operativa hoy aplicables en el Reino Unido y en la Unión Europea.

DORA se aplica desde el 17 de enero de 2025 y trata la resiliencia como una capacidad probada y no como una intención documentada. La distinción práctica es sencilla: un objetivo de recuperación que se ha ejercitado es un control, mientras que un objetivo de recuperación que solo existe en una política es un hallazgo pendiente de formularse. Las implicaciones de ingeniería se desarrollan en la preparación regulatoria.

Conclusión y próximos pasos

Una plataforma de exchange está completa cuando cada módulo tiene una frontera definida, un responsable designado y una cadena de evidencia: núcleo de negociación, ledger, wallets, raíles fiat, cumplimiento, back office y el despliegue que los rodea. Las lagunas de ese mapa no aparecen en la demostración. Aparecen en la conciliación, en el primer incidente y en la primera revisión, cuando cerrarlas resulta más caro.

El paso práctico siguiente consiste en mapear los módulos frente al mercado objetivo, la posición de autorización y el modelo operativo antes de comparar proveedores, porque la comparación solo adquiere sentido una vez conocido el alcance requerido.