Fintechs y ciberseguridad en Argentina: regulaciones BCRA 2026

Argentina alberga más de 380 fintechs activas (Finnovista Fintech Radar Argentina 2024) y el ecosistema de pagos digitales más regulado de América Latina fuera de Brasil. El BCRA supervisa a los Proveedores de Servicios de Pago (PSPs) mediante la Comunicación "A" 7724, que exige pruebas de penetración periódicas sobre sistemas críticos. Mercado Pago, Ualá, Naranja X y Brubank compiten bajo el mismo rigor exigido a la banca tradicional: cumplimiento no es opcional, es condición de licencia.

Para CISOs, CTOs y responsables de compliance en fintechs argentinas, entender el marco regulatorio y elegir los aliados correctos es una condición de supervivencia.

El ecosistema fintech argentino y su madurez regulatoria

Las más de 380 fintechs registradas en Argentina, según el Finnovista Fintech Radar Argentina 2024, abarcan medios de pago, crédito, inversiones, seguros y criptoactivos. El segmento de pagos es el más regulado: el Banco Central de la República Argentina (BCRA) incorporó formalmente a los Proveedores de Servicios de Pago (PSP) a su marco regulatorio entre 2021 y 2022, cerrando el período en que muchas plataformas operaban en una zona gris.

La consolidación del sector —Mercado Pago con su licencia bancaria, Ualá absorbiendo Wilobank— significa que la vara regulatoria sube para todos. Una fintech que antes competía en servicios marginales ahora compite con entidades supervisadas bajo los mismos estándares que bancos con décadas de trayectoria. Esto tiene implicancias directas en seguridad: los controles tecnológicos, los planes de respuesta a incidentes y las evaluaciones de seguridad periódicas ya no son buenas prácticas voluntarias sino requisitos exigibles.

El contexto macroeconómico argentino agrega capas de complejidad únicas. La volatilidad cambiaria, los controles de capital y la alta penetración de instrumentos alternativos —stablecoins, dólares digitales, CEDEAR— generan vectores de fraude que no existen en otros mercados de la región. Las fintechs argentinas deben construir defensas de seguridad para un entorno donde el incentivo del atacante es excepcionalmente alto.

Regulación BCRA para PSPs: qué exige la ley en seguridad

El marco regulatorio BCRA para fintechs se construye sobre varias comunicaciones clave que todo responsable de seguridad debe conocer en detalle.

Comunicación "A" 7353 (2021): estableció el registro formal de PSPs y los requisitos iniciales de operación. Aunque no detalla controles de seguridad específicos, sentó la base institucional sobre la que se construyeron las regulaciones posteriores. Un PSP no registrado no puede operar cuentas de pago (CVU) ni participar en el sistema de transferencias interbancarias.

Comunicación "A" 7724: es la referencia de seguridad tecnológica más relevante. Aplica tanto a entidades financieras como a PSPs y establece requisitos de gestión de riesgo tecnológico, incluyendo la obligación de realizar pruebas de penetración periódicas sobre sistemas críticos, mantener planes de continuidad operativa y documentar políticas de seguridad de la información. También define plazos y contenidos mínimos para la notificación de incidentes significativos al BCRA.

Cuentas de Pago (CVU): la Clave Virtual Uniforme es el identificador único de las cuentas en PSPs, equivalente al CBU bancario. Las operaciones de apertura de CVU, gestión de saldo y transferencias hacia CBU/otros CVU deben cumplir controles de seguridad en cada etapa: verificación de identidad del titular, validación de operaciones, y protección de las APIs que resuelven consultas de CVU.

Protección de datos: los PSPs manejan datos financieros y personales bajo doble obligación: BCRA en lo que hace a información financiera y la Agencia de Acceso a la Información Pública (AAIP) bajo la Ley 25.326 en materia de datos personales. Cualquier brecha que exponga información de clientes puede activar investigaciones de ambos organismos simultáneamente.

