Arquitectura, riesgo y compliance desde el diseño: la base de una innovación que sí escala#
Hay una frase que muchas organizaciones siguen repitiendo sin decirla exactamente así: primero innovamos y luego revisamos. Primero sale la idea, después el prototipo, luego la presión comercial, y al final —cuando ya hay fecha, sponsor y expectativa creada— entran arquitectura, riesgo, seguridad, cumplimiento y operación.
Ese orden es una fábrica de fricción.
En servicios financieros, no porque exista mala voluntad, sino porque ese modelo empuja a todas las áreas a chocar cuando el costo de cambiar ya subió. Negocio siente que control frena. Riesgo siente que lo invitan demasiado tarde. Arquitectura termina corrigiendo excepciones en lugar de diseñar capacidades. Compliance aparece como filtro terminal. Y operación recibe un cambio que nadie aterrizó completamente en el mundo real.
Luego la organización concluye que innovar en banca es lento.
Mi lectura es otra: lo que es lento no es innovar con control. Lo que es lento es innovar mal secuenciado.
¿Por qué arquitectura, riesgo y compliance deben entrar desde el diseño?#
Porque en una institución financiera regulada la innovación solo genera valor durable si puede escalar con gobierno, trazabilidad, operación y control. Cuando arquitectura, riesgo y compliance participan desde el inicio, la organización reduce retrabajo, hace explícitas las restricciones importantes y convierte la regulación en criterio de diseño, no en corrección tardía.
Como plantea el Basel Committee on Banking Supervision (BCBS), en el Banco de Pagos Internacionales (BIS), una gobernanza interna sólida es la base de una gestión efectiva del riesgo operacional y la función de gobernanza del riesgo operacional debe integrarse por completo en la estructura general de gobierno de riesgos. A su vez, el NIST Cybersecurity Framework (CSF) 2.0 ubica Govern en el centro del marco para conectar estrategia, expectativas, política, prioridades y supervisión.
El error no es tener controles; es integrarlos demasiado tarde#
Hay una diferencia enorme entre control temprano y revisión tardía.
El control temprano ayuda a diseñar.
La revisión tardía obliga a corregir.
Cuando una iniciativa se diseña desde el inicio con participación de arquitectura, riesgo y cumplimiento, la conversación cambia de tono. Ya no se trata de “aprobar o rechazar” algo casi terminado. Se trata de definir desde el principio qué restricciones son irrenunciables, qué riesgos cambian, qué patrones pueden reutilizarse, qué evidencias se necesitarán y qué decisiones no pueden dejarse para la última milla.
De nuevo, el BCBS deja una idea muy útil para aterrizar esta discusión: la gobernanza sólida del riesgo operacional no es un accesorio; es parte del marco que permite que productos, actividades, procesos y sistemas operen con control. En banca, esa lógica implica que riesgo no debería entrar como invitado al final, sino como parte constitutiva del diseño.
La innovación que sí escala se diseña como capacidad, no como excepción#
Aquí entra arquitectura.
Muchas organizaciones siguen tratando la arquitectura como un área que “revisa” diseños ajenos o “documenta” lo decidido. Pero el valor real de arquitectura no está en notar que algo incumple. Está en ayudar a que la innovación no dependa de soluciones artesanales, integraciones frágiles o decisiones imposibles de sostener.
Una innovación escala bien cuando:
- reutiliza capacidades existentes en vez de duplicarlas,
- se integra a un modelo de datos y control ya gobernado,
- reduce variabilidad innecesaria,
- evita dependencias ocultas con terceros,
- y puede operarse con trazabilidad, monitoreo y continuidad.
El NIST CSF 2.0 refuerza esta idea al señalar que está diseñado para ayudar a organizaciones de todos los tamaños y sectores a gestionar y reducir riesgos de ciberseguridad, independientemente de su nivel de madurez. Esa observación es importante porque recuerda que diseñar con control no es un lujo de organizaciones hipermaduras; es una disciplina básica para construir cambio sostenible.
Compliance by design no significa burocracia by design#
Vale la pena decirlo con claridad, porque muchas veces se caricaturiza mal esta conversación.
Integrar cumplimiento desde el diseño no significa llenar al proyecto de checklists muertos, comités innecesarios o documentación ornamental. Significa algo más útil: traducir obligaciones, restricciones regulatorias y compromisos de control en decisiones de diseño tempranas.
En México, eso importa especialmente cuando una iniciativa toca pagos, datos personales, onboarding, autenticación, terceros o canales digitales. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares establece desde su artículo 1 que el tratamiento de datos personales debe ser legítimo, controlado e informado. Y cuando el modelo de negocio cae dentro del alcance fintech regulado, la Ley para Regular las Instituciones de Tecnología Financiera confirma que estos servicios operan dentro de un marco formal supervisado por la Comisión Nacional Bancaria y de Valores y el Banco de México.
Cuando una iniciativa usa datos personales, biometría, perfiles o automatización sobre clientes, el cumplimiento no puede ser una idea posterior. Tiene que estar embebido en el diseño.
Por eso me gusta más pensar en compliance by design como una práctica de traducción: convertir norma, riesgo y responsabilidad en arquitectura, proceso, evidencias y controles operables.
Un ejemplo realista: innovación rápida en pagos sin diseño temprano#
Imaginemos una institución financiera que quiere acelerar una nueva experiencia de pagos y transferencias.
En el enfoque superficial, producto quiere lanzar rápido una experiencia más simple, el área comercial empuja la fecha, tecnología integra un proveedor, y después aparece la conversación sobre controles, seguridad, trazabilidad y reglas operativas. El proyecto ya viene cargado de urgencia, así que cualquier observación se interpreta como freno.
En el enfoque maduro, la misma iniciativa arranca distinto. Desde el inicio se pregunta:
- qué riesgo operativo cambia,
- qué controles del canal o del proceso son obligatorios,
- qué dependencias hay con terceros o con el sistema de pagos,
- qué evidencia operativa y de seguridad se necesitará,
- qué datos se tratarán,
- y qué arquitectura soportará la trazabilidad y el monitoreo.
Ese segundo enfoque no es más lento por definición. De hecho, suele ser más rápido en el tiempo total, porque evita correcciones masivas cerca de producción.
La Circular 14/2017 de Banco de México sobre las Reglas del SPEI muestra con claridad que los participantes están sujetos a obligaciones específicas y que deben designar responsables de cumplimiento normativo y oficiales de seguridad de la información del SPEI. En entornos críticos como pagos, el control no puede ser posterior al diseño. Tiene que quedar incorporado desde el principio.
Lo que cambia cuando arquitectura, riesgo y compliance trabajan como sistema#
Cuando estas funciones entran temprano, pasan al menos cinco cosas buenas.
Primero, baja el retrabajo.
La organización resuelve antes conflictos que de todos modos iban a aparecer.
Segundo, sube la calidad de decisión.
Porque el sponsor entiende desde el inicio el costo real, la complejidad y la exposición que está comprando.
Tercero, se reduce la cultura del “último filtro”.
Riesgo y compliance dejan de ser vistos como áreas que solo detienen, y pasan a ser parte del mecanismo que diseña algo viable.
Cuarto, la arquitectura recupera su papel habilitador.
Ya no se limita a validar documentación o detectar inconsistencia tardía.
Quinto, la velocidad se vuelve repetible.
No depende de heroísmo, presión o excepciones negociadas, sino de un modelo más maduro de cambio.
Los Principios para la resiliencia operacional del BCBS refuerzan esta lógica al exigir que los bancos asuman que las disrupciones ocurrirán y definan tolerancias para la interrupción de operaciones críticas. Eso obliga a diseñar cambio con una mentalidad de continuidad, no solo de entrega.
El verdadero cuello de botella no es riesgo ni compliance; es el diseño tardío del flujo#
Aquí es donde me interesa ser especialmente claro.
No creo que el problema principal sea que existan demasiados controles. Tampoco creo que riesgo o compliance sean, por naturaleza, áreas que frenan. Lo que sí creo es que muchas organizaciones diseñan mal el flujo completo de innovación.
Primero dejan crecer el proyecto.
Después intentan validarlo.
Y luego culpan al control por el costo de haberlo integrado tarde.
Esa secuencia produce una ilusión peligrosa: parece que la fricción viene del control, cuando en realidad viene del momento en que se decidió involucrarlo.
Aquí el NIST CSF 2.0 vuelve a ser útil: Govern no aparece como un apéndice. Está en el centro del marco precisamente porque informa cómo la organización implementa las demás funciones. Dicho en términos más simples: la gobernanza no debería vivir fuera del cambio. Debería organizarlo.
Reflexión de Arquitectura#
La innovación más cara no es la que fracasa en una prueba. Es la que llega lejos con una arquitectura débil, con controles pegados al final y con dependencias que nadie quiso ver cuando todavía era barato rediseñar. La arquitectura madura no entra para poner sello. Entra para evitar que la organización compre complejidad irreversible disfrazada de velocidad.
Lo que un CTO debería leer detrás de esta discusión#
Desde dirección tecnológica, este tema no se resuelve pidiendo a las áreas de control “ser más ágiles” como si el problema fuera actitudinal. La solución está en rediseñar el modelo de intervención.
Eso implica, al menos:
- distinguir qué tipo de iniciativas requieren qué nivel de revisión,
- definir umbrales de riesgo e impacto,
- integrar temprano a arquitectura, riesgo, seguridad, cumplimiento y operación,
- y medir no solo cuánto tarda el delivery, sino cuánto retrabajo genera la secuencia de decisión.
Si una organización sigue tratando arquitectura, riesgo y compliance como áreas que entran después de la idea, seguirá viviendo la misma película: urgencia al principio, fricción al final, y una falsa conclusión de que innovar con control es inviable.
Reflexión CTO#
La velocidad sostenible no depende de pedir menos control. Depende de diseñar mejor cómo intervienen las funciones que sostienen el control. Un CTO maduro no intenta ganar tiempo quitando restricciones clave. Intenta ganar tiempo moviendo esas restricciones al momento correcto del diseño.
Mi opinión: la innovación bien gobernada no compite con la velocidad; compite con la improvisación#
Me parece que aquí está una de las confusiones más dañinas en muchas organizaciones financieras.
Se sigue hablando como si hubiera dos bandos: el de la innovación y el del control. El de los que quieren mover y el de los que quieren revisar. El de negocio y el de cumplimiento. El de producto y el de arquitectura.
Esa narrativa ya no sirve.
La distinción útil no es innovación versus control.
La distinción útil es innovación diseñada versus innovación improvisada.
La primera puede escalar.
La segunda puede arrancar rápido, pero casi siempre acaba cobrando la factura después.
Conclusión#
La innovación que sí escala en servicios financieros no nace de correr primero y revisar después. Nace de algo más exigente: diseñar desde el principio con arquitectura, riesgo, compliance, seguridad y operación como partes del mismo sistema.
Eso no le quita velocidad al negocio. Le quita improvisación al cambio.
En 2026, esa diferencia importa más que nunca. Porque el mercado sí exige rapidez, pero la regulación, la operación y la confianza del cliente siguen cobrando muy caro los atajos mal diseñados.
Por eso, para mí, la tesis es simple: en banca y servicios financieros, la innovación sostenible no se consigue a pesar de arquitectura, riesgo y compliance. Se consigue cuando esas funciones dejan de llegar tarde.
Glosario breve#
Basel Committee on Banking Supervision (BCBS)
Comité de Supervisión Bancaria de Basilea. Emite principios internacionales para fortalecer supervisión bancaria, gestión de riesgos y resiliencia operacional.
NIST (National Institute of Standards and Technology)
Instituto Nacional de Estándares y Tecnología de Estados Unidos. Publica marcos de referencia muy usados para ciberseguridad, gestión de riesgos e inteligencia artificial.
NIST CSF 2.0
Cybersecurity Framework 2.0 de NIST. Organiza la gestión del riesgo de ciberseguridad en funciones como Govern, Identify, Protect, Detect, Respond y Recover.
Compliance by design
Enfoque que busca incorporar requisitos regulatorios, de control y cumplimiento desde el diseño de la solución, en lugar de revisarlos al final.
SPEI
Sistema de Pagos Electrónicos Interbancarios operado por Banco de México. Su operación está sujeta a reglas específicas publicadas por Banxico.
LFPDPPP
Ley Federal de Protección de Datos Personales en Posesión de los Particulares. En México, es central cuando una solución trata datos personales de clientes o usuarios.
Referencias#
Basel Committee on Banking Supervision, Revisions to the Principles for the Sound Management of Operational Risk
https://www.bis.org/bcbs/publ/d515.pdfBasel Committee on Banking Supervision, Principles for Operational Resilience
https://www.bis.org/bcbs/publ/d516.pdfNational Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdfBanco de México, Circular 14/2017 – Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado con modificaciones)
https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdfCámara de Diputados, Ley para Regular las Instituciones de Tecnología Financiera
https://www.diputados.gob.mx/LeyesBiblio/pdf/LRITF.pdfCámara de Diputados, Ley Federal de Protección de Datos Personales en Posesión de los Particulares
https://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf