El dominio más exigente: un banco

Son las 02:13 de un martes. En el servidor de un banco regional, un proceso de cierre acaba de detenerse. Dos cifras que llevaban diez años coincidiendo dejaron de coincidir por catorce centavos.

No es un error de cálculo. Es un error de historia. Alguien, en algún sistema satélite, escribió encima de un dato que un auditor necesitaba leer tal como estaba la semana pasada. Ese pasado ya no existe.

Multiplica los catorce centavos por millones de operaciones. Súmale un regulador que exige reconstruir cualquier instante. Ahí tienes el motivo por el que la banca es la prueba de fuego de cualquier modelo de datos: no perdona la elegancia que no resiste una citación judicial.

Conviene fijar la escala. Una empresa mediana guarda su operación en unas ciento cincuenta tablas, un par de sistemas viejos y un programa de contabilidad.

Un banco regional juega en otra liga. Unas mil quinientas tablas solo para el núcleo. Otro millar para tarjetas de crédito. Otro tanto para seguros. Y una nube de aplicaciones satélite para microcréditos, fraude y la app del móvil.

Cada sistema tiene su dueño, sus reglas y, lo más corrosivo, su propio idioma.

El spa mostró que el modelo era ágil. El taxi, que aguantaba la velocidad. La clínica, que sabía repartir la verdad entre varios custodios.

El banco reúne las tres exigencias y añade una cuarta que manda sobre todas: el regulador. Aquí, decisiones que en otros capítulos eran preferencias (no borrar nunca el pasado, tratar al software como un agente responsable) dejan de ser lujos teóricos. Las dicta la ley.

Este capítulo no es un manual de core banking. Toma cuatro escenas (una transferencia, la vida entera de un préstamo, una investigación de fraude y el catálogo de productos) y muestra que el modelo absorbe la complejidad industrial sin trucos.

Si aguanta el dinero, aguanta cualquier cosa.

La realidad honesta: cinco islas que no se hablan

Antes de presumir de soluciones, describamos el enfermo. Quien trabaja en banca asentirá; quien no, se asombrará. Por dentro, un banco no es un sistema: es un archipiélago de cinco islas que apenas se saludan.

• Isla 1 · El núcleo. El servidor central, el core bancario. Allí viven los saldos, los movimientos oficiales y la contabilidad pesada. Es la «verdad» que el Estado audita.
• Isla 2 · Las agencias. Cada sucursal corre pequeños programas para simular créditos o repartir turnos. Toman decisiones todos los días, pero rara vez le explican al núcleo cómo llegaron a ellas.
• Isla 3 · Contabilidad. El zoológico oculto. Una parte vive en el servidor; otra, enorme, vive en hojas de cálculo que se ajustan a mano a fin de mes. Cuando el núcleo y la contabilidad discrepan, suele ganar contabilidad —y casi nadie sabe explicar por qué.
• Isla 4 · Los promotores. Los agentes de calle que venden créditos anotan datos en planillas y papeles. Esa información valiosa del cliente es «fantasma» hasta el día en que el crédito se aprueba y recién entonces ingresa al banco.
• Isla 5 · La reportería. Cuando la gerencia pide un reporte que cruce las cuatro islas anteriores, el equipo técnico tarda semanas en cavar un túnel temporal que junte todo en un data lake. A veces los números no cuadran y el proyecto naufraga.

¿Por qué ocurre? Porque al modernizarse, el banco comete siempre el mismo error: obligar a todas las islas a hablar un único idioma.

Y reprogramar un sistema de quince años para que hable «moderno» sale tan caro que casi siempre lo dejan morir en paz. El resultado es un empate permanente. Nadie migra, nadie se entiende.

El banco sobre las siete coordenadas

Para domar el caos, repartamos las piezas del banco en los ejes de valor. El ejercicio es revelador por sí solo: lo que parecía una maraña de mil quinientas tablas se ordena en seis preguntas.

Los predicados del eje cómo (el séptimo eje, M) son los cables que conectan todo: agente, parte_de, cubierto_por, cancela. Sin ellos las seis cajas serían seis listas inertes. Con ellos, un hecho bancario se vuelve un punto navegable. Pasemos a verlo funcionar.

Caso 1 · Una transferencia y sus cinco agentes ocultos

