Morgan Stanley reduce a la mitad su conciliación diaria de resultados con FIXR, agentes que vuelven reglas lo que deciden los controllers

En dos frases

Morgan Stanley usa un sistema multiagente interno, FIXR, para despachar los miles de descuadres de su conciliación diaria de la cuenta de resultados: los agentes proponen, los controllers aprueban o corrigen cada propuesta y lo que se resuelve una y otra vez de la misma forma se convierte en una regla fija que ya no necesita al modelo. El banco dice que así ha reducido a la mitad el tiempo por cartera, y la lección más útil para cualquier departamento financiero es la decisión de diseño que hay detrás: menos autonomía para el modelo, más reglas deterministas y personas que siguen respondiendo del resultado.

Quién lo hace y por qué importa

La fuente es un artículo de Taryn Plumb en VentureBeat, publicado el 30 de junio de 2026, a partir de lo que contó Todd Johnson, director gerente (managing director) de Morgan Stanley, en uno de los eventos AI Impact que organiza el medio. El anuncio de ponentes de VentureBeat lo presenta como responsable de ingeniería de procesos, automatización y aplicación de la IA, y Crain’s New York Business lo citaba en 2024 como responsable de diseño estratégico y procesos del equipo de IA del banco. Su papel es diseñar procesos y automatizaciones, y no es un proveedor: Morgan Stanley construyó FIXR para uso propio y no lo vende.

Hay tres motivos para incluirlo en el directorio:

• Está en producción, a escala y en un proceso de control. Conciliar y firmar el resultado diario es uno de los trabajos más críticos en exactitud y plazos de un banco. La mayoría de las historias de agentes son pilotos en áreas de poco riesgo; esta no.
• Va contra la moda de la autonomía total. El titular de VentureBeat lo dice sin rodeos: el banco lo consiguió «haciendo a sus agentes menos autónomos». El modelo se ocupa de lo que requiere criterio; todo lo que puede hacerse repetible pasa a reglas.
• El patrón se puede llevar a empresas pequeñas. Cualquier empresa con una conciliación recurrente (bancos, saldos intragrupo, auxiliar contra mayor, pasarela de pagos contra contabilidad) tiene descuadres, personas que saben resolverlos y las mismas explicaciones repetidas mes tras mes.

No hemos encontrado ninguna publicación de Morgan Stanley sobre FIXR; los demás medios repiten el artículo de VentureBeat.

El problema: cientos de miles de atributos antes de un plazo fijo por la mañana

Cada día de mercado, las mesas del banco operan con productos como renta variable al contado o deuda. Al cierre, los controllers deben conciliar el resultado entre cuatro familias de sistemas: Finanzas, Riesgos, Operaciones y Captura de operaciones. Según el artículo, cientos de miles de atributos no casan con frecuencia. Cada discrepancia es un descuadre (en la jerga, un «break») que un controller tiene que investigar, decidir si ajusta y, idealmente, firmar antes de que la cifra llegue a la mesa a la mañana siguiente.

Antes de FIXR, según Johnson, una sola cartera (un «book») podía llevar hasta seis horas. Unos 100 controllers hacen este trabajo en América, Europa y Asia, y por eso lo eligieron: algo tan repetido se demuestra una vez y se extiende después.

Cómo funciona FIXR

Cuando termina el cálculo nocturno del resultado, el sistema analiza los descuadres y propone soluciones con las reglas que ha aprendido. El artículo describe varios agentes que trabajan juntos:

1. Un intérprete de instrucciones previas, que usa indicaciones y decisiones anteriores para preparar propuestas al inicio del día.
2. Un aprendiz, que observa lo que hacen los controllers y documenta las reglas que aplican.
3. Un constructor de reglas, que convierte los patrones repetidos en lógica automatizada estable.

Para cada descuadre, el sistema hace una de cuatro cosas: liquida automáticamente los que ya conoce, sugiere una solución para los menos habituales, pide ayuda cuando no está seguro o lo marca para que lo investigue una persona. Los controllers revisan, aprueban o corrigen cada recomendación, y sus decisiones alimentan la ejecución siguiente. «Se parece mucho más a un compañero de trabajo que a un copiloto», resumió Johnson.

Las decisiones de diseño detrás del resultado

El proceso antes que los agentes. Antes de meter IA, el equipo de Johnson hizo lo que él llamó una evaluación «muy exhaustiva» de inteligencia de procesos: mapearon y minaron el flujo de trabajo para decidir, paso a paso, si la respuesta era un agente, una automatización tradicional o simplemente rediseñar un paso ineficiente. Si se arregla eso antes de añadir agentes, vino a decir, la transformación es real.

