En qué estoy construyendo

// 01

ticker-reference-data ↗

Datos de mercado

Reference data de US equities reconstruida todos los días: qué ticker se llamaba antes de otra forma, cuál hizo reverse split, y todos los trading halts desde 2019. Es la capa aburrida que arruina backtests cuando está mal.

▸ Andando

69.256 halts reconciliados entre NYSE, Nasdaq y Cboe — un evento es una fila y se sabe qué feeds lo vieron
Releases diarios tageados por fecha: un backtest puede pinear el snapshot exacto que usó
Renames resueltos por CIK y splits que las fuentes perdieron

▸ Sin resolver

Los halts que nunca reanudan. Los feeds siguen devolviendo los que están abiertos — hay papeles halteados desde 2023 — y cada corrida los vuelve a rutear a su año. Funciona, pero no me convence como modelo: un evento sin cierre no es lo mismo que uno cerrado y hoy viven en la misma tabla.
Correcciones retroactivas sin rastro. Si una fuente corrige un evento de 2021, el CSV de 2021 cambia y no queda registro de qué cambió ni cuándo. Para un dataset que se usa en backtests, eso es un problema serio: dos corridas del mismo test pueden no ser comparables y no hay forma de saberlo.

A quién le sirve: Alguien que haya peleado con datos point-in-time de verdad — versionado de datasets, bitemporalidad, o reconstrucción de estado histórico.

// 02

Reconciliación backtest ↔ ejecución

Investigación

El backtest dice que la estrategia hace X. La ejecución real hizo Y. Este proyecto es el puente: cruzar señal por señal lo que el sistema decidió contra lo que efectivamente pasó en el mercado, y explicar cada diferencia.

▸ Andando

Cruce por señal entre lo simulado y lo ejecutado, sobre un rango de fechas
Detección de señales que existen en un lado y no en el otro

▸ Sin resolver

Atribuir el delta. Cuando el resultado real difiere del simulado, la diferencia se reparte entre slippage, timing, costos de borrow y decisiones que el sistema no tomó — y hoy no tengo una forma rigurosa de asignar cuánto le corresponde a cada causa. Sin esa atribución, "el backtest era optimista" es una frase, no un diagnóstico.
Que el resultado sea accionable. Detectar que hubo desvío es la parte fácil. Lo difícil es que la conclusión te diga qué corregir: el modelo, los supuestos de costos, o la ejecución.

A quién le sirve: Quien haya hecho walk-forward en serio, o venga de transaction cost analysis del lado institucional.

// 03

sekd ↗

Herramienta · Go

Due diligence de small caps desde la terminal: lee los filings de SEC, sigue la evolución de acciones en circulación y arma un score de riesgo de dilución con ATMs, shelfs, warrants y convertibles.

▸ Andando

Score de dilución con flags automáticos: ATM reciente, float bajo, warrants in-the-money, capacidad de shelf
Extracción profunda de los filings con LLM y caché agresiva, para que repetir una consulta sea gratis
Watchlist que reescanea y avisa qué cambió desde la última vez

▸ Sin resolver

Cuando la fuente cambia abajo, el score miente sin avisar. EDGAR cambia formatos y parte de los datos viene de scraping. Hoy, si una fuente empieza a devolver algo distinto, el resultado sigue saliendo con la misma cara de confianza. Falta que la herramienta sepa distinguir "no hay dilución" de "no pude leerla".
La extracción con LLM no es reproducible. El modo profundo saca warrants, ATMs y convertibles del texto del filing con un modelo, y dos corridas pueden diferir en los casos borde. Para un número que se usa para decidir una operación, hace falta verificación cruzada o un intervalo de confianza, no una respuesta suelta.

A quién le sirve: Gente de Go, o de parsing de documentos regulatorios. También sirve quien haya construido pipelines con LLMs donde el resultado tiene que ser auditable.

// 04

quant-llm-skills ↗

Investigación · LLM

Diez skills que le enseñan a un LLM las trampas del research quant que nadie documenta: que <code>period_end</code> no es fecha de publicación, que un shelf es capacidad y no evento, que sumar carátulas de 13D infla la tenencia de insiders entre 2 y 10 veces.

▸ Andando

Suite de evals que mide la diferencia real: 8 a 9 de 11 casos cambian el output en modelos chicos
Las skills se componen solas — pedir un score de dilución dispara las de ATM, tier de banco y lookahead
Cubre desde lookahead bias hasta costos de borrow reales en nombres con Reg-SHO

▸ Sin resolver

Saber si el modelo aplicó la regla o solo pareció aplicarla. Los evals miden que el output cambie, que no es lo mismo que garantizar que la regla se usó. Para research donde un lookahead silencioso te arruina un backtest, hace falta una forma de auditar el razonamiento, no solo comparar el resultado final.
Están destiladas de un dominio muy específico. Las reglas salen de operar small caps US con filings de SEC. Cuánto de esto sobrevive en otro mercado o con otro regulador, no lo sé todavía — y generalizarlas sin diluir la precisión es el problema interesante.

A quién le sirve: Quien trabaje en evals de LLMs o interpretabilidad, y quien haya hecho research quant fuera de US equities y pueda decir qué reglas se rompen.

¿Te interesó alguno?

No busco clientes ni estoy vendiendo horas: tengo un trabajo full-time que me gusta. Esto son proyectos propios, y prefiero construirlos con gente antes que solo. Si algo de acá te hizo pensar "eso lo resolvería así", escribime.

▸ Abrir un issue Escribirme Discord del lodge