Para un humano, una transferencia es una frase de seis palabras: «Mariana le envía 480 dólares a Bruno». Para el banco, ese gesto moviliza a cinco agentes y deja dos registros espejo en contabilidad.

Primero declaramos el evento central. Observa que tres de sus enlaces apuntan a agentes y que uno de ellos (el motor antifraude) no es una persona:

(transferencia_7791) ∈ O
  instancia_de:     accion_transferir
  agente:           mariana_q            # Agente 1 — inicia
  beneficiario:     bruno_q              # Agente 2 — recibe
  cuenta_origen:    cta_mariana_4410
  cuenta_destino:   cta_bruno_8820
  monto:            n_480_usd
  lugar_de:         app_movil_banco
  autorizado_por:   banca_web_sys        # Agente 3 — da el visto bueno
  verificado_por:   antifraude_sys       # Agente 4 — descarta el robo
  ts_orden:         2026-05-19T21:07:44  # reloj del cliente
  ts_proceso:       2026-05-19T21:07:46  # reloj del servidor

Pero la transferencia no termina ahí. Detrás, contabilidad (el quinto agente) tiene que cuadrar sus libros. La partida doble es ley de la profesión: a todo débito le corresponde un crédito.

En el modelo creamos dos subeventos y los colgamos de la transferencia con el cable parte_de:

(asiento_debito_7791) ∈ O               # le retiramos saldo a Mariana
  parte_de:         transferencia_7791
  cuenta_contable:  ahorros_mariana_interna
  monto:            n_480_usd
  tipo_movimiento:  debito

(asiento_credito_7791) ∈ O              # le abonamos saldo a Bruno
  parte_de:         transferencia_7791
  cuenta_contable:  ahorros_bruno_interna
  monto:            n_480_usd
  tipo_movimiento:  credito

La misma escena, vista como tres hechos atómicos, queda así de explícita: el evento y sus dos contrapartidas, unidos por un solo predicado.

Y si esta operación resultara mal hecha, jamás la borramos. Creamos una transferencia rectificativa que apunta a la vieja y la anula.

La ley obliga a conservar el historial completo de los errores, no solo el resultado pulido. El modelo lo hace por defecto, sin tablas de auditoría aparte.

Queda una arruga que no se deshace con agentes ni con asientos, sino con el reloj. La transferencia de Mariana a Bruno se liquidó en dos segundos porque era interna: el mismo banco movía dinero entre dos cuentas suyas.

Invierte ahora los papeles. A Mariana le envían un giro desde otro banco y, peor aún, desde el extranjero, un viernes por la tarde.

El dinero ya salió de la cuenta del remitente, pero a la de Mariana todavía no entra. Queda suspendido en una cámara de compensación, esperando a que los sistemas abran.

Y como el viernes la ventana ya cerró, tendrá que esperar hasta el lunes para disponer de su propio dinero. Dos días de limbo para un giro que la pantalla ya da por enviado. Y el dinero podía ser urgente.

Que esa espera exista no es culpa de ningún modelo de datos. Responde a ventanas de compensación, husos horarios, fines de semana y reglas que ningún grafo borra.

Pero sí es culpa del modelo plano que Mariana no pueda saber dónde está su dinero mientras tanto. Un sistema clásico le muestra un «pendiente» opaco y poco más.

WQuestions no trata la transferencia como un instante, sino como un evento con estados fechados:

(giro_int_8043, estado, ordenada,        inicio=2026-05-15T17:40, fin=2026-05-15T17:41)
(giro_int_8043, estado, en_compensacion, inicio=2026-05-15T17:41, fin=2026-05-18T09:02)
(giro_int_8043, estado, disponible,      inicio=2026-05-18T09:02, fin=hoy)
(giro_int_8043, fecha_valor, 2026-05-18)            # cuándo el dinero es de Mariana
(giro_int_8043, ts_orden,    2026-05-15T17:40)      # viernes: cuándo se ordenó

Modelada así, la pregunta angustiada del cliente («¿dónde está mi dinero y cuándo lo tendré?») deja de ser un secreto del banco. Es una consulta que el grafo contesta al instante, con el estado vigente y la fecha en que el dinero se libera.

El modelo no acelera el giro. Los dos días de espera siguen ahí. Lo que hace es convertir ese limbo opaco en un hecho fechado y consultable, que es justo lo que el cliente y el regulador tienen derecho a ver.

Caso 2 · La novela de un préstamo y la regla del tiempo

