Roles del quant: seis oficios alrededor de un mismo sistema.

Un mismo sistema, seis oficios

Un sistema de trading sistemático es una cadena: datos que entran, una señal que se investiga, un programa que la ejecuta, una persona que lo opera, unos límites que lo contienen y, si hay modelos de machine learning, un ciclo que los reentrena y los vigila. En una firma grande, cada eslabón tiene su equipo; en una pequeña, o para un trader independiente, una sola persona hace varios. Saber qué eslabón se ocupa en cada momento ayuda a decidir qué aprender, qué delegar y a qué puestos optar.

flowchart TB
  DE[Data engineer] --> QR[Quant researcher]
  QR --> QD[Quant developer]
  ML[ML engineer] --> QD
  QD --> QT[Quant trader]
  RQ[Risk quant] --> QT
  QT --> QR

La flecha de vuelta, del trader al researcher, es la que más se olvida: lo que se observa en real (costes, fills, deriva) vuelve a la investigación. Los nombres son los habituales en el sector, pero no están normalizados: el mismo trabajo puede llamarse quantitative analyst, strategist, research engineer o portfolio analyst según la firma. Por eso esta lección define cada rol por sus entregables y no por el título.

Una referencia pública para las tareas es O*NET, la base de ocupaciones del Departamento de Trabajo de EE. UU. Su ficha Financial Quantitative Analysts (13-2099.01) recoge 21 tareas, entre ellas «aplicar técnicas matemáticas o estadísticas a problemas prácticos de finanzas, como la valoración de derivados, la negociación de valores, la gestión del riesgo o la regulación», «desarrollar librerías de modelos» y «dar soporte analítico a researchers o traders»; entre los títulos que la ficha cita como reportados figuran Quantitative Analyst, Quantitative Research Analyst y Portfolio Manager. La de Financial Risk Specialists (13-2054.00) incluye «diseñar análisis de escenarios con eventos de mercado severos» y «contribuir al desarrollo de sistemas de gestión del riesgo»11Nota 1 · O*NET OnLine, U.S. Department of Labor, Employment and Training Administration: fichas 13-2099.01 Financial Quantitative Analysts, 13-2054.00 Financial Risk Specialists y 15-2051.00 Data Scientists (sitio actualizado el 6/10/2026), consultadas el 23/10/2026. Licencia CC BY 4.0; las citas son traducciones propias.. Son descripciones del mercado laboral de EE. UU., útiles como vocabulario; no son un estándar europeo ni una garantía de lo que pide cada oferta.

Qué hace cada rol

• Quant researcher. Formula hipótesis de ventaja (lección 2.2.1), las contrasta con datos y estadística honesta y descarta la mayoría. Su riesgo profesional es el sobreajuste, y sus herramientas para combatirlo son las del módulo 2.5. Un buen researcher deja un rastro que otro puede reproducir: diario, datos versionados y código (2.2.4).
• Quant developer. Convierte el prototipo en un sistema que no se cae, o que se cae de forma controlada: estados de órdenes, reconexiones, idempotencia y conciliación (4.5), estructura de proyecto, pruebas y rendimiento (7.1), despliegue (7.2). Su riesgo es el error silencioso: la orden duplicada o el dato desfasado que nadie ve.
• Quant trader. Opera el sistema y decide dentro de límites: cuándo pausar, cómo ejecutar órdenes grandes (4.3), qué hacer ante un evento que el modelo no conoce. En estrategias de opciones o de futuros gestiona griegas y roll (módulos 3.1 y 3.5). Es quien primero ve que algo no cuadra.
• Data engineer. Construye y mantiene los flujos de datos: descarga con reintentos, limpieza, ajustes por eventos corporativos, universos sin sesgo de supervivencia y almacenamiento eficiente (1.4), a escala cuando hace falta (6.6). Su trabajo es invisible cuando funciona.
• Risk quant. Mide y limita: VaR y Expected Shortfall con su backtesting, estrés por correlación y liquidez, riesgo de derivados (4.2), valoración independiente (3.4). En una firma regulada traduce las exigencias normativas en controles (7.4).
• ML engineer. Lleva modelos a producción y los mantiene sanos: registro de experimentos y de modelos, reentrenamiento con validación, champion/challenger, vigilancia de la deriva y servicio eficiente (7.3), con la base de validación financiera del nivel 5.

La matriz de competencias

La tabla anterior se puede convertir en datos. La matriz siguiente asigna a cada bloque del temario un peso por rol: 0 si es ajeno al puesto, 1 si es útil, 2 si es importante y 3 si es núcleo. Es una valoración del curso, no una encuesta: está escrita para que se pueda discutir y cambiar, y el código que la usa no depende de los números concretos.

import pandas as pd

ROLES = ["researcher", "developer", "trader", "data_eng",
         "risk", "ml_eng"]
