Normas de la HKMA: evalúe su app de banca móvil antes y después de cada versión.
El módulo TM-E-1 del manual de supervisión de la HKMA pide a los bancos una evaluación independiente rigurosa antes de lanzar o modificar un canal de banca electrónica, y pruebas de intrusión por parte de terceros cualificados a la banca por internet y a los servicios prestados por internet o redes inalámbricas al menos una vez al año, además de la autenticación de dos factores para las transacciones de alto riesgo. Desde 2025, las medidas E-Banking Security ABCD impulsan el paso de la autenticación de inicios de sesión y transacciones de alto riesgo a la app, mediante un dispositivo vinculado, en lugar de códigos de un solo uso por SMS. 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 autenticación reforzada, la vinculación de dispositivos y las sesiones con sus cuentas de prueba
- Enumera los SDK y bibliotecas nativas de cada versión y los relaciona con vulnerabilidades conocidas
- Demuestra cada hallazgo con un exploit reproducible o con la solicitud y la respuesta como evidencia
- A quién aplica
- A todas las instituciones autorizadas (IA) supervisadas por la HKMA. Las IA designadas operadores de infraestructuras críticas también asumen obligaciones legales bajo la PCICSO
- Fechas clave
- TM-E-1 V.4 publicada el 25 de octubre de 2024; E-Banking Security ABCD desde el 25 de agosto de 2025; la PCICSO en vigor desde el 1 de enero de 2026
- Enfoque
- Evaluación independiente y pruebas de intrusión anuales, controles de apps móviles, autenticación de dos factores e in-app, y pruebas de resiliencia C-RAF 2.0
- Texto de referencia
- Manual de supervisión de la HKMA, módulo TM-E-1 "Risk Management of E-banking" (V.4)
Los textos de la HKMA detrás de su canal móvil
TM-E-1 y las circulares de banca electrónica conviven con los módulos del manual de supervisión sobre riesgo cibernético y resiliencia operativa, y desde 2026 con la PCICSO. Las fechas corresponden a los textos citados en esta página.
- 3 de noviembre de 2020
Cybersecurity Fortification Initiative 2.0
La HKMA actualiza su marco de evaluación de la resiliencia cibernética y añade requisitos de equipo azul a las pruebas de simulación de ataques guiadas por inteligencia (iCAST). La CFI 2.0 entra en vigor el 1 de enero de 2021, con evaluaciones escalonadas en tres grupos de IA.
- 31 de mayo de 2022
OR-2 Resiliencia operativa
El módulo OR-2 fija el marco: identificar las operaciones críticas, fijar una tolerancia a las interrupciones y probar escenarios graves pero plausibles, incluidas fallas en un tercero o en su cadena de suministro.
- 25 de octubre de 2024
TM-E-1 V.4
El módulo vigente sobre gestión de riesgos de la banca electrónica se publica como directriz estatutaria conforme al artículo 7(3) de la Banking Ordinance: evaluación independiente antes del lanzamiento, pruebas de intrusión anuales, 2FA para transacciones de alto riesgo y controles específicos para la banca por internet accedida desde dispositivos móviles.
- 29 de noviembre de 2024
Supervisión del riesgo cibernético TM-C-1
La HKMA publica su enfoque de supervisión de la gestión del riesgo cibernético, que confirma el C-RAF y el iCAST como herramientas centrales para evaluar y elevar la madurez de defensa cibernética de las IA.
- 14 de abril de 2025
E-Banking Security ABC
La HKMA espera que los clientes con app de banca móvil autentiquen los inicios de sesión y las transacciones de alto riesgo in-app mediante un dispositivo vinculado, de forma predeterminada, en lugar de códigos de un solo uso por SMS. La vinculación y revinculación de dispositivos pasa al reconocimiento facial, con un calendario de implementación del segundo al cuarto trimestre de 2025.
- 25 de agosto de 2025
E-Banking Security ABCD
La detección de deepfakes se suma al marco, con efecto inmediato. El anexo recoge buenas prácticas: reforzar la seguridad de los dispositivos, aleatorizar las pruebas de vitalidad, añadir análisis de imágenes y vigilar huellas digitales anómalas.
- 1 de enero de 2026
Entrada en vigor de la PCICSO
La Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653) entra en funcionamiento e impone tres categorías de obligaciones legales a los operadores designados de infraestructuras críticas.
- 2 de junio de 2026
Código de práctica sectorial para las IA
Entra en funcionamiento el código de práctica de la Monetary Authority para las IA designadas operadores de infraestructuras críticas, que fija la base del plan de gestión de seguridad, la evaluación anual de riesgos con evaluación de vulnerabilidades y prueba de intrusión, y la auditoría bienal.
Las normas de la HKMA, aplicadas a su app móvil
Para cada regla: 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. La numeración y la redacción siguen los documentos en inglés de la HKMA.
- SPM TM-E-1, 3.3.1 a 3.3.3
Evaluación independiente y pruebas de intrusión anuales
Qué dice el texto
Como parte de la gobernanza de riesgos de la banca electrónica, la alta dirección debe asegurar que se realice una evaluación independiente rigurosa antes del lanzamiento de cualquier nuevo canal electrónico o de una mejora importante de un servicio existente, verificando que el servicio cumple las orientaciones aplicables y que los controles de gestión de riesgos están realmente implantados. Si la política de evaluación independiente no incluye pruebas de intrusión, deben realizarlas partes independientes cualificadas, evaluando como mínimo la banca por internet de la IA y los servicios financieros prestados por internet o redes inalámbricas, cada año. También se espera una evaluación formal de riesgos al menos anual.
Fuente:SPM TM-E-1, 3.3.1 a 3.3.3
Qué supone para su app móvil
Una app de banca móvil es un canal de banca electrónica. La evaluación independiente, la prueba de intrusión anual y la revisión anual de vulnerabilidades emergentes deben cubrirla, incluidas las API que llama.
Cómo ayuda Ostorlab
Ostorlab ejecuta un pentest con agentes de IA de la app y sus API con sesión iniciada, Mobile SAST sobre el APK, AAB o IPA, y pruebas de protección en tiempo de ejecución, repetibles a demanda, para producir la misma evidencia antes del lanzamiento, cada año y en cada versión.
Qué sigue en sus manos
Elegir a los evaluadores, realizar la evaluación formal de riesgos y resolver los problemas materiales antes del lanzamiento.
- SPM TM-E-1, 7.1.1 a 7.1.4
Evaluar el canal móvil y sus riesgos específicos
Qué dice el texto
La banca por internet accedida desde dispositivos móviles conlleva riesgos específicos: vulnerabilidades de las plataformas móviles, malware o apps maliciosas que capturan información sensible, redirigen u ocultan notificaciones o códigos de un solo uso, o inducen a los clientes a transacciones no autorizadas; pérdida o robo de dispositivos; y menor concienciación de seguridad de los clientes. Las IA deben identificar y evaluar esos riesgos y aplicar las medidas de seguridad correspondientes, desarrollar programas de educación para dispositivos móviles y buscar de forma continua apps bancarias falsas para avisar a los clientes. Cuando los clientes reciben o generan códigos de un solo uso en el mismo dispositivo que usan para la banca, se requieren controles de seguridad adicionales.
Fuente:SPM TM-E-1, 7.1.1 a 7.1.4
Qué supone para su app móvil
La app está en el alcance, no solo el backend. El malware de superposición, la interceptación de notificaciones, la manipulación y las apps falsas son amenazas propias del móvil que sus controles deben abordar.
Cómo ayuda Ostorlab
Mobile SAST inspecciona el binario y sus SDK integrados, Mobile Shielding Scan prueba en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el pinning, y el pentest con agentes de IA ejercita la app y sus API como lo haría un defraudador.
Qué sigue en sus manos
La vigilancia de apps falsas en las tiendas, la educación de los clientes y su política para dispositivos que también reciben códigos de un solo uso.
- SPM TM-E-1, 4.1.1 a 4.1.8; circular "New Anti-Digital Fraud Measures: E-Banking Security ABC", 14 de abril de 2025, anexo
Autenticación de dos factores y autenticación in-app por defecto
Qué dice el texto
Para la banca por internet, las IA deben exigir autenticación de dos factores al menos una vez para autenticar la identidad del cliente en cada sesión de inicio de sesión antes de realizar transacciones de alto riesgo, que incluyen transferencias a beneficiarios terceros no registrados, ciertos pagos de facturas y transferencias de ventajas o puntos de recompensa a terceros. Si una transacción de alto riesgo se considera sospechosa, por ejemplo una transferencia de importe elevado poco después de vincular un dispositivo, se espera una confirmación adicional. Desde 2025, la HKMA espera que los clientes con app de banca móvil autentiquen los inicios de sesión y las transacciones de alto riesgo mediante un dispositivo vinculado, de forma predeterminada, en lugar de códigos por SMS. La vinculación y revinculación deben usar reconocimiento facial o métodos igual de estrictos, con un periodo de reflexión y vigilancia reforzada del fraude cuando aún se permitan códigos de un solo uso por SMS.
Qué supone para su app móvil
El segundo factor debe imponerlo el servidor en cada paso clave, y la autenticación por dispositivo vinculado cambia cómo la app registra y confía en un dispositivo. Ambos son comportamientos que puede probar.
Cómo ayuda Ostorlab
Las pruebas autenticadas cubren inicio y cierre de sesión, códigos de un solo uso, flujos de autenticación reforzada e in-app, y las llamadas de API que los sustentan, con sus cuentas de prueba.
Qué sigue en sus manos
Desplegar la autenticación por dispositivo vinculado y el reconocimiento facial, las reglas del periodo de reflexión y la comunicación a los clientes.
- SPM TM-E-1, 4.4.1 a 4.4.3 y 5.3.3; circular "Enhancement to security of electronic banking services", 31 de octubre de 2023, punto 8
Controles de sesión y herramientas de actividad de la cuenta
Qué dice el texto
Para la banca por internet, las IA deben implantar controles de gestión de sesiones que impidan inicios de sesión simultáneos en una cuenta de banca electrónica, salvo necesidad real, y registrar datos clave de los intentos adicionales, como la dirección IP, el tipo de dispositivo y la ubicación geográfica. Los clientes deben poder revisar y vigilar la actividad de la cuenta, incluida la fecha y hora del inicio de sesión, la ubicación y la información del dispositivo, y buscar actividades de alto riesgo durante un periodo razonablemente largo, normalmente no inferior a 90 días. Las IA también deben ofrecer un canal accesible para pedir ayuda y un mecanismo para suspender de inmediato una cuenta de banca electrónica, con reactivación bajo autenticación estricta.
Qué supone para su app móvil
La gestión de inicios simultáneos, los tiempos de espera, la invalidación de tokens, las pantallas de actividad y el flujo de suspensión son comportamientos comprobables, y los registros que generan son evidencia.
Cómo ayuda Ostorlab
Ostorlab prueba inicio y cierre de sesión, renovación de tokens, tiempos de espera e invalidación de sesiones, incluidos los intentos de inicio simultáneo, y revisa qué escriben la app y sus API en el almacenamiento, las cachés y los registros.
Qué sigue en sus manos
Las herramientas de actividad para el cliente, el mecanismo de suspensión y la retención de registros.
- SPM TM-E-1, 5.2.1 y 5.4.1 a 5.4.3; SPM TM-G-1, 3.4.1 y 5.3.1
Evaluación de vulnerabilidades, vigilancia de amenazas y gestión de parches
Qué dice el texto
Las IA deben mantener un proceso sistemático de vigilancia de amenazas para su infraestructura de internet, sistemas de aplicación y demás componentes, y usar herramientas automatizadas, complementadas con técnicas manuales cuando haga falta, para realizar evaluaciones periódicas de vulnerabilidades de la infraestructura de internet y los sistemas de banca por internet, tratando los hallazgos según un enfoque basado en el riesgo. Los procedimientos de gestión de parches deben cubrir sistemas y componentes de infraestructura. TM-G-1 espera responsabilidades claras para que los parches y actualizaciones de seguridad se identifiquen, evalúen, prueben y apliquen a tiempo, y un inventario de hardware e instalaciones para controlar y seguir el hardware y el software comprados y arrendados.
Fuente:SPM TM-E-1, 5.2.1 y 5.4.1 a 5.4.3; SPM TM-G-1, 3.4.1 y 5.3.1
Qué supone para su app móvil
Los SDK y bibliotecas nativas dentro de su app son software que usted entrega a sus clientes, y la lista de componentes vulnerables puede cambiar con cada versión.
Cómo ayuda Ostorlab
SCA identifica las bibliotecas compiladas estáticamente y las relaciona con vulnerabilidades conocidas, versión tras versión. Los hallazgos se clasifican en críticos, altos, medios o bajos, se siguen como tickets en la plataforma o en Jira y ServiceNow, y se revalidan cuando se publica el arreglo.
Qué sigue en sus manos
El escaneo de infraestructura, la aplicación de parches en servidores y dispositivos, y las decisiones de aceptación de riesgos.
- SPM TM-E-1, 5.3.1 y 5.3.2; código de práctica sectorial de la PCICSO, 6.2.22
Desarrollo seguro y revisión del código fuente
Qué dice el texto
Las IA deben mantener un nivel adecuado de seguridad de los sistemas de aplicación de su banca por internet, incluidas las apps, que abarque al menos el diseño y desarrollo, las pruebas y la implantación, con referencia a buenas prácticas del sector. Antes de lanzar un sistema de banca por internet o cambios en él, debe realizarse una revisión adecuada del código fuente para identificar incumplimientos de los estándares de seguridad de aplicaciones, código que pueda crear amenazas o brechas y cualquier código malicioso. La revisión debe realizarla una parte con la experiencia necesaria e independiente de los desarrolladores. El código sectorial de la PCICSO añade un proceso de desarrollo seguro y la protección del código fuente para los sistemas informáticos críticos.
Fuente:SPM TM-E-1, 5.3.1 y 5.3.2; código de práctica sectorial de la PCICSO, 6.2.22
Qué supone para su app móvil
La revisión debe ocurrir antes del lanzamiento y cubrir también los componentes de terceros que acaban en el paquete de la app.
Cómo ayuda Ostorlab
Mobile SAST analiza el binario APK, AAB o IPA con análisis de propagación (taint) en la app y sus SDK integrados, de modo que los problemas de código se encuentran aunque solo esté disponible la versión de la tienda.
Qué sigue en sus manos
Los estándares de codificación segura, la propiedad del código y la revisión manual de su propio código fuente.
- Circular "Managing cyber risk associated with third-party service providers", 21 de diciembre de 2023; circular "Risk Associated with Third-party IT Solutions", 27 de septiembre de 2024
Gestionar el riesgo cibernético de servicios y software de terceros
Qué dice el texto
La HKMA compartió un conjunto de buenas prácticas para gestionar el riesgo cibernético asociado a proveedores de servicios externos: gobernanza, diligencia debida, controles contractuales y seguimiento continuo. Tras un incidente informático global causado por la actualización defectuosa de un proveedor de ciberseguridad, la HKMA recordó a las IA que gestionen las dependencias de terceros: probar las actualizaciones antes de desplegarlas, mantener el control sobre las actualizaciones automáticas sin elección del usuario y resistir el fallo de soluciones informáticas de terceros, incluso cuando de ellas dependen servicios críticos.
Qué supone para su app móvil
Una app de banca móvil se ensambla con SDK y servicios de terceros. Su ciclo de actualización y sus modos de fallo son parte de su riesgo, no solo del de su proveedor.
Cómo ayuda Ostorlab
Ostorlab enumera los SDK y bibliotecas nativas de cada versión con sus versiones y su ubicación en el paquete, y muestra qué intercambian la app y sus SDK con los backends en la red. Las revalidaciones muestran si un arreglo del proveedor cerró realmente el problema.
Qué sigue en sus manos
Los contratos, la diligencia debida, el seguimiento de proveedores y la decisión de mantener o sustituir a un proveedor.
- SPM TM-C-1, 3.5; circular "Cybersecurity Fortification Initiative 2.0", 3 de noviembre de 2020; SPM OR-2, 4.3 y 7; circular "Strengthening Cyber Resilience amid Artificial Intelligence-Empowered Cyber Threats", 2 de junio de 2026
C-RAF 2.0, iCAST y pruebas de escenarios
Qué dice el texto
En el marco de la Cybersecurity Fortification Initiative, las IA se autoevalúan con el Cyber Resilience Assessment Framework: una evaluación del riesgo inherente, una evaluación de madurez y, para las IA con riesgo inherente medio o alto, pruebas de simulación de ataques cibernéticos guiadas por inteligencia (iCAST) que simulan ataques reales. El C-RAF 2.0 añadió requisitos de equipo azul al iCAST para medir las funciones de detección, respuesta y recuperación. TM-C-1 confirma el C-RAF como herramienta de la HKMA para comprobar que la madurez de defensa cibernética es proporcionada al riesgo. OR-2 espera además pruebas de escenarios de interrupciones graves pero plausibles, incluidas fallas en un tercero o en su cadena de suministro. En junio de 2026 la HKMA pidió a las IA comprobar que sus controles siguen siendo adecuados frente a ataques asistidos por IA de frontera y revisar la resiliencia cibernética de sus proveedores externos.
Qué supone para su app móvil
El iCAST es un ejercicio de toda la institución, realizado por partes cualificadas, no un escaneo de app móvil. Los problemas de app y API ya cerrados son la base que evita arrastrar debilidades conocidas.
Cómo ayuda Ostorlab
Ostorlab no realiza iCAST ni otros ejercicios de red team. Mantiene cerrados y revalida los elementos de app y API de su plan de remediación, para que las evaluaciones más amplias partan de una base más limpia.
Qué sigue en sus manos
Definir y ejecutar el C-RAF y el iCAST con evaluadores cualificados, el ejercicio de equipo azul y las pruebas de escenarios de resiliencia operativa.
- Código de práctica sectorial de la PCICSO, 2 de junio de 2026, 6.3.4 a 6.3.7 y 6.4; PCICSO (Cap. 653), artículos 24 y 25
PCICSO: evaluación de riesgos, prueba de intrusión y auditoría legales
Qué dice el texto
Desde el 1 de enero de 2026, la Protection of Critical Infrastructures (Computer Systems) Ordinance impone obligaciones legales a los operadores designados, y la Monetary Authority ha publicado un código de práctica sectorial para las IA que designa operadores de infraestructuras críticas. La evaluación de riesgos de seguridad de los sistemas informáticos debe cubrir todas las aplicaciones, host y dispositivos de red de los sistemas informáticos críticos, e incluir una evaluación de vulnerabilidades y una prueba de intrusión. La prueba de intrusión debe realizarse desde la posición de un atacante potencial o a partir de inteligencia de amenazas, y cubrir la seguridad de red, la seguridad del software de sistema, la seguridad de aplicaciones del lado del cliente y del lado del servidor. La primera evaluación vence dentro de los 12 meses siguientes a la designación y al menos una vez cada 12 meses después, con una auditoría independiente al menos cada 24 meses. Los informes deben presentar cada hallazgo con su prioridad y un plan de tratamiento con plazos y responsables.
Qué supone para su app móvil
La seguridad de aplicaciones del lado del cliente se cita expresamente, así que la app móvil entra en el alcance de la prueba legal, y cada hallazgo necesita evidencia y un plan de tratamiento seguido.
Cómo ayuda Ostorlab
Ostorlab prueba la app y sus API y produce evidencia por hallazgo: exploits reproducibles, registros de solicitudes y respuestas, inventarios de componentes y resultados de revalidación que puede adjuntar al informe de evaluación.
Qué sigue en sus manos
Designar al evaluador cualificado y al auditor independiente, las pruebas de red e infraestructura, y presentar los informes.
- SPM TM-E-1, 4.3.1, 4.4.5 y 5.1.1; Personal Data (Privacy) Ordinance (Cap. 486), principio de protección de datos 4
Proteger los datos de los clientes en el dispositivo y en tránsito
Qué dice el texto
Las IA deben usar cifrado fuerte, seguro y reconocido internacionalmente para proteger la información de los clientes transmitida por redes externas y la información muy sensible, como las credenciales de acceso almacenadas, con buenas prácticas de gestión de claves. Debe advertirse a los clientes de su obligación de tomar precauciones razonables para proteger sus dispositivos y factores de autenticación. El manual recuerda a las IA la necesidad de cumplir la Personal Data (Privacy) Ordinance, que obliga a los usuarios de datos a tomar todas las medidas practicables para proteger los datos personales frente a acceso, tratamiento, borrado, pérdida o uso no autorizado o accidental.
Qué supone para su app móvil
Los tokens, credenciales y datos personales no deberían quedar en texto claro en el almacenamiento de la app, las cachés, los registros o las capturas de pantalla, y la protección del transporte debe resistir un ataque.
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 la protección del transporte y la evasión del pinning, y encuentra secretos y credenciales en el paquete de la app.
Qué sigue en sus manos
La clasificación de datos, la gestión de claves, los avisos de privacidad, la retención y la gestión de brechas.
Resumen de textos públicos de la HKMA y del código sectorial de la PCICSO, consultados el 27 de septiembre de 2026. La numeración y la redacción siguen los documentos en inglés. Esta página no constituye asesoramiento jurídico.
Normas de la HKMA y PCICSO, control por control
Los controles a los que apuntan los textos de la HKMA, 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 |
|---|---|---|
| Evaluación independiente y pruebas de intrusión anualesTM-E-1 3.3 | Pentest con agentes de IA de la app y sus API, con sesión iniciada, en la versión que entrega. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de cobertura |
| Evaluación del canal móvil y protecciones en tiempo de ejecuciónTM-E-1 7.1 | SAST sobre el binario y pruebas de protección en tiempo de ejecución: root, jailbreak, manipulación y pinning. Detalles | Hallazgos por versión sobre componentes y protecciones, con los resultados de evasión |
| 2FA, autenticación in-app y vinculación de dispositivosTM-E-1 4.1; circular ABC, anexo | Inicia sesión con códigos de un solo uso y dispositivos vinculados y prueba los flujos de autenticación reforzada, incluido cómo omitirlos o reproducirlos. Detalles | Hallazgos en los flujos de inicio de sesión, autenticación reforzada y vinculación, con pasos de reproducción |
| Controles de sesión e inicios simultáneosTM-E-1 5.3.3; circular del 31 de octubre de 2023 | Prueba inicio y cierre de sesión, renovación de tokens, tiempos de espera, invalidación de sesiones e intentos de inicio simultáneo. Detalles | Hallazgos de sesión y tokens, con registros de solicitudes y respuestas |
| Componentes vulnerables y plazos de correcciónTM-E-1 5.4; TM-G-1 3.4.1 | Identifica bibliotecas compiladas estáticamente, incluidos SDK nativos, y las relaciona con vulnerabilidades conocidas. Detalles | Vulnerabilidades identificadas con recomendaciones de actualización o sustitución, y cierre seguido versión tras versión |
| Desarrollo seguro y revisión del código fuenteTM-E-1 5.3.1, 5.3.2 | Mobile SAST con análisis de propagación (taint) en la app y sus SDK integrados, sobre el APK, AAB o IPA. Detalles | Hallazgos a nivel de código, con su ubicación en el binario y el flujo de datos |
| Credenciales integradas en apps y APITM-E-1 4.1.1; CoP 6.2.22 | Encuentra claves de API, tokens y credenciales en el paquete de la app y comprueba si funcionan. Detalles | Secretos validados, con los permisos y servicios que exponen |
| Datos de clientes en el dispositivo y en tránsitoTM-E-1 4.3.1, 4.4.5, 5.1.1; PDPO | 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. Detalles | Evidencia del sistema de archivos que muestra qué se escribió, dónde y cuándo |
| Evidencia para la evaluación y la prueba de intrusión de la PCICSOCoP sectorial 6.3, 6.4 | Prueba la app y las API, sigue cada hallazgo hasta su cierre y revalida, para que su evaluador reutilice la evidencia. Detalles | Historial de tickets y resultados de revalidación por hallazgo, listos para el plan de tratamiento |
| Preparación para C-RAF e iCASTTM-C-1 3.5; CFI 2.0 | Ostorlab no realiza iCAST. Cierra y revalida los elementos de app y API de su plan de remediación. | Resultados de revalidación de los elementos de app y API antes del ejercicio |
Ostorlab prueba controles en la app y sus API. La monitorización del SOC, la respuesta a incidentes y su notificación, los ejercicios, el iCAST y otras pruebas de red team, las copias de seguridad y la recuperación, la gobernanza y la seguridad física siguen en manos de sus equipos.
Controles de la HKMA que probar en su app móvil
Una lista práctica para los equipos de seguridad y riesgo de sistemas, basada en TM-E-1, las circulares de banca electrónica y el código sectorial de la PCICSO.
Evaluación independiente
Incluya la app móvil, sus API y la revisión previa al lanzamiento en el alcance de la evaluación independiente, y mantenga la prueba de intrusión anual en el calendario.
Amenazas propias del móvil
Pruebe en cada versión el root y el jailbreak, la superposición y la manipulación, la interceptación de notificaciones, la captura de pantalla y la detección de apps falsas.
Autenticación in-app
Verifique que el servidor impone la autenticación por dispositivo vinculado para los inicios de sesión y las transacciones de alto riesgo, y que todo respaldo por SMS recibe el periodo de reflexión y la vigilancia que esperan las circulares.
Vinculación de dispositivos
Pruebe los flujos de vinculación y revinculación, incluidos los pasos de reconocimiento facial, los intentos de reproducción y los controles omitidos.
Sesiones
Compruebe el rechazo de inicios simultáneos, los tiempos de espera, la invalidación de tokens, y el historial de actividad y las herramientas de suspensión que ven los clientes.
Componentes y plazos
Mantenga una lista versionada de los SDK y bibliotecas de cada versión, y fije plazos de corrección por gravedad.
Terceros
Mapee qué recibe cada SDK y backend externo, y revalide los arreglos de los proveedores en lugar de confiar en ellos.
Informar, revalidar y conservar evidencia
Siga los hallazgos hasta su cierre, conserve los resultados de revalidación y reutilícelos en los informes de evaluación y planes de tratamiento de la PCICSO.
Una lista sugerida, no una plantilla de la HKMA. 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, la autenticación reforzada y la autenticación in-app 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.
- Supervisory Policy Manual TM-E-1: Risk Management of E-banking (V.4)HKMA, 25 de octubre de 2024. Directriz estatutaria conforme al artículo 7(3) de la Banking Ordinance. Evaluación independiente, pruebas de intrusión anuales, 2FA, protección del cliente y banca por internet accedida desde dispositivos móviles (7.1)
- Supervisory Policy Manual TM-G-1: General Principles for Technology Risk Management (V.1)HKMA, 24 de junio de 2003. Nota de orientación no estatutaria. Autenticación y control de acceso, seguridad de sistemas y gestión de parches, y desarrollo y gestión de cambios; citada por el código sectorial de la PCICSO de 2026
- Supervisory Policy Manual TM-C-1: Supervisory Approach on Cyber Risk Management (V.1)HKMA, 29 de noviembre de 2024. Directriz estatutaria. El marco de evaluación de la resiliencia cibernética y el iCAST, la respuesta a incidentes y la recuperación, y la copia de seguridad terciaria segura
- Supervisory Policy Manual OR-2: Operational Resilience (V.1)HKMA, 31 de mayo de 2022. Nota de orientación no estatutaria. Operaciones críticas, tolerancia a las interrupciones y pruebas de escenarios graves pero plausibles, incluidas fallas en un tercero o en su cadena de suministro
- Cybersecurity Fortification Initiative 2.0, circular y anexoHKMA, 3 de noviembre de 2020, en vigor el 1 de enero de 2021. C-RAF 2.0, requisitos de equipo azul para el iCAST y calendario escalonado de evaluaciones para los tres grupos de IA
- New Anti-Digital Fraud Measures: E-Banking Security ABC, circular y anexoHKMA, 14 de abril de 2025. Autenticación por dispositivo vinculado por defecto en lugar de códigos de un solo uso por SMS, reconocimiento facial para la vinculación y revinculación, y calendario de implementación del segundo al cuarto trimestre de 2025
- E-Banking Security ABCD, circular y anexo: Good Practices for Countering Deepfake AttacksHKMA, 25 de agosto de 2025, efecto inmediato. Controles de seguridad de dispositivos, pruebas de vitalidad aleatorizadas, análisis de imágenes y vigilancia de huellas anómalas para la verificación de identidad
- Código de práctica para las IA designadas operadores de infraestructuras críticas bajo la PCICSOMonetary Authority, 2 de junio de 2026, en funcionamiento ese mismo día. Publicado conforme al artículo 8(1)(b) de la Protection of Critical Infrastructures (Computer Systems) Ordinance. Plan de gestión de seguridad, evaluación anual de riesgos con evaluación de vulnerabilidades y prueba de intrusión, y auditoría independiente cada 24 meses
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 la HKMA
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.