Un préstamo no dura un segundo. Es una novela de años. Se aprueba, se pagan cuotas, el cliente se atrasa, a veces la deuda se reestructura y, con suerte, todo termina cancelado.

En un sistema viejo, la celda «estado» del préstamo se va borrando y reescribiendo. Con cada reescritura desaparece un capítulo de la historia.

Aquí aplicamos la regla de vigencia temporal. Cada vez que el préstamo de Mariana cambia de estado, no borramos nada: inyectamos una línea nueva con su fecha de inicio y su fecha de fin. El pasado se acumula, no se pierde.

(prestamo_5503, estado, vigente,         inicio=2026-01-20, fin=2026-08-15)
(prestamo_5503, estado, mora_30_dias,    inicio=2026-08-15, fin=2026-09-15)
(prestamo_5503, estado, mora_60_dias,    inicio=2026-09-15, fin=2026-10-22)
(prestamo_5503, estado, reestructurado,  inicio=2026-10-22, fin=hoy)

Cinco años después, en plena audiencia, el juez pregunta: «¿En qué estado exacto estaba este préstamo el 1 de septiembre de 2026?». La base filtra por fecha y responde sin titubear: «Mora de treinta días».

Sin la regla D6, un banco tiene que construir tablas paralelas carísimas solo para guardar esos fantasmas del pasado, y rezar para que alguien las haya mantenido al día.

Hay un detalle fino que la figura insinúa. Un cambio de estado no es solo un cambio de etiqueta. Es un hecho que merece su propia causa.

Por eso cada cambio lleva un enlace motivado_por hacia el evento que lo provocó (un pago vencido, un acuerdo firmado) y, cuando hace falta, un justificado_por hacia el documento legal.

El «por qué» no es un eje, como vimos en su momento. Es una relación entre hechos. Y aquí es lo primero que leerá un auditor.

Caso 3 · Investigación de fraude: reconstruir la noche del cargo

Mariana llama indignada. Alguien usó su tarjeta para pagar 1.840 dólares en una tienda de electrónica al otro lado del país, de madrugada, mientras ella dormía.

El banco tiene que abrir una investigación. Y aquí la arquitectura saca una ventaja que no se cierra con más servidores.

El investigador no necesita el saldo de Mariana de hoy. Necesita viajar a la noche del cargo y preguntar dos cosas que un modelo plano no sabe responder. ¿Dónde creía el banco que estaba Mariana esa noche? ¿Qué decía su perfil de riesgo a esa hora exacta?

La respuesta buena no es el valor actual del perfil. Es el valor que el perfil tenía entonces.

Gracias a la vigencia, el perfil de riesgo de Mariana no es un dato que se pisa: es una serie de versiones fechadas. El investigador recupera la versión que estaba activa la noche del fraude:

(perfil_riesgo_mariana_v4, instancia_de, perfil_antifraude,
                           inicio=2026-04-30, fin=2026-06-02)
(perfil_riesgo_mariana_v4, score_riesgo, 0.27)
(perfil_riesgo_mariana_v4, geo_habitual, ciudad_costa)

Con eso a la vista, el investigador entiende por qué pasó la tarjeta esa noche: el score_riesgo era bajo y el comercio no levantó alertas suficientes.

Al confirmar el robo, no borra el pago de la tienda. El cargo fue real y movió dinero de verdad. En su lugar crea un reverso que apunta al original y deja escrita la causa:

(reverso_cargo_3120, cancela,          autorizacion_original_3120)
(reverso_cargo_3120, justificado_por,  investigacion_fraude_0457)
(reverso_cargo_3120, monto,            n_1840_usd)
(reverso_cargo_3120, ts_proceso,       2026-05-21T09:40:11)

El historial queda intacto. El cargo fraudulento sigue allí, fechado, y a su lado el reverso que lo neutraliza. El dinero vuelve y el banco conserva una prueba impecable para el seguro.

Eso es lo que un sistema plano no ofrece sin reconstrucciones heroicas: mostrar no solo el resultado, sino la secuencia exacta de lo que se supo y cuándo.

Caso 4 · Una tarjeta «Platino» no es una idea: es un objeto

Queda un error de modelado tan común como caro. Cuando el banco le entrega a Mariana una «Tarjeta Platino», muchos programadores dan por hecho que «Platino» es una categoría y la guardan en la caja K. Es falso, y el error cuesta millones.