# 0 = ajeno, 1 = útil, 2 = importante, 3 = núcleo del puesto
MATRIZ = pd.DataFrame.from_records([
    # competencia, módulos del curso, pesos por rol (orden de ROLES)
    ("Estadística y econometría", "0.7 2.1", 3, 1, 2, 1, 3, 2),
    ("Backtesting y validación", "2.4 2.5", 3, 2, 2, 0, 2, 2),
    ("Derivados y valoración", "3.4 3.5", 2, 1, 3, 0, 3, 0),
    ("Carteras y riesgo", "4.1 4.2", 2, 1, 3, 0, 3, 1),
    ("Microestructura y ejecución", "1.1 4.3", 1, 2, 3, 1, 1, 0),
    ("Datos y pipelines", "1.4 6.6", 2, 2, 1, 3, 1, 2),
    ("Sistemas en vivo", "4.4 4.5", 0, 3, 2, 1, 1, 1),
    ("Machine learning", "5.1 5.4", 2, 1, 1, 1, 1, 3),
    ("LLMs y datos alternativos", "6.2 6.7", 1, 1, 0, 2, 0, 2),
    ("Ingeniería de software", "7.1 7.2", 1, 3, 1, 3, 1, 3),
    ("MLOps", "7.3", 0, 2, 0, 2, 0, 3),
    ("Regulación y ética", "7.4", 1, 1, 2, 1, 3, 1),
], columns=["competencia", "modulos", *ROLES]).set_index("competencia")

print(MATRIZ[ROLES].sum().rename("suma de pesos").to_string())

researcher    18
developer     20
trader        20
data_eng      15
risk          19
ml_eng        20

La figura de la cabecera dibuja la misma matriz: cada cuadrado es un peso, y el tamaño, su valor. La suma de pesos indica la amplitud de cada rol. El data engineer es el más concentrado (15); el developer, el trader y el ML engineer, los más amplios (20). Las competencias núcleo de cada uno:

for rol in ROLES:
    print(rol)
    for competencia in MATRIZ.index[MATRIZ[rol] == 3]:
        print("  -", competencia)

researcher
  - Estadística y econometría
  - Backtesting y validación
developer
  - Sistemas en vivo
  - Ingeniería de software
trader
  - Derivados y valoración
  - Carteras y riesgo
  - Microestructura y ejecución
data_eng
  - Datos y pipelines
  - Ingeniería de software
risk
  - Estadística y econometría
  - Derivados y valoración
  - Carteras y riesgo
  - Regulación y ética
ml_eng
  - Machine learning
  - Ingeniería de software
  - MLOps

Dos lecturas de la matriz. La ingeniería de software es núcleo para tres roles (developer, data engineer y ML engineer) y no es ajena a ninguno: el código es el medio de trabajo de todos. Y la regulación solo es núcleo para el risk quant, la celda en ámbar de la figura, aunque nadie pueda ignorarla: un bot mal diseñado puede incurrir en manipulación de mercado (lección 7.4.5), y eso afecta a quien lo programa y a quien lo opera.

Autoevaluación y brecha

Con la matriz, una autoevaluación con la misma escala (0 a 3) se convierte en una cobertura por rol: la parte de lo que pide el rol que ya se tiene, ponderada por el peso. Saber más de lo que se pide no compensa lo que falta en otra competencia, así que lo que excede se recorta.

# Autoevaluación de ejemplo, de 0 (nada) a 3 (lo domino)
YO = pd.Series({
    "Estadística y econometría": 2, "Backtesting y validación": 3,
    "Derivados y valoración": 1, "Carteras y riesgo": 2,
    "Microestructura y ejecución": 1, "Datos y pipelines": 2,
    "Sistemas en vivo": 1, "Machine learning": 2,
    "LLMs y datos alternativos": 1, "Ingeniería de software": 2,
    "MLOps": 0, "Regulación y ética": 1,
})


def cobertura(yo, matriz=MATRIZ, roles=ROLES):
    """Parte cubierta de lo que pide cada rol, ponderada por peso."""
    pide = matriz[roles]
    tengo = pide.clip(upper=yo, axis=0)  # lo que sobra no suma
    return (tengo.sum() / pide.sum()).sort_values(ascending=False)


print(cobertura(YO).map("{:.0%}".format).to_string())

researcher    89%
developer     70%
ml_eng        70%
risk          68%
data_eng      67%
trader        65%

El perfil de ejemplo, alguien que ha hecho bien el nivel 2 y a medias los demás, cubre el 89 % de lo que pide el rol de researcher y entre el 65 % y el 70 % del resto. La cobertura no es una nota: con la escala de 0 a 3 y doce competencias es una medida gruesa, buena para ordenar prioridades y mala para comparar personas. Para el rol de developer, la lista concreta:

def brecha(rol, yo, matriz=MATRIZ):
    falta = (matriz[rol] - yo).clip(lower=0)
    tabla = matriz.loc[falta > 0, ["modulos"]].assign(
        pide=matriz[rol], tengo=yo, falta=falta)
    return tabla.sort_values(["falta", "pide"], ascending=False)


brecha("developer", YO)

                             modulos  pide  tengo  falta
competencia
Sistemas en vivo             4.4 4.5     3      1      2
MLOps                            7.3     2      0      2
Ingeniería de software       7.1 7.2     3      2      1
Microestructura y ejecución  1.1 4.3     2      1      1

La brecha se lee como un plan: sistemas en vivo (módulos 4.4 y 4.5) y MLOps (7.3) primero, porque faltan dos puntos en cada uno; después ingeniería de software (7.1 y 7.2) y microestructura (1.1 y 4.3). Con los pesos y la autoevaluación en código, el plan se recalcula cada vez que cambian, que es la ventaja sobre una lista mental.

Un día de trabajo, como modelo

Las descripciones de puesto dicen qué se hace, no cómo se reparte el día. Dos modelos sencillos ayudan a pensarlo. El primero describe la sesión de un quant trader como una máquina de estados, igual que el sistema que opera (lección 4.5.1): cada evento solo es válido en ciertos estados.

stateDiagram-v2
  [*] --> preapertura
  preapertura --> sesion: datos_ok
  preapertura --> incidencia: datos_mal
  sesion --> incidencia: alerta
  incidencia --> sesion: resuelta
  incidencia --> cierre: kill_switch
  sesion --> cierre: fin_mercado
  cierre --> revision: conciliado
  revision --> [*]: informe

Una bitácora ficticia de un día, con dos alertas resueltas, recorrida por la máquina:

from datetime import datetime

TRANSICIONES = {
    ("preapertura", "datos_ok"): "sesion",
    ("preapertura", "datos_mal"): "incidencia",
    ("sesion", "alerta"): "incidencia",
    ("incidencia", "resuelta"): "sesion",
    ("incidencia", "kill_switch"): "cierre",
    ("sesion", "fin_mercado"): "cierre",
    ("cierre", "conciliado"): "revision",
    ("revision", "informe"): "fuera",
}

# Bitácora de un día ficticio de un quant trader (hora de Madrid)
BITACORA = [
    ("08:00", "inicio"), ("08:40", "datos_ok"), ("11:20", "alerta"),
    ("11:55", "resuelta"), ("15:40", "alerta"), ("15:55", "resuelta"),
    ("17:35", "fin_mercado"), ("18:05", "conciliado"),
    ("18:30", "informe"),
]


def recorrer(bitacora, transiciones=TRANSICIONES):
    """Minutos en cada estado; un evento imposible es un error."""
    hora = lambda h: datetime.strptime(h, "%H:%M")
    estado, desde = "preapertura", hora(bitacora[0][0])
    minutos = {}
    for h, evento in bitacora[1:]:
        nuevo = transiciones.get((estado, evento))
        if nuevo is None:
            raise ValueError(f"{h}: «{evento}» no vale en {estado}")
        dur = (hora(h) - desde).seconds // 60
        minutos[estado] = minutos.get(estado, 0) + dur
        estado, desde = nuevo, hora(h)
    return estado, minutos


final, minutos = recorrer(BITACORA)
print("Estado final:", final)
for estado, m in minutos.items():
    print(f"  {estado:<12}{m:>4} min")

Estado final: fuera
  preapertura   40 min
  sesion       485 min
  incidencia    50 min
  cierre        30 min
  revision      25 min

De 10 horas y media, 50 minutos fueron incidencias y 95 minutos se fueron en preapertura, cierre y revisión: tareas que no aparecen en un backtest y que alguien tiene que hacer cada día. La máquina rechaza una bitácora imposible (una alerta «resuelta» sin estar en incidencia), lo que la hace útil también para auditar registros reales.

El segundo modelo mide el tiempo de foco. Cada rol recibe interrupciones (una alerta, una pregunta, un fallo de datos) a un ritmo y con una duración media distintos. Los parámetros son supuestos, no datos: el trader recibe muchas interrupciones cortas; el data engineer, pocas y largas; el researcher, pocas. Con 250 días simulados por rol, el modelo cuenta cuántos bloques de 90 minutos sin interrupción quedan entre las 9:00 y las 18:00:

import numpy as np

# Supuestos del modelo (no son datos): interrupciones por hora y
# duración media en minutos, por rol
INTERRUPCIONES = {"researcher": (0.3, 15), "developer": (0.6, 25),
                  "trader": (1.5, 10), "data_eng": (0.5, 30),
                  "risk": (0.7, 20), "ml_eng": (0.5, 20)}


