Pentest para fintech y banco digital: lo que exige la Resolución CMN 4.893 (2026)

Sí: hoy el Banco Central de Brasil exige pentest. Desde la Resolución CMN 5.274, del 18 de diciembre de 2025, la Resolución CMN 4.893 (la “BACEN 4.893”) incluye expresamente las pruebas de intrusión entre los controles mínimos de ciberseguridad de las instituciones autorizadas por el Banco Central. La prueba debe ser al menos anual, realizada por un profesional o empresa especializada independiente y documentada con las fallas encontradas y el plan de corrección. Para instituciones de pago, corredoras y distribuidoras, la misma regla está en la Resolución BCB 85.

Esta guía explica qué cambió, quién debe cumplir, qué exige exactamente la norma del pentest, qué debe cubrir en una fintech y cómo convertir el informe en evidencia para el regulador. Sirve tanto para instituciones brasileñas como para fintechs extranjeras que operan en Brasil o están por entrar al mercado.

Qué cambió en diciembre de 2025

El texto original de 2021 de la Resolución CMN 4.893 ya pedía “pruebas y escaneos periódicos para detectar vulnerabilidades”, sin detalles. La Resolución CMN 5.274 (texto oficial en portugués) convirtió ese punto en una lista de controles mínimos y creó reglas propias para el pentest:

La resolución entró en vigor con su publicación, y las instituciones que ya funcionaban tenían hasta el 1 de marzo de 2026 para adecuarse.

Quién debe cumplir

• Instituciones autorizadas por el Banco Central — bancos, bancos digitales, financieras, sociedades de crédito directo (SCD) y de préstamos entre personas (SEP), entre otras: siguen la Resolución CMN 4.893.
• Instituciones de pago, corredoras y distribuidoras de valores y corredoras de cambio: siguen la Resolución BCB 85, que recibió las mismas reglas de pentest por la Resolución BCB 538, también del 18/12/2025.
• Fintech sin licencia propia, que opera a través de un banco socio o de un proveedor de BaaS: la norma no se le aplica directamente. Pero la institución autorizada debe definir procedimientos y controles para los proveedores de servicios que manejan datos sensibles o relevantes para su operación, en un nivel compatible con el que ella misma usa (art. 3, inciso V, letra “b”, y § 5). En la práctica, esa exigencia tiende a llegar al contrato con el socio.

Qué exige la norma del pentest

El artículo 22-A, incluido en diciembre de 2025, es directo (traducción nuestra):

Art. 22-A. Las instituciones deben asegurar que las pruebas de intrusión mencionadas en el art. 3, § 8, inciso IV: I - tengan periodicidad mínima anual; II - sean realizadas con independencia e imparcialidad por una persona física o empresa especializada contratada por la institución para ese fin, sin perjuicio de las pruebas realizadas por equipos de la propia institución; y III - tengan sus resultados documentados, especialmente las vulnerabilidades que se identifiquen y los planes de acción establecidos para su corrección.

En la práctica, esto significa:

1. Al menos un pentest por año. “Al menos”: los cambios grandes en el producto justifican pruebas adicionales.
2. Hecho por alguien externo. El equipo interno puede (y debe) probar, pero no reemplaza la prueba independiente contratada.
3. Con informe y plan de corrección. No alcanza con el PDF de las fallas: la norma pide los planes de acción para corregirlas. Y el § 8 exige además la “corrección oportuna de las vulnerabilidades identificadas”: corregir y demostrar que se corrigió.

Los resultados también entran en el informe anual sobre el plan de acción y respuesta a incidentes, con fecha base el 31 de diciembre, que va al comité de riesgo (cuando existe) y al directorio o la dirección hasta el 31 de marzo del año siguiente (art. 8). Y la documentación queda 5 años a disposición del Banco Central (art. 23).

Qué debe cubrir un pentest en una fintech

La resolución no define el alcance de la prueba. La política de seguridad — y, por extensión, las pruebas — debe ser compatible con el tamaño, el perfil de riesgo y el modelo de negocio de la institución (art. 2, § 1), y los controles mínimos del art. 3 indican dónde mirar. En una fintech, un pentest serio cubre al menos:

