El 5 de febrero de 2026 el Banco Central emitió la Comunicación "A" 8398. Ocho días después, la "A" 8401 incorporó las hojas al texto ordenado. Entre las dos hicieron algo que la mayoría de los equipos técnicos de fintech todavía no terminó de dimensionar: pusieron a los Proveedores de Servicios de Pago bajo el mismo régimen de gestión de riesgos tecnológicos que rige para los bancos, y les dieron 180 días para adecuarse.

Si operás una billetera, un sistema de pagos o cualquier producto registrado como PSP ante el BCRA, ese reloj ya está corriendo. Y la adecuación no es un trámite de compliance que se resuelve con un documento. Es una serie de decisiones de arquitectura que, si no estaban contempladas desde el diseño, obligan a rehacer cosas que ya están en producción.

Qué cambió, en concreto

‍

El régimen de Requisitos Mínimos para la Gestión y Control de los Riesgos de Tecnología y Seguridad de la Información existía desde antes. Lo que cambió en febrero tiene tres aristas que importan para cómo está armada tu infraestructura.
La primera: los PSP ahora son sujetos obligados. Hasta febrero, el régimen completo aplicaba a entidades financieras e infraestructuras de pago sistémicas. Ahora alcanza también a los PSP del registro del BCRA, con un plazo de 180 días para implementar las adecuaciones. Una fintech de pagos que venía operando con criterios propios de seguridad pasa a tener que demostrar cumplimiento de un marco formal.
La segunda: se endureció el régimen de tercerización de servicios críticos. Antes de tercerizar un servicio de tecnología o ciberseguridad considerado crítico, ahora hay que notificar al BCRA con al menos 60 días corridos de anticipación, informando el servicio, las ubicaciones, el proveedor y los eventuales subcontratistas. Y el tercero tiene que asumir formalmente el compromiso de permitir auditorías del BCRA. Esto incluye a tu proveedor cloud, a tu integrador, a quien administre tu migración.
La tercera, y la que más condiciona la arquitectura: para tercerizaciones en el exterior, los proveedores deben estar en jurisdicciones alineadas con los estándares del GAFI, y la documentación clave —libros, legajos, registros relevantes— debe conservarse en Argentina. Esto tiene consecuencias directas sobre qué región de tu proveedor cloud podés usar y cómo estructurás el resguardo de datos.

El punto que conviene no perder de vista: el régimen es explícito en que tercerizar no libera a la entidad de sus responsabilidades. Podés delegar la ejecución, no la responsabilidad regulatoria. Si tu proveedor cloud no cumple, el problema es tuyo ante el BCRA.

Por qué esto es un problema de arquitectura, no de papeleo

La lectura fácil de una norma como esta es tratarla como un checklist de compliance: una lista de requisitos que el área legal tilda y archiva. Esa lectura es la que después genera el incidente.
Lo que la 8398 plantea, en el fondo, es una pregunta que es puramente de arquitectura: dónde tiene que correr cada carga de trabajo. No es lo mismo el core transaccional que un entorno de desarrollo. No es lo mismo una base con datos sensibles de clientes en producción que un modelo de analítica entrenado con datos anonimizados. No es lo mismo un motor antifraude que una web institucional. Cada una tiene una criticidad distinta, y el régimen te obliga a poder demostrar que entendés esa diferencia y que la infraestructura la refleja.
Eso no se resuelve con una política escrita. Se resuelve con decisiones concretas: qué va en qué región, cómo se segmentan los accesos, cómo se estructura la trazabilidad de manera que un evento sea auditable, dónde residen los backups, qué se puede tercerizar y bajo qué condiciones. Decisiones que viven en el Terraform, no en el documento de compliance.
La consecuencia práctica es que el momento de involucrar a quien diseña la infraestructura no es después de que legal interpretó la norma. Es antes. Una arquitectura diseñada sin la norma en mente y "ajustada" después casi siempre cuesta más que una diseñada con la norma como parámetro desde el inicio.

El plazo es el verdadero parámetro

Ciento ochenta días no es mucho cuando lo que está en juego es reorganizar dónde corren las cargas de trabajo de una operación que no puede frenar. Y acá aparece la tensión que conocemos bien de cualquier proyecto de infraestructura en producción: no podés parar la operación para adecuarte, pero tampoco podés ignorar el plazo.
La forma de resolver esa tensión no es técnica, es de secuencia. Lo primero no es migrar nada: es mapear. Qué cargas de trabajo tenés, qué criticidad tiene cada una bajo el criterio de la norma, qué está tercerizado y bajo qué condiciones, qué proveedores necesitan asumir el compromiso de auditoría. Recién con ese mapa se puede definir qué hay que mover, qué hay que reconfigurar y qué ya cumple. La mayoría de las adecuaciones que se frenan es porque arrancaron a ejecutar antes de tener ese mapa completo.
Hay un segundo orden de magnitud que conviene anticipar: la norma no es estática. El BCRA viene actualizando este marco con una frecuencia que no tiene parangón en otros mercados —la 8398 y la 8401 son apenas las últimas de una secuencia. Una arquitectura que cumple hoy pero que no tiene flexibilidad para adaptarse a la próxima comunicación es una solución que va a generar retrabajo dentro de un año. La pregunta de diseño no es solo "cumple con la 8398", es "puede adaptarse a la 8410 sin rehacerse".

Qué haría si tuviera un PSP con el reloj corriendo

Empezaría por el mapa de cargas de trabajo y su criticidad, antes de tocar infraestructura. Sin ese diagnóstico, cualquier movimiento es a ciegas.
Revisaría los contratos de tercerización vigentes contra el nuevo régimen: qué proveedores están en el exterior, en qué jurisdicción, y si pueden asumir el compromiso de auditoría que ahora exige el BCRA. Ahí es donde suelen aparecer las sorpresas más caras.
Y trataría la flexibilidad regulatoria como un requisito de arquitectura de primera clase, no como un agregado. En un contexto donde la norma cambia cada pocos meses, construir para el cumplimiento de hoy es construir deuda para mañana.
Modernizar la infraestructura de una entidad financiera argentina no es un problema solo técnico ni solo regulatorio: es resolver los dos al mismo tiempo, con la operación corriendo y sin margen para frenar. Si tu equipo está mirando el plazo de 180 días y todavía no tiene el mapa, en Renaiss hacemos consultoría cloud para empresas argentinas que trabajan bajo regulación del BCRA. Escribimos sobre cómo encarar estos proyectos en migrar a cloud en una fintech argentina y en modernización de core bancario.

‍