Cuando el banco entrega el plástico, conecta la tarjeta de Mariana a la oferta específica que estaba vigente ese día —no a la idea de «tarjeta platino», sino al contrato exacto que ella aceptó:

(oferta_platino_2026_t1) ∈ O            # el contrato de oferta del banco
  instancia_de:         tipo_tarjeta_platino   # ← su clase en K
  cuota_manejo_mensual: n_9_usd
  tasa_anual:           n_38_pct
  vigencia:             inicio=2026-01-01, fin=2026-06-30

(tarjeta_mariana_2255) ∈ O              # el plástico que tiene Mariana
  cliente:              mariana_q
  cubierto_por:         oferta_platino_2026_t1

¿Por qué importa tanto separar la oferta de la clase? Porque si en julio el banco lanza una versión nueva con cuota de doce dólares, la tarjeta de Mariana no puede encarecerse sola.

Ella firmó el contrato de enero, y ese contrato sigue congelado en el tiempo, con su propia vigencia.

Tratando los productos financieros como objetos con fecha, el banco se blinda contra demandas millonarias por cambiar las reglas sin avisar.

En banca, los productos no son adjetivos: son contratos firmados que el tiempo no debería poder reescribir.La lección del Caso 4

Caso 5 · La operación que no debía ocurrir, y ocurrió

Son las 03:11 de un domingo. De la cuenta de Ana sale una transferencia de 25.000 USD hacia el exterior. El límite por operación son 10.000, y el motor antifraude no la tocó. Dos normas rotas en un solo movimiento.

La pregunta de diseño es qué debe hacer el sistema, y la respuesta obvia es la equivocada. Un sistema convencional rechaza la escritura: la transacción no se asienta y el cajero recibe un error.

Suena prudente hasta que llega el auditor y pregunta qué se intentó esa madrugada. Entonces resulta que lo que se rechazó no se registró, y lo que no se registró no existe.

El intento vive, si acaso, en una traza que nadie diseñó para consultarse y que se borra cada treinta días.

Una operación sospechosa que se rechaza al escribir es una operación que después nadie puede auditar.La lección del dominio regulado

Aquí la transferencia se asienta. Las tres formas que el banco declaró viven en el grafo como cualquier otra entidad, y el evaluador las comprueba sin bloquear nada.

declarar_forma(u, "forma_limite_operacion", tipo="rango", rol="monto",
               maximo=limite_10000_usd, aplica_a="accion_transferir")
declarar_forma(u, "forma_antifraude", tipo="requiere", rol="cuenta_destino",
               requiere="verificado_por", aplica_a="accion_transferir")
declarar_forma(u, "forma_asiento_movimiento", tipo="cardinalidad",
               rol="tipo_movimiento", minimo=uno, maximo=uno,
               aplica_a="asiento_contable")

informe = u.validate()
#   {'abiertas': ['violacion_0001', 'violacion_0002'], 'cerradas': [], 'vigentes': 2}

La transferencia queda asentada con sus 25.000 USD, y a su lado aparecen dos hechos nuevos: las dos violaciones, cada una apuntando a la norma que la delata.

El oficial de cumplimiento no recibe una alerta que se pierde en una bandeja de entrada. Recibe hechos. Y los hechos se consultan.

Fíjate en lo que se puede preguntar ahora y con un sistema de alertas no.

«¿Cuántas operaciones excedieron el límite en junio?» es un conteo. «¿Cuáles seguían sin resolver el 30 de junio?» es la misma consulta con una fecha, porque la violación lleva su estado con vigencia. Y «¿por qué se marcó esta operación?» devuelve la norma exacta, con su límite, en un salto.

Conviene decir qué no hace este mecanismo, porque el banco es donde más tienta pedirle de más. No impide la operación.

Si el negocio necesita un bloqueo duro (y a veces lo necesita: una cuenta embargada, un cliente sancionado), ese bloqueo vive en la aplicación que decide, no en el almacén que registra.

El grafo no es el guardia de la puerta. Es el testigo que lo vio todo y no olvida.

El antes y el después: del esquema fragmentado al grafo único

Pongamos las dos arquitecturas frente a frente con una sola pregunta, deliberadamente modesta: ¿cuáles fueron las dos contrapartidas contables de la transferencia 7791 y qué perfil de riesgo tenía Mariana en ese instante exacto?

Antes, en el modelo relacional. La información se reparte entre tablas como clientes, cuentas, transferencias, asientos y perfiles_riesgo.

La primera mitad de la pregunta sale con un join de cuatro tablas: incómodo, pero posible. La segunda mitad fracasa, porque perfiles_riesgo solo guarda el registro actual.

Para saber qué decía el perfil la noche del cargo hay que rebuscar en tablas de auditoría aparte, si alguien las creó. Si no, la respuesta no existe en los datos.

-- Antes: perfiles_riesgo solo guarda el estado ACTUAL — la historia se pierde.
CREATE TABLE transferencias (id INTEGER PRIMARY KEY, monto NUMERIC, ts TEXT);
CREATE TABLE asientos       (id INTEGER PRIMARY KEY, transferencia_id INT, tipo TEXT, monto NUMERIC);
CREATE TABLE perfiles_riesgo(cliente_id INTEGER PRIMARY KEY, nivel TEXT);  -- sin vigencia

-- Las dos contrapartidas contables de la transferencia: sale bien.
SELECT tipo, monto FROM asientos WHERE transferencia_id = 7791;

-- "¿Qué nivel de riesgo tenía Mariana la noche del cargo?"
-- Imposible: la tabla solo tiene el valor de hoy, no el de entonces.
SELECT nivel FROM perfiles_riesgo WHERE cliente_id = 4410;

No es el defecto de un banco concreto. Es el defecto del modelo plano frente a los dos tiempos. Qué ocurrió y qué sabía el sistema cuando ocurrió son dos relojes distintos, y el esquema clásico los aplasta en una sola columna.

Después, en WQuestions. La misma información vive como un grafo de hechos. La transferencia transferencia_7791 se liga por parte_de a sus dos asientos. El perfil perfil_riesgo_mariana_v4 lleva su propio rango de vigencia inicio=2026-04-30, fin=2026-06-02.

La pregunta entera se vuelve una consulta: recoge los hechos que cuelgan de la transferencia y suma el perfil cuyo intervalo cubre la hora del cargo.

No hay join de cuatro tablas. No hay tabla de auditoría paralela, porque el tiempo viaja dentro de cada hecho. Y no hay que migrar ningún esquema: el banco no abandona sus mil quinientas tablas, las deja publicar al grafo.

La consulta que antes era un proyecto de semanas pasa a ser una pregunta bien formada. Y la respuesta que antes «no existía en los datos» pasa a estar siempre ahí, fechada al segundo.

Del préstamo de Mariana a la cartera entera

Una transferencia, la novela de un préstamo, un cargo fraudulento. Casos que se entienden de a uno.

El regulador, en cambio, nunca pregunta por Mariana. Pregunta por la cartera entera. Cuánto saldo sigue vivo en cada estado de mora. Qué proporción de los préstamos lleva más de sesenta días vencido. Cómo se movió ese número de un mes al otro.

Y esas respuestas no piden tablas nuevas. El préstamo prestamo_5503 ya guarda su estado fechado con la vigencia D6. El reporte regulatorio es leer ese mismo estado sobre todos los préstamos a la vez y sumar los montos.

# Saldo vivo de los préstamos en mora de 60 días — un corte; el reporte recorre cada estado
suma(u, "monto", Pattern(fixed={"estado": u.ind("mora_60_dias")},
                         type_constraint=u.ind("prestamo")))

Lo que el banco le exigió al modelo

Vale la pena cuantificar de qué tamaño es el problema que el modelo absorbe. Estas son las tablas aproximadas que un banco regional dedica a cada frente (el orden de magnitud que obliga a las cinco islas a existir):

Reunamos lo que estas cuatro escenas pusieron a prueba. Ninguna pidió una extensión del modelo; todas cayeron sobre la misma maquinaria que el libro venía construyendo:

El banco no logró tumbar al modelo. Y lo decisivo no es que aguantara, sino cómo lo hizo. Las reglas que en el spa parecían refinamientos elegantes resultaron ser, en banca, las únicas que sobreviven al regulador.

Cuando una decisión de diseño que nació por gusto reaparece como exigencia legal en el dominio más duro, deja de ser una hipótesis.

En el próximo capítulo subimos un peldaño de complejidad organizativa: un ERP donde una sola venta atraviesa inventario, finanzas y logística a la vez.