El suscriptor puede recibir una senal correcta y aun asi tener una posicion incorrecta. La causa a menudo no esta en la logica del lider, sino entre el envio de la orden y su estado final: tiempo de espera, ejecucion parcial, cancelacion, reintento o una operacion manual en la cuenta.
Para evitar que esta discrepancia se acumule, el sistema de copytrading necesita una reconciliacion separada. Compara la posicion objetivo, las ordenes activas conocidas y el estado real de la cuenta en el intercambio. Ninguna de estas fuentes se puede considerar una imagen completa por si sola.
Tres estados de una misma operacion
Despues de la senal existen al menos tres estados diferentes.
La intencion del sistema. Que posicion debe tener el suscriptor tras aplicar el coeficiente de copia, los limites de riesgo, el lote minimo y el redondeo.
Ordenes enviadas pero no terminadas. Estas ya pueden alterar la posicion, aunque el volumen actual en la cuenta aun no haya cambiado.
El hecho en el intercambio. Ordenes, ejecuciones y posicion que el intercambio devuelve a traves del flujo privado y las solicitudes REST de control.
Si solo se compara el objetivo con la posicion actual, el sistema puede no notar una orden en camino y enviar volumen de mas. Si solo se confia en el registro local, no vera una operacion manual o un cambio ocurrido despues de una perdida de conexion. La reconciliacion debe considerar ambas fuentes.
Por que la respuesta a la creacion de la orden no termina la operacion
Las API de los intercambios funcionan de forma asincrona. La respuesta exitosa a una solicitud usualmente indica que la plataforma acepto procesar la solicitud. Despues, el estado de la orden puede cambiar.
En la documentacion de Bybit, para obtener ordenes abiertas y cerradas, se distinguen estados sin llenar, parcialmente ejecutados y recientemente completados. Para actualizaciones rapidas, el intercambio recomienda el flujo privado WebSocket de ordenes. Binance transmite cambios de estado y volumen ejecutado acumulado en el evento de actualizacion de orden. En la documentacion de OKX tambien se describe la suscripcion al canal de ordenes y las transiciones entre los estados live, filled y cancelacion.
De esto se deduce una regla practica: la respuesta HTTP, el evento de orden y la posicion en la cuenta son testimonios distintos. Para una conclusion final deben vincularse mediante un identificador estable.
Timeout y reintento peligroso
El timeout solo significa que el cliente no recibio una respuesta a tiempo. No indica si la solicitud llego al sistema comercial.
Hay dos escenarios posibles:
- el intercambio no recibio la orden;
- el intercambio recibio e incluso ejecuto la orden, pero la respuesta se perdio en el camino.
Si se repite la solicitud inmediatamente sin verificar, en el segundo escenario aparecera una segunda orden. Por eso la integracion comercial generalmente usa un identificador unico del cliente y un procesamiento idempotente por su parte. Despues de un resultado incierto, el sistema primero busca la orden por su identificador o la recupera mediante el historial y el flujo de eventos. Una nueva orden solo es necesaria si el intento previo ha sido clasificado.
Este es un principio general de integracion confiable, no una afirmacion sobre la implementacion interna especifica de CopyTrader.
La ejecucion parcial modifica el calculo del delta
Supongamos que la posicion objetivo del suscriptor es 1,0 BTC, la posicion actual real es 0,6 BTC y una orden abierta de compra por 0,4 BTC ya fue ejecutada a la mitad.
Si el intercambio ya incluyo 0,2 BTC ejecutados en la posicion actual, queda abierto un saldo de 0,2 BTC. El estado considerado es:
posicion real saldo no ejecutado de ordenes activas.
En el ejemplo es 0,8 0,2 = 1,0 BTC. No se necesita una orden adicional.
Si el sistema solo observa la posicion de 0,8 BTC, podria enviar otros 0,2 BTC y tras la conclusion de la primera orden obtener 1,2 BTC. Si, en cambio, cuenta todo el volumen inicial de la orden sobre la posicion ya actualizada, el error ocurrira porque la parte ejecutada se contabilizara dos veces.
La formula concreta depende del modelo de posiciones, direccion, modo hedge/one-way y contrato del intercambio. Pero el principio es uno: no se deben mezclar el volumen ejecutado y el saldo abierto.
Ciclo de reconciliacion de ordenes y posicion
El ciclo practico de reconciliacion consta de varios pasos.
- Obtener el objetivo. Registrar la posicion objetivo tras aplicar las reglas de copia y restricciones del suscriptor.
- Obtener el hecho del intercambio. Conseguir la posicion actual, ordenes activas y estados finales recientes.
- Relacionar identificadores. Asociar la decision interna, ID de cliente y ID de orden del intercambio.
- Normalizar estado. Considerar direccion, volumen ejecutado, saldo abierto, paso de cantidad y modo de posicion.
- Calcular discrepancia. Comparar el objetivo con la posicion real y el volumen aun capaz de ejecutarse.
- Clasificar causa. Timeout, rechazo, ejecucion parcial, cancelacion, operacion manual, perdida de evento o cambio de configuracion.
- Seleccionar accion. Observar, cancelar saldo, enviar orden correctiva, bloquear correccion automatica o pasar el caso a un operador.
- Verificar estado final. Tras la accion, consultar de nuevo el hecho del intercambio.
La correccion automatica no siempre es apropiada. Si la causa es desconocida o se detecta actividad externa en la cuenta, es mas seguro detenerse y mostrar la discrepancia que perseguir indefinidamente el objetivo con nuevas ordenes de mercado.
Escenarios tipicos
| Observacion |
Posible causa |
Que verificar antes de repetir la orden |
| No hay respuesta tras envio |
timeout o perdida de conexion |
ID de orden de cliente, historial de ordenes y flujo privado |
Estado permanece partially filled |
liquidez insuficiente o precio limite |
volumen ejecutado, saldo, tiempo de vigencia y objetivo actual |
| Orden cancelada |
cancelacion manual, IOC/FOK, regla del intercambio |
estado final y motivo de cancelacion |
| La posicion difiere sin ordenes abiertas |
operacion manual, evento perdido, modo de posicion diferente |
historial de ejecuciones y configuraciones de cuenta |
| Tras reintento, volumen supera el objetivo |
el primer intento fue aceptado |
ambos ID de orden y reglas de reenvio |
La tabla ayuda a iniciar una investigacion, pero no reemplaza el contrato de un intercambio especifico. Los nombres de estados y el orden de los eventos varian.
Que debe ver el usuario
El estado «operacion copiada» no es suficiente. Agrupa varios estados distintos y genera una falsa confianza.
Es mas util mostrar separadamente:
- se recibio la senal;
- orden preparada;
- orden aceptada por el intercambio;
- ejecutada parcial o totalmente;
- rechazada o cancelada;
- posicion reconciliada;
- discrepancia detectada y se requiere accion.
En casos dudosos se necesita un registro minimo sin secretos: hora, instrumento, direccion, volumen solicitado y ejecutado, precio medio, estado final y enlace al identificador interno. Las claves API y otros datos sensibles no deben aparecer en este registro.
Como se relaciona este material con otras comprobaciones
La sincronizacion de configuraciones responde si es seguro enviar una copia de una operacion con los parametros actuales de la cuenta. El estudio del slippage muestra por que una senal identica no garantiza el mismo precio medio. La reconciliacion tras la ejecucion resuelve la tercera tarea: si el estado real coincide con el que el sistema intentaba crear.
Estas comprobaciones no eliminan el riesgo de mercado. Separan las causas de las discrepancias y dan al operador evidencia para actuar correctamente.
El material es educativo y describe principios generales de integraciones comerciales. No constituye garantia de ejecucion concreta, caracteristica de todas las plataformas conectadas ni recomendacion de inversion.
CopyTrader · Telegram