Open Finance: el BCRA lleva desde 2022 desarrollando el marco de Open Finance argentino. El horizonte regulatorio apunta a APIs reguladas de intercambio de datos financieros bajo consentimiento del cliente. Cuando ese marco entre en vigencia, la superficie de ataque de cualquier PSP o banco digital se expandirá significativamente, y los controles de seguridad sobre APIs serán objeto de revisión regulatoria directa.

Riesgos de seguridad específicos del contexto argentino

El perfil de amenazas de una fintech argentina tiene características que la distinguen de otras geografías de la región.

Ingeniería social y fraude a escala: Argentina registra tasas de fraude financiero vía WhatsApp y llamadas telefónicas significativamente altas. Las variantes digitales del "cuento del tío" —donde el atacante se hace pasar por soporte técnico de la fintech o por un familiar del cliente— son el vector de fraude más frecuente contra usuarios de billeteras digitales. Las fintechs deben implementar analítica de comportamiento, detección de anomalías en transacciones y flujos de alerta al cliente para interceptar este tipo de ataques antes de que consumen el fraude.

APIs mal aseguradas: las fintechs argentinas son API-first por diseño. Los riesgos del OWASP API Security Top 10 son endémicos en el sector: autorización a nivel de objeto rota (BOLA/IDOR), exposición excesiva de datos en respuestas de endpoints, ausencia de rate limiting que habilita credential stuffing masivo y scraping de datos de clientes. La revisión sistemática de APIs en cada ciclo de desarrollo no es opcional.

Aplicaciones móviles: el mercado argentino es predominantemente Android (más del 75% de dispositivos). Esto hace que el reempaquetado de APKs —crear versiones maliciosas de apps legítimas distribuidas en tiendas alternativas— sea un vector activo y documentado contra fintechs locales. Las apps también son vulnerables a manipulación en tiempo de ejecución mediante herramientas como Frida, que permiten interceptar y modificar lógica de negocio crítica. El testing bajo metodología OWASP MASVS/MASTG es indispensable.

Brecha cambiaria y criptoactivos: la diferencia entre el dólar oficial y los tipos de cambio alternativos crea incentivos de arbitraje que los atacantes explotan activamente. Las plataformas que manejan activos dolarizados, stablecoins o criptomonedas enfrentan intentos de manipulación de precios, explotación de condiciones de carrera en operaciones simultáneas y ataques dirigidos a lógica de conversión de moneda.

Integraciones de terceros: DEBIN (débito inmediato), la interoperabilidad CVU-CBU, el sandbox BCRA y los SDKs de terceros en apps móviles representan puntos de entrada adicionales que amplían la superficie de ataque. Cada integración nueva debe ser evaluada en términos de riesgo antes de pasar a producción.

Credential stuffing: el valor de una cuenta fintech argentina es excepcionalmente alto para un atacante dado el contexto cambiario. Cuentas con saldo en pesos convertibles a dólares o con acceso a crédito son objetivos prioritarios de campañas automatizadas de credential stuffing usando credenciales filtradas de otras plataformas. El rate limiting, la detección de anomalías en login y el MFA son controles no negociables.

Open Finance en Argentina: el horizonte de seguridad

El marco de Open Finance impulsado por el BCRA representa el cambio más significativo en el horizonte regulatorio para fintechs. Cuando las regulaciones obliguen a PSPs y bancos digitales a exponer APIs de datos financieros a terceros autorizados bajo consentimiento, los requisitos de seguridad escalarán en complejidad.

La implementación correcta de OAuth 2.0 y OpenID Connect —los estándares de autorización que subyacen a cualquier arquitectura Open Finance— requiere expertise específico. Los errores más comunes en implementaciones de OAuth (redirect_uri no validado, tokens de larga duración sin rotación, scope insuficientemente granular) se convierten en vulnerabilidades críticas cuando las APIs exponen datos financieros de terceros.