def simular_dia(tasa, media, rng, inicio=9 * 60, fin=18 * 60):
    """Minutos de interrupción y bloques de foco de >= 90 minutos."""
    t, bloques, perdido = inicio, 0, 0
    while True:
        siguiente = t + rng.exponential(60 / tasa)
        foco = min(siguiente, fin) - t
        bloques += int(foco // 90)
        if siguiente >= fin:
            return perdido, bloques
        dura = min(rng.exponential(media), fin - siguiente)
        perdido += dura
        t = siguiente + dura


rng = np.random.default_rng(7)
filas = []
for rol, (tasa, media) in INTERRUPCIONES.items():
    dias = [simular_dia(tasa, media, rng) for _ in range(250)]
    perdido, bloques = np.array(dias).T
    filas.append((rol, perdido.mean() / 60, bloques.mean(),
                  (bloques == 0).mean()))
dia = pd.DataFrame(filas, columns=["rol", "horas_interrumpidas",
                                   "bloques_90", "dias_sin_bloque"])
dia.set_index("rol").round(2)

            horas_interrumpidas  bloques_90  dias_sin_bloque
rol
researcher                 0.60        4.06             0.00
developer                  1.85        2.64             0.03
trader                     1.74        1.12             0.28
data_eng                   1.72        3.06             0.02
risk                       1.66        2.50             0.03
ml_eng                     1.33        3.04             0.00

El developer y el trader pierden un tiempo parecido (1,85 y 1,74 horas al día), pero el trader conserva 1,12 bloques de foco de media y en el 28 % de los días ninguno; el developer, 2,64. La diferencia está en la frecuencia: muchas interrupciones cortas trocean el día. La consecuencia práctica es de organización, no de carácter: el research profundo de un trader cabe fuera de la sesión, y un developer de guardia necesita guardias rotatorias para que el resto del equipo conserve sus bloques.

Cómo usar el resto del nivel

Los proyectos de capstone del nivel 7 se pueden leer con la misma matriz. C1 (sistema multi-activo de futuros en NautilusTrader) es sobre todo trabajo de developer y trader; C2 (libro de opciones con griegas en tiempo real), de trader y risk quant; C3 (cartera con ML, HRP y fiscalidad), de researcher y ML engineer; C4 (plataforma con LLMs y datos alternativos), de data engineer y ML engineer; C5 (market making o arbitraje en cripto), de developer y trader. Elegir el capstone según el rol al que se aspira convierte el proyecto en una prueba de ese rol, que es lo que pregunta una entrevista (lección 7.5.3).

Dos advertencias. La primera: en equipos pequeños los roles se funden, y un perfil con cobertura alta en dos roles contiguos (researcher y developer, o data engineer y ML engineer) es más útil que uno perfecto en uno solo. La segunda: la matriz describe competencias, no valía; la escala de 0 a 3 la rellena cada uno sobre sí mismo, con los sesgos de cualquier autoevaluación. Contrastarla con trabajo publicado (un repositorio, un informe reproducible) es el objeto de la lección 7.5.3.

Ejercicios

1. Añade a la matriz un rol de quant de ejecución (execution quant), que diseña algoritmos de ejecución y mide costes, con los pesos que te parezcan razonables, y calcula su cobertura con la autoevaluación de ejemplo.

ejec = pd.Series({
    "Estadística y econometría": 2, "Backtesting y validación": 1,
    "Derivados y valoración": 0, "Carteras y riesgo": 1,
    "Microestructura y ejecución": 3, "Datos y pipelines": 2,
    "Sistemas en vivo": 3, "Machine learning": 1,
    "LLMs y datos alternativos": 0, "Ingeniería de software": 2,
    "MLOps": 1, "Regulación y ética": 2,
})
m7 = MATRIZ.assign(ejecucion=ejec)
print(cobertura(YO, m7, ROLES + ["ejecucion"])
      .map("{:.0%}".format).to_string())

researcher    89%
developer     70%
ml_eng        70%
risk          68%
data_eng      67%
ejecucion     67%
trader        65%

2. Un equipo establece guardias rotatorias: el developer de guardia recibe el doble de interrupciones y los demás developers, una de cada cuatro (0,15 por hora). ¿Cuántos bloques de foco ganan los que no están de guardia?

rng = np.random.default_rng(11)
for nombre, tasa in [("de guardia", 1.2), ("sin guardia", 0.15),
                     ("sin guardias", 0.6)]:
    dias = np.array([simular_dia(tasa, 25, rng) for _ in range(250)])
    print(f"{nombre:<13}{dias[:, 1].mean():>5.2f} bloques de 90 min")

de guardia    1.25 bloques de 90 min
sin guardia   4.85 bloques de 90 min
sin guardias  2.63 bloques de 90 min

3. Elige el rol al que aspiras y escribe, para el capstone que elegirías, tres entregables que demuestren las competencias núcleo de ese rol según la matriz.