Normas de ciberseguridad de la CMF: evalúe su app de banca móvil antes y después de cada versión.
El capítulo 20-10 de la Recopilación Actualizada de Normas (RAN) de la CMF pide a los bancos realizar periódicamente pruebas de seguridad sobre su infraestructura tecnológica, incluidas pruebas de penetración y ethical hacking, y comunicar los resultados al directorio al menos cada seis meses. El capítulo 20-7 extiende las evaluaciones de vulnerabilidades y las pruebas de penetración a los servicios externalizados críticos y a los proveedores de nube. La Ley 21.663 fija el marco nacional de ciberseguridad y la norma de la CMF sobre operaciones de pago hace obligatoria la autenticación reforzada en la app. Ostorlab prueba su app y las API en las que se apoya, detrás del inicio de sesión, en cada versión.
- Cubre la app móvil y las API a las que llama, sobre la compilación que descargan sus clientes
- Prueba el inicio de sesión, los códigos de un solo uso, las verificaciones reforzadas y los flujos de pago con sus cuentas de prueba
- Enumera los SDK y las bibliotecas nativas de cada versión y los asocia a vulnerabilidades conocidas
- Demuestra cada hallazgo con un exploit reproducible o con evidencia de solicitudes y respuestas
- A quién se aplica
- Los bancos y otras entidades supervisadas por la CMF cubiertas por el capítulo, incluidos los emisores de tarjetas y los operadores de tarjetas de pago, y los servicios esenciales conforme a la Ley 21.663, incluidos la banca, los servicios financieros y los medios de pago
- Fecha clave
- Capítulo 20-10 vigente desde el 1 de diciembre de 2020; autenticación reforzada obligatoria desde el 1 de agosto de 2026; ley de datos personales vigente el 1 de diciembre de 2026
- Objeto
- Pruebas de seguridad, riesgo de externalización y de nube, autenticación reforzada y protección de datos personales
- Referencia principal
- Recopilación Actualizada de Normas (RAN) de la CMF, capítulo 20-10
Los textos chilenos que rigen su canal móvil
Los capítulos de la CMF coexisten con la ley marco de ciberseguridad y las leyes sobre fraude de pago y datos personales. Las fechas siguientes corresponden a los textos citados en esta página.
- 29 de mayo de 2020
Ley 21.234 sobre fraude de pago
Entra en vigor un nuevo régimen de responsabilidad para tarjetas y transacciones electrónicas. Los usuarios pueden limitar su responsabilidad por uso no autorizado, y los emisores deben bloquear el medio de pago y restituir los fondos en los plazos establecidos.
- 1 de diciembre de 2020
Capítulo 20-10 de la RAN
La circular n° 2.261 de la CMF, de 6 de julio de 2020, pone en vigor el capítulo de seguridad de la información y ciberseguridad: políticas aprobadas por el directorio, proceso de gestión de riesgos, pruebas de seguridad como pentesting y ethical hacking, y presentación de resultados al directorio cada seis meses.
- 8 de abril de 2024
Ley Marco de Ciberseguridad
Se publica la Ley 21.663. Crea la Agencia Nacional de Ciberseguridad (ANCI), fija deberes generales de prevención, reporte y resolución de incidentes, y clasifica la banca, los servicios financieros y los medios de pago como servicios esenciales.
- 30 de mayo de 2024
Modificación de la ley de fraude
La Ley 21.673 endurece el procedimiento de restitución de la ley de fraude y faculta a la CMF para definir cuándo los emisores deben usar autenticación reforzada de cliente (ARC).
- 13 de diciembre de 2024
Ley 21.719 sobre datos personales
Publicada, con entrada en vigor el 1 de diciembre de 2026. Exige protección de datos desde el diseño, medidas de seguridad, evaluaciones de impacto y reporte de vulneraciones a la nueva Agencia de Protección de Datos Personales.
- 1 de marzo de 2025
Reporte de incidentes y sanciones en vigor
Entran en vigor los deberes de los operadores de importancia vital, la obligación de reportar incidentes y el régimen sancionatorio de la Ley 21.663. Los incidentes significativos se reportan al CSIRT Nacional, con una alerta temprana en un plazo de tres horas.
- 17 de junio de 2025
Norma de autenticación de la CMF
La Norma de Carácter General n° 538 fija los estándares mínimos de seguridad, registro y autenticación y los casos obligatorios de autenticación reforzada. Se modifica mediante la NCG n° 568 el 1 de junio de 2026, y los casos obligatorios se aplican desde el 1 de agosto de 2026.
- Abril de 2026
Borrador de actualización del capítulo 20-7
La CMF somete a consulta un borrador de actualización del capítulo de externalización y un nuevo archivo de reporte de servicios externalizados. El capítulo de 2014, modificado en 2019, sigue vigente.
Las normas chilenas, aplicadas a su app móvil
Para cada norma: qué dice el texto, qué supone para una app de banca móvil, cómo ayuda Ostorlab y qué sigue correspondiendo a su equipo. Los capítulos de la CMF se resumen a partir de los textos en español.
- RAN capítulo 20-10, numeral 4.1 (texto en español)
Pruebe su seguridad, con pentesting y ethical hacking
Qué dice el texto
La entidad debe realizar periódicamente pruebas de seguridad sobre su infraestructura tecnológica, con alcance y profundidad suficientes, para detectar las amenazas y vulnerabilidades existentes, como pentesting y/o ethical hacking. Los resultados los gestionan las áreas responsables y se comunican al directorio al menos cada seis meses, dejando constancia en las actas de los análisis y de las acciones acordadas. Entre los vectores de ataque que se deben identificar y evaluar están la manipulación o interceptación de las comunicaciones, el phishing, el malware, la elevación de privilegios, la inyección de código y la denegación de servicios.
Qué supone para su app móvil
Esta es la cláusula que nombra el pentesting. Su app móvil y las API a las que llama forman parte de la infraestructura, y el directorio debe ver los resultados dos veces al año.
Cómo ayuda Ostorlab
El pentest con agentes de IA prueba la app y sus API detrás del inicio de sesión, sobre la versión que usted publica, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA. Los hallazgos se clasifican como críticos, altos, medios o bajos, se gestionan como tickets y se vuelven a probar tras la corrección.
Qué sigue en sus manos
Las pruebas de servidores y red, el informe interno al directorio y las decisiones de corrección.
- RAN capítulo 20-10, numeral 4.1; RAN capítulo 1-13, numeral 3.2 c) (texto en español)
Mantenga bajo control los parches y los componentes
Qué dice el texto
La entidad debe contar con un programa de gestión de parches que asegure su aplicación oportuna al software y al firmware, con un proceso de gestión de cambios que mantenga las modificaciones de la infraestructura controladas y monitoreadas, y con un proceso de gestión de la obsolescencia que mantenga estándares de seguridad adecuados a los objetivos de la entidad. El capítulo 1-13 también espera una planificación tecnológica de largo plazo con políticas de parche vigentes.
Fuente:RAN capítulo 20-10, numeral 4.1; RAN capítulo 1-13, numeral 3.2 c) (texto en español)
Qué supone para su app móvil
Los SDK y las bibliotecas nativas de su app son software que usted distribuye. Cada uno necesita una versión conocida, una gravedad cuando aparece una vulnerabilidad y un plazo de corrección que pueda demostrar.
Cómo ayuda Ostorlab
SCA identifica las bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas, versión tras versión. Los hallazgos se clasifican como críticos, altos, medios o bajos y se gestionan como tickets en la plataforma o en Jira y ServiceNow.
Qué sigue en sus manos
La aplicación de parches en servidores e infraestructura, las actualizaciones de firmware y los contratos de mantenimiento con proveedores.
- RAN capítulo 20-10, numeral 4.1 (texto en español)
Proteja los canales electrónicos y sus credenciales
Qué dice el texto
Los canales electrónicos que utilizan los clientes deben contar con controles de acceso apropiados para mitigar, entre otros riesgos, la suplantación o el uso indebido de productos y servicios por parte de terceros. La gestión de identidades y accesos debe cubrir a los usuarios privilegiados y el acceso a redes, sistemas operativos, bases de datos y aplicaciones de negocio. La entidad también debe definir qué información requiere protección mediante cifrado, los algoritmos criptográficos autorizados y los controles utilizados para la transmisión y el almacenamiento.
Qué supone para su app móvil
Las claves de API y los tokens que quedan en el paquete de la app son credenciales que cualquiera puede extraer. La autorización entre la app, el backend y los servicios de identidad externos debe mantenerse en cada límite.
Cómo ayuda Ostorlab
Ostorlab detecta claves de API, tokens y credenciales en el paquete de la app y valida si funcionan. Intercepta el tráfico de la app, incluso con TLS pinning, y prueba las API en busca de fallos de autorización (BOLA, BFLA, IDOR) y usos indebidos de tokens y sesiones.
Qué sigue en sus manos
La gestión de las cuentas privilegiadas, las revisiones de accesos y los controles de acceso físico.
- RAN capítulo 20-10, numeral 4.1 (texto en español)
Refuerce la app y pruébela en dispositivos comprometidos
Qué dice el texto
Los controles que implante la entidad deben mitigar los riesgos derivados del uso de dispositivos móviles, del trabajo a distancia y de los dispositivos IoT, así como los riesgos derivados de la adquisición, integración o desarrollo de aplicaciones y sistemas y de su puesta en producción. Entre los vectores de ataque que se deben identificar y evaluar están la manipulación o interceptación de las comunicaciones, la inyección de código y la elevación de privilegios.
Qué supone para su app móvil
La detección de root y jailbreak, la protección contra manipulación y el pinning son los controles de la app que hay detrás de esta cláusula, y cada uno puede probarse sobre la versión que descargan sus clientes.
Cómo ayuda Ostorlab
Mobile Shielding Scan ejecuta la app en entornos rooteados y con jailbreak, intenta evadir la detección de root y jailbreak, la protección contra manipulación y el TLS pinning, y muestra qué hace la app después. Obtiene una puntuación de endurecimiento y evidencia de las evasiones.
Qué sigue en sus manos
La elección y configuración de su solución de protección, la gestión de dispositivos móviles y la política de trabajo a distancia.
- RAN capítulo 20-7, numerales III.4, IV.1 b) y V (texto en español)
Gestione la externalización y los proveedores de nube
Qué dice el texto
La entidad debe asegurarse de que su proveedor mantiene un programa de seguridad de la información que garantice la confidencialidad, la integridad, la trazabilidad y la disponibilidad de sus activos de información y de los de sus clientes, coherente con las políticas de la entidad. Debe controlar y monitorear la infraestructura de seguridad de la información del proveedor y la gestión de identidades y accesos de los servicios externalizados críticos y, para esos servicios críticos, controlar que el proveedor realice periódicamente evaluaciones de vulnerabilidad y pruebas de penetración de su infraestructura tecnológica. Los servicios en la nube exigen diligencia reforzada: el directorio se pronuncia anualmente sobre la tolerancia al riesgo de nube, y los servicios de nube críticos o estratégicos exigen certificaciones reconocidas internacionalmente, informes de auditoría independientes, análisis legal de las jurisdicciones implicadas y mecanismos de aislamiento. El procesamiento crítico en el exterior también exige un centro de procesamiento de datos de contingencia en Chile, salvo que aplique la excepción aprobada por el directorio.
Fuente:RAN capítulo 20-7, numerales III.4, IV.1 b) y V (texto en español)
Qué supone para su app móvil
Las apps móviles integran SDK de terceros que se comunican con sus propios backends, y los backends de pago suelen funcionar en la nube. La evidencia de sus pruebas de seguridad debe estar en sus expedientes de proveedores.
Cómo ayuda Ostorlab
Ostorlab enumera los SDK y las bibliotecas nativas de cada versión con sus versiones y su ubicación en el paquete de la app, y muestra qué intercambian la app y sus SDK con los backends a través de la red. Las pruebas de API cubren los backends de proveedores que usted indique.
Qué sigue en sus manos
Los contratos, los expedientes de diligencia debida, el pronunciamiento anual del directorio sobre riesgo de nube y las auditorías de proveedores.
- RAN capítulo 1-13, numerales 3.2 c) y 5 (texto en español)
Cumpla las expectativas de la evaluación de la gestión
Qué dice el texto
En su clasificación de gestión y solvencia, la CMF evalúa la estrategia del directorio en materia de riesgo operacional, la definición de los activos de información, incluidos los expuestos en el ciberespacio, las políticas para las actividades entregadas a terceros con verificaciones y monitoreo, la planificación tecnológica y de parches, los planes de continuidad y contingencia con pruebas periódicas, y la independencia de la auditoría interna. Para la seguridad de la información y la ciberseguridad considera directamente el capítulo 20-10. La propia administración del banco también debe analizar y pronunciarse sobre su gestión al menos una vez al año, y presentar el resultado al directorio.
Fuente:RAN capítulo 1-13, numerales 3.2 c) y 5 (texto en español)
Qué supone para su app móvil
Este capítulo no exige una herramienta concreta. Exige evidencia de que los controles en torno a su canal móvil tienen responsable, se prueban y se reportan.
Cómo ayuda Ostorlab
Ostorlab entrega resultados de escaneo repetibles por compilación y por versión, con tickets e historiales de nuevas pruebas que puede adjuntar a los informes internos. No sustituye la gobernanza, la auditoría interna ni la revisión del directorio.
Qué sigue en sus manos
La gobernanza, las tres líneas de defensa, la auditoría interna y la autoevaluación anual.
- Ley 20.009 modificada por las leyes 21.234 y 21.673; NCG n° 538 de la CMF, modificada por la NCG n° 568 (texto en español)
Exija autenticación reforzada en los pagos
Qué dice el texto
Conforme a la ley de fraude, modificada en 2024, la CMF define las transacciones que exigen autenticación reforzada de cliente (ARC). La NCG n° 538, modificada por la NCG n° 568, exige una ARC basada en al menos dos factores independientes de categorías distintas, obligatoria para las transferencias electrónicas de fondos, incluidos los datos de destinatarios y los pagos recurrentes, el alta del cliente en plataformas digitales, la incorporación o modificación de datos personales, la modificación de claves de autenticación, y la incorporación, el reemplazo o la eliminación de un dispositivo de confianza. Los emisores deben mantener registros auditables y trazables de todas las transacciones y eventos de autenticación, incluidos los intentos fallidos con sus códigos de error, monitorear continuamente los patrones de transacción, proteger y hacer expirar los códigos de autenticación, y contar con detección de manipulación o clonación en los dispositivos de autenticación. Los conjuntos de datos impresos para la autenticación debían eliminarse antes del 1 de agosto de 2026.
Qué supone para su app móvil
Son comportamientos de la app y de sus API: pasos de OTP y biometría, alta de dispositivos, cambios de datos de contacto y las llamadas que podrían saltarse un paso. El servidor debe exigirlos.
Cómo ayuda Ostorlab
Las pruebas autenticadas cubren el inicio y el cierre de sesión, la renovación de tokens, los tiempos de espera, la invalidación de sesiones y la aplicación de la MFA, incluidos los flujos de autenticación reforzada, junto con las llamadas a la API detrás de transferencias, cambios de destinatarios y alta de dispositivos. Ostorlab completa los códigos de un solo uso por SMS, correo electrónico o TOTP con sus cuentas de prueba.
Qué sigue en sus manos
La elección de los métodos de autenticación, la política de excepción para grupos de clientes vulnerables y el reporte semestral a la CMF si utiliza la excepción.
- Ley 21.719, artículos 14 quáter, 14 quinquies, 14 sexies y 15 ter (texto en español)
Proteja los datos personales en la app y reporte las vulneraciones
Qué dice el texto
La Ley 21.719, vigente desde el 1 de diciembre de 2026, exige la protección de datos desde el diseño y por defecto, y medidas de seguridad que aseguren la confidencialidad, integridad, disponibilidad y resiliencia de los sistemas de tratamiento, incluida la seudonimización y el cifrado cuando proceda y una verificación periódica de su eficacia. Las vulneraciones que supongan un riesgo razonable deben reportarse sin dilaciones indebidas a la Agencia de Protección de Datos Personales y, cuando afecten a datos sensibles o a datos financieros, bancarios o comerciales, también a los titulares afectados. El tratamiento que probablemente genere un riesgo alto exige una evaluación de impacto antes de iniciarse, y los datos biométricos utilizados para identificar a una persona son datos sensibles.
Fuente:Ley 21.719, artículos 14 quáter, 14 quinquies, 14 sexies y 15 ter (texto en español)
Qué supone para su app móvil
Las credenciales de pago, la biometría, los saldos y los historiales de transacciones son exactamente las categorías de datos mencionadas. Lo que la app y sus SDK almacenan, registran o envían forma parte de la evidencia.
Cómo ayuda Ostorlab
Ostorlab busca tokens y datos personales en el almacenamiento local, las cachés, los registros y las capturas de pantalla, comprueba las protecciones del transporte y muestra qué intercambian la app y sus SDK con los backends. No realiza evaluaciones de impacto ni presenta las notificaciones de vulneración.
Qué sigue en sus manos
La evaluación de impacto, los registros de tratamiento, el delegado de protección de datos y las notificaciones de vulneración a la Agencia y a los clientes.
- Ley 21.663, artículos 4, 7, 8 y 9, deberes vigentes desde el 1 de marzo de 2025 (texto en español)
Prepárese para los incidentes con la Ley 21.663
Qué dice el texto
Conforme a la Ley Marco de Ciberseguridad, las entidades que prestan servicios esenciales, incluidos la banca, los servicios financieros y los medios de pago, deben aplicar de manera permanente medidas para prevenir, reportar y resolver incidentes de ciberseguridad. Los operadores de importancia vital deben mantener un sistema de gestión de seguridad de la información continuo, certificar y revisar periódicamente sus planes de continuidad y ciberseguridad al menos cada dos años, realizar actividades continuas de revisión y ejercicios, y designar un delegado de ciberseguridad. Los incidentes significativos se reportan al CSIRT Nacional: una alerta temprana dentro de las tres horas desde que se conoce el evento, y una actualización dentro de 72 horas, o 24 horas cuando un operador de importancia vital ve afectado su servicio esencial.
Fuente:Ley 21.663, artículos 4, 7, 8 y 9, deberes vigentes desde el 1 de marzo de 2025 (texto en español)
Qué supone para su app móvil
La detección, la respuesta y el reporte de incidentes siguen en sus manos. Lo que puede preparar es el lado de la app y las API: menos hallazgos abiertos, evidencia de que están corregidos y una nueva prueba que mostrar tras un incidente.
Cómo ayuda Ostorlab
Ostorlab no opera un SOC ni reporta incidentes al CSIRT. Prueba los controles de la app y de sus API, hace seguimiento de los hallazgos hasta su cierre y los vuelve a probar, de modo que el lado de la app de su plan de incidentes se apoya en evidencia vigente.
Qué sigue en sus manos
El SOC y el monitoreo, la respuesta a incidentes y los reportes al CSIRT Nacional, los ejercicios y el delegado de ciberseguridad.
Resumen de textos públicos de la CMF y de la legislación chilena, consultados el 27 de septiembre de 2026. Los capítulos de la CMF se resumen a partir de los textos en español. El borrador de actualización del capítulo 20-7 de abril de 2026 no estaba vigente en esta revisión y no se cita aquí. Esta página no constituye asesoramiento jurídico.
Normas chilenas, control por control
Los controles a los que apuntan los textos chilenos, cómo los prueba Ostorlab en su app y sus API, y la evidencia que puede conservar.
| Control | Cómo ayuda Ostorlab | Evidencia que conserva |
|---|---|---|
| Pruebas de seguridad periódicas, incluidas pentesting y ethical hackingRAN 20-10, 4.1 | Pentest con agentes de IA de la app y de sus API, detrás del inicio de sesión, sobre la versión que publica. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de calor de cobertura |
| Controles de acceso de los canales electrónicos, tokens y suplantaciónRAN 20-10, 4.1 | Intercepta el tráfico incluso con TLS pinning y prueba la autorización, el uso indebido de tokens y los flujos de cuenta. Detalles | Evidencia de solicitudes y respuestas para cada hallazgo de API |
| Gestión de parches y plazos de correcciónRAN 20-10, 4.1 | Identifica mediante huellas las bibliotecas compiladas estáticamente y las relaciona con vulnerabilidades conocidas, de una versión a otra. Detalles | Vulnerabilidades asociadas con recomendaciones de actualización o sustitución, y seguimiento del cierre entre versiones |
| Inventario de componentes de cada versiónRAN 20-10, 4.1; RAN 20-7, III.4 | Enumera los SDK y las bibliotecas nativas de cada versión con sus números de versión, y muestra con qué backends se comunican la app y sus SDK. Detalles | Identidad, versión y ubicación de cada componente en el paquete de la app, por versión |
| Secretos y credenciales en el paquete de la appRAN 20-10, 4.1 | Detecta claves de API, tokens y credenciales en el paquete de la app y valida si funcionan. Detalles | Secretos validados, con los permisos y servicios que exponen |
| Autenticación reforzada en transferencias y cambios de dispositivoNCG 538, modificada por la NCG 568 | Inicia sesión con códigos de un solo uso y prueba la aplicación de la MFA y los flujos de autenticación reforzada, así como las llamadas a la API que hay detrás. Detalles | Hallazgos sobre los flujos de inicio de sesión, transferencia y alta de dispositivos, con los pasos de reproducción |
| Protecciones frente a root, jailbreak y manipulaciónRAN 20-10, 4.1 | Ejecuta la app en entornos rooteados y con jailbreak e intenta evadir la detección, la protección contra manipulación y el pinning. Detalles | Puntuación de endurecimiento y evidencia de evasión de cada protección que falló |
| Gestión de sesiones y códigos de un solo usoNCG 538; RAN 20-10, 4.1 | Prueba el inicio y el cierre de sesión, la renovación de tokens, los tiempos de espera, la invalidación de sesiones y la expiración de códigos. Detalles | Hallazgos sobre sesiones y tokens, con registros de solicitudes y respuestas |
| Protección de los datos en el dispositivo y en tránsitoRAN 20-10, 4.1; Ley 21.719, art. 14 quinquies | Busca tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y comprueba las protecciones del transporte. Detalles | Evidencia del sistema de archivos que muestra qué se escribió, dónde y cuándo |
| Evidencia de pruebas de servicios externalizados y de nubeRAN 20-7, III.4 y V | Prueba la app y las API de proveedores que usted indique, y conserva evidencia de SDK y de red por versión. Detalles | Resultados de escaneo por versión y por integración de proveedor |
Ostorlab prueba los controles de la app y de sus API. La supervisión del SOC, la respuesta a incidentes y su reporte al CSIRT Nacional, las TLPT, la gobernanza, el pronunciamiento anual sobre riesgo de nube y la seguridad física siguen correspondiendo a sus equipos.
Controles chilenos que probar en su app móvil
Una lista práctica para los equipos de seguridad y de riesgo tecnológico, basada en los capítulos de la CMF, la norma de autenticación y la ley de datos personales.
Alcance de las pruebas de seguridad
Incluya la app móvil y las API a las que llama en el alcance de sus pruebas de seguridad del capítulo 20-10, con una fase previa a la publicación y una cadencia regular.
Evidencia semestral
Mantenga a disposición del directorio, al menos cada seis meses, los resultados de pentesting y ethical hacking, los análisis y las acciones acordadas.
Componentes y plazos
Mantenga una lista versionada de los SDK y las bibliotecas de cada versión, y fije plazos de corrección según la gravedad.
Nube y expedientes de proveedores
Actualice el pronunciamiento anual del directorio sobre riesgo de nube y conserve certificaciones, auditorías y pruebas de penetración de los proveedores críticos.
ARC en los flujos de pago
Verifique que las transferencias, los cambios de destinatarios, los pagos recurrentes, los cambios de datos personales y el alta de dispositivos de confianza exigen dos factores independientes, aplicados por el servidor.
Datos en el dispositivo
Revise el paquete de la app y el dispositivo en busca de claves de API, tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla.
Insumos para la evaluación de impacto
Mapee lo que la app y sus SDK recogen y envían, y úselo en las evaluaciones de impacto que deben estar listas antes del 1 de diciembre de 2026.
Reportar y volver a probar
Haga seguimiento de los hallazgos hasta el cierre, vuelva a probar tras cada corrección y conserve los resultados como evidencia para los expedientes de incidentes y auditoría.
Una lista sugerida, no una plantilla de la CMF. Esto no constituye asesoramiento jurídico.
Las capacidades detrás de esta página
Cada una tiene su propia página con los detalles.
- Mobile Agentic Deep ScanLos agentes de IA realizan el pentest de la versión publicada en cada release, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA.Más información
- Pruebas autenticadasPruebe el inicio de sesión, los códigos de un solo uso y la autenticación reforzada con sus cuentas de prueba.Más información
- Pruebas de API y backendIntercepte el tráfico de la app incluso con TLS pinning y pruebe las API y los backends detrás de cuentas y pagos.Más información
- Mobile SASTAnálisis estático basado en el binario de archivos APK, AAB e IPA, con análisis de propagación (taint) en toda la app y sus SDK integrados.Más información
- SCA y SBOMDetecte dependencias vulnerables, incluidas las bibliotecas nativas compiladas estáticamente, y haga un seguimiento de su cierre versión tras versión.Más información
- Mobile Shielding ScanPruebe en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el pinning, y vea qué protecciones resistieron y cuáles se evadieron.Más información
- Su propia clave de IAEjecute los escaneos con agentes de IA con la clave de su proveedor de IA y un límite de gasto por escaneo, según sus políticas internas.Más información
- Escaneo on-premisesEscanee apps de preproducción, API y repositorios detrás de su firewall o VPN, en una infraestructura que usted controla.Más información
Bancos y fintechs confían en nosotros, entre ellos
Fuentes
Los textos oficiales en los que se basa esta página, consultados el 27 de septiembre de 2026.
- Recopilación Actualizada de Normas (RAN), capítulo 20-10: Gestión de Seguridad de la Información y CiberseguridadCMF, circular n° 2.261 de 6 de julio de 2020, aprobada por la Resolución n° 3255, vigente desde el 1 de diciembre de 2020. Pruebas de seguridad, gestión de parches, controles de canales electrónicos y preparación ante incidentes. Texto en español
- Recopilación Actualizada de Normas (RAN), capítulo 20-7: Externalización de ServiciosCMF, circular n° 3.570 de 7 de octubre de 2014, con la actualización de la circular n° 2.244 de 23 de diciembre de 2019. Programas de seguridad de proveedores, evaluaciones de vulnerabilidad y pruebas de penetración de servicios externalizados críticos, y diligencia reforzada para servicios de nube. Un borrador de actualización estuvo en consulta en abril de 2026 y no estaba vigente en esta revisión. Texto en español
- Recopilación Actualizada de Normas (RAN), capítulo 1-13: Clasificación de gestión y solvenciaCMF, texto consolidado con la circular n° 2.373 de 14 de julio de 2026. La evaluación de la gestión de los bancos, incluidos el riesgo operacional, los activos de información, las actividades entregadas a terceros, la planificación de parches y la auditoría interna, y la autoevaluación anual. Texto en español
- Ley 21.663, Ley Marco de CiberseguridadPublicada en el Diario Oficial el 8 de abril de 2024; deberes de los operadores de importancia vital, reporte de incidentes y sanciones vigentes desde el 1 de marzo de 2025. La banca, los servicios financieros y los medios de pago son servicios esenciales. Texto en español
- Decreto n° 295, Reglamento de reporte de incidentes de ciberseguridadMinisterio del Interior y Seguridad Pública, publicado el 1 de marzo de 2025. El reglamento de reporte de la Ley 21.663, con el contenido de los informes de incidentes al CSIRT Nacional. Texto en español
- Ley 21.234 y Ley 21.673: responsabilidad por uso no autorizado de medios de pagoLa Ley 21.234, publicada el 29 de mayo de 2020, fija el régimen de responsabilidad para tarjetas y transacciones electrónicas. La Ley 21.673, publicada el 30 de mayo de 2024, la modifica y obliga a la CMF a definir los casos de autenticación reforzada. Texto en español
- CMF Norma de Carácter General n° 538, modificada por la n° 568CMF, NCG n° 538 de 17 de junio de 2025 sobre estándares de seguridad y autenticación de operaciones sometidas a la Ley 20.009, modificada por la NCG n° 568 de 1 de junio de 2026. Los casos obligatorios de autenticación reforzada se aplican desde el 1 de agosto de 2026. Texto en español
- Ley 21.719: protección y tratamiento de los datos personalesPublicada el 13 de diciembre de 2024, vigente desde el 1 de diciembre de 2026. Protección de datos desde el diseño, medidas de seguridad, evaluaciones de impacto y reporte de vulneraciones a la nueva Agencia de Protección de Datos Personales. Texto en español
Preguntas frecuentes
Respuestas claras sobre cobertura, configuración y cómo llegan los resultados a su equipo.
¿No encuentra su respuesta? Reserve una demo o contáctenos.
Evalúe su app de banca móvil frente a las normas chilenas
Empiece con un escaneo gratuito de su app desde la tienda, o reserve una demo para realizar con nuestro equipo pruebas con sesión iniciada de su app y sus API.