BDDK and CBRT rules: test your mobile banking app before and after every release.
The BDDK's Regulation on Information Systems and Electronic Banking Services of Banks requires at least two authentication factors for electronic banking, keeps SMS one-time codes away from customers who have activated the mobile app, and requires a penetration test at least once a year by teams independent of the systems they test. Circular 2023/1 explains how the app should detect rooted or jailbroken devices, debugging and tampering, and how transaction signing should work. The CBRT's Tebliğ for payment institutions adds at least six vulnerability scans a year and an annual penetration test. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the mobile app and the APIs it calls, on the build your customers download
- Tests app PIN, biometrics, transaction signing and one-time codes with your test accounts
- Checks root, jailbreak, debugging and tampering detections, and what the app does when they fire
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Banks supervised by the BDDK, and payment institutions and e-money institutions supervised by the CBRT for the payment services rules
- Legal basis
- Regulation on Information Systems and Electronic Banking Services of Banks, Official Gazette 15 March 2020, No. 31069 (BSEBY)
- Focus
- Mobile banking security, strong customer authentication, penetration testing, remote onboarding and data protection
- Main references
- BSEBY and BDDK Circular 2023/1; CBRT Tebliğ No. 31676 (Turkish texts)
The texts behind Turkey's mobile banking rules
The BDDK sets the banking rules, the BDDK's circulars explain how to apply them, the CBRT covers payment services, and the KVKK sets the data protection baseline. The dates below are for the texts cited on this page.
- 15 March 2020
BSEBY published
The Regulation on Information Systems and Electronic Banking Services of Banks enters the Official Gazette No. 31069. Most provisions apply from 1 January 2021.
- 1 April 2021
Remote identification rules
The Regulation on Remote Identification Methods to be Used by Banks is published in Official Gazette No. 31441 and applies from 1 May 2021.
- 1 December 2021
CBRT payment rules
The CBRT publishes the Payment Services Regulation and the Tebliğ on the information systems of payment and e-money institutions, both in Official Gazette No. 31676.
- 27 March 2023
Circular 2023/1
The BDDK publishes Circular 2023/1, approved by Board decision 10546 of 23 March 2023, on authentication, transaction signing and mobile app controls.
- 25 May 2023
Remote identification amended
The remote identification regulation is amended (Official Gazette No. 32201) for corporate customers, with AI-based methods left to the Board. The changes apply from 1 June 2023.
- 4 September 2026
CBRT Tebliğ amended
The CBRT updates the Tebliğ (Official Gazette No. 33360): identity documents are verified over NFC by default, biometric data is covered, and foreign nationals can onboard with an NFC passport.
The BDDK and CBRT rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team. BSEBY articles are cited from the BDDK's English translation; Circular 2023/1, the 2012 penetration testing circular and the CBRT Tebliğ are summarised from the Turkish texts.
- BSEBY, Article 18(7); BDDK Circular BSD.2012/1, Scope and Methodology (Turkish text)
Run an annual penetration test, with mobile apps in scope
What the text says
Banks must have a penetration test performed at least once a year by teams that are not involved in or assigned to the design, development, implementation or performance of the services offered through the systems being tested. The BDDK's penetration testing circular sets the framework: basic tests followed by detailed tests, performed at least from the internet, the bank's internal network and a branch network, and covering a minimum scope that includes web applications and mobile applications. Findings are graded using the circular's severity levels and reported in its finding format, and deciding which assets matter most stays with the bank.
Source:BSEBY, Article 18(7); BDDK Circular BSD.2012/1, Scope and Methodology (Turkish text)
What it means for your mobile app
Mobile applications are a named test area. The app and the APIs it calls sit in the internet-facing part of the annual test, next to web and ATM systems.
How Ostorlab helps
The AI-agent pentest tests the store build and the APIs behind login, with a working exploit you can replay for each AI-agent finding and a coverage heatmap. It does not replace the network, branch, ATM or social engineering parts of the circular.
What stays with you
Running the full annual test, the internal and branch network parts, asset criticality decisions and reporting into the bank's process.
- BSEBY, Articles 22(4)-(5) and 24
Test internet-facing applications before release and after every update
What the text says
Applications open to the internet, whether developed in the bank or procured from suppliers, must be scanned and checked for security vulnerabilities before they are installed and again after each update made to them. Security requirements such as authorisation and access, identity verification, data integrity, logging and exception handling are defined from the start of development or procurement, and changes go through request management, risk assessment, testing and approval before they reach production.
What it means for your mobile app
Every new version of the mobile app is an update to an internet-facing application. A pre-release check and a post-release check are the minimum, and releases that go to the store between them should be monitored.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA with no source code needed; Mobile DAST runs the app; both fit a CI/CD pipeline. Store releases are monitored without manual triggers, so updates that ship between sprints do not go unseen.
What stays with you
Secure coding standards, source code review, release approval and the supplier clauses that require the same tests.
- BSEBY, Article 34(14)-(15); BDDK Circular 2023/1, annex, section 1 (Turkish text)
Harden the app and detect compromised devices
What the text says
Software and mobile applications offered to customers for electronic banking must verifiably originate from the bank, must not contain code that threatens customer security, and must receive the patches and updates needed to close their vulnerabilities. Critical data used by banking applications on phones and tablets must be inaccessible to other applications and processes on the same device, must be protected if the device is lost or stolen, and controls suitable to current technology must reduce the risks that come from a device being captured, its reliability being broken, or its operating system being broken or replaced. Circular 2023/1 describes the controls in detail: app and SDK integrity, anti-keylogging, anti-injection, anti-debugging, anti-emulation, device binding, anti-malware and jailbreak detection, reported to a dedicated security server over a separate secure channel.
Source:BSEBY, Article 34(14)-(15); BDDK Circular 2023/1, annex, section 1 (Turkish text)
What it means for your mobile app
This is the root, jailbreak and tamper territory. Detection is only the start: the app has to act on what it detects, and the check should not be trivial to switch off.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted, jailbroken and instrumented environments and attempts to bypass each protection, then shows whether the app blocks the workflow, refuses to start or keeps running, with a hardening score and bypass evidence.
What stays with you
Choosing and configuring the shielding SDK, the policy for compromised devices, and the security server.
- BSEBY, Articles 34(1), (6), (9) and 38(1)
Enforce two independent factors, online
What the text says
Electronic banking services, including transactions with no financial result such as displaying customer data, require an authentication mechanism of at least two factors from different classes: something the customer knows, something the customer owns, or a biometric characteristic. The factors must be independent, and the owned factor must be specific to the customer and not imitable. A customer-known factor must be entered by the customer and verified online at the bank, not recalled by the app or browser or linked to local authentication methods. After too many failed attempts the user's access must be blocked, and one-time passwords must be long enough to resist guessing, generated randomly, and valid only for a limited time.
What it means for your mobile app
MFA is enforced by the server, not drawn on the screen by the app. Lockout thresholds, OTP lifetime and what happens when the app skips a step are behaviours you can test.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, session timeouts and MFA enforcement, including step-up flows and bypass attempts, with your test accounts and the API calls behind them.
What stays with you
Choosing the authentication methods, the lockout thresholds and the OTP validity period.
- BSEBY, Article 34(7)-(8)
Keep SMS one-time codes out of the app channel
What the text says
For customers who have installed and activated the mobile banking application, the bank may not send an SMS one-time password or verification code for logging in or for verifying any transaction during a session, and may not use SMS as an authentication factor. SMS codes are allowed only at the first installation, activation or re-activation of the application, or when the application has become unusable. If a customer has changed their SIM card or ported their number to another operator, the bank must detect this through integration with mobile operators, and a SIM-based factor cannot be used for 90 days after the change unless the customer explicitly confirms it.
Source:BSEBY, Article 34(7)-(8)
What it means for your mobile app
The app needs a second channel that is not SMS. Testing has to cover what happens if SMS is used anyway, and how SIM changes and re-activations are handled.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP codes with your test accounts, tests whether the server still sends or accepts SMS codes for app-activated customers, and tests the API calls behind activation, number changes and step-up.
What stays with you
Operator integrations, SIM-change confirmation flows and customer communication.
- BSEBY, Articles 35 and 38(3); BDDK Circular 2023/1, annex, sections 1 and 2 (Turkish text)
Sign transactions so the customer approves what is shown
What the text says
Electronic banking transactions must be capable of non-repudiation and responsibility assignment. A one-time verification code is generated and signed with a private key assigned to the customer; the code must not reveal any authentication factor, must not be derivable from a known code and must not be imitable, and for transactions with a financial result it must be specific to the amount and the recipient approved by the customer, becoming invalid if either changes. Circular 2023/1 describes how this should be built: a dedicated SDK and a bank security server, the customer's key created and kept in the phone's cryptographic hardware such as Secure Enclave, a hardware-backed keystore or Strong Box, mutual TLS on a channel separate from the app's normal backend traffic, and security checks before each signing request.
Source:BSEBY, Articles 35 and 38(3); BDDK Circular 2023/1, annex, sections 1 and 2 (Turkish text)
What it means for your mobile app
What-you-see-is-what-you-sign is a backend property, but it can fail in the app: an overlay, injected code or a manipulated screen can change what the customer thinks they are approving.
How Ostorlab helps
Ostorlab tests how the app shows and signs transactions, including what happens when the amount or recipient changes after the code is displayed, whether a code can be replayed or derived, and the API calls around the signing flow.
What stays with you
The security server, key lifecycle, transaction templates and non-repudiation records.
- UKTY (Regulation on Remote Identification Methods to be Used by Banks), Articles 4, 6, 7, 8, 10 and 11
Run remote onboarding as a controlled process
What the text says
Remote identification is carried out in a real-time, uninterrupted video call between a trained customer representative and the person. The identity document is verified over NFC where possible, with its security features, photograph and signature checked under white light, and the whole session is recorded so it can be audited. Liveness detection is used and additional measures are taken against fake face technology, the person's face is compared with the document photograph, and the process is stopped if anything is doubtful. Only biometric data, as a special category of personal data, may be used for the identification, with the person's explicit consent recorded electronically. The process is tested before launch and reviewed at least twice a year, responsibility stays with the bank, and additional security measures apply to remotely onboarded customers.
What it means for your mobile app
The onboarding flow is high risk: camera, NFC, biometrics and a live backend. It is also the flow attackers try first, with fake faces, emulators and interception.
How Ostorlab helps
Ostorlab tests the onboarding APIs and the app's checks: what happens on emulated or rooted devices, whether liveness can be fed a recorded or synthetic face, how the session is protected, and how the client stores identity artefacts.
What stays with you
The representative process, the video platform, document verification decisions, retention and regulatory filings.
- KVKK Law No. 6698, Articles 4 and 12; KVKK, Recommendations for the Protection of Privacy in Mobile Applications, March 2025 (Turkish text)
Meet the KVKK security obligations on the phone
What the text says
Under the Personal Data Protection Law No. 6698, the data controller must take all necessary technical and organisational measures to prevent unlawful processing of, and unlawful access to, personal data, and must carry out the necessary audits. Where personal data is obtained by others unlawfully, the data controller must inform the data subject and notify the Board as soon as possible. In its recommendations for mobile applications, updated in 2025, the KVKK asks for privacy by design and by default, encryption of personal data in transit and in storage, hashed passwords, regular patch management and software updates, software testing before publication, limits on failed logins, and user control over permissions, notifications and privacy settings.
What it means for your mobile app
KVKK duties are about what the app collects and how it is protected. Permissions, SDK data flows, local storage, logs and screenshots are where this gets tested.
How Ostorlab helps
Ostorlab inventories the SDKs in the build, maps what they can access, and looks for personal data and tokens in storage, caches, logs and screenshots. It checks transport protections and reports what is exposed and where.
What stays with you
Data classification, legal bases, consent records, retention periods and breach notification.
- BSEBY, Article 16; CBRT Tebliğ on the information systems of payment and e-money institutions, Article 12 (Turkish text)
Manage vulnerabilities with deadlines
What the text says
Banks must run a vulnerability and patch management process: track vulnerability information, assess impact, define remediation methods and deadlines, keep records, and set compensating controls where a patch cannot be applied. Automatic vulnerability scanning tools report the most critical findings with priority to the security supervisor and the owner of the affected system. For payment institutions and e-money institutions the CBRT Tebliğ is more prescriptive: servers and the communication network are vulnerability-scanned at least six times a year and before first use, and penetration-tested at least once a year by people or companies that hold a national or international penetration testing credential and are not involved in the security of the systems tested. Findings are remediated as soon as possible under a board-approved action plan, and a report covering breaches, test results and critical vulnerabilities goes to the CBRT at least once a year.
What it means for your mobile app
Two deadlines cultures meet here: the bank's own patch deadlines under BSEBY, and the CBRT's six scans and annual test for payment institutions. Both need a traceable fix and retest loop.
How Ostorlab helps
Findings are rated critical, high, medium or low, grouped into tickets in the platform or in Jira and ServiceNow, mapped to the affected component and release, and retested once the fix ships. History stays available for the action plan and the annual report.
What stays with you
Patching servers and network devices, the board-approved action plan and the filings to the CBRT.
Summary of public BDDK, CBRT and KVKK texts, checked on 27 September 2026. BSEBY articles are cited from the BDDK's English translation unless marked (Turkish text); Circular 2023/1, the 2012 penetration testing circular and the CBRT Tebliğ are summarised from the Turkish texts. This page is not legal advice.
Turkish rules, control by control
The controls the BDDK, CBRT and KVKK texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Annual penetration testing, with mobile applications in scopeBSEBY 18(7); BSD.2012/1 | AI-agent pentest of the app and its APIs, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Vulnerability scanning of internet-facing applications before release and after updatesBSEBY 22(5) | Mobile SAST and DAST in CI/CD on every build, and monitoring of store releases. Details | Scan results per build and per store release |
| Root, jailbreak, tampering and debugging protectionsBSEBY 34(15); Circular 2023/1 | Bypass attempts in rooted, jailbroken and instrumented environments, with what the app does next. Details | Bypass evidence and a hardening score |
| Two-factor authentication, lockout and one-time codesBSEBY 34(1), (6), (9) | Logs in with your test accounts and tests MFA enforcement, step-up flows and lockout. Details | Findings on login, step-up and lockout, with reproduction steps |
| No SMS one-time codes for app-activated customers; SIM change controlsBSEBY 34(7)-(8) | Tests whether the server still sends or accepts SMS codes for app users, and how activation and number changes are handled. Details | Request and response logs of the activation and code flows |
| Transaction signing bound to the approved amount and recipientBSEBY 35, 38(3); Circular 2023/1 | Tests signing and approval flows, including changes to the amount or recipient after the code is shown. Details | Evidence of what the customer approved and what was signed |
| Credentials and keys in the app packageBSEBY 34(14); Circular 2023/1 | Finds API keys, tokens and credentials in the package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| Embedded SDKs, native libraries and third-party componentsBSEBY 29; CBRT Tebliğ 6(4) | Lists the SDKs and native libraries per release with their versions and maps them to known vulnerabilities. Details | Component identity, version and location in the app bundle, per release |
| Binary static analysis and app integrityBSEBY 34(14) | Static analysis of APK, AAB and IPA, including taint analysis across embedded SDKs. Details | Code and configuration findings with file and line references |
| Remote onboarding checks: liveness, NFC and recordingUKTY 6-8, 10 | Tests the onboarding APIs and the app's device and liveness checks from the person's side. | Findings on emulator, liveness and session handling, with evidence |
Ostorlab tests controls in the app and its APIs. Network and branch penetration testing, ATM and social engineering tests, the customer representative process, SOC monitoring, incident reporting and governance stay with your teams.
Turkish controls to test in your mobile app
A practical list for security and system risk teams, based on BSEBY, Circular 2023/1, the remote identification regulation and the CBRT Tebliğ.
Annual test scope
Add the mobile app and its APIs to the annual penetration test scope, next to the web applications the circular names.
Before and after release
Scan every build and every store release, not only the version tested last quarter.
Hardening
Check root, jailbreak, debugging and tampering detections, and confirm the app actually acts when they fire.
Authentication
Verify the second factor is enforced by the server, that lockout works after failures, and that one-time codes are short-lived.
SMS and SIM
Confirm SMS codes are not used for app-activated customers, and test activation and number-change flows.
Signing
Test that the approved amount and recipient are what gets signed, and that the code dies when either changes.
Components and secrets
Keep a versioned list of SDKs and libraries per release, and rotate any key that works from the app package.
Onboarding and data
Test liveness and device checks, and keep personal data encrypted in storage and in transit, and out of logs.
A suggested list, not a BDDK template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes, transaction signing and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering, anti-debugging and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Regulation on Information Systems and Electronic Banking Services of Banks (English translation)BDDK, published 15 March 2020, Official Gazette No. 31069. Identity verification and transaction security (Articles 34, 38 and 39), penetration tests (Article 18), patch management (Article 16) and domestic hosting of primary and secondary systems (Article 25)
- Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında YönetmelikBDDK, Official Gazette 15 March 2020, No. 31069 (Turkish original). An amendment on 20 June 2020, No. 31161, moved the application dates; the consolidated text reflects no other amendment as of September 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, published 27 March 2023, approved by Board decision 10546 of 23 March 2023. Application notes for Articles 34, 38 and 39 of BSEBY, including mobile app security sensors, device binding and transaction signing (Turkish text)
- Bilgi Sistemlerine İlişkin Sızma Testleri Hakkında Genelge (BSD.2012/1)BDDK, 24 July 2012. Penetration testing scope, access points and methodology; the minimum scope includes mobile applications. Annual frequency set by Board decision 4022 of 27 January 2011 (Turkish text)
- Regulation on Remote Identification Methods to be Used by Banks and Establishment of Contractual Relationship in Electronic Environment (English translation)BDDK, published 1 April 2021, No. 31441, in force from 1 May 2021. Amended on 6 April 2022 (No. 31801) and 25 May 2023 (No. 32201), adding corporate customers and leaving AI-based methods to the Board
- Ö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, published 1 December 2021, No. 31676. Mandatory strong customer authentication and mobile app rules (Article 10), vulnerability scanning and annual penetration tests (Article 12); last amended 4 September 2026, No. 33360 (Turkish text)
- Kişisel Verilerin Korunması Kanunu (Law No. 6698) (English translation)Published 7 April 2016, Official Gazette No. 29677. Data security obligations, including measures against unlawful processing and access and notification of breaches (Articles 4 and 12)
- Mobil Uygulamalarda Mahremiyetin Korunmasına Yönelik TavsiyelerKVKK publication No. 65, March 2025. Recommendations for parties processing personal data through mobile applications: privacy by design and by default, encryption, patch management, limits on failed logins and user control over permissions (Turkish text)
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Assess your mobile banking app the way the BDDK describes it
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.