Bitcoin es BTC en la mayoría de los exchanges, pero es XBT en algunos, y los pares de trading están formateados de manera diferente en todas partes. BTCUSDT, BTC/USDT, BTC-USDT, tBTCUSD. Estas inconsistencias de nombres parecen triviales, pero son la primera barrera para cualquier análisis entre plataformas. Un sistema que compara precios entre exchanges necesita una capa de mapeo que traduzca la convención de nombres de cada plataforma a un formato canónico.
El desafío se vuelve más difícil con activos menos establecidos. Un token podría estar listado bajo diferentes direcciones de contrato en diferentes cadenas, con diferentes símbolos de ticker en diferentes exchanges. Algunos exchanges listan versiones envueltas. Otros listan versiones nativas. Un token llamado ABC en un exchange podría ser un proyecto completamente diferente a ABC en otro. La coincidencia confiable entre plataformas requiere una combinación de verificación de dirección de contrato, coincidencia de símbolo y curaduría manual.
La sincronización de marcas de tiempo es otro desafío fundamental. Los exchanges reportan marcas de tiempo en diferentes formatos y con diferentes niveles de precisión. Algunos reportan en milisegundos desde la época, otros en formato ISO 8601. Algunos usan UTC, otros usan hora local. Y la latencia entre cuando ocurre una operación y cuando se reporta a través de la API varía entre exchanges. Alinear los datos a una referencia temporal común es esencial para cualquier análisis entre plataformas como la detección de arbitraje o la comparación de volumen.
La normalización de precios va más allá de la simple conversión de monedas. Los diferentes exchanges tienen distintas estructuras de comisiones que afectan el precio efectivo. Los modelos de comisión maker-taker significan que el costo real de una operación depende de si usted está añadiendo o retirando liquidez. Un precio que parece una oportunidad de arbitraje podría desaparecer por completo una vez que usted tiene en cuenta las comisiones en ambos lados de la operación.
La comparación de profundidad del libro de órdenes es particularmente complicada. Los diferentes exchanges reportan libros de órdenes con distintos niveles de granularidad. Algunos proporcionan el libro de órdenes completo con órdenes individuales. Otros agregan por niveles de precio. El número de niveles proporcionados varía. Comparar la liquidez entre plataformas requiere normalizar estas representaciones diferentes a un formato comparable, normalmente agregado por nivel de precio con el volumen total en cada nivel.
La coincidencia entre plataformas para mercados de predicción añade otra dimensión. La misma pregunta podría estar listada en Polymarket, Kalshi y otras plataformas con una redacción ligeramente diferente, distintas fechas de expiración o diferentes criterios de resolución. Hacer coincidir estas requiere una comprensión semántica, no solo una coincidencia de cadenas. Una pregunta sobre cambios de tasas de un banco central en una plataforma podría estar redactada de manera muy diferente en otra, pero un algoritmo de coincidencia ingenuo no las reconocería como equivalentes.
Las puntuaciones de calidad de los datos ayudan a gestionar la brecha de confiabilidad entre plataformas. Un sistema de coincidencia podría asignar mayor confianza a los datos de exchanges con mejores historiales de reporte preciso y menor confianza a los datos de exchanges conocidos por feeds retrasados o poco confiables. Estas puntuaciones de calidad pueden ponderar los datos emparejados, de modo que el análisis no se vea influenciado de manera desproporcionada por fuentes de baja calidad.
La deduplicación es necesaria cuando la misma operación aparece en múltiples fuentes de datos. Los agregadores que obtienen datos tanto de las API directas de los exchanges como de proveedores de datos externos pueden terminar contando dos veces la misma operación. La deduplicación normalmente utiliza una combinación de marca de tiempo, precio, volumen e ID de operación para identificar duplicados, pero las marcas de tiempo imprecisas y los diferentes niveles de granularidad lo hacen más difícil de lo que parece.
Los sistemas que hacen esto bien tienden a construirse de forma iterativa. Usted comienza con el mapeo de símbolos para los activos principales, añade adaptadores específicos de cada exchange uno por uno, construye el monitoreo de calidad para detectar problemas de datos y expande lentamente la cobertura. No hay atajos para manejar la larga cola de casos límite que emergen cuando usted intenta crear una vista unificada de un mercado fragmentado.