BIAN en la práctica: las tres decisiones que el estándar no toma por ti

La mayoría de las presentaciones sobre BIAN terminan donde empieza el trabajo difícil. Explican qué es BIAN: que existen unos trescientos Service Domains, que el banco se descompone en capacidades y que eso habilita una modernización gradual. Todo cierto, y todo insuficiente.

Después de instanciar modelos taxonómicos alineados a BIAN en varias instituciones financieras mexicanas, lo que he aprendido es que el estándar resuelve menos de lo que la gente espera, y que eso no es un defecto. Es su diseño. Una de esas plataformas —siete capas, 161 microservicios, 249 APIs— está hoy en producción.

Lo que BIAN es, en una línea

BIAN es un vocabulario. Un acuerdo de la industria sobre cómo nombrar y delimitar las funciones de un banco, para que dos personas que hablan de "originación de crédito" se refieran a lo mismo y para que dos sistemas que la implementan puedan entenderse.

Eso es mucho. El vocabulario compartido es exactamente lo que falta cuando un banco descubre que tiene la misma capacidad construida tres veces en tres canales distintos, con tres nombres y tres dueños.

Pero un vocabulario no es un diseño. Y ahí empieza el malentendido más caro que veo en el mercado.

El malentendido: creer que BIAN entrega APIs listas

He visto equipos abrir el portal de BIAN esperando encontrar contratos que se puedan implementar tal cual. No es así, y esperar eso lleva a una de dos conclusiones igualmente equivocadas: o "el estándar está incompleto", o —peor— se implementa literalmente la semántica del estándar y se termina con una capa de servicios que nadie del banco reconoce como su negocio.

Las semánticas de BIAN describen qué hace un dominio de servicio y qué información controla. No dicen cómo se ve tu contrato, qué campos necesita tu canal móvil, ni cómo se comporta bajo la normativa mexicana. Esa traducción es trabajo de arquitectura, y es donde se gana o se pierde la modernización.

BIAN te da el mapa de la ciudad. No te dice por dónde pasa tu camión, a qué hora, ni qué calles aguantan su peso.

Decisión 1: la granularidad

El estándar define dominios de servicio con un nivel de descomposición determinado. Tu banco no tiene por qué construir uno por cada uno.

La pregunta real no es "¿cuántos Service Domains implemento?" sino "¿qué unidad puede desplegarse, versionarse y fallar de forma independiente sin arrastrar a las demás?". A veces un componente cubre tres dominios del estándar porque separarlos crearía tres despliegues acoplados que siempre se liberan juntos. A veces un solo dominio necesita partirse porque dos de sus comportamientos tienen ciclos de cambio radicalmente distintos.

El criterio que uso: la alineación semántica es obligatoria, la correspondencia uno a uno no lo es. Cada componente declara a qué dominios del estándar responde. Que sean uno, tres o medio, lo decide el acoplamiento real, no la tabla.

Quien implementa un microservicio por cada Service Domain porque el estándar los lista así no está haciendo arquitectura: está transcribiendo.

Decisión 2: la frontera con el core

Esta es la que más presupuesto consume cuando se decide tarde.

BIAN describe el banco completo, incluyendo funciones que hoy viven dentro de tu core y que no vas a mover en los próximos cinco años. La pregunta no es si alineas todo el banco al estándar —eso es un ejercicio de papel—, sino dónde pones la frontera entre lo que reconstruyes con semántica nueva y lo que envuelves tal como está.

Lo que funciona: una capa anticorrupción que expone las funciones del core con el vocabulario estándar, sin tocar el core. El canal consume semántica moderna; el núcleo sigue hablando como siempre habló. Eso permite reemplazar el core después, o nunca, sin que el canal se entere.

Lo que no funciona: dejar que el modelo del core se filtre hacia arriba "provisionalmente". Nunca es provisional. Diez años después, los campos del mainframe siguen apareciendo en el contrato de la app móvil, y cada intento de sustituir el núcleo se topa con que medio banco depende de sus estructuras internas.

Una consecuencia práctica

Esa frontera determina algo más importante que la arquitectura: determina si el banco puede cambiar de proveedor de core. Un banco con frontera bien puesta negocia distinto que uno que no la tiene. Es una decisión de arquitectura con efecto comercial directo.

Decisión 3: quién es dueño del dato

BIAN incorpora dos conceptos que suelen ignorarse porque no son vistosos, y que son los que de verdad ordenan una modernización: el registro de control de cada dominio y los calificadores de comportamiento que lo modulan.

