El RMiT de Bank Negara Malaysia: evalúe su app de banca móvil como lo describe BNM.
El documento de política Risk Management in Technology de BNM pide a las instituciones financieras una evaluación trimestral de vulnerabilidades de los componentes de red que sostienen los sistemas críticos, una prueba de penetración anual basada en inteligencia que cubra los servicios digitales, incluidas las apps móviles, y controles para la propia app: un entorno a prueba de manipulación, vinculación del dispositivo, MFA más segura que los SMS sin cifrar y códigos vinculados a la transacción generados en el dispositivo del cliente. Ostorlab prueba su app y las API que la sustentan, detrás del inicio de sesión, en cada versión.
- Comprueba la detección de root y jailbreak, la protección contra manipulación y el pinning, y lo que hace la app cuando se activan
- Prueba el inicio de sesión, los códigos de un solo uso, las verificaciones reforzadas y la gestión de sesiones con sus cuentas de prueba
- Sigue a la app en sus API, incluso con TLS pinning
- Demuestra cada hallazgo con un exploit reproducible o con evidencia de solicitudes y respuestas
- A quién se aplica
- Bancos, aseguradoras, operadores de takaful, emisores de dinero electrónico, operadores de sistemas de pago, adquirentes comerciales e instituciones de remesas regulados por BNM
- Fechas clave
- RMiT publicado y en vigor el 28 de noviembre de 2025; el texto se reeditó el 25 de septiembre de 2026 con el código de práctica para entidades NCII
- Objeto
- Seguridad de apps móviles y API, evaluación de vulnerabilidades y pruebas de penetración, autenticación y controles antifraude
- Referencia principal
- Documento de política Risk Management in Technology (RMiT), BNM/RH/PD 028-98
Los textos de BNM que rigen su canal móvil
El documento RMiT reúne en un solo texto las especificaciones anteriores sobre banca electrónica y fraude. Las fechas siguientes corresponden a los textos citados en esta página.
- Septiembre de 2022
Cinco medidas antifraude
BNM anuncia cinco medidas clave contra el fraude y un kill switch: migración de los SMS OTP a una autenticación más segura, reglas de detección más estrictas, un periodo de reflexión para la primera inscripción y la vinculación a un solo dispositivo para la autenticación.
- 1 de enero a 1 de junio de 2025
Entran en vigor las enmiendas a la PDPA
La Ley de reforma de la Ley de Protección de Datos Personales de 2024 entra en vigor en tres etapas: 1 de enero, 1 de abril y 1 de junio de 2025. La nueva obligación de notificar violaciones de datos y el nombramiento de un delegado de protección de datos comienzan el 1 de junio de 2025.
- 31 de octubre de 2025
Política sobre información de clientes
BNM publica el documento de política Management of Customer Information and Permitted Disclosures, en vigor el mismo día y en sustitución de la versión publicada el 3 de abril de 2023.
- 28 de noviembre de 2025
RMiT revisado
Entra en vigor el documento RMiT revisado, que reúne las especificaciones de banca electrónica y fraude en un solo texto. Sustituye al RMiT publicado el 1 de junio de 2023.
- 1 de julio de 2026
FAQ del RMiT actualizada
BNM actualiza sus preguntas frecuentes sobre el documento RMiT, aclarando cómo deben leerse las cláusulas revisadas.
- 25 de septiembre de 2026
Código de práctica NCII
BNM reedita el texto del RMiT con el anexo 12, el código de práctica para los bancos designados entidades de infraestructura de información crítica nacional en virtud de la Cyber Security Act 2024.
- Cada trimestre y cada año
Cadencia de pruebas
Evaluaciones trimestrales de vulnerabilidades de los componentes de red de los sistemas críticos, pruebas de penetración anuales basadas en inteligencia que cubren las apps móviles y las aplicaciones expuestas al exterior, y una evaluación independiente de compromisos cada tres años.
Las normas de BNM, 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.
- RMiT, anexo 4, Control Measures for Mobile Applications and Devices, párrafos 1 y 2
Proteja la app móvil y el dispositivo en el que se ejecuta
Qué dice el texto
Una institución financiera debe conocer los riesgos asociados a las aplicaciones móviles y evaluarlos de forma continua. Los servicios digitales con información sensible de clientes en dispositivos móviles deben protegerse adecuadamente: diseñar la app para que funcione en un entorno seguro y a prueba de manipulación, no comprometido, con jailbreak o root; prohibir que la app almacene información de clientes utilizada para autenticarse ante el servidor, como PIN y contraseñas, y centralizar en el host la autenticación y verificación de claves y PIN; someter la activación de la app a una autenticación sólida; garantizar un aprovisionamiento y desaprovisionamiento seguros; y usar plataformas de distribución reputadas.
Fuente:RMiT, anexo 4, Control Measures for Mobile Applications and Devices, párrafos 1 y 2
Qué supone para su app móvil
La detección de root y jailbreak, la resistencia a la manipulación y el lugar donde viven las credenciales son controles nombrados, no extras. Deben mantenerse en tiempo de ejecución, en la versión que descargan sus clientes.
Cómo ayuda Ostorlab
Mobile Shielding Scan ejecuta la app en entornos con root y jailbreak, intenta eludir la detección de root y jailbreak, la protección contra manipulación y el pinning, y muestra si la app bloquea el flujo, se niega a arrancar o sigue funcionando. Ostorlab también busca PIN, tokens y datos personales en el almacenamiento local, las cachés, los registros y las capturas de pantalla.
Qué sigue en sus manos
La elección del producto de protección, el proceso de aprovisionamiento seguro y la vigilancia de las tiendas para detectar apps falsas.
- RMiT, anexo 3, Control Measures for Digital Services, párrafos 4, 5, 6, 7 y 9
Use MFA más segura que los SMS sin cifrar, con códigos generados en el dispositivo
Qué dice el texto
Para las transacciones financieras y las no financieras de alto riesgo, incluido el registro de un beneficiario favorito y todas las transferencias posteriores hacia él, una institución financiera debe adoptar la autenticación multifactor, pedir al usuario que verifique los detalles de la transacción y enviar notificaciones oportunas. La MFA debe resistir el phishing, la interceptación y la manipulación, y los canales usados deben ser más seguros que los SMS sin cifrar. Cuando se use OTP, debe ser dinámico y con límite de tiempo, estar vinculado a los detalles de la transacción y generarse en el dispositivo del cliente, no en el servidor del banco. Las instituciones también deben ofrecer autenticación basada en clave criptográfica, como un certificado digital o passwordless, como alternativa a las contraseñas.
Fuente:RMiT, anexo 3, Control Measures for Digital Services, párrafos 4, 5, 6, 7 y 9
Qué supone para su app móvil
El servidor debe exigir el segundo factor en cada transacción financiera, y el código debe llevar el beneficiario y el importe que aprueba. Los SMS por sí solos ya no cumplen el texto.
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 que hay detrás. Ostorlab completa los códigos de un solo uso por SMS, correo electrónico o TOTP con sus cuentas de prueba y prueba cómo se comportan los flujos cuando se omite o se repite un paso.
Qué sigue en sus manos
La elección y el despliegue de la MFA y de los métodos por passkey o certificado, y la gestión de la migración fuera de los SMS OTP para su base de clientes.
- RMiT, anexo 3, Control Measures for Digital Services, párrafo 3
Vincule el dispositivo y proteja los cambios de datos de contacto
Qué dice el texto
El registro y la actualización del dispositivo móvil y de los datos de contacto usados para la autenticación, como el número de móvil, el correo electrónico y la dirección postal, deben reforzarse para que los defraudadores no puedan usar credenciales robadas para mover fondos. Los controles incluyen la vinculación y desvinculación seguras de un solo dispositivo móvil o seguro por titular de cuenta por defecto; alertas inmediatas cuando se accede a la cuenta desde un dispositivo nuevo o cambian los datos del cliente; verificación sólida antes de registrar un número nuevo o de sustituir el existente; un periodo de reflexión para la primera inscripción y los patrones de transacciones anómalos; y verificación para el aumento de los límites de transacción.
Fuente:RMiT, anexo 3, Control Measures for Digital Services, párrafo 3
Qué supone para su app móvil
El cambio de número de teléfono y de correo electrónico es el paso que necesitan los estafadores antes de tomar el control de una cuenta. El cambio, la alerta y el periodo de reflexión deben imponerlos el backend, no solo mostrarse en la app.
Cómo ayuda Ostorlab
Ostorlab prueba las llamadas a la API que hay detrás del registro de dispositivos, los cambios de datos de contacto, el registro de beneficiarios y los aumentos de límites, incluido si se exige un segundo factor y si las reglas de reflexión o de límites pueden eludirse a través de la API.
Qué sigue en sus manos
Los propios procedimientos de verificación y reflexión, y los canales de alerta.
- RMiT, anexo 5, Control Measures on Cybersecurity, parte E: Application Programming Interface (API) Security, párrafo 1
Evalúe y refuerce sus API
Qué dice el texto
La seguridad de las API debe ser proporcional a los riesgos. Como mínimo: mantener un inventario centralizado de API que cubra todas las conexiones y dependencias; diseñar las API para soportar tráfico elevado y mitigar la denegación de servicio; seguir prácticas de codificación segura, incluida la validación del código y las bibliotecas de terceros, un manejo robusto de errores, la validación de entradas y las cabeceras de seguridad; usar cifrado robusto y buena gestión de claves; desplegar mecanismos anti fuerza bruta como la limitación de tasa y el bloqueo de cuentas; implementar autenticación y autorización sólidas; considerar una pasarela de API; realizar evaluaciones de seguridad periódicas de las API, incluidas pruebas de penetración y pruebas de seguridad estáticas o dinámicas; vigilar el uso de las API; y disponer de un proceso para revocar tokens de acceso o claves de API tras un compromiso.
Qué supone para su app móvil
Todas las API que llama la app entran en el alcance, incluidas las que están detrás del inicio de sesión. La limitación de tasa, el bloqueo y la revocación de tokens son comportamientos que se pueden probar, no solo documentos de diseño.
Cómo ayuda Ostorlab
Ostorlab 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), usos indebidos 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
El inventario de API, la pasarela, la vigilancia de las API y el proceso de revocación.
- RMiT, anexo 5, parte D: Vulnerability Assessment and Penetration Test (VAPT), párrafos 1 a 6; RMiT párrafo 11.6
Cumpla la cadencia VAPT que fija BNM
Qué dice el texto
Una institución financiera debe disponer de procedimientos operativos estándar para la evaluación de vulnerabilidades y las pruebas de penetración, con supervisión de los probadores externos, validación de los registros de eventos y purga de datos. Debe realizar una evaluación trimestral de vulnerabilidades de los componentes de red externos e internos que sostienen todos los sistemas críticos, y pruebas de penetración anuales basadas en inteligencia sobre su infraestructura de red interna y externa, sus sistemas críticos y sus servicios digitales, incluidos web, móvil y todas las aplicaciones expuestas al exterior, con escenarios de ataque extremos pero plausibles y probadores debidamente acreditados. Los nuevos sistemas para nuevos productos o servicios también deben probarse antes de introducirse. Los resultados se documentan y se escalan a la alta dirección. Se exige una evaluación independiente de compromisos al menos cada tres años, y una simulación de red team al menos cada tres años.
Qué supone para su app móvil
La app y sus API entran en el alcance de la prueba anual basada en inteligencia, y los nuevos servicios digitales se prueban antes de su lanzamiento. Entre esas pruebas, cada versión sigue siendo un cambio en un canal expuesto a internet.
Cómo ayuda Ostorlab
Un pentest con agentes de IA prueba la app y sus API detrás del inicio de sesión, sobre la versión que publica, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA. Los hallazgos se gestionan como tickets y se vuelven a probar cuando se publica la corrección, de modo que los puntos de app y API de su plan de corrección quedan cerrados antes de la prueba anual.
Qué sigue en sus manos
La definición y la ejecución de las evaluaciones trimestrales, la prueba anual basada en inteligencia con probadores acreditados, la evaluación de compromisos y el ejercicio de red team.
- RMiT, párrafos 10.5, 10.6, 10.8, 10.9, 10.10 y 10.12
Integre la seguridad en el SDLC y pruebe antes de publicar
Qué dice el texto
El ciclo de vida del desarrollo de sistemas debe cubrir requisitos, diseño, desarrollo, pruebas, despliegue, gestión de cambios, mantenimiento y retirada, e integrar principios y requisitos de seguridad. Los métodos de desarrollo rápido como DevOps deben automatizar la revisión de cumplimiento de seguridad informática y el descubrimiento y las pruebas de vulnerabilidades. Las pruebas de sistema antes del despliegue deben ser rigurosas, y su alcance puede incluir pruebas de seguridad de aplicaciones. Los cambios en el código fuente de los sistemas críticos deben someterse a revisiones de código adecuadas. Cuando un tercero desarrolla o mantiene un sistema crítico, los contratos deben exigir principios de seguridad desde el diseño y acceso continuo al código fuente.
Qué supone para su app móvil
Cada versión de la app es un cambio en un canal expuesto a internet. Las pruebas automatizadas en el pipeline cubren el antes; los escaneos de las versiones publicadas en las tiendas cubren el después.
Cómo ayuda Ostorlab
Ostorlab ejecuta escaneos automatizados desde su pipeline de CI/CD en cada compilación y supervisa las versiones publicadas en las tiendas sin activación manual. Mobile SAST trabaja sobre el APK, AAB o IPA, sin necesidad del código fuente, y Mobile DAST ejercita la app en ejecución.
Qué sigue en sus manos
Los requisitos de seguridad, las normas de codificación segura, las revisiones manuales de código y la aprobación de las versiones.
- RMiT, párrafos 10.15, 10.17 y 10.18
Gestione componentes, parches y sistemas al final de su vida útil
Qué dice el texto
Los sistemas, incluidos los servicios digitales, no deben funcionar con vulnerabilidades conocidas, en plataformas obsoletas ni con tecnología al final de su vida útil. Las instituciones deben mantener una base de seguridad actualizada, vigilar y aplicar los últimos parches con prontitud, planificar medidas correctivas para los sistemas próximos al final de su vida útil y obtener la aprobación de la dirección para las excepciones. El marco de parches y fin de vida debe fijar criterios, prioridad y plazos según la gravedad de las vulnerabilidades identificadas. Para el software de terceros, BNM recomienda una lista de materiales de software (SBOM) y una política de seguridad del software de código abierto, con pruebas robustas y evaluación temprana de vulnerabilidades.
Qué supone para su app móvil
Las bibliotecas y los SDK 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. Mobile SAST y SCA enumeran los SDK y las bibliotecas nativas de cada versión con sus versiones, y los hallazgos se clasifican como críticos, altos, medios o bajos y se gestionan como tickets.
Qué sigue en sus manos
La aplicación de parches en servidores e infraestructura, los contratos de mantenimiento con proveedores y las decisiones de aceptación del riesgo.
- Management of Customer Information and Permitted Disclosures, párrafos 10.12, 10.26, 10.31, 11.8, 11.19, 11.20 y 11.25; Personal Data Protection (Amendment) Act 2024, sección 12B
Proteja la información de los clientes y gestione las violaciones
Qué dice el texto
El documento de política Management of Customer Information and Permitted Disclosures exige controles TIC preventivos y detectivos contra el robo, la pérdida, el uso indebido o el acceso, la modificación o la divulgación no autorizados de información de clientes, controles de acceso a nivel de aplicación, base de datos, sistema operativo y red, controles para la información recogida fuera de las instalaciones y en tránsito, y una destrucción segura. Una violación de información de clientes que plantee riesgo reputacional, cause o pueda causar un daño significativo o afecte a un gran número de clientes debe notificarse de inmediato a BNM, investigarse en un plazo de tres meses y comunicarse a BNM dentro del día hábil siguiente a su presentación al consejo. Los clientes afectados deben ser notificados sin dilación indebida. Las enmiendas a la PDPA añaden la misma obligación ante el Comisionado de Protección de Datos Personales, con la notificación de violaciones y el nombramiento del delegado de protección de datos en vigor desde el 1 de junio de 2025.
Qué supone para su app móvil
Los datos personales escritos en el teléfono, sus cachés, registros o capturas de pantalla forman parte de su superficie de violación, y las API que los transportan son donde debe sostenerse el control de acceso.
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 errores de configuración que debilitan las protecciones del transporte y de las sesiones. Cada hallazgo incluye evidencia del sistema de archivos o de solicitudes y respuestas que puede conservar.
Qué sigue en sus manos
La clasificación de datos, la gestión de claves, la investigación de violaciones y la notificación a BNM, al Comisionado y a los clientes.
- RMiT, párrafos 10.47, 10.48 y 10.49; Personal Data Protection (Amendment) Act 2024, sección 5
Gestione a los terceros y lo que integran en su app
Qué dice el texto
Antes de incorporar a un tercero, y durante toda la relación, una institución financiera debe realizar la diligencia debida y mantener un acuerdo de nivel de servicio que cubra derechos de acceso, confidencialidad, notificación de incidentes, continuidad de negocio y salida. Debe elaborar una hoja de ruta para vigilar de forma continua la postura de ciberseguridad del tercero, medir la huella de infraestructura informática y la información de clientes accesible a los terceros, e incorporar protocolos de terceros a la respuesta a incidentes. Según las enmiendas a la PDPA, el principio de seguridad se aplica ahora también a los encargados del tratamiento, no solo a los responsables.
Fuente:RMiT, párrafos 10.47, 10.48 y 10.49; Personal Data Protection (Amendment) Act 2024, sección 5
Qué supone para su app móvil
Una app de banca móvil integra SDK de terceros que se comunican con sus propios backends y pueden tratar datos personales. Deben figurar en su inventario, en su visión del riesgo de terceros y en sus acuerdos de encargado del tratamiento.
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. No realiza la vigilancia continua de terceros.
Qué sigue en sus manos
La diligencia debida, los contratos, la hoja de ruta de vigilancia y los acuerdos de encargado del tratamiento.
- RMiT, anexo 12, Code of Practice for NCII Entities, párrafos 11.3.2 a 11.3.6
Si le designan entidad NCII, cumpla el código de práctica
Qué dice el texto
Los bancos designados por BNM como entidades de infraestructura de información crítica nacional en virtud de la Cyber Security Act 2024 deben cumplir el anexo 12 del RMiT, que constituye su código de práctica. Exige directrices de ciberseguridad para el desarrollo de software y sistemas que cubran prácticas de codificación segura alineadas con el OWASP Top 10, mecanismos de control de acceso en las aplicaciones y requisitos de actualizaciones y parches periódicos, aplicadas en todo el SDLC y en las adquisiciones a terceros. Deben realizarse pruebas de seguridad durante el desarrollo, seguidas de pruebas de penetración antes del despliegue en producción o en un entorno público, incluidas exploraciones de vulnerabilidades, pruebas de penetración y validación del cumplimiento de las directrices de codificación segura.
Fuente:RMiT, anexo 12, Code of Practice for NCII Entities, párrafos 11.3.2 a 11.3.6
Qué supone para su app móvil
Para los bancos designados, esto añade una ruta documentada y verificable de desarrollo seguro y pruebas previas al despliegue para el canal móvil.
Cómo ayuda Ostorlab
Ostorlab cubre esas comprobaciones previas al despliegue: Mobile SAST sobre la compilación, Mobile DAST sobre la app en ejecución, SCA sobre los componentes y un pentest con agentes de IA de la app y sus API con un exploit reproducible para cada hallazgo.
Qué sigue en sus manos
Las directrices de codificación segura, las aprobaciones del comité de gobernanza y la decisión de despliegue en producción.
Resumen de textos públicos de BNM, consultados el 27 de septiembre de 2026. El texto del RMiT citado es la revisión vigente, publicada el 28 de noviembre de 2025 y reeditada el 25 de septiembre de 2026. Esta página no constituye asesoramiento jurídico.
Normas de BNM, control por control
Los controles a los que apuntan los textos de BNM, 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 |
|---|---|---|
| Entorno de la app, resistencia a la manipulación y credenciales almacenadasRMiT anexo 4 | Modifica el binario, ejecuta la app en dispositivos con root y jailbreak, inyecta hooks e intenta eludir el pinning TLS. Detalles | Evidencia de qué protecciones resistieron y cuáles se eludieron, y de lo que la app escribió en el almacenamiento |
| MFA más segura que los SMS sin cifrar, con códigos vinculados a la transacciónRMiT anexo 3, párrafos 4 a 7 | Inicia sesión con códigos de un solo uso y prueba la aplicación de la MFA, los flujos de autenticación reforzada y las llamadas a la API detrás de las transacciones. Detalles | Hallazgos sobre los flujos de inicio de sesión, autenticación reforzada y aprobación de transacciones, con pasos de reproducción |
| Vinculación del dispositivo y cambios de datos de contactoRMiT anexo 3, párrafo 3 | Prueba las llamadas a la API detrás del registro de dispositivos, los cambios de teléfono y correo, el registro de beneficiarios y los aumentos de límites. Detalles | Evidencia de solicitudes y respuestas para cada intento de elusión |
| Inventario de API, límites de tasa, revocación de tokens y evaluaciones periódicasRMiT anexo 5 parte E | Intercepta el tráfico incluso con TLS pinning y prueba la autorización, el uso indebido de tokens y abusos como la enumeración y la repetición. Detalles | Evidencia de solicitudes y respuestas para cada hallazgo de API |
| Evaluación trimestral de vulnerabilidades y pentest anual basado en inteligencia de los servicios digitalesRMiT anexo 5 parte D | Pentest con agentes de IA de la app y sus API, detrás del inicio de sesión, sobre la versión que publica, entre las pruebas anuales. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de calor de cobertura |
| SDLC seguro y pruebas de seguridad de aplicaciones antes de publicarRMiT párrafos 10.5 a 10.10 | Mobile SAST sobre el binario y Mobile DAST sobre la app en ejecución, en CI/CD en cada compilación. Detalles | Resultados del escaneo por compilación, con el contexto del código descompilado y el tráfico |
| Vulnerabilidades conocidas, plazos de corrección e inventario de componentesRMiT párrafos 10.15, 10.17 y 10.18 | 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 |
| Credenciales integradas en el paquete de la appRMiT anexo 5 parte E | 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 |
| Información de clientes en el dispositivo y en tránsitoMCIPD párrafos 10.12, 10.26 y 10.31 | 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 |
| Evaluación de compromisos y red teamingRMiT anexo 5 parte D.6; RMiT párrafo 11.6 | Ostorlab no realiza evaluaciones de compromisos ni ejercicios de red team. Mantiene cerrados y reprobados los puntos de app y API de su plan de corrección. | Resultados de las nuevas pruebas de los puntos de app y API de su plan de corrección |
Ostorlab prueba los controles de la app y de sus API. La vigilancia del SOC, el análisis antifraude, la respuesta a incidentes y su notificación, la evaluación de compromisos, el red teaming, las copias de seguridad y la recuperación, la gobernanza y la seguridad física siguen correspondiendo a sus equipos.
Controles de BNM que probar en su app móvil
Una lista práctica para los equipos de seguridad y riesgo tecnológico, basada en el documento RMiT y en las normas sobre información de clientes.
Protecciones de la app móvil
Ejecute la app en dispositivos con root y jailbreak, intente eludir la detección de manipulación y el pinning, y compruebe que los PIN y las contraseñas no se almacenan en la app.
MFA y códigos de un solo uso
Verifique que la MFA se exige en las transacciones financieras y las no financieras de alto riesgo, incluidos los beneficiarios favoritos, y que los códigos son dinámicos, están vinculados a la transacción y se generan en el dispositivo del cliente.
Vinculación del dispositivo y cambios de datos
Pruebe el valor por defecto de un solo dispositivo, las alertas ante dispositivos nuevos, la verificación sólida de los cambios de número de teléfono y el periodo de reflexión.
Las API detrás de la app
Pruebe la autorización, la limitación de tasa, el bloqueo y la revocación de tokens en cada API que llama la app, antes de que cada versión llegue a producción.
Cadencia VAPT
Incluya la app y sus API en el alcance de la prueba anual basada en inteligencia, pruebe los nuevos servicios antes de su lanzamiento y mantenga las evaluaciones trimestrales.
Componentes y plazos
Mantenga una lista versionada de los SDK y las bibliotecas de cada versión, una SBOM cuando sea útil, y plazos de corrección según la gravedad.
Secretos y datos en el dispositivo
Revise el paquete de la app en busca de claves de API y tokens, y busque datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla.
Preparación ante violaciones y reprobación
Conserve evidencia de cada hallazgo, haga su seguimiento hasta el cierre, vuelva a probar tras la corrección y alinee el tratamiento de datos de la app con sus procedimientos de violación MCIPD y PDPA.
Una lista sugerida, no una plantilla de BNM. 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.
- Risk Management in Technology (RMiT) policy documentBank Negara Malaysia, BNM/RH/PD 028-98, publicado y en vigor el 28 de noviembre de 2025. El texto vigente, reeditado el 25 de septiembre de 2026, añade el anexo 12, el código de práctica para entidades NCII. Sustituye al RMiT publicado el 1 de junio de 2023 y a las especificaciones anteriores de banca electrónica y fraude
- Frequently Asked Questions on the RMiT policy documentBank Negara Malaysia, actualizadas el 1 de julio de 2026. Interpretaciones de los requisitos del RMiT, incluido el estatus de las cláusulas marcadas como «G»
- Management of Customer Information and Permitted DisclosuresBank Negara Malaysia, BNM/RH/PD 028-65, publicado y en vigor el 31 de octubre de 2025. Controles sobre información de clientes, tratamiento de violaciones y divulgaciones permitidas; sustituye al documento de política publicado el 3 de abril de 2023
- Personal Data Protection (Amendment) Act 2024 (Act A1727)Laws of Malaysia, sanción real el 9 de octubre de 2024, publicada en el Boletín Oficial el 17 de octubre de 2024. Añade la obligación de notificar violaciones de datos y el nombramiento del delegado de protección de datos, y extiende el principio de seguridad a los encargados del tratamiento
- Personal Data Protection (Amendment) Act 2024: Appointment of Date of Coming into Operation (P.U. (B) 522/2024)Ministerio de lo Digital, publicado en el Boletín Oficial el 24 de diciembre de 2024. Las disposiciones modificadas entran en vigor el 1 de enero, el 1 de abril y el 1 de junio de 2025
- Bank Negara Malaysia Annual Report 2023, Promoting Financial StabilityBNM. Recoge las cinco medidas clave contra el fraude y el kill switch anunciados en septiembre de 2022, incluida la migración de los SMS OTP a una autenticación más segura
- Bank Negara Malaysia Annual Report 2025, Promoting Safe & Efficient Payment & Remittance ServicesBNM. Las normas de seguridad de los pagos con tarjeta se alejan de los OTP por SMS, que se mantienen como opción de reserva para un grupo limitado de usuarios; los controles para emisores de dinero electrónico entraron en vigor en enero de 2025
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.
Pruebe su app de banca móvil contra los controles de BNM
Empiece con un escaneo gratuito de su app desde la tienda, o reserve una demo para realizar con nuestro equipo pruebas de protección y con sesión iniciada.