State Bank of Vietnam Circular 50/2024: test your mobile banking app against the SBV rulebook.
Circular 50/2024 on security for online services has applied since 1 January 2025 and, as amended by Circular 77/2025 from 1 March 2026, names OWASP Mobile Application Security for mobile banking apps, requires apps to stop on rooted, jailbroken or debugged devices, and sets vulnerability scanning cadence and patch deadlines, with critical internet-facing fixes due within one day. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the mobile app and the APIs it calls against the SBV requirements, on the build your customers download
- Tests login, one-time codes and transaction confirmation with your test accounts
- Checks root, jailbreak, debugger and repackaging detection at runtime, and lists the SDKs in each release
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Credit institutions, foreign bank branches, payment intermediary providers and mobile money providers, and credit information companies under SBV supervision
- Key date
- Circular 50/2024 in force from 1 January 2025; Circular 77/2025 amendments apply from 1 March 2026
- Focus
- Security of Online Banking and Mobile Banking software, transaction confirmation and OTP, vulnerability and patch management
- Main reference
- SBV Circular 50/2024/TT-NHNN as amended by Circular 77/2025/TT-NHNN
The SBV texts behind your mobile channel
The online services circular sits alongside the information system security circular and the SBV's decisions on online payments. The dates below are for the texts cited on this page.
- 21 October 2020
Circular 09/2020/TT-NHNN
The SBV issues minimum information system security requirements for banking, in force from 1 January 2021. Article 42 requires penetration testing for systems that connect to the internet, customers and third parties, a security assessment before go-live, and periodic testing from every six months to every two years depending on the system class.
- 17 April 2023
Personal data protection decree
Decree 13/2023/ND-CP applies from 1 July 2023, with consent, security measures, breach notification and impact assessment duties for personal data, including the account, transaction and biometric data a banking app handles.
- 18 December 2023
Decision 2345/QD-NHNN
The SBV sets biometric verification for online payments, in force from 1 July 2024: individual transfers over VND 10 million, or more than VND 20 million in a day, and the first use of Mobile Banking or use from a new device, require a matching biometric check.
- 31 October 2024
Circular 50/2024/TT-NHNN
The SBV replaces Circular 35/2016 with security rules for online services, in force from 1 January 2025. It carries the biometric rules into Articles 10 and 11 and the transaction classification appendices, sets OTP validity limits, and requires vulnerability scans at least yearly, and every three months for internet-facing components, with patch deadlines by severity.
- 30 December 2024
Decision 2345 repealed
Decision 2872/QD-NHNN repeals Decision 2345/QD-NHNN from 1 January 2025, because its content now sits in Circular 50/2024. The biometric requirement continues to apply through the circular and its appendices.
- 31 December 2025
Circular 77/2025/TT-NHNN
The SBV amends Circular 50/2024, in force from 1 March 2026. Mobile Banking software must meet OWASP Mobile Application Security and Online Banking software the OWASP Top Ten; apps must exit on debuggers, emulators, hooks, repackaging, root or jailbreak; and institutions must review the security of installable app versions at least every three months.
The SBV's online banking 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. Circular 50/2024 and its amendment are summarised from the Vietnamese text.
- Circular 50/2024/TT-NHNN, Article 7(3)(c), as amended by Circular 77/2025/TT-NHNN, Article 4(1) (Vietnamese text)
Test mobile banking software before release, against OWASP
What the text says
Online Banking and Mobile Banking software must be tested before it goes live: an approved test plan that states the security conditions, checks for input errors and fraud, and scanning for technical vulnerabilities and weaknesses. The test must assess defences against attack classes including injection (SQL, XPath, LDAP), cross-site scripting, cross-site request forgery, server-side request forgery and brute force, and against access control, authentication, cryptography, misconfiguration and logging failures. From 1 March 2026 the test must cover the OWASP Top Ten for web software and OWASP Mobile Application Security for mobile software, using the latest version or a version issued within the last six months.
What it means for your mobile app
The SBV names the OWASP mobile standard explicitly. Your app binary and the web and API surfaces behind it are in scope, and the test happens before release and on a regular cadence.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA, including embedded SDKs. Mobile DAST and the AI-agent pentest test the running app and its APIs, behind login, in CI/CD on every build. Findings map to the OWASP categories the circular names.
What stays with you
Writing the test plan and approving the release, and the server, VPN and infrastructure platforms outside the app.
- Circular 50/2024/TT-NHNN, Articles 7(1) and 7(2); Circular 09/2020/TT-NHNN, Article 40 (Vietnamese text)
Build security into development and control the source
What the text says
Security requirements must be identified before development and applied through analysis, design, build and testing. Source code must be controlled: for in-house code, check it periodically and whenever the app changes to remove malicious code and security vulnerabilities, with reviewers independent of the developers, and keep the source at two geographically separate locations. For outsourced code, require the provider to fix vulnerabilities before handover, or to scan the delivered software and commit to no malicious code. Test data must not be real customer data unless it is masked or altered.
What it means for your mobile app
The SBV treats the app as software under change control, including code written by vendors. Reviews have to be independent of the developers, and test environments cannot carry live customer data.
How Ostorlab helps
Mobile SAST works on the compiled binary with taint analysis across the app and its embedded SDKs, so it covers code you cannot read and third-party components. Secrets scanning finds keys and credentials left in the build.
What stays with you
Secure coding standards, code review sign-off, vendor contracts and the source code repositories themselves.
- Circular 50/2024/TT-NHNN, Article 8(2) to (5), as amended by Circular 77/2025/TT-NHNN, Article 5 (Vietnamese text)
Stop the app on rooted, jailbroken, debugged or repackaged devices
What the text says
Mobile Banking apps must be distributed through the official app stores, protected against reverse engineering, protected against interference in their data flows and with the server, and able to detect unauthorised interference. From 1 March 2026 the app must automatically exit or stop and tell the customer why when it detects a debugger, an emulator or virtual machine, Android Debug Bridge, hooking or repackaging, or a rooted, jailbroken or bootloader-unlocked device. Remembering the access password is not allowed, except where device biometrics are the confirmation form.
What it means for your mobile app
Root, jailbreak and tamper detection are named requirements with a defined reaction, not optional hardening. They are runtime behaviours you can test, on the build customers install.
How Ostorlab helps
Mobile Shielding Scan tests root and jailbreak detection, anti-tampering and pinning at runtime, and shows which protections held and which were bypassed. The agentic pentest tests whether the detection can be evaded or repackaged around.
What stays with you
Choosing and configuring the shielding SDK, and deciding the customer message and support path.
- Circular 50/2024/TT-NHNN, Articles 9, 10 and 11, as amended by Circular 77/2025/TT-NHNN, Article 7 (Vietnamese text)
Confirm transactions with SBV-approved forms, including biometrics
What the text says
Customers get an electronic transaction account and log in with at least one SBV confirmation form. The circular sets the forms and their limits: passwords of at least eight characters and PINs of at least six digits, each valid for at most twelve months and thirty days for a first default credential; SMS and email OTP valid for at most five minutes, voice OTP three minutes, soft and token OTP two minutes, two-channel confirmation five minutes; and lockout after at most ten wrong attempts. Where a transaction is confirmed by matching biometrics, the solution must meet accuracy and liveness standards, with presentation attack detection certified to ISO 30107 Level 2 or equivalent from 1 March 2026. The biometric requirement for high-value transactions continues through the transaction classification appendices.
What it means for your mobile app
The confirmation step has to be enforced by the server for the right transaction class, including high-value transfers, and the OTP and biometric rules have testable properties: validity windows, lockout and liveness.
How Ostorlab helps
Authenticated testing completes SMS, email and TOTP one-time codes with your test accounts and tests OTP validity, lockout, step-up flows and the API calls behind them. It tests whether a confirmation step can be skipped or replayed; it does not certify biometric liveness.
What stays with you
Choosing biometric and liveness vendors and holding their FIDO or ISO certification, and the transaction classification and limits you apply.
- Circular 50/2024/TT-NHNN, Articles 7(6)(h) and 8(6) (Vietnamese text)
Check the customer on a new device, and notify about logins
What the text says
For individual customers, the app must verify the customer on first access or when they access from a device other than the last one used, at minimum by matching an SMS or voice OTP sent to the registered phone number, or a soft or token OTP, or by matching biometrics where sectoral law requires collecting them. Online Banking software must also notify the customer, by SMS or another registered channel, about the first login or a login from a different device.
Source:Circular 50/2024/TT-NHNN, Articles 7(6)(h) and 8(6) (Vietnamese text)
What it means for your mobile app
Device binding and new-device verification are named controls, so a new phone should not reach the account without a fresh check, and the notification is part of the flow.
How Ostorlab helps
Ostorlab tests login and first-login flows, completing one-time codes with your test accounts, and checks whether device checks and notifications can be skipped from the API side.
What stays with you
Deciding which methods you offer and handling device registration support for customers.
- Circular 50/2024/TT-NHNN, Article 8(1a), inserted by Circular 77/2025/TT-NHNN, Article 5(1) (Vietnamese text)
Control installed versions and review them every three months
What the text says
From 1 March 2026 institutions must assess the security of the app versions they allow customers to install at least every three months, to find security vulnerabilities and assess the risk of cybercriminal interference. When a customer activates on a new device or reactivates the app, they must install the latest version, or a version that still meets the security requirements, and downgrading must be blocked. When a high or critical vulnerability is found, the institution must check and stop transactions or apply controls against exploitation, and fix and update the app within the deadlines of Article 14(6).
What it means for your mobile app
Every version still installable is in scope, not only the newest release, and an old build with a critical issue has to be blocked or restricted.
How Ostorlab helps
Ostorlab scans each store release and can scan older builds you still support, with results per version, so you can decide which versions to block and prove the fix in the next release.
What stays with you
The version policy, the in-app update and block logic, and the store review process.
- Circular 50/2024/TT-NHNN, Article 14 (Vietnamese text)
Scan for vulnerabilities and patch within the SBV deadlines
What the text says
Institutions must manage vulnerabilities in the Online Banking system: detect unauthorised changes to the app, run intrusion detection, follow CVSS v4 or equivalent severity information, and scan for vulnerabilities at least once a year, and at least every three months for components directly connected to the internet. Each vulnerability is assessed for impact and risk with a remediation plan, and patched within the SBV deadlines: critical within one day for internet-facing components and one month for the rest, high within one day and two months, and medium or low within a period the institution decides.
Source:Circular 50/2024/TT-NHNN, Article 14 (Vietnamese text)
What it means for your mobile app
The one-day deadline for critical internet-facing issues sets the pace for the app and the APIs behind it, and the evidence has to show severity, timing and closure.
How Ostorlab helps
Findings are rated critical, high, medium or low and tracked as tickets in the platform or in Jira and ServiceNow, with retest once the fix ships, so you can show when a finding was reported, fixed and verified.
What stays with you
Applying the patches on your servers and infrastructure, and the SOC monitoring and incident response around the system.
- Circular 50/2024/TT-NHNN, Articles 7(7) and 19 (Vietnamese text); Decree 13/2023/ND-CP; Law 91/2025/QH15
Protect customer data, confirmation secrets and records
What the text says
Customer data must be kept safe under the law. Passwords, PINs and biometric information must be encrypted or masked at rest, access to customer data is limited to the roles that need it and monitored, and devices and storage media holding customer data are controlled to prevent leaks. When a leak occurs, the institution must notify customers and report promptly to the SBV. Online Banking software must keep device identification and transaction and confirmation logs online for at least three months, backed up for at least one year, including the ten most recent biometric confirmations of each customer. Personal data processing also sits under Decree 13/2023/ND-CP and, from 1 January 2026, the Personal Data Protection Law.
What it means for your mobile app
Confirmation secrets and biometric data have storage rules of their own, and the app is where a leak is most likely to start, so local storage, caches, logs and screenshots are all in scope.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections and misconfigurations, and finds credentials and keys in the app package and its APIs.
What stays with you
Data classification, encryption and key management, consent and assessment dossiers, and notifying customers and the SBV.
Summary of public SBV and Vietnamese Government texts, checked on 27 September 2026. Circular 50/2024 and its amendment are summarised from the Vietnamese text. This page is not legal advice.
SBV rules, control by control
The controls the SBV 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 |
|---|---|---|
| Mobile app security testing against OWASP MASCircular 50/2024 Art. 7(3), Circular 77/2025 Art. 4 | 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 |
| Online Banking and API testing against the OWASP Top TenCircular 50/2024 Art. 7(3), Circular 77/2025 Art. 4 | 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 |
| Independent source code review and secure developmentCircular 50/2024 Art. 7(1) to (2) | Mobile SAST with taint analysis across the app and its embedded SDKs, with no source code needed. Details | Binary analysis results per build, including embedded SDK code paths |
| Vulnerable components and fix deadlinesCircular 50/2024 Art. 14(4) to (6) | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with CVSS severity, upgrade or replace advice, and closure across releases |
| Root, jailbreak, tamper and repackaging detectionCircular 50/2024 Art. 8(4), Circular 77/2025 Art. 5(2) | Tests root and jailbreak detection, anti-tampering and pinning at runtime, and whether the unsafe-device exit behaviour triggers. Details | Findings showing which protections held and which were bypassed, with reproduction steps |
| Transaction confirmation, OTP and lockoutCircular 50/2024 Arts. 9 to 11 | Logs in with one-time codes and tests OTP validity, lockout after wrong attempts and step-up flows, and the API calls behind them. Details | Findings on login and confirmation flows, with reproduction steps |
| New-device checks and login notificationsCircular 50/2024 Art. 8(6), Art. 7(6)(h) | Tests first login and login from a new device, completing one-time codes with your test accounts. Details | Findings on device checks and notifications, with request and response logs |
| Secrets, PINs and data on the deviceCircular 50/2024 Art. 19; Circular 09/2020 Art. 24 | Finds API keys, tokens and credentials in the app package and validates whether they work, and looks for customer data in storage, caches, logs and screenshots. Details | Validated secrets with the permissions they expose, and file system evidence of what was written and where |
| Version control and review of installable releasesCircular 50/2024 Art. 8(1a), Circular 77/2025 Art. 5(1) | Scans each store release and older supported builds, so results are measured per version rather than per quarter. Details | Scan results per app version, and the retest that proves the fix in the next release |
| Reporting to the SBV and customer notificationCircular 50/2024 Arts. 19(5) and 20 | Supplies the finding evidence and retest records that support your reports; it does not file reports with the SBV or notify customers. | Findings, affected versions and retest records you keep as supporting documentation |
Ostorlab tests controls in the app and its APIs. SOC monitoring, incident response and reporting, biometric liveness certification, version blocking logic, backups and recovery, governance and physical security stay with your teams.
SBV controls to test in your mobile app
A practical list for security and system risk teams, based on Circular 50/2024 as amended by Circular 77/2025 and on Circular 09/2020.
Scope the app and its APIs
Put the Mobile Banking app and the APIs it calls in the pre-release test plan, naming the OWASP MAS and OWASP Top Ten categories the circular requires.
Independent code and component review
Check in-house code with reviewers who do not write it, scan outsourced and third-party components, and keep a component inventory per release.
Hardening behaviour
Verify that a rooted, jailbroken, debugged, hooked or repackaged environment stops the app, and that pinning holds.
Confirmation controls
Test OTP validity windows, lockout after wrong attempts, and that the correct confirmation form is enforced for each transaction class.
Biometric and liveness certification
Check that the biometric solution and its presentation attack detection carry the FIDO or ISO 30107 Level 2 certification the SBV expects.
New-device and notification flows
Test first login and login from a new device, and that the customer notification is sent on the right events.
Version and patch deadlines
Review installable versions every three months, block downgrades, and set internal deadlines that meet the one-day and monthly rules.
Report and retest
Keep findings, severity, fix dates and retest results as records, and use them in the reports to the SBV and to customers after a data leak.
A suggested list, not an SBV 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 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 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.
- Circular 50/2024/TT-NHNN on security and confidentiality for online services in the banking sectorState Bank of Vietnam, dated 31 October 2024, in force from 1 January 2025, as amended by Circular 77/2025/TT-NHNN. Replaces Circular 35/2016/TT-NHNN and repeals Article 25 of Circular 09/2020/TT-NHNN (Vietnamese text)
- Circular 77/2025/TT-NHNN amending Circular 50/2024/TT-NHNNState Bank of Vietnam, dated 31 December 2025, in force from 1 March 2026, with Articles 3 and 10 applying from 1 July 2026 and 1 October 2026. Adds the OWASP standards, unsafe-device exit rules, version control and biometric liveness certification requirements (Vietnamese text)
- Circular 09/2020/TT-NHNN on information system security in banking operationsState Bank of Vietnam, dated 21 October 2020, in force from 1 January 2021. Articles 40 and 42 to 43 cover secure development, mandatory penetration testing for internet-facing and customer-connected systems, and vulnerability management (Vietnamese text)
- Decision 2345/QD-NHNN on secure solutions for online and card paymentsState Bank of Vietnam, dated 18 December 2023, in force from 1 July 2024. Introduced biometric verification for high-value transfers and new-device use; repealed from 1 January 2025 by Decision 2872/QD-NHNN, with the content carried into Circular 50/2024. Referenced through the Vietnamese Government portal
- Decree 13/2023/ND-CP on personal data protectionGovernment of Vietnam, dated 17 April 2023, in force from 1 July 2023. Consent, security measures, breach notification and impact assessment duties; the 2025 Personal Data Protection Law and its implementing decree took over the framework from 1 January 2026 (Vietnamese text)
- Law on Personal Data Protection, No. 91/2025/QH15National Assembly of Vietnam, adopted 26 June 2025, in force from 1 January 2026. Sensitive personal data including biometrics, cross-border transfer and processing impact assessment duties; Decree 356/2025/ND-CP sets out the details from the same date (Vietnamese text)
- Decree 356/2025/ND-CP detailing the Personal Data Protection LawGovernment of Vietnam, dated 31 December 2025, in force from 1 January 2026. Implementing provisions for the processing and protection of personal data (Vietnamese 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.
Test your mobile banking app the way the SBV 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.