Determinista por diseño. El equipo limitó a propósito cuánto del flujo depende del criterio del modelo. Su razonamiento: lo que se puede dejar «muy pautado y repetible» sale más barato en consumo de tokens y es más repetible desde el punto de vista del control, y el modelo de lenguaje queda para las partes en las que no hace falta un flujo determinista. Cuando un tipo de descuadre acumula suficientes decisiones de los controllers, pasa a ser una regla fija en vez de una decisión del modelo.

Las personas responden del comportamiento. Johnson compara el agente con un controller júnior que trabaja con uno sénior: el sénior no deja de ser responsable porque alguien le ayude. Uno de los principios de gobierno de la IA del banco, dijo, es que siempre tiene que haber una persona que responda, aunque haya cierto grado de automatización. Los equipos técnicos siguen a cargo de las protecciones como cortafuegos o cifrado; los usuarios de negocio que se apoyan en el agente responden de su rendimiento.

La confianza es lo que libera las ganancias. También advirtió de que no habrá eficiencia si todo el mundo comprueba todo lo que hace un agente. La salida no es saltarse la revisión, sino llevar los patrones ya revisados a reglas cuyo comportamiento se conoce de antemano.

La evaluación no termina nunca. Como los modelos cambian sin parar, Johnson bromeó con que los agentes necesitarán formación continua: nunca llega el momento de dar por hecha toda la prueba y «soltarlo».

Lo que no se cuenta

El artículo no dice qué modelos ni proveedores usa FIXR, dónde se ejecuta, cómo se guardan o aprueban las reglas, cuántos descuadres se liquidan solos, cuánto duró la construcción ni cuánto costó. Tampoco sabemos qué parte del ahorro viene de los agentes y qué parte de los arreglos de proceso previos.

Paso a paso para reproducir el patrón a menor escala

Estos pasos son nuestros, adaptados del artículo para un departamento financiero mediano que concilia, por ejemplo, la pasarela de pagos contra la contabilidad o los saldos intragrupo.

1. Elige una conciliación recurrente y mídela. Horas por ejecución, número de descuadres y cómo se resuelven hoy. Sin esa línea de base no podrás decir si algo ha mejorado.
2. Dibuja el proceso antes que el modelo. Enumera cada paso y etiquétalo: eliminar, corregir en origen, automatización clásica (una consulta, una regla de casación) o criterio. Solo el último grupo necesita un agente.
3. Crea un registro de descuadres. Una fila por descuadre: fecha, origen A y B, clave, campo que difiere, importes, tipo de descuadre, solución propuesta, quién la propuso (regla, modelo o persona), decisión (aprobada, corregida, escalada), solución final, revisor y motivo de la corrección.
4. Que el modelo proponga, nunca contabilice. Dale el descuadre, el histórico de descuadres parecidos ya resueltos y tus instrucciones escritas, y pídele una propuesta razonada con una etiqueta de confianza. Él redacta; decide un controller.
5. Registra cada decisión y su porqué. Las correcciones son el dato más valioso que tienes: es el conocimiento de tus controllers puesto por escrito.
6. Convierte patrones en reglas con un criterio escrito. Por ejemplo: mismo tipo de descuadre, misma solución, aprobada al menos N veces en al menos M días distintos y sin correcciones. La regla se escribe en código o SQL normal, la revisa alguien distinto de quien la propone, se prueba contra descuadres pasados y tiene un responsable.
7. Degrada las reglas de forma automática. Si un controller corrige el resultado de una regla, la regla deja de liquidar sola y vuelve a revisión.
8. Mide y amplía poco a poco. Sigue las horas por ejecución, los descuadres liquidados por reglas, por propuesta del modelo y a mano, y las correcciones por semana. Pasa a la siguiente cartera o sociedad solo cuando las cifras aguanten.

Ejemplo concreto: un prompt de triaje y una regla de promoción

Prompt propio para el paso de propuesta, para cualquier asistente que tu empresa haya aprobado (sin datos confidenciales en herramientas que no estén autorizadas):

Ayudas a un controller a resolver descuadres de conciliación entre
{{ORIGEN_A}} y {{ORIGEN_B}} de {{SOCIEDAD}} a fecha {{FECHA}}. Nunca
contabilizas, ajustas ni apruebas nada. Para cada descuadre de abajo,
devuelve una tabla con: ID del descuadre, causa probable, solución propuesta,
evidencia usada (cita la sección de las instrucciones o los ID de descuadres
pasados parecidos), confianza (alta / media / baja) y la acción que
recomiendas: «proponer», «preguntar» (di exactamente qué información
necesitas) o «marcar para investigar». Usa «marcar» si el importe supera
{{UMBRAL}}, si no hay ningún descuadre pasado parecido o si las instrucciones
no cubren el caso. No inventes cuentas, ID de operaciones ni importes que no
estén en los datos.

