Riesgo de TI del BSP y normas AFASA: evalúe su app de banca móvil en cada versión.
La circular BSP 982 pide a las instituciones financieras supervisadas que prueben las aplicaciones con pruebas de penetración, evaluaciones de vulnerabilidades y pruebas de seguridad de aplicaciones antes de cargarlas en producción, y que una parte externa realice evaluaciones de vulnerabilidades y pruebas de penetración al menos una vez al año para los servicios financieros digitales y electrónicos. La circular 1213, que implementa la Anti-Financial Account Scamming Act, restringe las apps en dispositivos rooteados, con jailbreak o emulados, limita los códigos PIN de un solo uso enviados por SMS y correo electrónico y exige una pausa de 24 horas tras los cambios clave de la cuenta. Ostorlab prueba su app y las API en las que se apoya, detrás del inicio de sesión, en cada versión.
- Evalúa la app móvil y las API a las que llama en la compilación que descargan sus clientes
- Inicia sesión con sus cuentas de prueba, incluidos códigos de un solo uso y flujos de autenticación reforzada
- Intenta evadir la detección de root, jailbreak, emuladores y manipulación, y muestra qué resistió
- Demuestra cada hallazgo con un exploit reproducible o con evidencia de solicitudes y respuestas
- A quién se aplica
- Bancos y otras instituciones financieras supervisadas por el BSP, incluidas las instituciones financieras no bancarias y los operadores de sistemas de pago
- Fecha clave
- Circular 1213 vigente desde el 25 de junio de 2025, con sus estándares a aplicar en el plazo de un año; la circular 982 está en vigor desde diciembre de 2017
- Objeto
- Pruebas de seguridad de aplicaciones, evaluación de vulnerabilidades y pruebas de penetración externas anuales, autenticación y controles antifraude en los canales móviles
- Referencia principal
- Circular BSP 982, Enhanced Guidelines on Information Security Management, apéndice 75b del MORB
Los textos del BSP que rigen su canal móvil
Las directrices de seguridad de la información conviven con el marco de riesgo de TI y las normas AFASA. Las fechas siguientes corresponden a los textos citados en esta página.
- 22 de agosto de 2013
Circular 808, riesgo de TI
La circular BSP 808 establece las directrices sobre gestión del riesgo de las tecnologías de la información para todos los bancos y demás instituciones supervisadas por el BSP, el marco que modificaron las circulares posteriores.
- 5 de diciembre de 2017
Circular 982, seguridad de la información
Entran en vigor las Enhanced Guidelines on Information Security Management. Entre otras medidas, piden prácticas de desarrollo seguro, pruebas de seguridad de aplicaciones antes de producción y evaluación de vulnerabilidades y pruebas de penetración por una parte externa al menos una vez al año para los servicios financieros digitales y electrónicos.
- 24 de marzo de 2022
Circular 1140, gestión del fraude
Las enmiendas añaden sistemas automatizados de vigilancia y detección del fraude en tiempo real y un programa reforzado de concienciación del consumidor, ante el aumento del fraude electrónico.
- 20 de julio de 2024
Firma de la AFASA
Se firma la Republic Act No. 12010, la Anti-Financial Account Scamming Act. Su artículo 6 exige que las instituciones protejan el acceso a las cuentas financieras de sus clientes con sistemas y controles de gestión de riesgos adecuados, como la MFA, los sistemas de gestión del fraude y los procesos de verificación de cuentas.
- 25 de junio de 2025
Circular 1213, normas AFASA
Entran en vigor las enmiendas a las normas de riesgo de TI: pausa de 24 horas tras los cambios clave de la cuenta, restricciones en dispositivos rooteados, con jailbreak o emulados, límites a los códigos PIN de un solo uso por SMS y correo, huella de dispositivo y prohibición de enlaces clicables y códigos QR en los mensajes de los bancos.
- 27 de abril de 2026
Cybersecurity Maturity Framework
La circular 1232 sustituye el IT Rating System por el Supervisory Assessment Framework e introduce el Cybersecurity Maturity Framework y la autoevaluación CCSA, con informes anuales y niveles de madurez ligados al perfil de TI de cada institución.
- Junio de 2026
Plazo de los estándares AFASA
Los estándares de la circular 1213 debían estar en vigor en el plazo de un año desde su entrada en vigor, un plazo del que se informó como el 30 de junio de 2026. Las normas incluyen limitar los códigos PIN de un solo uso interceptables y pasar las transacciones de alto riesgo a autenticación fuerte.
Las normas del BSP, 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. Las citas provienen de las circulares publicadas por el Bangko Sentral ng Pilipinas.
- Circular BSP 982, apéndice 75b, 3.3.3.4 Application Security
Probar las aplicaciones antes de su puesta en producción
Qué dice el texto
La dirección debe asegurarse de que todas las aplicaciones, desarrolladas internamente o adquiridas ya hechas, tengan controles adecuados a su sensibilidad y criticidad. Las prácticas de codificación segura que incorporan los requisitos de seguridad desde la fase de desarrollo deben formar parte de las políticas y procedimientos de desarrollo y adquisición de sistemas de la institución. Las nuevas aplicaciones, incluidas las mejoras posteriores, deben probarse adecuadamente con diversas metodologías (por ejemplo, pruebas de penetración, evaluaciones de vulnerabilidades y pruebas de seguridad de aplicaciones) antes de cargarlas en producción. Las revisiones de sistemas, las pruebas de penetración y las evaluaciones de vulnerabilidades deben realizarse periódicamente.
Fuente:Circular BSP 982, apéndice 75b, 3.3.3.4 Application Security
Qué supone para su app móvil
Cada versión de una app de banca móvil es una nueva versión de software que va a producción. La app, y el backend con el que habla, forman parte del proceso de versión, no solo de un ejercicio anual.
Cómo ayuda Ostorlab
Un pentest con agentes de IA prueba la compilación publicada en la tienda y las API en las que se apoya, detrás del inicio de sesión, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA. Mobile SAST y Mobile DAST se ejecutan desde su pipeline CI/CD en cada compilación, sobre el APK, el AAB o el IPA, sin necesidad del código fuente.
Qué sigue en sus manos
Los estándares de codificación segura, la aprobación de cambios, la decisión de puesta en producción y la supervisión de las apps desarrolladas por proveedores.
- Circular BSP 982, apéndice 75b, 3.7.1 y 3.7.2 (c) a (g)
Realizar cada año una evaluación de vulnerabilidades y pruebas de penetración por una parte externa
Qué dice el texto
La evaluación de vulnerabilidades identifica vulnerabilidades de seguridad en sistemas y redes, normalmente con escáneres automatizados, con una frecuencia determinada por el riesgo y la criticidad del sistema, y las vulnerabilidades de alto riesgo detectadas deben corregirse en un plazo razonable. Las pruebas de penetración someten a un sistema o red a ataques simulados o reales que explotan vulnerabilidades en condiciones controladas. Para las BSFI que prestan servicios financieros digitales o electrónicos, la evaluación de vulnerabilidades y las pruebas de penetración deben realizarlas una parte externa al menos una vez al año. Las pruebas también deben cubrir escenarios extremos pero plausibles, y las directrices incluyen las evaluaciones de compromiso y los ejercicios de red teaming entre los tipos de prueba.
Fuente:Circular BSP 982, apéndice 75b, 3.7.1 y 3.7.2 (c) a (g)
Qué supone para su app móvil
Su app móvil forma parte de un servicio financiero digital. Planifique al menos una evaluación de vulnerabilidades y unas pruebas de penetración externas al año, y siga probando entre esos ciclos, porque la app cambia en cada versión.
Cómo ayuda Ostorlab
Ostorlab es una parte externa que puede probar la app y sus API en cada versión, entre sus pruebas anuales. Los hallazgos se clasifican como críticos, altos, medios o bajos, se siguen como tickets en la plataforma o en Jira y ServiceNow, y se vuelven a probar cuando se publica la corrección.
Qué sigue en sus manos
Elegir y contratar a la parte externa, las condiciones de las pruebas en producción y la decisión sobre el alcance y la frecuencia.
- Circular BSP 982, apéndice 75b, 3.3.3.8.3 Patch Management y 3.7.2(c)
Mantener la gestión de parches y los plazos de corrección
Qué dice el texto
La dirección debe adoptar un proceso de gestión de parches para identificar con prontitud los parches de seguridad disponibles para los activos tecnológicos y de software, evaluar su criticidad y su riesgo, y probarlos y desplegarlos en un plazo adecuado. Las vulnerabilidades de alto riesgo detectadas en las evaluaciones de vulnerabilidades deben corregirse en un plazo razonable.
Fuente:Circular BSP 982, apéndice 75b, 3.3.3.8.3 Patch Management y 3.7.2(c)
Qué supone para su app móvil
Las bibliotecas y SDK incluidos en su app son activos de software. Cada uno necesita una versión conocida, una evaluación cuando aparece una vulnerabilidad y una corrección en un plazo razonable y documentado.
Cómo ayuda Ostorlab
SCA identifica mediante huellas las bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas, versión tras versión. Cada hallazgo lleva una severidad y puede seguirse como ticket, de modo que el cierre es visible entre versiones.
Qué sigue en sus manos
El despliegue de parches en sus sistemas e infraestructura, las ventanas de mantenimiento y las decisiones de aceptación de riesgos.
- Circular BSP 982, apéndice 75b, 3.3.3.8.4 Vendor Management and Outsourcing; circular BSP 1213, artículo 1 (sección 148 del MORB), marco de responsabilidad compartida (c)
Gestionar proveedores y terceros
Qué dice el texto
La dirección debe realizar la diligencia debida adecuada y considerar la seguridad de la información al seleccionar proveedores de servicios externos, asegurar que existan procesos eficaces de supervisión de sus actividades y detallar suficientemente los requisitos de seguridad de la información en los contratos, en particular para los proveedores que almacenan, transmiten, procesan o eliminan información de clientes. Las exposiciones al ciberriesgo procedentes de terceros deben evaluarse y usarse para ajustar el programa de gestión del ciberriesgo de la institución. La circular 1213 también pide a las BSFI que hagan cumplir y evalúen periódicamente que las entidades y proveedores externos que participan en transacciones financieras respeten estrictamente sus obligaciones contractuales de disponibilidad, seguridad de la información y ciberseguridad.
Qué supone para su app móvil
Una app de banca móvil incluye SDK de terceros que hablan con sus propios backends, y las API que la sostienen pueden ser operadas por proveedores. Forman parte de su visión del riesgo de terceros.
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 con qué backends intercambian datos la app y sus SDK, para que vea qué aporta cada tercero a la compilación.
Qué sigue en sus manos
La diligencia debida, los contratos, el seguimiento de proveedores y los planes de salida.
- Circular BSP 982, apéndice 75b, 3.3.3.5 Data Security, incluidos 3.3.3.5.1 y 3.3.3.5.2
Proteger los datos en el dispositivo y en tránsito
Qué dice el texto
La BSFI debe contar con una estrategia de clasificación de la información e instaurar controles de protección conforme a ese esquema, protegiendo la información durante todo su ciclo de vida, desde la manipulación, el almacenamiento o datos en reposo, la transmisión o datos en tránsito, hasta su eliminación. Los controles sobre la información almacenada en dispositivos portátiles como portátiles, teléfonos inteligentes y tabletas deben tener en cuenta su susceptibilidad a la pérdida o el robo, e incluir medidas como el cifrado de datos, los controles de acceso del propio dispositivo y el borrado remoto. Las políticas, normas y procedimientos deben mantener los datos seguros en tránsito y al compartirse con terceros.
Fuente:Circular BSP 982, apéndice 75b, 3.3.3.5 Data Security, incluidos 3.3.3.5.1 y 3.3.3.5.2
Qué supone para su app móvil
El teléfono es el dispositivo portátil. Las contraseñas, los tokens y los datos personales no deben quedar en claro en él, en cachés, registros o capturas de pantalla, 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, comprueba qué escribe la app en el disco y prueba si las protecciones del transporte, como el TLS pinning, pueden evadirse.
Qué sigue en sus manos
La clasificación de datos, la gestión de claves, el borrado remoto y las políticas de gestión de dispositivos.
- Circular BSP 1213, artículo 1 (sección 148 del MORB), párrafo (e)(ii)
Restringir la app en dispositivos rooteados, con jailbreak y emulados
Qué dice el texto
Las cuentas financieras deben protegerse con medidas de seguridad que mitiguen riesgos como los ciberataques, el acceso no autorizado y las transacciones fraudulentas. Estas salvaguardas incluyen una restricción a la instalación de aplicaciones móviles en dispositivos no seguros, como, entre otros, los que tienen sistemas desactualizados, los dispositivos rooteados o con jailbreak, o los emuladores.
Fuente:Circular BSP 1213, artículo 1 (sección 148 del MORB), párrafo (e)(ii)
Qué supone para su app móvil
La detección por sí sola no basta. La app debe detener la sesión, el alta o la transacción cuando el dispositivo está comprometido, y la comprobación no debe poder desactivarse con facilidad.
Cómo ayuda Ostorlab
Mobile Shielding Scan ejecuta la app en entornos rooteados, con jailbreak y emulados, intenta evadir la detección y muestra si la app bloquea el flujo, se niega a arrancar o sigue funcionando. Obtiene una puntuación de endurecimiento y evidencia de la evasión.
Qué sigue en sus manos
La política para dispositivos comprometidos o desactualizados, la elección de la tecnología de detección o protección y la atención a los clientes bloqueados.
- Circular BSP 1213, artículo 1 (sección 148 del MORB), párrafos (e)(vi) y (k)
Limitar los códigos PIN de un solo uso interceptables y eliminar los enlaces en los mensajes
Qué dice el texto
Las BSFI deben limitar el uso de mecanismos de autenticación que puedan compartirse con, o ser interceptados por, terceros ajenos a la transacción, como los códigos PIN de un solo uso enviados por SMS y correo electrónico. Las instituciones con productos y servicios electrónicos complejos y volúmenes elevados de transacciones en línea deben adoptar mecanismos de autenticación fuerte, como la autenticación biométrica, la biometría del comportamiento, la autenticación sin contraseña, incluida FIDO, o la autenticación adaptativa. Las directrices sobre la adopción de la autenticación multifactor están en el apéndice 79. Además, las BSFI no deben enviar enlaces clicables ni códigos QR por correo electrónico, mensajería instantánea o SMS, salvo que el mensaje responda a una acción previa del cliente, solo aporte información y no redirija a un sitio o aplicación web que pida información sensible o credenciales de acceso.
Fuente:Circular BSP 1213, artículo 1 (sección 148 del MORB), párrafos (e)(vi) y (k)
Qué supone para su app móvil
Los códigos por SMS y correo son el eslabón débil en la toma de control de cuentas, y un enlace en un mensaje bancario parece un mensaje de phishing. El inicio de sesión y las transacciones de alto riesgo deben pasar a métodos vinculados a la app o resistentes al phishing, y los mensajes no deben incluir enlaces.
Cómo ayuda Ostorlab
Las pruebas autenticadas inician sesión con sus cuentas de prueba, completan códigos de un solo uso por SMS, correo o TOTP, y prueban la aplicación efectiva de la MFA y los flujos de autenticación reforzada en las operaciones clave, incluida la posibilidad de reproducir, reutilizar o eludir los códigos, junto con las llamadas a la API que los sustentan.
Qué sigue en sus manos
La elección de los métodos de autenticación sustitutos, el plan de migración y la comunicación a los clientes.
- Circular BSP 1213, artículo 1 (sección 148 del MORB), párrafo (e)(i)
Aplicar la pausa de 24 horas tras los cambios clave de la cuenta
Qué dice el texto
Las BSFI deben implementar una pausa de 24 horas en las transacciones tras aplicar cambios clave en la cuenta, durante la cual los clientes quedan restringidos para realizar transacciones financieras. Los cambios clave son las modificaciones de información considerada esencial para proteger el acceso a las cuentas del cliente, como la actualización del número de móvil, la dirección de correo electrónico y el dispositivo registrado o autenticado que se usa para acceder a la cuenta. Una BSFI puede acortar la pausa o aplicar restricciones o límites de transacción en su lugar, siempre que existan mecanismos de autenticación fuerte y la institución asuma plena responsabilidad por los riesgos asociados.
Fuente:Circular BSP 1213, artículo 1 (sección 148 del MORB), párrafo (e)(i)
Qué supone para su app móvil
La pausa es lógica de negocio. Si la app o sus API permiten que un cliente, o un atacante con una sesión, la salte, el control ha fallado. El registro de dispositivos también debe probarse frente a la suplantación.
Cómo ayuda Ostorlab
El pentest con agentes de IA prueba los flujos de cambio de cuenta y de registro de dispositivos, y las pruebas de API comprueban que la pausa, los límites y las verificaciones reforzadas resisten en el servidor, con evidencia de solicitudes y respuestas.
Qué sigue en sus manos
La política sobre pausas acortadas y límites, las notificaciones a los clientes y el proceso de atención durante la pausa.
- Circular BSP 1213, artículo 1 (sección 148 del MORB), párrafos (e)(iii), (iv) y (v)
Bloquear la automatización no autorizada y comprobar la identidad del dispositivo
Qué dice el texto
Las BSFI deben prohibir el uso de scripts o herramientas de automatización no autorizados, como el screen scraping y la automatización de navegadores, para acceder a cuentas financieras y ejecutar transacciones, mediante medidas como el análisis del comportamiento, la limitación de la tasa de peticiones, la gestión de sesiones y la detección de bots. También deben adoptar una huella de dispositivo robusta y mecanismos eficaces para impedir la suplantación de la identidad del dispositivo. Las comprobaciones adecuadas de autenticación e integridad deben garantizar que las transacciones iniciadas en las aplicaciones accesibles a los clientes no se alteren antes o durante la transmisión o la ejecución en los sistemas backend.
Fuente:Circular BSP 1213, artículo 1 (sección 148 del MORB), párrafos (e)(iii), (iv) y (v)
Qué supone para su app móvil
Estos controles están en la API y en el backend. La limitación de tasa, la gestión de sesiones, las comprobaciones de integridad y la vinculación con el dispositivo son comprobables, y cada una puede faltar en al menos un endpoint.
Cómo ayuda Ostorlab
Ostorlab intercepta el tráfico de la app incluso con TLS pinning, y prueba las API en busca de controles de autorización defectuosos (BOLA, BFLA, IDOR), uso indebido de tokens y sesiones y abusos como la enumeración, la repetición y la automatización, con evidencia de solicitudes y respuestas para cada hallazgo.
Qué sigue en sus manos
La gestión de bots y del WAF, la vigilancia del fraude y la gobernanza de los datos de identidad de los dispositivos.
- Republic Act No. 10173, Data Privacy Act of 2012, artículo 20
Proteger los datos personales y notificar las brechas
Qué dice el texto
Según la Data Privacy Act of 2012, los responsables del tratamiento de datos personales deben implementar medidas organizativas, físicas y técnicas razonables y apropiadas para proteger los datos personales contra la destrucción, la alteración y la divulgación accidentales o ilícitas, así como contra cualquier otro tratamiento ilícito. Las medidas deben incluir salvaguardas de las redes informáticas, una política de seguridad, un proceso para identificar y atender las vulnerabilidades razonablemente previsibles de esas redes y una vigilancia periódica de las brechas de seguridad. Los responsables deben notificar sin demora a la National Privacy Commission y a los afectados cuando haya motivos razonables para creer que datos personales sensibles, o información que pueda permitir la suplantación de identidad, han sido adquiridos por una persona no autorizada y probablemente generen un riesgo real de daño grave.
Fuente:Republic Act No. 10173, Data Privacy Act of 2012, artículo 20
Qué supone para su app móvil
Los datos de los clientes en la app y en el tráfico de API son datos personales, y el malware móvil, los dispositivos rooteados y el almacenamiento inseguro son las vías de fuga.
Cómo ayuda Ostorlab
Ostorlab prueba las medidas técnicas de la app y de sus API: almacenamiento y registros, transporte, autenticación y autorización, y acceso a datos de otros clientes mediante controles de acceso defectuosos, con evidencia para cada hallazgo.
Qué sigue en sus manos
La gobernanza de la privacidad, los registros de tratamiento, la evaluación de brechas y la notificación a la NPC y a los afectados.
Resumen de textos públicos del BSP y de la Data Privacy Act, consultados el 27 de septiembre de 2026. Las citas provienen de las circulares publicadas por el Bangko Sentral ng Pilipinas. Esta página no constituye asesoramiento jurídico.
Las normas del BSP, control por control
Los controles a los que apuntan los textos del BSP, 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 aplicaciones antes de producciónCircular 982, 3.3.3.4 | Pentest con agentes de IA de la app y sus API, detrás del inicio de sesión, en la compilación que usted publica. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de cobertura |
| Evaluación de vulnerabilidades y pruebas de penetración externas anualesCircular 982, 3.7.2 (c) y (d) | Pruebas externas en cada versión, con severidades, tickets y retests entre sus pruebas anuales. Detalles | Resultados de escaneo con fecha por versión, y resultados de retest de cada corrección |
| Desarrollo seguro y pruebas estáticas antes de producciónCircular 982, 3.3.3.4 y 3.3.3.8.1 | Mobile SAST sobre el APK, el AAB o el IPA, con análisis de propagación (taint) en toda la app y sus SDK integrados, desde CI/CD. Detalles | Hallazgos con el contexto del código descompilado, por compilación |
| Gestión de parches y componentes vulnerablesCircular 982, 3.3.3.8.3 | Identifica mediante huellas 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 |
| Supervisión de terceros y SDKCircular 982, 3.3.3.8.4; circular 1213, (c) | Enumera los SDK y las bibliotecas nativas de cada 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 |
| Credenciales y claves en el paquete de la appCircular 982, 3.3.3.4 | Encuentra 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 |
| Dispositivos rooteados, con jailbreak y emuladosCircular 1213, (e)(ii) | Ejecuta la app en entornos comprometidos e intenta evadir la detección de root, jailbreak y emuladores. Detalles | Puntuación de endurecimiento, y evidencia de evasión de cada protección que falló |
| Códigos PIN de un solo uso interceptables y autenticación fuerteCircular 1213, (e)(vi) | Inicia sesión con códigos de un solo uso y prueba la aplicación efectiva de la MFA y los flujos de autenticación reforzada, incluida la repetición y reutilización de códigos. Detalles | Hallazgos en los flujos de inicio de sesión y autenticación reforzada, con pasos de reproducción |
| Cambios clave de cuenta, pausa de 24 horas y antiautomatizaciónCircular 1213, (e)(i), (iii) y (v) | Prueba los flujos de cambio de cuenta y registro de dispositivos, las autorizaciones de API, la gestión de sesiones y abusos como la repetición y la automatización. Detalles | Evidencia de solicitudes y respuestas de cada hallazgo, y resultados de retest tras la corrección |
| Protección de datos en el dispositivo y en tránsitoCircular 982, 3.3.3.5; RA 10173, artículo 20 | 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 |
Ostorlab prueba controles en la app y sus API. Los sistemas de vigilancia del fraude y la pausa de transacciones como política antifraude, el envío de alertas, la vigilancia del SOC, la respuesta y notificación de incidentes, la conservación de registros de transacciones, la gobernanza y el envío anual de la CCSA siguen en manos de sus equipos.
Controles del BSP que probar en su app móvil
Una lista práctica para los equipos de seguridad y riesgo de TI, basada en la circular 982, la circular 1213 y la Data Privacy Act.
Pruebas antes de cada versión
Incorpore las pruebas de seguridad de aplicaciones, incluidas las pruebas de penetración y el análisis estático, al proceso de versión antes de que la compilación llegue a producción.
VA y PT externas anuales
Programe una evaluación de vulnerabilidades y unas pruebas de penetración por una parte externa al menos una vez al año, además de las pruebas de cada versión.
Componentes y parches
Mantenga una lista versionada de los SDK y bibliotecas de cada versión, y corrija los problemas de alto riesgo en un plazo razonable y documentado.
Secretos en la app
Revise el paquete de la app en busca de claves de API, tokens y credenciales, y rote los que funcionen.
Dispositivos comprometidos
Ejecute la app en dispositivos rooteados, con jailbreak y emulados, y compruebe que el acceso y las transacciones quedan restringidos.
Códigos de un solo uso y autenticación fuerte
Verifique que los códigos de un solo uso no puedan reproducirse ni desviarse, y que las transacciones de alto riesgo exijan autenticación fuerte.
Cambios de cuenta y la pausa
Pruebe que los cambios de número de móvil, correo y dispositivo activan la pausa, y que no puede saltarse desde la app o sus API.
Datos en el dispositivo
Busque tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y pruebe las protecciones del transporte.
Una lista sugerida, no una plantilla del BSP. 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, jailbreak y emuladores, 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.
- BSP Circular No. 982, Series of 2017: Enhanced Guidelines on Information Security ManagementBSP, resolución del Monetary Board n.º 1854 del 2 de noviembre de 2017, en vigor desde el 5 de diciembre de 2017. Modifica el apéndice 75b del MORB y el apéndice Q-59b del MORNBFI: gestión del riesgo de seguridad de la información, seguridad de aplicaciones (3.3.3.4), seguridad de datos (3.3.3.5), gestión de parches (3.3.3.8.3) y pruebas (3.7)
- BSP Circular No. 808, Series of 2013: Guidelines on Information Technology Risk Management for All Banks and Other BSP Supervised InstitutionsBSP, resolución del Monetary Board n.º 1286 del 1 de agosto de 2013, publicada el 22 de agosto de 2013. El marco de gestión del riesgo de TI para las instituciones supervisadas, modificado por circulares posteriores
- BSP Circular No. 1140, Series of 2022: Amendments to Regulations on Information Technology Risk ManagementBSP, resolución del Monetary Board n.º 375 del 17 de marzo de 2022, de fecha 24 de marzo de 2022. Añade sistemas automatizados de vigilancia y detección del fraude en tiempo real y un programa reforzado de concienciación del consumidor
- BSP Circular No. 1213, Series of 2025: Amendments to Regulations on Information Technology Risk Management to Implement Section 6 of the Anti-Financial Account Scamming Act (AFASA)BSP, resolución del Monetary Board n.º 521 del 22 de mayo de 2025, de fecha 30 de mayo de 2025 y en vigor desde el 25 de junio de 2025. Añade la pausa de 24 horas, las restricciones en dispositivos no seguros, la huella de dispositivo, el contenido de las notificaciones, la prohibición de enlaces clicables y códigos QR, y los límites a los códigos PIN de un solo uso interceptables
- AFASA Booklet with Implementing Rules and RegulationsBSP, junio de 2025. Republic Act No. 12010, firmada el 20 de julio de 2024, con las circulares BSP n.º 1213, 1214 y 1215, serie de 2025. El artículo 6 exige sistemas y controles de gestión de riesgos adecuados, como la MFA, para proteger el acceso a las cuentas financieras de los clientes
- Republic Act No. 10173: Data Privacy Act of 2012National Privacy Commission, versión web de la ley firmada el 15 de agosto de 2012. El artículo 20 exige medidas de seguridad organizativas, físicas y técnicas razonables y apropiadas, y la notificación de brechas a la NPC y a los afectados
- BSP Circular No. 1232, Series of 2026: Cybersecurity Maturity Framework (CMF) and Cybersecurity Control Self-Assessment (CCSA) RequirementBSP, de fecha 27 de abril de 2026. Sustituye el IT Rating System por el Supervisory Assessment Framework y añade el CMF y la CCSA anual, con niveles de madurez ligados al perfil de TI de cada institución
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 BSP
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.