• Autenticación y control de acceso: login, recuperación de cuenta, sesión, MFA (incluido el acceso remoto a la red corporativa, ahora obligatorio) y los permisos de usuarios internos y tercerizados.
• Autorización entre cuentas: un cliente nunca debe ver ni modificar el saldo, el extracto o los datos de otro. Es la falla de API más común en plataformas financieras.
• Integraciones por API: la norma pasó a tratar específicamente los requisitos de seguridad para integrar sistemas por interfaces electrónicas (art. 3, § 2, XIII): APIs de socios, webhooks, Open Finance, proveedores de KYC y de pagos.
• Lógica de las transacciones: límites, contracargos, devoluciones, retiros y transferencias hechos en paralelo (race conditions), redondeos y montos negativos.
• Ambiente Pix, para participantes conectados a la red del sistema financiero (RSFN): MFA en el acceso administrativo, aislamiento del ambiente, custodia de certificados y claves de firma (art. 3-A).
• Trazabilidad: si las transacciones y los accesos generan registros de auditoría que permitan investigar un incidente (art. 3, § 7).

Para la autorización entre cuentas, el enfoque más eficiente es la caja gris (con cuentas de prueba); para módulos críticos como billetera, Pix y motor de límites, conviene la revisión de código del pentest de caja blanca. Un ejemplo real del tipo de falla que encuentra esta prueba está en BOLA en fintech: 1 endpoint, R$ 200k en riesgo.

Cómo el informe se convierte en evidencia para el regulador

En la supervisión o en la auditoría interna, lo que cuenta es la documentación. Un informe de pentest que cumple el art. 22-A deja claro:

1. Quién lo hizo y en qué condiciones: empresa o profesional contratado, sin conflicto con el equipo que desarrolló el sistema.
2. Alcance y período: qué sistemas, ambientes y APIs se probaron, y cuándo.
3. Metodología: cómo se condujo la prueba y con qué nivel de acceso.
4. Vulnerabilidades encontradas: con severidad, evidencia y pasos para reproducirlas.
5. Plan de acción: qué se va a corregir, quién y en qué plazo.
6. Re-test: la prueba de que las correcciones funcionaron.

Guarda todo junto (informe, plan de acción y re-test) con la fecha de la prueba: el plazo de 5 años cuenta desde su ejecución.

Un calendario que funciona

Como el informe anual tiene fecha base el 31 de diciembre y va al directorio hasta el 31 de marzo, lo ideal es que el pentest del año, las correcciones y el re-test estén listos antes del cierre. En la práctica: planifica el pentest para el primer semestre o el tercer trimestre, reserva tiempo para corregir, haz el re-test y llega a diciembre con el ciclo cerrado. Los cambios grandes a mitad de año — un producto nuevo, una integración de Open Finance, la entrada en Pix — justifican pruebas adicionales enfocadas.

Cuánto cuesta

En No Vuln, el pentest se contrata por horas, con una tarifa de US$ 150 a US$ 250 por hora. Para una fintech con producto en producción, lo más común es el Deep Dive (50h), de US$ 7.500 a US$ 12.500; para bancos digitales y plataformas con varios productos, APIs y Pix, el Full Scope (100h+), desde US$ 15.000. Si prefieres pruebas a lo largo del año y no solo la anual, existe el PTaaS (pentest continuo, con banco de horas mensual o trimestral). Consulta también cuánto cuesta un pentest en Brasil.

Qué hacer ahora

1. Confirma qué norma aplica a tu institución (CMN 4.893 o BCB 85), o a tu socio si operas vía BaaS.
2. Verifica que el último pentest se haya hecho hace menos de 12 meses, por una empresa independiente, y que esté documentado.
3. Revisa que cada falla relevante tenga plan de acción y re-test.
4. Revisa el MFA en el acceso remoto y, si estás en Pix, el aislamiento del ambiente y la custodia de claves.
5. Agenda el próximo pentest para que el ciclo cierre antes del 31 de diciembre.

Para el alcance técnico, consulta pentest para fintech, pentest para medios de pago y seguridad Pix. Si quieres hablar de tu caso: habla con un investigador, con NDA bilateral antes de la primera llamada técnica.

Este artículo resume las normas para orientar la planificación técnica y no reemplaza la lectura del texto oficial ni la orientación de tus equipos jurídico y de cumplimiento. Fuentes (textos oficiales en portugués): Resolución CMN 4.893, Resolución CMN 5.274, Resolución BCB 85 y Resolución BCB 538.