Normas del BDDK y el CBRT: pruebe su app de banca móvil antes y después de cada publicación.
El Reglamento del BDDK sobre los sistemas de información y los servicios de banca electrónica de los bancos exige al menos dos factores de autenticación para la banca electrónica, mantiene los códigos de un solo uso por SMS fuera del alcance de los clientes que han activado la app móvil y requiere una prueba de penetración al menos una vez al año por equipos independientes de los sistemas que prueban. La circular 2023/1 explica cómo debe detectar la app los dispositivos rooteados o con jailbreak, la depuración y la manipulación, y cómo debe funcionar la firma de transacciones. El Tebliğ del CBRT para las entidades de pago añade al menos seis escaneos de vulnerabilidades al año y una prueba de penetración anual. Ostorlab prueba su app y las API que hay detrás, con sesión iniciada, en cada publicación.
- Evalúa la app móvil y las API a las que llama, sobre la compilación que descargan sus clientes
- Prueba el PIN de la app, la biometría, la firma de transacciones y los códigos de un solo uso con sus cuentas de prueba
- Comprueba las detecciones de root, jailbreak, depuración y manipulación, y lo que hace la app cuando se activan
- Demuestra cada hallazgo con un exploit reproducible o con evidencia de solicitudes y respuestas
- A quién aplica
- Bancos supervisados por el BDDK, y entidades de pago y de dinero electrónico supervisadas por el CBRT para las normas de servicios de pago
- Base legal
- Reglamento sobre los sistemas de información y los servicios de banca electrónica de los bancos, Boletín Oficial del 15 de marzo de 2020, n.º 31069 (BSEBY)
- Enfoque
- Seguridad de la banca móvil, autenticación reforzada, pruebas de penetración, alta remota de clientes y protección de datos
- Referencias principales
- BSEBY y circular 2023/1 del BDDK; Tebliğ n.º 31676 del CBRT (textos en turco)
Los textos detrás de las normas turcas de banca móvil
El BDDK fija las normas bancarias, sus circulares explican cómo aplicarlas, el CBRT cubre los servicios de pago y el KVKK marca la base de protección de datos. Las fechas corresponden a los textos citados en esta página.
- 15 de marzo de 2020
Se publica el BSEBY
El Reglamento sobre los sistemas de información y los servicios de banca electrónica de los bancos se publica en el Boletín Oficial n.º 31069. La mayoría de sus disposiciones se aplica desde el 1 de enero de 2021.
- 1 de abril de 2021
Normas de identificación remota
El Reglamento sobre los métodos de identificación remota que pueden usar los bancos se publica en el Boletín Oficial n.º 31441 y se aplica desde el 1 de mayo de 2021.
- 1 de diciembre de 2021
Normas de pago del CBRT
El CBRT publica el Reglamento de servicios de pago y el Tebliğ sobre los sistemas de información de las entidades de pago y de dinero electrónico, ambos en el Boletín Oficial n.º 31676.
- 27 de marzo de 2023
Circular 2023/1
El BDDK publica la circular 2023/1, aprobada por la decisión del Consejo n.º 10546 del 23 de marzo de 2023, sobre autenticación, firma de transacciones y controles de la app móvil.
- 25 de mayo de 2023
Se modifica la identificación remota
El reglamento de identificación remota se modifica (Boletín Oficial n.º 32201) para clientes personas jurídicas, dejando los métodos basados en IA al Consejo. Los cambios se aplican desde el 1 de junio de 2023.
- 4 de septiembre de 2026
Se modifica el Tebliğ del CBRT
El CBRT actualiza el Tebliğ (Boletín Oficial n.º 33360): verificación de documentos de identidad por NFC de forma preferente, cobertura de datos biométricos y alta de extranjeros con pasaporte NFC.
Las normas del BDDK y el CBRT, 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 sus manos. Los artículos del BSEBY se citan según la traducción inglesa del BDDK; la circular 2023/1, la circular de 2012 sobre pruebas de penetración y el Tebliğ del CBRT se resumen a partir de los textos en turco.
- BSEBY, artículo 18(7); circular BSD.2012/1 del BDDK, alcance y metodología (texto en turco)
Haga una prueba de penetración anual, con las apps móviles incluidas
Qué dice el texto
Los bancos deben encargar una prueba de penetración al menos una vez al año a equipos que no participen en el diseño, el desarrollo, la implantación ni la explotación de los servicios ofrecidos por los sistemas probados. La circular del BDDK sobre pruebas de penetración fija el marco: pruebas básicas y después detalladas, realizadas al menos desde Internet, la red interna del banco y una red de sucursal, y con un alcance mínimo que incluye aplicaciones web y aplicaciones móviles. Los hallazgos se califican con los niveles de gravedad de la circular y se presentan en su formato, y la priorización de los activos sigue siendo responsabilidad del banco.
Fuente:BSEBY, artículo 18(7); circular BSD.2012/1 del BDDK, alcance y metodología (texto en turco)
Qué supone para su app móvil
Las aplicaciones móviles son un área de prueba nombrada. La app y las API a las que llama forman parte de la vertiente expuesta a Internet de la prueba anual, junto a las aplicaciones web y los sistemas ATM.
Cómo ayuda Ostorlab
El pentest con agentes de IA prueba la compilación publicada en la tienda y las API detrás del inicio de sesión, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA y un mapa de cobertura. No sustituye las partes de red, red de sucursal, ATM e ingeniería social de la circular.
Qué sigue en sus manos
Realizar la prueba anual completa, las partes de red interna y red de sucursal, la priorización de activos y el encaje de los resultados en su proceso.
- BSEBY, artículos 22(4)-(5) y 24
Pruebe las aplicaciones expuestas a Internet antes de publicarlas y tras cada actualización
Qué dice el texto
Las aplicaciones abiertas a Internet, tanto si las desarrolla el banco como si se adquieren a proveedores, deben escanearse y comprobarse en busca de vulnerabilidades de seguridad antes de instalarse y de nuevo después de cada actualización. Los requisitos de seguridad, como autorización y accesos, verificación de identidad, integridad de los datos, registro y gestión de excepciones, se definen desde el inicio del desarrollo o de la adquisición, y los cambios pasan por gestión de solicitudes, análisis de riesgo, pruebas y aprobación antes de llegar a producción.
Qué supone para su app móvil
Cada nueva versión de la app móvil es una actualización de una aplicación expuesta a Internet. Una comprobación antes de publicar y otra después son el mínimo, y las versiones que llegan a la tienda entre ambas deben vigilarse.
Cómo ayuda Ostorlab
Mobile SAST analiza el APK, AAB o IPA sin código fuente; Mobile DAST ejecuta la app; ambos encajan en una cadena CI/CD. Las versiones publicadas en la tienda se vigilan sin lanzamientos manuales, para no perder las actualizaciones que salen entre sprint y sprint.
Qué sigue en sus manos
Los estándares de codificación segura, la revisión de código, la aprobación de la publicación y las cláusulas con proveedores que exigen las mismas pruebas.
- BSEBY, artículo 34(14)-(15); circular 2023/1 del BDDK, anexo, sección 1 (texto en turco)
Endurezca la app y detecte dispositivos comprometidos
Qué dice el texto
El software y las aplicaciones móviles que se ofrecen a los clientes para la banca electrónica deben proceder de forma verificable del banco, no deben contener código que amenace la seguridad del cliente y deben recibir los parches y actualizaciones necesarios para cerrar sus vulnerabilidades. Los datos críticos que usan las aplicaciones bancarias en el teléfono deben ser inaccesibles para las demás aplicaciones y procesos del mismo dispositivo, deben protegerse si el dispositivo se pierde o se roba, y controles acordes con la tecnología actual deben reducir los riesgos de que un dispositivo sea capturado, se degrade su fiabilidad o se rompa o sustituya su sistema operativo. La circular 2023/1 detalla esos controles: integridad de la app y del SDK, anti-keylogging, anti-inyección, anti-depuración, anti-emulación, vinculación al dispositivo, anti-malware y detección de jailbreak, reportados a un servidor de seguridad dedicado por un canal seguro separado.
Fuente:BSEBY, artículo 34(14)-(15); circular 2023/1 del BDDK, anexo, sección 1 (texto en turco)
Qué supone para su app móvil
Este es el terreno del root, el jailbreak y la manipulación. Detectar es solo el principio: la app debe actuar ante lo que detecta, 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 e instrumentados e intenta eludir cada protección, y después muestra si la app bloquea el flujo, se niega a arrancar o sigue funcionando, con una puntuación de endurecimiento y evidencia de la elusión.
Qué sigue en sus manos
Elegir y configurar el SDK de protección, la política para dispositivos comprometidos y el servidor de seguridad.
- BSEBY, artículos 34(1), (6), (9) y 38(1)
Exija dos factores independientes, verificados en línea
Qué dice el texto
Los servicios de banca electrónica, incluidas las operaciones sin resultado financiero como mostrar datos del cliente, exigen un mecanismo de autenticación de al menos dos factores de clases distintas: algo que el cliente sabe, algo que posee o una característica biométrica. Los factores deben ser independientes, y el factor poseído debe ser específico del cliente y no imitable. Un factor conocido por el cliente debe introducirlo el cliente y verificarse en línea en el banco, no recuperarse de la app o el navegador ni vincularse a métodos de autenticación locales. Tras demasiados intentos fallidos debe bloquearse el acceso del usuario, y las contraseñas de un solo uso deben ser lo bastante largas para resistir intentos, generarse al azar y ser válidas solo durante un tiempo limitado.
Qué supone para su app móvil
El MFA lo aplica el servidor, no lo dibuja la app en pantalla. Los umbrales de bloqueo, la vida de los OTP y lo que ocurre cuando la app se salta un paso son comportamientos que se pueden probar.
Cómo ayuda Ostorlab
Las pruebas autenticadas cubren inicio y cierre de sesión, renovación de tokens, expiración de sesión y aplicación del MFA, incluidos los flujos de verificación reforzada y los intentos de elusión, con sus cuentas de prueba y las llamadas de API correspondientes.
Qué sigue en sus manos
Elegir los métodos de autenticación, los umbrales de bloqueo y la validez de los OTP.
- BSEBY, artículo 34(7)-(8)
Mantenga los códigos de un solo uso por SMS fuera del canal de la app
Qué dice el texto
Para los clientes que han instalado y activado la aplicación de banca móvil, el banco no puede enviar contraseñas de un solo uso ni códigos de verificación por SMS para iniciar sesión o verificar una operación durante una sesión, ni usar el SMS como factor de autenticación. Los códigos por SMS solo se admiten en la primera instalación, la activación o la reactivación de la aplicación, o cuando la aplicación ha quedado inutilizable. Si un cliente ha cambiado de tarjeta SIM o ha portado su número a otro operador, el banco debe detectarlo mediante integración con los operadores móviles, y un factor basado en la SIM no puede usarse durante 90 días tras el cambio salvo confirmación explícita del cliente.
Fuente:BSEBY, artículo 34(7)-(8)
Qué supone para su app móvil
La app necesita un segundo canal que no sea el SMS. Las pruebas deben cubrir qué ocurre si se usa el SMS de todos modos y cómo se gestionan los cambios de SIM y las reactivaciones.
Cómo ayuda Ostorlab
Ostorlab completa códigos por SMS, correo o TOTP con sus cuentas de prueba, comprueba si el servidor sigue enviando o aceptando códigos por SMS para clientes con la app activada, y prueba las llamadas de API detrás de la activación, los cambios de número y la verificación reforzada.
Qué sigue en sus manos
Las integraciones con operadores, los flujos de confirmación de cambio de SIM y la comunicación al cliente.
- BSEBY, artículos 35 y 38(3); circular 2023/1 del BDDK, anexo, secciones 1 y 2 (texto en turco)
Firme las transacciones para que el cliente apruebe lo que ve
Qué dice el texto
Las transacciones de banca electrónica deben permitir el no repudio y la atribución de responsabilidades. Se genera un código de verificación de un solo uso firmado con una clave privada asignada al cliente; el código no debe revelar ningún factor de autenticación, no debe poder derivarse de un código conocido ni ser imitable, y en las operaciones con resultado financiero debe ser específico del importe y del beneficiario aprobados por el cliente, quedando inválido si cambia cualquiera de los dos. La circular 2023/1 describe cómo construirlo: un SDK dedicado y un servidor de seguridad del banco, la clave del cliente creada y guardada en el hardware criptográfico del teléfono (Secure Enclave, almacén respaldado por hardware o Strong Box), TLS mutuo en un canal separado del tráfico backend habitual de la app, y controles de seguridad antes de cada solicitud de firma.
Fuente:BSEBY, artículos 35 y 38(3); circular 2023/1 del BDDK, anexo, secciones 1 y 2 (texto en turco)
Qué supone para su app móvil
El principio de que se firma lo que se ve es una propiedad del backend, pero puede fallar en la app: una superposición, código inyectado o una pantalla manipulada pueden cambiar lo que el cliente cree aprobar.
Cómo ayuda Ostorlab
Ostorlab prueba cómo muestra y firma la app las transacciones, incluido qué pasa si el importe o el beneficiario cambian después de mostrarse el código, si un código puede reutilizarse o derivarse, y las llamadas de API alrededor del flujo de firma.
Qué sigue en sus manos
El servidor de seguridad, el ciclo de vida de las claves, las plantillas de transacción y los registros de no repudio.
- UKTY (Reglamento sobre los métodos de identificación remota que pueden usar los bancos), artículos 4, 6, 7, 8, 10 y 11
Trate el alta remota como un proceso controlado
Qué dice el texto
La identificación remota se realiza en una videollamada en tiempo real e ininterrumpida entre un representante formado y la persona. El documento de identidad se verifica por NFC cuando es posible, sus elementos de seguridad, fotografía y firma se comprueban bajo luz blanca, y toda la sesión se graba para poder auditarla. Se usa detección de vitalidad y medidas adicionales contra rostros falsos, la cara de la persona se compara con la fotografía del documento, y el proceso se detiene ante cualquier duda. Solo pueden usarse datos biométricos, categoría especial de datos personales, con el consentimiento explícito de la persona registrado electrónicamente. El proceso se prueba antes de entrar en servicio y se revisa al menos dos veces al año, la responsabilidad sigue siendo del banco, y a los clientes captados así se les aplican medidas de seguridad adicionales.
Qué supone para su app móvil
El flujo de alta es de alto riesgo: cámara, NFC, biometría y un backend en vivo. También es el flujo que los atacantes intentan primero, con caras falsificadas, emuladores e interceptación.
Cómo ayuda Ostorlab
Ostorlab prueba las API de alta y las comprobaciones de la app: qué ocurre en dispositivos emulados o rooteados, si la detección de vitalidad se puede engañar con una cara grabada o sintética, cómo se protege la sesión y cómo guarda el cliente los elementos de identidad.
Qué sigue en sus manos
El proceso de los representantes, la plataforma de vídeo, las decisiones de verificación documental, la conservación y las comunicaciones regulatorias.
- Ley n.º 6698 (KVKK), artículos 4 y 12; KVKK, Recomendaciones para la protección de la privacidad en aplicaciones móviles, marzo de 2025 (texto en turco)
Cumpla las obligaciones de seguridad del KVKK en el teléfono
Qué dice el texto
Según la Ley n.º 6698 de protección de datos personales, el responsable del tratamiento debe adoptar todas las medidas técnicas y organizativas necesarias para impedir el tratamiento ilícito de los datos personales y el acceso ilícito a ellos, y debe realizar las auditorías necesarias. Cuando terceros obtienen datos personales de forma ilícita, el responsable debe informar a la persona afectada y notificarlo al Consejo lo antes posible. En sus recomendaciones para aplicaciones móviles, actualizadas en 2025, el KVKK pide privacidad desde el diseño y por defecto, cifrado de los datos personales en tránsito y en reposo, contraseñas con hash, gestión periódica de parches y actualizaciones, pruebas de software antes de publicar, límites a los inicios de sesión fallidos y control del usuario sobre permisos, notificaciones y ajustes de privacidad.
Qué supone para su app móvil
Las obligaciones del KVKK tienen que ver con lo que recoge la app y cómo se protege. Los permisos, los flujos de datos de los SDK, el almacenamiento local, los registros y las capturas de pantalla son los puntos que se prueban.
Cómo ayuda Ostorlab
Ostorlab inventaría los SDK de la compilación, mapea a qué pueden acceder y busca datos personales y tokens en almacenamiento, cachés, registros y capturas de pantalla. Comprueba las protecciones del transporte e indica qué está expuesto y dónde.
Qué sigue en sus manos
La clasificación de datos, las bases legales, los registros de consentimiento, los plazos de conservación y la notificación de brechas.
- BSEBY, artículo 16; Tebliğ del CBRT sobre los sistemas de información de las entidades de pago y de dinero electrónico, artículo 12 (texto en turco)
Gestione las vulnerabilidades con plazos
Qué dice el texto
Los bancos deben tener un proceso de gestión de vulnerabilidades y parches: seguir la información sobre vulnerabilidades, evaluar el impacto, definir métodos de corrección y plazos, conservar registros y establecer controles compensatorios cuando no se pueda aplicar un parche. Las herramientas automáticas de escaneo informan de los hallazgos más críticos, por prioridad, al responsable de seguridad y al del sistema afectado. Para las entidades de pago y de dinero electrónico, el Tebliğ del CBRT es más prescriptivo: los servidores y la red de comunicaciones se escanean al menos seis veces al año y antes de la primera puesta en servicio, y se someten a pruebas de penetración al menos una vez al año por personas o empresas con una credencial nacional o internacional de pruebas de penetración que no participen en la seguridad de los sistemas probados. Los hallazgos se corrigen lo antes posible bajo un plan de acción aprobado por el consejo, y un informe con brechas, resultados de pruebas y vulnerabilidades críticas se envía al CBRT al menos una vez al año.
Qué supone para su app móvil
Aquí confluyen dos culturas de plazos: los plazos de parche del banco bajo el BSEBY y los seis escaneos y la prueba anual del CBRT para las entidades de pago. Ambos exigen un ciclo trazable de corrección y reintento.
Cómo ayuda Ostorlab
Los hallazgos se califican como críticos, altos, medios o bajos, se agrupan en tickets en la plataforma o en Jira y ServiceNow, se asocian al componente y la versión afectados y se vuelven a probar cuando llega la corrección. El historial queda disponible para el plan de acción y el informe anual.
Qué sigue en sus manos
Aplicar los parches en servidores y equipos de red, el plan aprobado por el consejo y las comunicaciones al CBRT.
Resumen de textos públicos del BDDK, el CBRT y el KVKK, consultados el 27 de septiembre de 2026. Los artículos del BSEBY se citan según la traducción inglesa del BDDK salvo indicación de (texto en turco); la circular 2023/1, la circular de 2012 sobre pruebas de penetración y el Tebliğ del CBRT se resumen a partir de los textos en turco. Esta página no constituye asesoramiento jurídico.
Las normas turcas, control por control
Los controles a los que apuntan los textos del BDDK, el CBRT y el KVKK, 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 |
|---|---|---|
| Prueba de penetración anual, con las aplicaciones móviles incluidasBSEBY 18(7); BSD.2012/1 | Pentest con agentes de IA de la app y sus API, sobre la compilación que publica. Detalles | Un exploit funcional que reproducir para cada hallazgo de un agente de IA, y un mapa de cobertura |
| Escaneo de vulnerabilidades de las aplicaciones expuestas a Internet antes de publicar y tras las actualizacionesBSEBY 22(5) | Mobile SAST y DAST en CI/CD en cada compilación, y vigilancia de las versiones publicadas en la tienda. Detalles | Resultados de escaneo por compilación y por versión publicada |
| Protecciones frente a root, jailbreak, manipulación y depuraciónBSEBY 34(15); circular 2023/1 | Intentos de elusión en entornos rooteados, con jailbreak e instrumentados, y lo que hace la app después. Detalles | Evidencia de la elusión y puntuación de endurecimiento |
| Autenticación de dos factores, bloqueo y códigos de un solo usoBSEBY 34(1), (6), (9) | Inicia sesión con sus cuentas de prueba y prueba la aplicación del MFA, los flujos reforzados y el bloqueo. Detalles | Hallazgos sobre inicio de sesión, verificación reforzada y bloqueo, con pasos de reproducción |
| Sin códigos de un solo uso por SMS para clientes con la app activada; controles de cambio de SIMBSEBY 34(7)-(8) | Comprueba si el servidor sigue enviando o aceptando códigos por SMS para esos clientes, y cómo se gestionan activación y cambios de número. Detalles | Registros de solicitudes y respuestas de los flujos de activación y códigos |
| Firma de transacciones ligada al importe y al beneficiario aprobadosBSEBY 35, 38(3); circular 2023/1 | Prueba los flujos de firma y aprobación, incluidos los cambios de importe o beneficiario tras mostrarse el código. Detalles | Evidencia de lo que el cliente aprobó y de lo que se firmó |
| Credenciales y claves en el paquete de la appBSEBY 34(14); circular 2023/1 | Encuentra claves de API, tokens y credenciales en el paquete y valida si funcionan. Detalles | Secretos validados, con los permisos y servicios que exponen |
| SDK embebidos, bibliotecas nativas y componentes de tercerosBSEBY 29; Tebliğ CBRT 6(4) | Enumera los SDK y bibliotecas nativas por versión con sus números y los asocia a vulnerabilidades conocidas. Detalles | Identidad, versión y ubicación de los componentes en el paquete, por versión |
| Análisis estático del binario e integridad de la appBSEBY 34(14) | Análisis estático de APK, AAB e IPA, con análisis de flujo a través de los SDK embebidos. Detalles | Hallazgos de código y configuración con archivo y línea |
| Controles del alta remota: vitalidad, NFC y grabaciónUKTY 6-8, 10 | Prueba las API de alta y las comprobaciones de dispositivo y vitalidad de la app desde el lado de la persona. | Hallazgos sobre emulador, vitalidad y gestión de sesión, con evidencia |
Ostorlab prueba los controles de la app y de sus API. Las pruebas de penetración de red y de red de sucursal, las pruebas de ATM e ingeniería social, el proceso de los representantes, la supervisión del SOC, la respuesta a incidentes y su notificación y la gobernanza siguen correspondiendo a sus equipos.
Controles turcos que probar en su app móvil
Una lista práctica para los equipos de seguridad y de riesgo de sistemas, basada en el BSEBY, la circular 2023/1, el reglamento de identificación remota y el Tebliğ del CBRT.
Alcance de la prueba anual
Añada la app móvil y sus API al alcance de la prueba de penetración anual, junto a las aplicaciones web que nombra la circular.
Antes y después de publicar
Escanee cada compilación y cada versión publicada en la tienda, no solo la versión probada el trimestre pasado.
Endurecimiento
Compruebe las detecciones de root, jailbreak, depuración y manipulación, y confirme que la app actúa de verdad cuando se activan.
Autenticación
Verifique que el segundo factor lo aplica el servidor, que el bloqueo funciona tras los fallos y que los códigos de un solo uso duran poco.
SMS y SIM
Confirme que no se usan códigos por SMS con clientes que han activado la app, y pruebe la activación y los cambios de número.
Firma
Pruebe que el importe y el beneficiario aprobados son lo que se firma, y que el código queda inválido si cambia cualquiera de los dos.
Componentes y secretos
Mantenga una lista versionada de SDK y bibliotecas por versión, y rote cualquier clave que funcione desde el paquete.
Alta y datos
Pruebe la vitalidad y las comprobaciones de dispositivo, y mantenga los datos personales cifrados en reposo y en tránsito, y fuera de los registros.
Una lista sugerida, no una plantilla del BDDK. 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 firma de transacciones y los flujos de verificación reforzada con sus cuentas de prueba.Más información
- Pruebas de API y backendIntercepte el tráfico de la app incluso con pinning TLS y pruebe después 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 flujo a través de la app y sus SDK embebidos.Más información
- SCA y SBOMEncuentre dependencias vulnerables, incluidas bibliotecas nativas compiladas estáticamente, y siga su cierre release tras release.Más información
- Mobile Shielding ScanPruebe la detección de root y jailbreak, la anti-manipulación, la anti-depuración y el pinning en tiempo de ejecución, y vea qué protecciones aguantaron y cuáles se eludieron.Más información
- Su propia clave de IAEjecute escaneos con agentes de IA con su propia clave de proveedor de IA y un límite de gasto por escaneo, para que el uso siga 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.
- Regulation on Information Systems and Electronic Banking Services of Banks (traducción inglesa)BDDK, publicado el 15 de marzo de 2020, Boletín Oficial n.º 31069. Verificación de identidad y seguridad de las transacciones (artículos 34, 38 y 39), pruebas de penetración (artículo 18), gestión de parches (artículo 16) y alojamiento nacional de los sistemas primarios y secundarios (artículo 25)
- Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında YönetmelikBDDK, Boletín Oficial del 15 de marzo de 2020, n.º 31069 (original en turco). Una modificación del 20 de junio de 2020, n.º 31161, movió las fechas de aplicación; el texto consolidado no refleja ninguna otra modificación a septiembre de 2026
- Elektronik Bankacılık Hizmetlerinde ve Elektronik Ortamda Sözleşme İlişkisinin Kurulmasında Kimlik Doğrulama ve İşlem Güvenliği için Sağlanması Gereken Kriterler Hakkında Genelge (2023/1)BDDK, publicada el 27 de marzo de 2023, aprobada por la decisión del Consejo n.º 10546 del 23 de marzo de 2023. Notas de aplicación de los artículos 34, 38 y 39 del BSEBY, con los sensores de seguridad de la app móvil, la vinculación al dispositivo y la firma de transacciones (texto en turco)
- Bilgi Sistemlerine İlişkin Sızma Testleri Hakkında Genelge (BSD.2012/1)BDDK, 24 de julio de 2012. Alcance, puntos de acceso y metodología de las pruebas de penetración; el alcance mínimo incluye las aplicaciones móviles. Frecuencia anual fijada por la decisión del Consejo n.º 4022 del 27 de enero de 2011 (texto en turco)
- Regulation on Remote Identification Methods to be Used by Banks and Establishment of Contractual Relationship in Electronic Environment (traducción inglesa)BDDK, publicado el 1 de abril de 2021, n.º 31441, en vigor desde el 1 de mayo de 2021. Modificado el 6 de abril de 2022 (n.º 31801) y el 25 de mayo de 2023 (n.º 32201), con clientes personas jurídicas y métodos basados en IA reservados al Consejo
- Ödeme ve Elektronik Para Kuruluşlarının Bilgi Sistemleri ile Ödeme Hizmeti Sağlayıcılarının Ödeme Hizmetleri Alanındaki Veri Paylaşım Servislerine İlişkin TebliğCBRT, publicado el 1 de diciembre de 2021, n.º 31676. Autenticación reforzada obligatoria y reglas para apps móviles (artículo 10), escaneo de vulnerabilidades y pruebas de penetración anuales (artículo 12); última modificación el 4 de septiembre de 2026, n.º 33360 (texto en turco)
- Kişisel Verilerin Korunması Kanunu (Ley n.º 6698) (traducción inglesa)Publicada el 7 de abril de 2016, Boletín Oficial n.º 29677. Obligaciones de seguridad de los datos, incluidas medidas contra el tratamiento y el acceso ilícitos y la notificación de brechas (artículos 4 y 12)
- Mobil Uygulamalarda Mahremiyetin Korunmasına Yönelik TavsiyelerPublicación del KVKK n.º 65, marzo de 2025. Recomendaciones para las partes que tratan datos personales mediante aplicaciones móviles: privacidad desde el diseño y por defecto, cifrado, gestión de parches, límites a los inicios de sesión fallidos y control del usuario sobre los permisos (texto en turco)
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 BDDK
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.