Directrices del CBSL sobre riesgo tecnológico: evalúe su app de banca móvil antes y después de cada versión.
El Banco Central de Sri Lanka exige a los bancos licenciados pruebas de seguridad previas a la puesta en producción, evaluaciones de vulnerabilidad al menos trimestrales y pruebas de penetración por expertos externos independientes. La guía sobre apps móviles de pago añade registro de dispositivos, autenticación multifactor, controles de sesión, detección de manipulación y certificate pinning. Ostorlab prueba su app y las API que la sustentan, con sesión iniciada, en cada versión.
- Evalúa la app móvil y las API que llama, en la versión que descargan sus clientes
- Prueba el inicio de sesión, los códigos de un solo uso, la MFA, el bloqueo de cuentas y la gestión de sesiones con sus cuentas de prueba
- Comprueba en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación, la detección de depurador y emulador y el certificate pinning
- Enumera los SDK y bibliotecas nativas de cada versión y los asocia a vulnerabilidades conocidas con plazos de corrección
- A quién aplica
- Bancos comerciales y especializados licenciados según las directrices sobre riesgo tecnológico, y proveedores de servicios de pago que operan o facilitan apps móviles de pago
- Fechas clave
- Directrices n.º 16 de 2021 emitidas el 9 de diciembre de 2021 y modificadas el 8 de diciembre de 2023; pruebas de penetración en producción antes del 31 de diciembre de 2028; partes I y III de la Ley de Protección de Datos desde el 1 de enero de 2027
- Objeto
- Pruebas previas a la puesta en producción, evaluaciones de vulnerabilidad trimestrales, pruebas de penetración anuales y controles de las apps móviles de pago
- Textos de referencia
- Banking Act Directions No. 16 of 2021 y Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020
Los textos del CBSL que enmarcan su canal móvil
Las directrices sobre riesgo tecnológico se suman a la guía sobre apps móviles de pago y a las circulares que fijan las reglas de las transacciones. Las fechas siguientes corresponden a los textos citados en esta página.
- 1 de junio de 2020
Entra en vigor la Guía n.º 01/2020
El estándar mínimo de cumplimiento para apps móviles de pago entra en vigor y sustituye a la guía de 2018. Cubre la app, los servicios web, la infraestructura del lado del servidor y las comunicaciones de red.
- 9 de diciembre de 2021
Directrices sobre riesgo tecnológico
Las Banking Act Directions No. 16 of 2021 se aplican a los bancos licenciados: pruebas de seguridad de la información, cifrado, gestión de accesos, SOC e infraestructura de terceros.
- 8 de diciembre de 2023
Plazos modificados
Las Directions No. 05 of 2023 modifican el marco: plazos de cumplimiento revisados, incluidas las pruebas de penetración en producción antes del 31 de diciembre de 2028, y revisiones trimestrales de privilegios de acceso para sistemas críticos.
- 17 de enero de 2024
OTP de JustPay
La Circular No. 01 of 2024 exige un código de un solo uso emitido por el emisor de la cuenta para las transacciones JustPay de 10.000 rupias o más, enviado al número de móvil registrado con el emisor. En vigor desde el 1 de abril de 2024.
- 3 de diciembre de 2024
Identificación de clientes de apps de pago
La Circular No. 02 of 2024 exige a los proveedores de apps de pago identificar a los usuarios con un documento de identidad aceptado, verificar esa identidad y hacer coincidir el número de móvil del dispositivo con el registrado para la cuenta al vincularla, desde el 31 de marzo de 2025.
- 7 de mayo de 2025
Circular de notificación de incidentes
La Circular No. 02 of 2025 exige a los bancos licenciados notificar los incidentes de TI y ciberseguridad al Director of Bank Supervision en las 2 horas siguientes a su detección, con informe detallado en 14 días e informe trimestral tras cada trimestre.
- 20 de enero de 2026
Límites de JustPay y controles de registro
La Circular No. 01 of 2026 limita las transacciones JustPay a 150.000 rupias y exige a los proveedores de apps móviles de pago controles y procedimientos de seguridad adecuados al registrar clientes y vincular cuentas, en vigor desde el 2 de febrero de 2026.
- 22 de julio de 2026
Orden de entrada en vigor de la Ley de Datos
La Gaceta extraordinaria n.º 2498/16 fija el 1 de enero de 2027 para la entrada en vigor de la sección 2, la sección 3, la parte I y la parte III de la Ley de Protección de Datos Personales, que cubren los principios de tratamiento y las obligaciones de responsables y encargados.
Las normas del CBSL sobre riesgo tecnológico, 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 en manos de su equipo. Los puntos de las directrices y de la guía de pagos se resumen a partir de los textos en inglés.
- Banking Act Directions No. 16 of 2021, 5.8.1; plazo de cumplimiento el 31 de diciembre de 2025 según las Directions No. 05 of 2023
Probar antes de la puesta en producción y antes de cada cambio
Qué dice el texto
Los sistemas de información críticos y los sistemas expuestos a datos de clientes deben someterse a pruebas de seguridad de la información previas a la puesta en producción, tanto antes de la implantación inicial como antes de las modificaciones, salvo que una política de exclusión aprobada por el consejo cubra la modificación menor concreta. El marco nombra las pruebas: análisis estático de seguridad de aplicaciones (SAST) o revisión del código fuente, análisis dinámico de seguridad de aplicaciones (DAST), comprobaciones de endurecimiento de la infraestructura informática y de red, y evaluaciones de vulnerabilidad de la infraestructura. Las pruebas deben realizarlas un equipo independiente del que desarrolla o implanta el sistema.
Qué supone para su app móvil
Cada versión móvil que toca un sistema crítico o expuesto a datos de clientes es una modificación. El pipeline y el proceso de publicación necesitan pruebas de seguridad automatizadas e independientes en la versión que descargan sus clientes.
Cómo ayuda Ostorlab
Mobile SAST funciona sobre el APK, AAB o IPA, sin necesidad del código fuente, y Mobile DAST prueba la app en ejecución en CI/CD. El pentest con agentes de IA prueba la app y sus API con sesión iniciada, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA.
Qué sigue en sus manos
La política de exclusión y su aprobación por el consejo, la independencia del equipo de pruebas, el acceso al código fuente y la aprobación de las publicaciones.
- Banking Act Directions No. 16 of 2021, 5.8.2 y 5.2.4 (según las Directions No. 05 of 2023)
Realizar evaluaciones de vulnerabilidad al menos cada trimestre
Qué dice el texto
Los sistemas de información críticos y los sistemas expuestos a datos de clientes se someten a evaluaciones de vulnerabilidad al menos trimestrales. Las evaluaciones abarcan tanto vulnerabilidades de infraestructura como de aplicación y se realizan en entornos de producción. Las vulnerabilidades identificadas deben corregirse en un plazo aprobado por el comité de seguridad de la información del banco. El mismo marco exige revisiones de privilegios de acceso al menos trimestrales para sistemas críticos y semestrales para sistemas no críticos expuestos a datos de clientes o datos confidenciales de no clientes.
Fuente:Banking Act Directions No. 16 of 2021, 5.8.2 y 5.2.4 (según las Directions No. 05 of 2023)
Qué supone para su app móvil
Cuatro ciclos de evaluación al año sobre la app de producción y sus API dejan poco margen para pruebas manuales puntuales. La cadencia tiene que ser automatizada y repetible.
Cómo ayuda Ostorlab
Ostorlab ejecuta escaneos programados desde su pipeline de CI/CD y vigila las versiones publicadas en las tiendas sin activación manual. Los hallazgos se clasifican como críticos, altos, medios o bajos y se siguen como tickets en la plataforma o en Jira y ServiceNow.
Qué sigue en sus manos
Los plazos de corrección aprobados por el ISC, el parcheo de infraestructura y la gestión de cambios en producción.
- Banking Act Directions No. 16 of 2021, 5.8.3; plazo en producción el 31 de diciembre de 2028 según las Directions No. 05 of 2023
Pruebas de penetración por expertos externos independientes
Qué dice el texto
Los sistemas de información críticos, los sistemas expuestos a datos de clientes y los repositorios de datos de clientes, incluidos los de agentes y proveedores terceros, deben ser probados por expertos externos independientes en pruebas de penetración. Los sistemas críticos al menos una vez al año, y todos los demás sistemas incluidos al menos una vez cada dos años. Las pruebas se basan en inteligencia de amenazas, se realizan sobre sistemas de producción reales en condiciones normales de negocio, sin cambiar las medidas de seguridad habitualmente en vigor, y cubren amenazas externas e internas. Se exigen pruebas de caja negra y de caja gris con credenciales proporcionadas por el banco para categorías de usuario clientes, operativas y gerenciales. Una especificación del alcance de la prueba define los sistemas, los escenarios de amenaza, los objetivos y el periodo, el consejo de administración aprueba el ejercicio, y un resumen ejecutivo se remite al Director of Bank Supervision en los 60 días siguientes al informe del proveedor.
Qué supone para su app móvil
La prueba anual de penetración es la evaluación más profunda del marco, y la app, sus API y las cuentas de prueba son las partes que un proveedor especializado en móvil puede cubrir. Atención al plazo: las pruebas en producción deben realizarse antes del 31 de diciembre de 2028.
Cómo ayuda Ostorlab
El pentest con agentes de IA prueba la app y sus API con sesión iniciada y sus cuentas de prueba, incluidos los flujos de caja gris, y ofrece un exploit reproducible para cada hallazgo de un agente de IA. Los hallazgos se agrupan en tickets y se vuelven a probar tras publicarse la corrección.
Qué sigue en sus manos
La aprobación del consejo de la especificación de alcance y del ejercicio, el equipo de dirección, la acreditación del proveedor externo, las verificaciones y las referencias, y el informe a 60 días al Director of Bank Supervision.
- Banking Act Directions No. 16 of 2021, 5.8.4
Prepararse para los ejercicios de red team
Qué dice el texto
Los ejercicios de red team extienden las pruebas de penetración a las capas humana y física de la seguridad. Los D-SIB deben realizarlos al menos una vez cada dos años y los demás bancos licenciados al menos una vez cada tres años, sobre la base de una Red Teaming Scope Statement aprobada por el consejo de administración y junto con una prueba de penetración del mismo ciclo. Cuando el consejo determina que la madurez de seguridad del banco aún no es suficiente, los ejercicios se aplazan hasta 12 meses.
Qué supone para su app móvil
El red team prueba todo el banco, no solo la app. Es un ejercicio de naturaleza distinta a una prueba de penetración externa y se espera además de ella.
Cómo ayuda Ostorlab
Ostorlab no realiza ejercicios de red team ni los sustituye. Mantiene los elementos de app y API de su plan de remediación probados y reprobados, para que la capa tecnológica esté en forma antes de un ciclo de red team.
Qué sigue en sus manos
El alcance y la ejecución de los ejercicios de red team, la RTSS, las decisiones del consejo y las evaluaciones de las capas humana y física.
- Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, secciones 5, 6 y 8
Implantar los controles de apps de pago: MFA, vinculación de dispositivo, sesiones y bloqueo
Qué dice el texto
La guía de pagos exige registrar las cuentas de usuario y los dispositivos con el proveedor usando el número de móvil y un identificador único de dispositivo, que una cuenta solo pueda usarse en dispositivos registrados y que no se permita el uso simultáneo de la misma cuenta desde varios dispositivos. La autenticación debe procesarse en el backend, salvo los métodos basados en biometría o chip. La MFA combina el número de móvil, el identificador de dispositivo, la contraseña o PIN y un identificador específico de la app. La app debe tener un bloqueo de cuenta configurable tras varios intentos de inicio de sesión no válidos, un identificador de sesión aleatorizado, cierre de sesión automático tras un periodo de inactividad, un cierre de sesión claramente visible que borre los datos sensibles propios de la app de la memoria temporal y permanente, detección en el servidor de intentos de inicio de sesión simultáneos y un procedimiento para desactivar la app de forma centralizada en un dispositivo denunciado como perdido o robado.
Qué supone para su app móvil
Son comportamientos comprobables, y deben cumplirse en el backend, no solo en la interfaz de la app. Un atacante que llame directamente a la API debe encontrarse los mismos controles.
Cómo ayuda Ostorlab
Las pruebas autenticadas cubren inicio y cierre de sesión, renovación de tokens, tiempos de espera, invalidación de sesiones, bloqueo de cuentas y aplicación efectiva de la MFA con sus cuentas de prueba, junto con las llamadas de API que los sustentan.
Qué sigue en sus manos
La gestión de identidades y accesos, los registros de dispositivos y el proceso para dispositivos perdidos.
- Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, secciones 12, 13, 14 y 15
Endurecer la app: manipulación, root, depuración y pinning
Qué dice el texto
La guía exige comprobaciones de integridad en el servidor sobre valores hash o sumas de comprobación de bloques de código, tamaño y fechas de modificación de archivos y la firma del paquete, desactivándose la app si fallan. La app no debe ejecutarse en dispositivos con root o jailbreak. Deben implantarse la detección de depurador y emulador, la minificación y la ofuscación del código fuente, y ningún tercero debe poder depurar la app en tiempo de ejecución. Se exige cifrado de la capa de transporte para todas las comunicaciones, con certificados SSL válidos emitidos por una autoridad de certificación de confianza, certificate pinning implementado con un manejo adecuado de excepciones y controles para mitigar la elusión del pinning. La app debe cesar su funcionamiento hasta que los errores de certificado SSL se resuelvan correctamente.
Qué supone para su app móvil
Estas protecciones son lo primero que prueba un atacante en una app de pago. Un control que existe en el código pero puede eludirse en tiempo de ejecución no cuenta.
Cómo ayuda Ostorlab
Mobile Shielding Scan prueba en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación, la detección de depurador y emulador y el pinning, y muestra qué protecciones resistieron y cuáles se eludieron.
Qué sigue en sus manos
La infraestructura de ofuscación y firma de código, las publicaciones en las tiendas y el comportamiento de la app en producción.
- Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, secciones 11 y 16; Banking Act Directions No. 16 of 2021, 5.8.2
Mantener los componentes corregidos y demostrarlo
Qué dice el texto
Las apps móviles de pago no deben usar componentes, protocolos, bibliotecas o scripts vulnerables u obsoletos, las implementaciones de esos componentes no deben introducir vulnerabilidades, y la app debe corregirse correctamente cuando se identifique una vulnerabilidad. Los algoritmos criptográficos y los recuentos de iteraciones deben ser actualmente no identificados como vulnerables, probados por la industria y aceptados por instituciones como la FFIEC, ANSI y NIST. Según las directrices sobre riesgo tecnológico, las vulnerabilidades identificadas en las evaluaciones deben corregirse en un plazo aprobado por el ISC.
Qué supone para su app móvil
Los SDK y bibliotecas nativas de una app bancaria son software que usted publica. Cada uno necesita una versión conocida, una gravedad cuando aparece una vulnerabilidad y un plazo de corrección demostrable.
Cómo ayuda Ostorlab
SCA identifica por huella las bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas versión tras versión. El cierre se sigue como tickets en la plataforma o en Jira y ServiceNow, y los hallazgos se clasifican como críticos, altos, medios o bajos.
Qué sigue en sus manos
Las decisiones de parcheo, los contratos de mantenimiento con proveedores, la planificación de actualizaciones y la aceptación de riesgos.
- Banking Act Directions No. 16 of 2021, 5.5.1; Guidelines No. 1 of 2020, secciones 9.3, 11.2 y 11.3; Personal Data Protection Act No. 9 of 2022, sección 10
Proteger los datos de clientes en el dispositivo y en tránsito
Qué dice el texto
Según las directrices sobre riesgo tecnológico, los datos de clientes se protegen con cifrado: cifrado en reposo a nivel de base de datos o de archivos, cifrado de los datos en tránsito y cifrado de disco completo para dispositivos endpoint y medios extraíbles que almacenen datos de clientes. Cuando el cifrado no sea factible o adecuado, las excepciones requieren aprobación del consejo, controles compensatorios y monitorización, y una revisión al menos cada dos años. La guía de pagos añade que la información sensible, como números de cuenta y credenciales de clientes en almacenamiento temporal del dispositivo, debe protegerse, que los datos sensibles se cifran en tránsito y en reposo, que las claves de cifrado no se almacenan en el dispositivo móvil sin controles de seguridad adecuados y que los datos sensibles no se almacenan en el dispositivo. La Ley de Protección de Datos Personales exige a los responsables garantizar la integridad y confidencialidad de los datos personales con medidas técnicas y organizativas adecuadas, como cifrado, seudonimización, anonimización o controles de acceso.
Qué supone para su app móvil
Los tokens, números de cuenta y credenciales nunca deberían estar en texto claro en el almacenamiento, las cachés, los registros o los informes de fallos de la app, ni viajar sin protección al backend.
Cómo ayuda Ostorlab
Ostorlab busca tokens de sesión y datos personales en el almacenamiento local, las cachés, los registros y las capturas de pantalla, y detecta configuraciones erróneas que debilitan la protección del transporte y de las sesiones.
Qué sigue en sus manos
La clasificación de datos, la gestión de claves, las copias de seguridad y el proceso de excepciones con el consejo.
- Payment and Settlement Systems Circulars No. 01 of 2024, No. 02 of 2024 y No. 01 of 2026
Aplicar el umbral de OTP de JustPay y los controles de registro de apps de pago
Qué dice el texto
Para las transacciones JustPay de 10.000 rupias o más, la app móvil de pago que inicia la transacción debe solicitar un código de un solo uso al emisor de la cuenta vinculada, enviado al número de móvil registrado con el emisor. Esto se aplica desde el 1 de abril de 2024. Desde el 31 de marzo de 2025, los proveedores deben identificar a los usuarios con un documento de identidad aceptable, verificar esa identidad antes de permitir transacciones o vincular una cuenta y, para JustPay, verificar que el usuario de la app y el titular de la cuenta son la misma persona haciendo coincidir el número de móvil del dispositivo con el registrado para la cuenta. La Circular No. 01 of 2026 limita las transacciones JustPay a 150.000 rupias desde el 2 de febrero de 2026 y exige a todos los proveedores de apps móviles de pago controles y procedimientos de seguridad adecuados al registrar clientes y vincular cuentas.
Fuente:Payment and Settlement Systems Circulars No. 01 of 2024, No. 02 of 2024 y No. 01 of 2026
Qué supone para su app móvil
La aplicación efectiva del OTP y las comprobaciones de identidad son comportamientos del backend. Pruébelos intentando completar una transacción o vincular una cuenta sin el factor requerido o desde el dispositivo equivocado.
Cómo ayuda Ostorlab
Ostorlab completa códigos de un solo uso por SMS, correo o TOTP con sus cuentas de prueba y prueba la aplicación efectiva del OTP, la MFA y los flujos de autenticación reforzada, junto con las llamadas de API detrás de la vinculación de cuentas y los pagos.
Qué sigue en sus manos
El proceso de verificación de identidad, los registros de dispositivos y la configuración de los límites de transacción.
- Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sección 25
Auditar antes del lanzamiento y reportar cada año
Qué dice el texto
Cada proveedor de servicios de pago debe presentar un informe de cumplimiento, aprobado por su consejo de administración, al Director of the Payments and Settlements Department antes del lanzamiento comercial de cada app móvil de pago, y un informe del año anterior antes del 31 de enero de cada año que cubra nuevas versiones, parches y actualizaciones. Se recomienda encarecidamente una auditoría del sistema de información y una auditoría de seguridad de la información de todo el ecosistema por un auditor externo independiente, con un alcance que incluya análisis de seguridad estático y dinámico, revisión del código fuente para controles de seguridad, puertas traseras e información sensible codificada, revisión de los entornos de producción y pruebas, y revisión de evaluaciones de vulnerabilidad y pruebas de penetración.
Qué supone para su app móvil
El expediente de cumplimiento necesita pruebas, no solo afirmaciones, y cada nueva versión reinicia el ciclo en la práctica.
Cómo ayuda Ostorlab
Ostorlab genera resultados de escaneo, evidencias de solicitudes y respuestas, exploits reproducibles y resultados de reprobado para cada versión, que puede adjuntar al expediente de auditoría. Ostorlab no presenta informes al CBSL y no es una firma de auditoría.
Qué sigue en sus manos
La aprobación del informe de cumplimiento por el consejo, las presentaciones al CBSL y cualquier opinión que solicite a una firma de auditoría autorizada.
Resumen de textos públicos del CBSL y de la Ley de Protección de Datos Personales, consultados el 27 de septiembre de 2026. Los puntos de la guía de pagos se resumen a partir del texto en inglés. Esta página no es asesoramiento jurídico.
Las normas del CBSL, control por control
Los controles a los que apuntan los textos del CBSL, 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 de la app antes de la puesta en producciónDirectrices 16/2021, 5.8.1 | Mobile SAST sobre el APK, AAB o IPA y Mobile DAST en CI/CD, en cada cambio y sin necesidad del código fuente. Detalles | Resultados de escaneo por build y por cambio, adjuntos al expediente de la versión |
| Evaluaciones de vulnerabilidad trimestrales en producciónDirectrices 16/2021, 5.8.2 | Escaneos programados desde su pipeline sobre la versión de producción y vigilancia de las publicaciones en las tiendas sin activación manual. Detalles | Resultados de evaluación por trimestre, con gravedad y estado de corrección |
| Prueba de penetración anual por expertos externos independientesDirectrices 16/2021, 5.8.3 | Pentest con agentes de IA de la app y sus API con sesión iniciada, incluidos los flujos de caja gris con sus cuentas de prueba. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de calor de cobertura |
| Inicio de sesión, MFA y bloqueo de cuentasGuía 01/2020, 6 | Inicia sesión con códigos de un solo uso y prueba la aplicación efectiva de la MFA, los flujos de autenticación reforzada y el bloqueo tras intentos no válidos. Detalles | Hallazgos sobre los flujos de inicio de sesión y bloqueo, con pasos de reproducción |
| Vinculación de dispositivo, sesiones y desactivación por pérdidaGuía 01/2020, 5 y 8 | Prueba la aleatorización de sesiones, el cierre por inactividad, la invalidación de sesiones y las llamadas de API detrás del registro de dispositivos. Detalles | Hallazgos sobre sesiones y tokens, con registros de solicitudes y respuestas |
| Detección de manipulación, root y emulador, certificate pinningGuía 01/2020, 12 a 15 | Prueba en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación, la detección de depurador y emulador y el pinning. Detalles | Evidencia de elusión que muestra qué protección falló y qué expuso |
| Componentes vulnerables y plazos de correcciónGuía 01/2020, 11 y 16 | Identifica por huella las bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas, versión tras versión. Detalles | Vulnerabilidades identificadas con recomendaciones de actualización o sustitución, y cierre seguido entre versiones |
| Claves y configuración sensible codificadasGuía 01/2020, 16.5 | Detecta claves de API, tokens y credenciales en el paquete de la app y verifica si funcionan. Detalles | Secretos validados, con los permisos y servicios que exponen |
| Datos de clientes en el dispositivo y en tránsitoDirectrices 16/2021, 5.5.1; Guía 11 | Busca tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y comprueba la protección del transporte. | Evidencia del sistema de archivos que muestra qué se escribió, dónde y cuándo |
| SDK de terceros e infraestructura en la versiónDirectrices 16/2021, 9.9; Guía 23 | Enumera los SDK y bibliotecas nativas de cada versión y muestra con qué backends habla la app y sus SDK. Detalles | Identidad, versión y ubicación de cada componente en el bundle de la app, por versión |
Ostorlab prueba los controles de la app y sus API. La monitorización del SOC, la respuesta a incidentes y su notificación, los ejercicios de red team, el TLPT, la recuperación ante desastres, la gobernanza, la contratación de proveedores y las aprobaciones del consejo siguen en manos de sus equipos.
Controles del CBSL que probar en su app móvil
Una lista práctica para equipos de seguridad y riesgo tecnológico, basada en las directrices del CBSL sobre riesgo tecnológico, la guía de pagos móviles y la Ley de Protección de Datos Personales.
Pruebas previas a la publicación
Incluya SAST o revisión de código fuente y DAST en el pipeline para cada cambio de la app y su backend, como exigen las pruebas previas a la puesta en producción.
Evaluaciones de vulnerabilidad trimestrales
Programe evaluaciones de la app y las API en producción al menos cada trimestre, con plazos de corrección aprobados por el comité de seguridad de la información.
Prueba de penetración anual
Prepare la especificación de alcance aprobada por el consejo y la prueba externa: caja negra y caja gris, escenarios de amenaza, sistemas de producción, y el resumen ejecutivo a 60 días al Director of Bank Supervision.
Endurecimiento de la app
Pruebe la detección de root y jailbreak, la protección contra manipulación, la detección de depurador y emulador, la ofuscación y el pinning, y confirme que la app se desactiva cuando fallan las comprobaciones de integridad.
Autenticación, OTP y sesiones
Verifique la MFA en el backend, el bloqueo de cuentas, la aleatorización de los identificadores de sesión, el cierre por inactividad que borra datos sensibles, la desactivación por pérdida y el umbral de OTP de JustPay.
Componentes y secretos
Enumere los SDK y bibliotecas de cada versión, fije plazos de corrección según la gravedad y busque claves y configuración codificadas en el paquete.
Protección de datos
Revise el almacenamiento, las cachés, los registros y los informes de fallos en busca de tokens y datos personales, y documente el cifrado y las medidas de protección de datos.
Reportar y reprobar
Conserve el informe de cumplimiento previo al lanzamiento, el informe anual del 31 de enero y la evidencia de reprobado de cada corrección.
Una lista sugerida, no una plantilla del CBSL. 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 eludieron.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.
- Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications (Guideline No. 01/2020)CBSL, emitida el 29 de mayo de 2020, en vigor desde el 1 de junio de 2020, en sustitución de la guía n.º 01 de 2018. Registro de dispositivos, autenticación, sesiones, almacenamiento de datos, criptografía, detección de manipulación e informe de cumplimiento previo al lanzamiento para apps móviles de pago y su ecosistema (texto en inglés)
- Banking Act Directions No. 16 of 2021, Regulatory Framework on Technology Risk Management and Resilience for Licensed BanksCBSL, 9 de diciembre de 2021. Aplica a bancos comerciales licenciados y bancos especializados licenciados, incluidas las operaciones a través de agentes y proveedores terceros. Pruebas de seguridad de la información, cifrado, gestión de accesos y requisitos de infraestructura (texto en inglés)
- Banking Act Directions No. 05 of 2023, Amendments to the Banking Act Directions No. 16 of 2021CBSL, 8 de diciembre de 2023. Plazos de cumplimiento revisados, incluidas las pruebas de penetración en producción antes del 31 de diciembre de 2028, revisiones trimestrales de privilegios de acceso para sistemas críticos y equipos de pruebas de penetración de la casa matriz para bancos constituidos fuera de Sri Lanka
- Payment and Settlement Systems Circular No. 01 of 2024, Facilitating safer and more secure transactions via mobile payment applicationsCBSL, 17 de enero de 2024, en aplicación desde el 1 de abril de 2024. Código de un solo uso emitido por el emisor de la cuenta para transacciones JustPay de 10.000 rupias o más, enviado al número de móvil registrado con el emisor
- Payment and Settlement Systems Circular No. 02 of 2024, Strengthening Customer Identification Process to Safeguard Funds in Current Accounts/Savings Accounts linked to Mobile Payment ApplicationsCBSL, 3 de diciembre de 2024, aplicable desde el 31 de marzo de 2025. Comprobaciones de documento de identidad, verificación antes de las transacciones y coincidencia entre el número de móvil del dispositivo y el de la cuenta al vincularla
- Payment and Settlement Systems Circular No. 01 of 2026, Maximum per transaction limit and fees for JustPay transactionsCBSL, 20 de enero de 2026, en vigor desde el 2 de febrero de 2026. Transacciones JustPay limitadas a 150.000 rupias y controles y procedimientos de seguridad adecuados exigidos al registrar clientes y vincular cuentas
- Circular No. 02 of 2025, Reporting of Information Technology and Cybersecurity Incidents of Licensed BanksCBSL, 7 de mayo de 2025. Notificación inmediata al Director of Bank Supervision en las 2 horas siguientes a la detección, informe detallado en 14 días e informe trimestral en los 15 días posteriores a cada trimestre
- Personal Data Protection Act No. 9 of 2022Certificada el 19 de marzo de 2022, modificada por la Personal Data Protection (Amendment) Act No. 22 of 2025, certificada el 30 de octubre de 2025. La Gaceta extraordinaria n.º 2498/16, de 22 de julio de 2026, fija el 1 de enero de 2027 para la sección 2, la sección 3, la parte I y la parte III, que cubren los principios de tratamiento y las obligaciones de responsables y encargados (texto en inglés)
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 como lo describe el CBSL
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.