Quien opera fuera de libro asume un doble compromiso: demostrar que cumple las reglas y, al mismo tiempo, no revelar con quién opera ni a qué precio. Esta página reúne el trabajo de mesas, custodios y equipos de cumplimiento que sostienen ese equilibrio con pruebas criptográficas, biometría procesada en el dispositivo y vigilancia sobre patrones de ejecución. El material está pensado para quien ya conoce el flujo de una operación y necesita criterios concretos para elegir, integrar o auditar estas herramientas.
En mesas de dark pool y cruces P2P, el cuello de botella rara vez es la liquidez. Es el tiempo que se pierde validando contrapartes, el riesgo de filtrar posiciones en cada onboarding y la imposibilidad de auditar sin abrir la caja. Estos son los puntos donde un esquema de verificación anónima cambia la operación diaria.
El operador deja de acumular huellas, rostros o documentos en un repositorio propio. La prueba se genera en el dispositivo del participante y solo viaja el resultado criptográfico. Menos superficie de ataque, menos obligaciones de retención, menos exposición ante una brecha.
Se confirma que la contraparte está autorizada, dentro de límites y sin sanciones activas, sin exponer quién es. Útil cuando el valor del dark pool está justamente en que nadie sepa con quién cruzó, pero el cumplimiento sigue siendo obligatorio.
Un regulador o un auditor interno puede verificar que las reglas se cumplieron en cada operación sin acceder al detalle de posiciones ni a la identidad de las partes. La traza queda, el secreto operativo también.
Cuando la verificación previa es sólida, los modelos de detección de colusión y wash trading trabajan sobre señales más limpias. Baja el ruido de alertas por contrapartes mal clasificadas y el equipo de vigilancia dedica tiempo a lo que importa.
Se puede empezar por el onboarding de nuevos participantes y dejar el flujo existente para los actuales. La migración avanza a medida que el equipo valida latencias, coste de cómputo en nodos y compatibilidad con el motor de cruce.
Si tu mesa opera con contrapartes recurrentes y volumen bajo, conviene revisar primero cómo se comportan los esquemas zk-SNARK frente a los zk-STARK en tiempos de verificación. Lo desarrollamos en detalle en el análisis comparativo de pruebas de conocimiento cero, y en quiénes somos explicamos por qué este enfoque dejó de ser experimental para volverse operativo.
La verificación de contrapartes fuera de libro se apoya en pruebas criptográficas, no en carpetas compartidas. Estas son las piezas que un operador necesita tener resueltas antes de conectar su mesa a un flujo con verificación anónima.
El alta de un nuevo participante se resuelve con una prueba de conocimiento cero sobre listas de sanciones, residencia fiscal y límites de exposición. El operador emite la prueba desde su propio entorno; la mesa receptora valida el resultado sin recibir el expediente completo. Esto reduce el tiempo de conexión y elimina el repositorio de documentos personales que suele acumularse en los procesos tradicionales.
Cuando se exige confirmar que la persona que firma coincide con el registro autorizado, el procesamiento biométrico ocurre localmente. Solo viaja una prueba criptográfica, no la plantilla. Para el operador esto implica revisar el hardware de sus terminales y definir qué ocurre si un dispositivo se pierde o queda comprometido, porque la verificación depende de esa cadena.
La ausencia de libro público no elimina la manipulación, la desplaza a correlaciones de timing y tamaño entre pares recurrentes. Los indicadores que revisamos incluyen reincidencia de contrapartes, coherencia entre actividad declarada y ejecutada, y desvíos en la ventana de ejecución. Cada señal trae su tasa de falsos positivos y conviene calibrarla según el volumen real de la mesa.
Los reguladores piden trazabilidad; los participantes piden discreción. La salida práctica es un registro de eventos donde se guardan hashes y pruebas verificables, no identidades ni posiciones. El operador define qué se conserva, durante cuánto tiempo y quién puede reconstruir una operación concreta ante un requerimiento formal.
Ninguna de estas piezas reemplaza el motor de órdenes ni el sistema de liquidación. Se acoplan como una capa de verificación previa a la ejecución. Revisamos los puntos de enganche, la latencia que agrega la validación y qué ocurre cuando un nodo validador no responde en el momento crítico.
Para el contexto general del proyecto, ver cómo trabajamos; para coordinar una revisión de la mesa, escribir a contacto.