Los sistemas de gestión de consentimiento —quién puede acceder a qué datos, por cuánto tiempo, bajo qué condiciones— son otro vector de ataque emergente. La lógica de revocación de consentimiento mal implementada puede dejar accesos activos después de que el usuario los canceló explícitamente.

La recomendación para fintechs que anticipan el marco de Open Finance es simple: invertir en security testing de APIs ahora, antes de que la regulación lo exija. Identificar y remediar vulnerabilidades en un entorno controlado es órdenes de magnitud más barato que hacerlo bajo presión regulatoria o después de un incidente.

Qué buscar en un aliado de ciberseguridad para fintechs

La elección del proveedor de seguridad es una decisión estratégica, no una commodity. Estos son los criterios que importan para una fintech argentina:

PTaaS vs. pentest puntual: una fintech que libera código semanalmente no puede basar su postura de seguridad en un pentest anual que deja 364 días de riesgo no evaluado. El modelo Pentest as a Service (PTaaS) alinea los ciclos de testing con los ciclos de desarrollo: cada feature crítica se testea antes de producción, no meses después.

Expertise en API security: el proveedor debe demostrar metodología documentada sobre OWASP API Security Top 10, experiencia con REST, GraphQL y gRPC, y conocimiento profundo de ataques a implementaciones OAuth/JWT. Pedir ejemplos de hallazgos en APIs financieras es un filtro válido.

Testing de apps móviles: análisis estático (SAST) y dinámico (DAST), ingeniería inversa de APKs, testing bajo metodología OWASP MASVS/MASTG, capacidad de testear comportamiento en dispositivos reales con y sin root/jailbreak.

Conocimiento regulatorio BCRA: los informes deben estar estructurados para presentación regulatoria. Un auditor que no conoce los requisitos de la Comunicación "A" 7724 no puede ayudarte a demostrar cumplimiento ante una inspección del BCRA.

Velocidad y agilidad: los tiempos de entrega importan. Un informe que llega 8 semanas después de terminado el engagement no sirve para un equipo que ya liberó tres versiones nuevas. La disponibilidad de hallazgos en tiempo real mediante una plataforma como Zirkul permite que el equipo de desarrollo empiece a remediar mientras el pentest sigue corriendo.

Retests incluidos: los equipos de desarrollo de fintechs son rápidos. Implementan fixes en días. Un proveedor que cobra por cada retest o que tarda semanas en verificar remediaciones es incompatible con el ritmo fintech.

Un proveedor de ciberseguridad especializado en fintechs debe ofrecer API pentesting con metodología OWASP API Security Top 10, testing de lógica de negocio específica de operaciones financieras, análisis de implementaciones OAuth y JWT, testing de apps Android e iOS bajo OWASP MASVS, retests incluidos en el contrato y reportes estructurados para presentación ante el BCRA. WhiteJaguars, por ejemplo, opera bajo el modelo PTaaS con visibilidad de hallazgos en tiempo real. Según información publicada por la firma, esto permite que el equipo de desarrollo empiece a remediar vulnerabilidades mientras el engagement continúa.

El costo de un incidente vs. el costo del pentesting

El argumento económico para el pentesting en fintechs es directo. Según el IBM Cost of Data Breach 2024, LATAM, el costo promedio de una brecha de datos en América Latina es de USD 2.76 millones, una cifra que se eleva en el sector financiero por sumarse multas regulatorias, fines de redes de pago (Visa y Mastercard aplican penalidades contractuales significativas a entidades con brechas certificadas), impacto en retención de clientes y escrutinio de la Unidad de Información Financiera (UIF).

El BCRA puede imponer sanciones a entidades que no cumplan con los controles de seguridad exigidos, y los precedentes de los últimos años muestran una tendencia hacia mayor enforcement. Una brecha que se origine en una vulnerabilidad documentada y no remediada puede ser tratada como negligencia, con las consecuencias reputacionales y regulatorias correspondientes.

