BIAN es un vocabulario. Un catálogo de nombres acordados para describir lo que hace un banco, publicado por una asociación sin ánimo de lucro —el Banking Industry Architecture Network— que reúne desde 2008 a bancos como BBVA, Santander e ING junto a proveedores como IBM, Microsoft y Temenos.
Eso es todo lo que es. Y entender exactamente eso ahorra más dinero que cualquier otra cosa que puedas leer sobre el estándar, porque casi todo lo que se vende como «implementar BIAN» consiste en asumir que es otra cosa.
El problema que resuelve
Dentro de un banco, la misma operación tiene tres nombres distintos según con quién hables. Lo que el canal digital llama alta de cliente, el core lo llama apertura de contrato y el área de riesgo lo llama onboarding. Los tres equipos creen estar hablando de lo mismo, y descubren que no durante la integración.
Ese desacuerdo no es un problema de comunicación: es un problema de arquitectura. Cuando no hay un nombre acordado para una capacidad, cada sistema inventa el suyo, y cada integración entre dos sistemas se convierte en una traducción hecha a mano que alguien tiene que mantener.
BIAN pone el nombre. Después de eso, cuando el canal pide algo, el core sabe qué le están pidiendo.
Los Service Domains
BIAN descompone el banco en unas trescientas unidades funcionales llamadas Service Domains. Cada una representa una capacidad de negocio con una frontera clara: qué hace, qué información gobierna y qué se le puede pedir.
Algunos de los que más aparecen en una modernización: Customer Offer, Current Account, Credit Facility, Payment Execution, Fraud Evaluation, Regulatory Compliance.
Coreless banking
De ahí sale la idea de coreless banking: si cada capacidad tiene una frontera y un nombre, el banco no necesita un único núcleo monolítico que lo haga todo. Puede ensamblarse con componentes especializados, cada uno alineado a un Service Domain, reemplazables por separado.
Eso no significa quedarse sin core. Significa que el core deja de ser el sitio donde vive todo y pasa a ser un componente más, que se puede sustituir sin reescribir el banco.
Las tres cosas que BIAN no hace
Aquí es donde la mayoría de las presentaciones terminan y donde empieza el trabajo real.
No te entrega APIs listas para implementar. BIAN describe qué información gobierna cada dominio y qué se le puede pedir. El contrato concreto —los campos, los códigos de error, qué pasa cuando el proveedor no responde— lo escribes tú.
No decide dónde va la frontera con tu core. Qué capacidad se envuelve y se deja quieta, cuál se reimplementa y cuál se jubila es una elección que depende de tu paisaje, de tu contrato con el proveedor y de lo que tu equipo puede operar. El estándar no conoce ninguna de las tres cosas.
No acelera tu calendario por sí solo. Ordena el vocabulario, que es mucho; pero el tiempo que tarda tu banco en decidir dónde poner una frontera sigue siendo exactamente el mismo.
Por dónde empezar
La adopción no exige transformar el banco de una vez, y conviene que no lo haga:
- Mapear tu arquitectura actual contra los Service Domains, para saber qué capacidades tienes y dónde están repetidas.
- Priorizar los dominios que hoy generan más fricción: los que todo el mundo tiene que integrar y nadie quiere tocar.
- Probar con dos o tres, de punta a punta, incluyendo la operación. No la maqueta: el dominio funcionando en producción.
- Extender con lo aprendido, que casi siempre cambia el plan original.
En México, la presión de las fintechs, los requerimientos de la CNBV y lo que un cliente digital da por sentado están empujando esa conversación en casi todos los bancos tradicionales. BIAN ofrece una ruta que no obliga a un reemplazo de golpe, que es donde estos programas se rompen.
Lo que sigue después de entender el estándar
Las tres decisiones que BIAN deja en tus manos —dónde poner la frontera, cómo se traduce el contrato y qué se reemplaza frente a qué se envuelve— determinan si la modernización se sostiene o se cae en la integración.
BIAN en la práctica: las tres decisiones que el estándar no toma por ti