Instrucciones escritas:
{{INSTRUCCIONES}}

Descuadres pasados parecidos con su solución final y los comentarios del revisor:
{{HISTORICO}}

Descuadres de hoy:
{{DESCUADRES}}

Y una regla mínima de promoción y degradación sobre el registro de descuadres (Python, esbozo propio; los umbrales son ilustrativos y deben fijarlos tus controllers y auditores):

from collections import defaultdict

MIN_APROBACIONES, MIN_DIAS = 20, 10  # ilustrativos, no son los de Morgan Stanley

def reglas_candidatas(registro):
    """Agrupa los descuadres ya decididos por (tipo, solución) y propone
    reglas solo donde los controllers aprobaron lo mismo repetidamente."""
    grupos = defaultdict(list)
    for d in registro:
        if d["decision"] in ("aprobada", "corregida"):
            grupos[(d["tipo"], d["solucion_propuesta"])].append(d)
    for (tipo, solucion), items in grupos.items():
        correcciones = [d for d in items if d["decision"] == "corregida"]
        dias = {d["fecha"] for d in items}
        if not correcciones and len(items) >= MIN_APROBACIONES and len(dias) >= MIN_DIAS:
            yield {"tipo": tipo, "solucion": solucion,
                   "evidencia": [d["id"] for d in items],
                   "estado": "pendiente de aprobación humana"}  # la firma una persona

def degradar_si_contradicha(regla, decision):
    if decision == "corregida":
        regla["estado"] = "suspendida: vuelve a revisión"
    return regla

El código propone reglas, no las activa. Una persona aprueba cada regla, y la regla en sí es lógica normal que funciona sin el modelo, que es justo la idea del patrón.

Resultados, según la fuente

• Tiempo por cartera: de hasta seis horas a entre dos y tres (Johnson).
• Escala: unos 100 controllers en América, Europa y Asia; unas 1.500 horas ahorradas por semana (Johnson). Nuestra propia cuenta muestra que las dos cifras son coherentes: tres horas ahorradas por controller y día de mercado durante cinco días son 15 horas semanales, por 100 controllers.
• Cualitativo: los controllers dedican el tiempo a «análisis de más valor» y a una «consideración más profunda del riesgo» (Johnson).
• No se dan: exactitud, porcentaje de liquidación automática, errores detectados o que se escaparon, costes, calendario de construcción ni revisión independiente.

Limitaciones y riesgos

• Una charla, un artículo. Todo procede de un director gerente que habló en un evento del sector, contado por el medio que lo organizó. Las cifras son declaradas, no auditadas, y no hemos encontrado ningún documento de Morgan Stanley sobre FIXR.
• Las reglas pueden congelar errores. Si los controllers aprueban muchas veces la misma solución equivocada, acaba siendo una regla. La promoción necesita un segundo revisor y muestreos periódicos de lo liquidado automáticamente.
• Deriva. Cambian los sistemas de origen, los productos y los modelos. Una regla o un prompt que acertaba el trimestre pasado puede fallar hoy; lo de que la evaluación no termina nunca vale para ambos.
• Pista de auditoría. Una entidad regulada tiene que poder demostrar quién aprobó cada solución y cada regla, y por qué. Monta el registro primero, no al final.
• Datos y confidencialidad. Usa solo modelos y entornos aprobados, con acceso limitado a lo que necesita cada paso.
• Escala. La economía de un banco con 100 controllers no es la de un departamento de diez personas. El patrón se puede trasladar; las horas ahorradas, no.

Errores frecuentes

• Añadir un agente a un proceso roto. Morgan Stanley mapeó y arregló el flujo primero.
• Dejar al modelo lo que podría decidir una regla. Todo tipo de descuadre que se pueda pautar debería pautarse, por coste y por control.
• Aprobar en bloque. Revisar sin registrar las correcciones no enseña nada al sistema y no deja rastro.
• Reglas sin responsable. Cada regla promovida necesita un responsable, una prueba y una forma de suspenderla.
• Contar solo el tiempo ahorrado. Mide también las correcciones y lo que se escapó, o no sabrás si fiarte de la siguiente ampliación.

Conclusiones

FIXR es el sistema de un gran banco, pero su idea central es sencilla y trasladable: usar el modelo para leer instrucciones, aprender de las personas y proponer; dejar que decidan las personas, y convertir lo que deciden una y otra vez en reglas baratas, previsibles y auditables. El resultado declarado, la mitad de tiempo en un proceso de control diario para unos 100 controllers, sale de esa combinación, no de dejar solos a los agentes. Para un equipo más pequeño, el punto de partida no es el modelo, sino el registro de descuadres y el criterio escrito de cuándo una decisión se convierte en regla.