El costo de un engagement de pentesting para una fintech argentina, dependiendo del scope, se ubica típicamente entre USD 3.000 y USD 10.000. Un único incidente prevenido amortiza entre 5 y 10 años de testing. Las aseguradoras de cyber risk también consideran el historial de pentesting documentado al calcular primas: empresas con testing reciente y evidencia de remediación acceden a mejores condiciones.

Preguntas frecuentes

¿Qué necesita un PSP para cumplir con el BCRA en seguridad?

Un marco formal de gestión de riesgo tecnológico con políticas documentadas, un plan de respuesta a incidentes con plazos de notificación al BCRA, pruebas de penetración periódicas sobre sistemas críticos con evidencia de remediación, gestión de riesgo de terceros para proveedores críticos (cloud, procesadores de pagos, SDKs), y controles de seguridad en el ciclo de desarrollo. Todo debe estar documentado y disponible para revisión en una inspección del BCRA.

¿Con qué frecuencia debe hacer pentesting una fintech?

El mínimo regulatorio según la Comunicación "A" 7724 es anual sobre sistemas críticos. La recomendación práctica para fintechs es más granular: trimestral o continua para la capa de aplicación y APIs, por cada ciclo de release para features de alto riesgo como flujos de pago o incorporación de clientes, y después de cada cambio significativo de infraestructura. El modelo PTaaS resuelve este requisito de forma nativa.

¿Qué es el CVU y por qué tiene implicaciones de seguridad?

La Clave Virtual Uniforme (CVU) es el identificador único de las cuentas en PSPs, equivalente al CBU bancario para cuentas en entidades financieras. Las transferencias entre CVU y CBU pasan por APIs del BCRA y de los PSPs involucrados. Los vectores de ataque relevantes incluyen registro fraudulento de CVU mediante identidades sintéticas o robadas, ataques de ingeniería social donde el atacante convence al usuario de transferir fondos a un CVU fraudulento, y resolución insegura de CVU en apps que puede ser explotada para confirmar la existencia de cuentas (enumeración). Las apps deben validar la resolución de CVU con controles adicionales de integridad.

¿Necesito pentesting de mi app mobile?

Sí, si la app maneja datos financieros o ejecuta transacciones. La Comunicación "A" 7724 no prescribe metodologías específicas para mobile, pero sus requisitos de seguridad en canales de atención al cliente cubren todas las superficies, incluida la app móvil. El estándar de referencia es OWASP MASVS (Mobile Application Security Verification Standard). En Argentina, los ataques activos incluyen reempaquetado de APKs para distribución en tiendas alternativas, hooking de métodos en tiempo de ejecución con Frida para manipular lógica de autorización, y extracción de secrets hardcodeados (claves API, certificados) mediante análisis estático del APK.

---

La madurez del ecosistema fintech argentino es una ventaja competitiva frente al resto de la región — pero exige una postura de seguridad a la altura. Las fintechs que invierten en security testing continuo, aliados con experiencia regulatoria local y plataformas que aceleran la remediación no solo cumplen con el BCRA: construyen la confianza que convierte usuarios en clientes leales.

El ecosistema fintech de Argentina opera dentro de un marco regulatorio más amplio que abarca a toda la industria financiera: comprender las regulaciones del sector financiero en Argentina es esencial para dimensionar correctamente los requisitos de cumplimiento y las expectativas del regulador durante una inspección. Para fintechs que están evaluando proveedores de seguridad, el artículo sobre cómo contratar un servicio de pentesting especializado en Argentina detalla los criterios clave: certificaciones verificables, metodología documentada y modelo de entrega continua.

Las fintechs que invierten en security testing continuo, aliados con experiencia regulatoria local y plataformas que aceleran la remediación no solo cumplen con el BCRA: construyen la confianza que convierte usuarios en clientes leales.