Desmontamos un backtest de un mercado de predicción que compró el contrato equivocado

Un backtest de un mercado de predicción puede usar un ticker que parece correcto, el historial de precios adecuado y el contrato equivocado. Es fácil pasar por alto ese error porque los nombres de los mercados son breves, las páginas de los eventos se actualizan y una participación YES siempre parece tener un precio entre cero y uno.

Tomemos un mercado hipotético llamado «¿Se aprobará la Ley de Transporte Limpio?». Una estrategia compra YES a 0.42 tras una señal de noticias. Más adelante, el backtest valora la posición en 1.00. Antes de confiar en esa ganancia, quiero saber exactamente qué prometía el contrato: qué proyecto de ley era, qué se consideraba «aprobación», cuál era la fecha límite y qué fuente determinó el resultado.

El título: «¿Se aprobará la Ley de Transporte Limpio?»

Un título es una cadena de presentación, no un identificador estable del instrumento. Dos mercados pueden tener una redacción casi idéntica y referirse a distintas sesiones legislativas, proyectos enmendados o fechas límite. Además, una plataforma puede cambiar el título para aclarar el mercado sin modificar sus condiciones subyacentes.

Por eso, el backtest debe vincular la posición al ID inmutable del mercado o contrato de la plataforma y conservar el texto íntegro de las reglas junto con su versión. Si los datos históricos solo incluyen un título y un ticker, no se puede demostrar que la serie de precios corresponda al contrato que la estrategia pretendía negociar.

Las reglas: ¿qué significa «aprobar»?

Supongamos que las reglas exigen que el proyecto de ley sea aprobado por la Cámara de Representantes y el Senado antes del 30 de junio y que después lo firme el presidente. Un backtest que considera un éxito la aprobación en cualquiera de las dos cámaras ha cambiado la apuesta. También la cambia si cuenta un proyecto con el mismo nombre en la siguiente sesión.

Lee los criterios de resolución reales como condiciones ejecutables. Registra la fecha límite y la zona horaria, el evento que cumple los requisitos, las excepciones y la fuente de resolución indicada. La ambigüedad también importa: si las reglas de la plataforma dejan sin resolver un escenario plausible, no elijas en silencio la interpretación que coincide con el resultado histórico.

Hay una parte maravillosamente poco glamurosa de este trabajo: guardar la página de reglas antes de que ocurra algo interesante. Una página capturada solo después de la resolución puede mostrar la redacción final, aunque la estrategia entrara cuando estaba vigente una versión anterior.

La cronología: ¿cuándo podía saberlo la estrategia?

Supongamos ahora que las reglas son sólidas y que la señal de noticias se activó a las 14:05 UTC. El feed histórico indica que hubo una operación a las 14:05, a un precio de 0.42. Esa marca de tiempo por sí sola no indica si la información estaba disponible antes de la operación, si el precio registrado seguía siendo ejecutable después ni si la barra representa una cotización, una operación o un resumen del intervalo.

Mantén separadas la hora en que la señal estuvo disponible y la hora del evento de mercado. Después, envía la orden cuando la estrategia ya haya podido calcularla y remitirla. En un mercado con poca liquidez, la siguiente operación registrada puede producirse minutos después; eso no demuestra que tu orden se hubiera ejecutado a ese precio.

El precio: una cotización no es una ejecución

YES a 0.42 implica un precio de 42 centavos por participación, pero una serie de últimas operaciones oculta el diferencial y el volumen disponible. Si la mejor oferta de venta es 0.45 para 20 participaciones, una compra simulada de 100 participaciones no puede ejecutarse íntegramente a 0.42. Puede consumir varios niveles del libro, esperar o quedar sin ejecutar.

Los precios de los mercados de predicción también tientan a simplificar la contabilidad: tratar 0.42 como una probabilidad del 42% y olvidar que también es el desembolso inicial. Una posición de 100 participaciones YES cuesta $42 antes de comisiones. Si se liquida a $1, el cobro bruto es de $100; si se liquida a $0, es cero. Las comisiones, las ejecuciones parciales y cualquier mecanismo de liquidación específico de la plataforma deben figurar en el registro.

La liquidación: ¿qué cierra la operación?

A menudo, un backtest cierra la posición al precio final de mercado. Pero un contrato mantenido hasta su resolución paga según las reglas, y su última cotización puede estar desactualizada, tener un diferencial amplio o alejarse mucho del pago final. Modela la resolución como un evento independiente: el resultado, la hora de liquidación y el movimiento de efectivo deben proceder del registro del contrato.

Ten en cuenta también los mercados que se resuelven con un resultado inválido o disputado, si las reglas de la plataforma lo contemplan. En esos casos, se puede devolver la apuesta, pagar una cantidad distinta o aplicar una demora. La suposición de un pago binario no representa todas las vías de resolución.

El veredicto sobre el backtest

En este ejemplo, solo aceptaría la ganancia informada tras verificar el ID inmutable del mercado, la versión de las reglas vigente al entrar, el token YES, la hora en que estuvo disponible la señal, las ofertas de venta y el volumen ejecutables, las comisiones y la liquidación registrada. Si el archivo de precios no permite hacer esas comprobaciones, el resultado honesto es un rango de escenarios o un resultado sin verificar.

Puede parecer exigente para una operación pequeña. Pero si el mismo error al combinar datos se repite en miles de mercados, el backtest puede acabar midiendo con precisión contratos que la estrategia nunca negoció.