Bangladesh Bank ICT Security: test your mobile banking app the way the guideline describes it.
Bangladesh Bank's Guideline on ICT Security, Version 4.0, asks banks and other regulated organizations to run SAST and DAST on their mobile app code, apply app hardening or shielding, enforce multi-factor authentication and session controls, and penetration test at least annually and after significant changes. The Cybersecurity Framework, Version 1.0 (2026), must be complied with by 31 December 2026. Ostorlab tests those controls in your app and the APIs behind it, on every release.
- Static and dynamic testing of the build you ship, with no source code needed
- Checks root and jailbreak detection, anti-tampering, anti-instrumentation and pinning, and what the app does when they trigger
- Tests login, one-time codes, MFA and session handling with your test accounts
- Follows the app into its APIs, even with TLS pinning, with a replayable exploit for each AI-agent finding
- Who it applies to
- Banks, NBFIs, MFS providers, PSPs, PSOs and other financial service providers regulated by Bangladesh Bank
- Key date
- Cybersecurity Framework compliance due by 31 December 2026 (BRPD-2 Circular No. 02)
- Focus
- Internet and app banking, mobile financial services, VAPT and APIs
- Main reference
- Guideline on ICT Security, Version 4.0 (2023), issued by BRPD Circular No. 10 of 19 June 2023
How the Bangladesh Bank rules took shape
The ICT Security Guideline sets the technical baseline, and the 2026 Cybersecurity Framework builds on it. The dates below are for the texts cited on this page.
- 16 March 2023
Guidelines on Cloud Computing
BRPD Circular No. 05 of 2023 issues the cloud guidelines, and cloud services already in use had to comply by 31 December 2023.
- 19 June 2023
ICT Security Guideline, Version 4.0
BRPD Circular No. 10 directs all scheduled banks to follow Version 4.0, replacing the 2015 version, with immediate effect.
- 13 July 2023
Version 4.0 for financial institutions
DFIM Circular No. 08 gives the same instruction to financial institutions, also with immediate effect.
- 29 March 2026
Cybersecurity Framework, Version 1.0
BRPD-2 Circular No. 02 issues the framework to banks, finance companies, MFS providers, payment service providers and payment system operators.
- 31 December 2026
Framework compliance deadline
Compliance with the Cybersecurity Framework must be ensured by this date.
- Every year
Penetration testing
Internal and external penetration testing at least annually and after any significant infrastructure or application upgrade, and internal vulnerability scans at least half-yearly.
The Bangladesh Bank 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.
- Guideline on ICT Security v4.0, 11.4.12 and 11.4.13
Run SAST and DAST on the mobile app
What the text says
Employ secure coding practices, such as input validation, output encoding and secure storage of sensitive data within the application. Regularly perform static and dynamic application security testing (SAST and DAST) to identify and remediate security vulnerabilities in the mobile app code.
What it means for your mobile app
Few regulators name SAST and DAST for the mobile app this directly. "Regularly" fits a release cadence: test each build before it reaches the store.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app, keeps authenticated sessions and captures traffic, stack traces and screenshots. Both run from your CI/CD pipeline on every build.
What stays with you
Secure coding training and reviews of your backend code.
- Guideline on ICT Security v4.0, 11.4.14 and 11.7.8
Harden and shield the app
What the text says
Perform application hardening (or application shielding) mechanisms to protect the app from tampering, misuse, IP theft and vulnerability exploitation. For mobile financial services, take measures so that misconfigured devices cannot access enterprise resources, and actively deny a device trying to access enterprise data if it is in an insecure state.
What it means for your mobile app
Shielding is expected. What matters is whether it holds when someone repackages the app, hooks it at runtime or runs it on a rooted or jailbroken phone.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments, attempts bypasses of root and jailbreak detection, anti-tampering, anti-instrumentation and TLS pinning, and shows whether the app blocks the workflow, refuses to start or keeps running. You get a hardening score and bypass evidence.
What stays with you
Choosing and configuring your shielding or runtime protection product.
- Guideline on ICT Security v4.0, 11.4.2, 11.4.6, 11.4.7 and 11.4.11
Enforce MFA and secure sessions for online transactions
What the text says
Implement multi-factor authentication for all online financial transactions. An online session must end automatically after a fixed period unless the customer re-authenticates, and secure session management must prevent session hijacking, with unique session identifiers, secure cookies and enforced session time-outs. Internet banking accounts are blocked after multiple wrong PIN attempts.
Source:Guideline on ICT Security v4.0, 11.4.2, 11.4.6, 11.4.7 and 11.4.11
What it means for your mobile app
MFA on every financial transaction, session expiry and lockout are concrete settings you can test in the app and its backend.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, and traffic analysis shows how credentials travel from the app to the backend.
What stays with you
Choosing authentication methods and the policy values, such as time-outs and lockout thresholds.
- Guideline on ICT Security v4.0, 11.7.18 and 11.7.19
Authenticate mobile payments on the server
What the text says
Put login authentication and risk-based, value-based transaction authentication in place. Protect mobile payments and access to sensitive data with robust customer authentication, including MFA for app registration, a configurable PIN, password, pattern or biometric, time-based one-time passwords, OTP auto-fetching, a maximum number of failed attempts, a maximum duration for inactive sessions, and authentication processed only at the app owner's server end.
What it means for your mobile app
Each item in the list can be checked against the running app. The last one is key: the app must not decide on its own that a user is authenticated.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP one-time codes with your test accounts and tests MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind account changes.
What stays with you
Choosing authentication methods and transaction limits.
- Guideline on ICT Security v4.0, 11.7.16, 11.7.17 and 11.7.23
Bind devices and alert on new ones
What the text says
Implement device registration or binding using multiple properties unique to the device, so that only registered devices can access backend servers. Notify the user of every new device registration, keep a record of registered devices, and detect multiple simultaneous login attempts and tell the user through an alternate channel such as a callback, SMS or email.
Source:Guideline on ICT Security v4.0, 11.7.16, 11.7.17 and 11.7.23
What it means for your mobile app
Device binding is enforced by the backend. A request from an unregistered device, or a replayed token, should be refused by the API, not just hidden in the app.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
The binding design, new-device notifications and login anomaly monitoring.
- Guideline on ICT Security v4.0, 11.7.10, 11.7.11 and 11.7.20 to 11.7.22
Leave no sensitive data on the device
What the text says
Turn off auto-complete for login IDs and passwords, and the clipboard for sensitive data, with an in-app keypad as an option. Do not store sensitive information in a storage segment shared with other apps, delete confidential data from caches and memory after use, and erase application-specific sensitive data from temporary and permanent memory at logoff or when the app instance ends.
Source:Guideline on ICT Security v4.0, 11.7.10, 11.7.11 and 11.7.20 to 11.7.22
What it means for your mobile app
Tokens, account data and personal data left in storage, caches or logs can be read by malware or by anyone holding the phone.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks for misconfigurations that weaken transport and session protections, and tests the APIs behind transactions.
What stays with you
In-app keypad design and the input settings of each screen.
- Guideline on ICT Security v4.0, 6.2.1 to 6.2.3 and 6.2.7; Cybersecurity Framework v1.0, 5.1.2.25
Scan and penetration test on a fixed cadence
What the text says
Run vulnerability scans periodically and after any significant change, internal scans at least half-yearly with rescans until all high-risk vulnerabilities are resolved, and a scan of critical systems and applications once a year by an independent party, with a time-bound remediation plan. Perform internal and external penetration testing at least annually and after any significant infrastructure or application upgrade or modification. The 2026 Cybersecurity Framework repeats the annual penetration testing rule.
Source:Guideline on ICT Security v4.0, 6.2.1 to 6.2.3 and 6.2.7; Cybersecurity Framework v1.0, 5.1.2.25
What it means for your mobile app
The app and its APIs are applications. A major release is a significant application modification, which is a trigger for a new penetration test on top of the yearly one.
How Ostorlab helps
Run automated scans from your CI/CD pipeline on every build and monitor store releases without manual triggers. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
The independent annual scan, infrastructure and network testing, and the remediation plan.
- Guideline on ICT Security v4.0, 6.2.6 and 11.7.15
Have apps tested by internal and independent assessors
What the text says
The organization may ensure that its apps have passed extensive and recursive vulnerability assessment, scan and intrusion tests to identify weaknesses, through internal and independent assessors. The penetration testing methodology is based on an industry-accepted approach such as NIST SP800-115, covers critical systems, tests from inside and outside the network, considers threats from the last 12 months and specifies retention of test and remediation results.
What it means for your mobile app
Testing is expected to be repeated, not one-off, and results and fixes have to be kept.
How Ostorlab helps
Fast scans usually finish in 1 to 5 minutes and full scans in 15 to 45 minutes, so they fit every release. An AI-agent pentest goes deeper, typically in a few hours, with a working exploit you can replay for each AI-agent finding, for critical changes and your periodic deep tests.
What stays with you
Choosing the independent assessor and writing the methodology.
- Guideline on ICT Security v4.0, 10.8.3, 10.8.4 and 10.8.12
Secure and test APIs before production
What the text says
Set security standards for designing and developing APIs, including protection of API keys and access tokens and a reasonable, enforced token expiry. Implement strong authentication and access control for API services, and perform security screening and testing of the API between the organization and its third parties before it is deployed into production.
Source:Guideline on ICT Security v4.0, 10.8.3, 10.8.4 and 10.8.12
What it means for your mobile app
The APIs behind the app carry the same money and data as the app. They need testing before go-live and after changes.
How Ostorlab helps
Logged-in testing follows the app into its APIs to test authorization, sessions and MFA enforcement, with request and response logs and reproduction steps for each finding.
What stays with you
Vetting third parties, API monitoring and alerting, and protection against denial of service.
Summary of public Bangladesh Bank texts, checked on 27 September 2026. Some provisions use "should" or "may" rather than "shall", as quoted. This page is not legal advice.
Bangladesh Bank rules, control by control
The controls the Bangladesh Bank 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 |
|---|---|---|
| SAST and DAST of the mobile appICT Guideline 11.4.13 | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| App hardening and shieldingICT Guideline 11.4.14 | Modifies the binary, injects debuggers and hooks, and attempts to bypass TLS pinning. Details | Evidence of which protections held and which were bypassed |
| Denying devices in an insecure stateICT Guideline 11.7.8 | Runs the app in rooted and jailbroken environments and attempts to bypass root and jailbreak detection. Details | Hardening score, and bypass evidence for each protection that failed |
| MFA and session time-outsICT Guideline 11.4.6, 11.4.7, 11.4.11 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| Mobile payment authenticationICT Guideline 11.7.19 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| API tokens, access control and device bindingICT Guideline 10.8.3, 10.8.4, 11.7.16 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
| Sensitive data on the deviceICT Guideline 11.7.20 to 11.7.22 | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| Secure storage of sensitive data in the appICT Guideline 11.4.12 | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| No end-of-life librariesICT Guideline 6.1.7 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Penetration testing yearly and after significant changesICT Guideline 6.2.7; CSF 5.1.2.25 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
Ostorlab tests controls in the app and its APIs. Intrusion detection and web application firewalls, fraud and anomaly monitoring, log management, SIM replacement agreements with mobile operators, external IS audit, business continuity and reporting to Bangladesh Bank stay with your teams.
Bangladesh Bank controls to test in your mobile app
A practical list for security and ICT risk teams, based on the ICT Security Guideline and the Cybersecurity Framework.
SAST and DAST on every build
Run static and dynamic tests on each build of the app before it reaches the store, and fix what they find.
Shielding under attack
Run the app on rooted and jailbroken devices, try a modified build and runtime hooks, and check that the app reacts.
MFA and sessions
Check MFA on every financial transaction, session time-outs, re-authentication and lockout after wrong PIN attempts.
Server-side authentication
Confirm that authentication is decided by your server, and that failed attempts and inactive sessions are limited there.
Device binding at the API
Send requests from an unregistered device and replay tokens, and check that the backend refuses them.
Data left on the device
Look for tokens and personal data in storage, caches, logs and screenshots, including after logoff.
Testing calendar
Plan penetration tests at least annually and after significant upgrades, internal scans at least half-yearly, and the yearly independent scan of critical applications.
APIs before go-live
Test each API for authorization and token handling before production, and check that tokens expire.
A suggested list, not a Bangladesh Bank template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- 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 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
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.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.
- Guideline on ICT Security, Version 4.0, 2023Bangladesh Bank. Applies to banks, NBFIs, MFS providers, PSPs, PSOs and other regulated financial service providers. Chapters 6 (VAPT), 10 (development, testing and APIs) and 11 (internet and app banking, mobile financial services)
- BRPD Circular No. 10: Guideline on ICT SecurityBangladesh Bank, 19 June 2023. Directs all scheduled banks to follow Version 4.0, with immediate effect. Published in Bangla only
- DFIM Circular No. 08: Guideline on ICT Security, Version 4.0Bangladesh Bank, 13 July 2023. Gives the same instruction to financial institutions, with immediate effect. Published in Bangla only
- Cybersecurity Framework, Version 1.0 (2026)Bangladesh Bank. Built on the NIST Cybersecurity Framework functions. Applies to banks, financial institutions, MFS providers, PSPs, PSOs and other financial or payment service providers
- BRPD-2 Circular No. 02: Cybersecurity Framework, Version 1.0 (2026)Bangladesh Bank, 29 March 2026. Issues the framework and requires compliance by 31 December 2026. Published in Bangla only
- Guidelines on Cloud ComputingBangladesh Bank, issued by BRPD Circular No. 05 of 16 March 2023. Security testing before application deployment (4.5.4.3) and VAPT of cloud services (6.4)
- Bangladesh Mobile Financial Services (MFS) Regulations, 2022Bangladesh Bank. Section 12 requires all MFS transactions to be authenticated with a PIN or similar secured mechanism, and encourages a second authentication factor
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.
Test your mobile banking app against the Bangladesh Bank controls
Start with a free scan of your app from the store, or book a demo to run shielding and logged-in tests with our team.