.jpg)
Com. A 8398: errores de los PSP frente a la adecuación normativa
Com. A 8398: errores de los PSP frente a la adecuación normativa
Acompañamos procesos de adecuación a la A 7724 en entidades financieras desde 2023, y hoy los acompañamos a PSP frente a su extensión bajo la Com. A 8398. El patrón de errores se repite. No son errores de conocimiento técnico: los equipos de tecnología de los PSP argentinos suelen tener buen nivel. Son errores de enfoque y de gestión del proceso.
De la misma forma que había ocurrido con la Com A 7724 para entidades financieras, con la Com. A 8398, emitida por el BCRA en febrero de 2026, el patrón de errores de los Proveedores de Servicios de Pago (PSP) vuelve a repetirse. De hecho, no se tratan de inconvenientes de conocimiento técnico, sino problemas principalmente de enfoque y gestión del proceso.
Estos son algunos de los errores más frecuentes por parte de los PSP en su adecuación normativa.
Cuando la adecuación se trata como un proyecto de IT, el resultado es un conjunto de controles técnicos razonables sin el marco de gobierno ni la trazabilidad documental que la norma exige. Un PSP puede tener infraestructura sólida y no estar en condiciones de demostrar cumplimiento.
La norma exige un marco acorde a la complejidad del PSP. En este sentido existen dos desvíos opuestos: PSP que subestiman su exposición porque son chicos, y PSP que intentan replicar el marco de control de un banco de primera línea sin necesidad ni presupuesto para sostenerlo. Los dos terminan con un marco desalineado de su perfil de riesgo real, y eso se detecta rápido en una inspección.
Tener una política no es lo mismo que poder demostrar que se aplica. El BCRA pide actas de comité, minutas de revisión de riesgos, reportes de indicadores, registros de pruebas de continuidad. Construir esa evidencia con meses de atraso, justo antes de una inspección, es notoriamente distinto de sostenerla como parte de la operación normal. Un supervisor lo nota.
La mayoría de los PSP terceriza procesamiento, infraestructura cloud, KYC o biometría. Es común que esos contratos no contemplen niveles de servicio, métricas de desempeño ni cláusulas ante cambios en la prestación. Renegociar contratos ya firmados, muchas veces con proveedores del exterior, es la tarea que más tiempo consume en todo el proceso, porque no depende solo del PSP.
La norma pide que la estrategia de seguridad esté alineada con la estrategia de negocio. Cuando Compliance redacta políticas sin involucrar a Tecnología, y Tecnología implementa controles sin involucrar a Negocio, el marco queda completo en el papel y no se aplica en la operación diaria.
Los PSP que usan IA para scoring o prevención de fraude, o biometría para autenticación, suelen tratarlas como decisiones de producto. La norma las trae al terreno regulatorio: exige evaluación de impacto, apetito de riesgo definido y mitigación de riesgos específicos, como la tasa de falsos positivos en biometría. Es uno de los gaps que más aparece en los diagnósticos iniciales.
El cuello de botella no es la implementación de controles técnicos puntuales. Es construir un historial de gobierno, con comités que sesionan, revisan y documentan de forma sostenida. Ese historial no se arma en las últimas semanas antes del plazo.
Ningún error de esta lista es puramente técnico. Todos se originan en cómo se organiza el proceso puertas adentro. Un diagnóstico temprano, con Directorio, Compliance, Tecnología y Negocio en la misma mesa desde el primer día, es lo que separa un proceso ordenado de uno resuelto contra el reloj.
De la misma forma que había ocurrido con la Com A 7724 para entidades financieras, con la Com. A 8398, emitida por el BCRA en febrero de 2026, el patrón de errores de los Proveedores de Servicios de Pago (PSP) vuelve a repetirse. De hecho, no se tratan de inconvenientes de conocimiento técnico, sino problemas principalmente de enfoque y gestión del proceso.
Estos son algunos de los errores más frecuentes por parte de los PSP en su adecuación normativa.
1. Delegar todo a Tecnología
Cuando la adecuación se trata como un proyecto de IT, el resultado es un conjunto de controles técnicos razonables sin el marco de gobierno ni la trazabilidad documental que la norma exige. Un PSP puede tener infraestructura sólida y no estar en condiciones de demostrar cumplimiento.
2. Ignorar la proporcionalidad
La norma exige un marco acorde a la complejidad del PSP. En este sentido existen dos desvíos opuestos: PSP que subestiman su exposición porque son chicos, y PSP que intentan replicar el marco de control de un banco de primera línea sin necesidad ni presupuesto para sostenerlo. Los dos terminan con un marco desalineado de su perfil de riesgo real, y eso se detecta rápido en una inspección.
3. Evidencia que se genera recién antes de la inspección
Tener una política no es lo mismo que poder demostrar que se aplica. El BCRA pide actas de comité, minutas de revisión de riesgos, reportes de indicadores, registros de pruebas de continuidad. Construir esa evidencia con meses de atraso, justo antes de una inspección, es notoriamente distinto de sostenerla como parte de la operación normal. Un supervisor lo nota.
4. Contratos con terceros críticos sin los puntos mínimos exigidos
La mayoría de los PSP terceriza procesamiento, infraestructura cloud, KYC o biometría. Es común que esos contratos no contemplen niveles de servicio, métricas de desempeño ni cláusulas ante cambios en la prestación. Renegociar contratos ya firmados, muchas veces con proveedores del exterior, es la tarea que más tiempo consume en todo el proceso, porque no depende solo del PSP.
5. Compliance, tecnología y negocio trabajando por separado
La norma pide que la estrategia de seguridad esté alineada con la estrategia de negocio. Cuando Compliance redacta políticas sin involucrar a Tecnología, y Tecnología implementa controles sin involucrar a Negocio, el marco queda completo en el papel y no se aplica en la operación diaria.
6. No cubrir IA y biometría
Los PSP que usan IA para scoring o prevención de fraude, o biometría para autenticación, suelen tratarlas como decisiones de producto. La norma las trae al terreno regulatorio: exige evaluación de impacto, apetito de riesgo definido y mitigación de riesgos específicos, como la tasa de falsos positivos en biometría. Es uno de los gaps que más aparece en los diagnósticos iniciales.
7. Arrancar tarde
El cuello de botella no es la implementación de controles técnicos puntuales. Es construir un historial de gobierno, con comités que sesionan, revisan y documentan de forma sostenida. Ese historial no se arma en las últimas semanas antes del plazo.
El punto en común
Ningún error de esta lista es puramente técnico. Todos se originan en cómo se organiza el proceso puertas adentro. Un diagnóstico temprano, con Directorio, Compliance, Tecnología y Negocio en la misma mesa desde el primer día, es lo que separa un proceso ordenado de uno resuelto contra el reloj.