Traducido: cada dominio de servicio es dueño de una información concreta, y nadie más debería escribirla. Cuando ese principio se respeta, las duplicidades se vuelven visibles de inmediato —dos componentes que reclaman el mismo registro de control no pueden coexistir sin que alguien decida—. Cuando se ignora, el banco termina con tres verdades sobre el mismo cliente y un comité mensual para reconciliarlas.

En la práctica, este es el instrumento de gobierno más útil que ofrece el estándar. No por la API: por la conversación que obliga a tener antes de construir.

Sobre "coreless": lo que no significa

Coreless banking no significa operar sin core. Significa que ningún proveedor concentra la definición de tu negocio.

Un banco coreless sigue teniendo un motor contable, un motor de productos y un libro mayor. La diferencia es que esas piezas son sustituibles, porque las reglas de negocio, la orquestación y los contratos hacia los canales viven en un espacio que el banco controla y que está descrito con vocabulario de industria, no con el diccionario de un fabricante.

La trampa de calendario: el contrato y el runtime no son el mismo frente

Hay un error de secuencia que no tiene nada que ver con BIAN y que hunde igual a los programas que lo adoptan: tratar la migración del contrato y la migración del runtime como un solo frente.

Ocurre así. El equipo decide que, ya que va a mover el servicio a la plataforma nueva, aprovecha para publicar el contrato nuevo con semántica estándar. Suena eficiente. El efecto real es que el canal —que tiene su propio calendario, sus propias pruebas y una aplicación ya publicada en dos tiendas— pasa a determinar la fecha del runtime. Basta que el canal se atrase una vez para que se atrase el programa entero.

Lo que funciona es separar los dos frentes. Las aplicaciones que ya consumen el servicio siguen llamando al contrato de siempre, sin que se les pida un solo cambio. En medio se coloca una pieza que traduce: recibe la llamada con la forma vieja y la convierte a la que espera el servicio nuevo. Así el equipo de plataforma migra cuando está listo, y el canal adopta la semántica estándar más adelante, en su propio calendario.

Esa traducción es trabajo desechable: el día que el canal adopte el contrato nuevo, se borra. Lo que compra a cambio es que una fecha deje de depender de la otra.

Es la misma idea de la frontera con el core, una capa más arriba: quien controla el contrato controla el calendario.

Cómo se ve una adopción que sí avanza

El consejo habitual —"mapea tu arquitectura, prioriza, haz un piloto de dos o tres dominios"— no está mal, pero omite el paso donde fracasan los proyectos. Este es el encadenamiento que uso:

1. De la capacidad al dominio. Se parte de las capacidades de negocio que el banco ya reconoce, no del catálogo del estándar. El mapeo va de lo que el banco hace hacia el vocabulario, nunca al revés.
2. Del dominio al registro de control. Se declara qué información controla cada dominio y quién la escribe. Aquí aparecen las duplicidades, y aquí es donde alguien tiene que decidir.
3. Del registro al contrato. Hasta este punto se diseña la API, con la semántica estándar como referencia y las necesidades reales del canal como requisito. El contrato se escribe antes que el código.
4. Del contrato al componente. Y solo entonces se decide la granularidad de despliegue, con el criterio de acoplamiento, no de catálogo.

Cada paso deja trazabilidad hacia el anterior. Cuando alguien pregunta, dos años después, por qué existe un servicio, la respuesta está escrita y se puede auditar. Esa trazabilidad es lo que convierte un mapeo BIAN en un activo de gobierno en vez de un diagrama que envejece en una carpeta.

El contexto mexicano

Dos particularidades locales que cambian cómo se aplica el estándar.

La primera es regulatoria. Las disposiciones de la CNBV imponen requisitos de trazabilidad, continuidad y control sobre servicios contratados con terceros que no aparecen en ningún modelo internacional. Un mapeo de dominios que no sabe dónde caen esas obligaciones sirve para la presentación, no para el proyecto.

La segunda es de mercado. Muchos bancos mexicanos operan cores propietarios con décadas de reglas de negocio que nadie documentó nunca. En ese escenario, el valor inmediato de BIAN no es rediseñar el banco: es tener un vocabulario neutral para descubrir lo que hoy existe, antes de decidir qué se toca.

En resumen

BIAN no moderniza tu banco. Te da el lenguaje para decidir cómo hacerlo, y elimina las discusiones que se producen solo porque dos áreas usan la misma palabra para cosas distintas.

El trabajo real sigue siendo tuyo: dónde pones la frontera, qué granularidad eliges, quién es dueño de cada dato. El estándar es deliberadamente silencioso en esas tres, y esa es exactamente la razón por la que funciona en bancos muy distintos entre sí.