Bank of Thailand mobile banking rules: assess your mobile banking app against the minimum standards.
The Bank of Thailand's mobile banking security notification sets minimum standards for banking apps: no embedded links in customer messages, one account on one device, face comparison with presentation attack detection above 50,000 baht, anti-tampering checks and blocks on rooted devices. The IT risk notification adds an annual penetration test for internet-facing systems, and the PDPA sets the duties for customer data. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Checks root and jailbreak detection, anti-tampering, session handling and certificate pinning, and what the app does when they trigger
- Tests login, one-time codes and the face-verification step-up above the 50,000 baht threshold with your test accounts
- Follows the app into its APIs, even with TLS pinning
- Finds keys, tokens and personal data left in the app package, storage, caches and logs
- Who it applies to
- Banks and state financial institutions under BOT supervision, and e-Money providers with mobile apps; personal data duties under the PDPA apply to all of them
- Key date
- Mobile Banking Security notification No. 4/2568 published on 7 February 2025, in force 30 days later; technology crime standards effective 8 August 2025
- Focus
- Mobile banking app security, face verification for high-value transfers, device checks, annual penetration tests and PDPA duties
- Main reference
- Bank of Thailand Notification No. 4/2568 (Mobile Banking Security)
The BOT texts behind your mobile channel
The mobile banking security notification sits alongside the IT risk notification, the technology crime standards and the PDPA. The dates below are for the texts cited on this page.
- 1 June 2022
PDPA in force
The Personal Data Protection Act B.E. 2562 (2019) becomes fully effective, with security duties for personal data and breach notification to the PDPC without delay and within 72 hours.
- 16 October 2023
IT risk notification
Notification No. สกช. 5/2566 replaces the 2019 IT risk rules. Internet-facing systems, including mobile banking and internet banking, need a penetration test at least once a year and after significant change.
- 7 February 2025
Mobile Banking Security
Notification No. 4/2568 is published in the Royal Gazette. It sets minimum security standards for banking apps and enters into force 30 days after the day following publication, and 60 days for the operating-system risk clause. Notifications No. 17/2568 and No. 18/2568 carry the same measures to state financial institutions and e-Money mobile applications.
- 8 August 2025
Technology crime standards
Notification No. 19/2568 takes effect: no links in customer messages, one account on one device, face verification thresholds, anti-tampering, blocks on risky apps and a customer hotline, under the Emergency Decree on Technology Crime Prevention.
- 17 December 2025
Digital fraud management
Notification No. 57/2568 takes effect, replacing the 2023 fraud policy for financial service providers. It covers end-to-end fraud management, including authentication matched to customer risk, transaction alerts and default daily limits. The monitoring and loss handling stay with your fraud teams.
- 23 July 2026
Digital Channel Security consultation
The BOT opens consultation on a draft Digital Channel Security notification. It would extend the rules to internet banking and non-bank providers and phase out SMS one-time codes for transaction authentication. Comments closed on 24 August 2026. The draft is not in force.
- Every year
Penetration testing
Systems connected to public networks, such as mobile banking and internet banking, go through a penetration test by independent internal or external experts at least once a year, and after significant changes.
The BOT's mobile banking rules, applied to your 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. The Bank of Thailand texts are in Thai and are summarised here.
- IT Risk Notification No. สกช. 5/2566, 6.6 and 6.7 (Thai text)
Test internet-facing systems at least once a year
What the text says
Assess vulnerabilities of every system according to its risk level. For critical systems, run the assessment at least once a year and whenever there is a significant change. Run a penetration test by independent internal or external experts, covering the systems and networks connected to public networks, at least once a year and after significant changes. The BOT may order an additional test by an independent external expert if the report, scope or methods are not adequate.
Source:IT Risk Notification No. สกช. 5/2566, 6.6 and 6.7 (Thai text)
What it means for your mobile app
Your mobile banking app and its APIs are internet-facing systems. The yearly test is a named expectation, and it covers systems and networks, not only the app you can see.
How Ostorlab helps
An AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding. 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
Choosing the independent testers for the annual test, and deciding whether their report covers the app and APIs.
- IT Risk Notification No. สกช. 5/2566, 7.2; IT Risk Management Implementation Guideline, 2.7.2 (Thai text)
Test before go-live and build security in
What the text says
Design, develop and test systems so they keep data confidential, remain reliable and stay available. Security testing should include a vulnerability assessment of the system, and where the system connects to an external network, a penetration test by external experts before it starts service. Review the source code independently whenever a critical transaction part is developed or changed. Keep development, testing and production environments separate, and sign off test results before go-live.
What it means for your mobile app
Every release of your banking app is a change to an internet-facing system. The security tests belong to the release process, not to a yearly exercise you do afterwards.
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, and both run from your CI/CD pipeline on every build.
What stays with you
Source code review for critical transaction changes, environment separation, sign-off and release approval.
- IT Risk Notification No. สกช. 5/2566, 6.6, 6.10 and the third party rules (Thai text)
Manage vulnerabilities, patches and third parties with deadlines
What the text says
Run a vulnerability management process for every system, with a frequency that matches its risk. Keep a patch management process for systems and devices, and complete security patches within a time that matches the vulnerability risk and the system importance. Where the vendor has not released a patch, put compensating controls in place, and use a formal exception process when a patch cannot be installed. Manage third parties that provide IT services, connect to your IT systems or can reach customer data, with due diligence and audit rights.
Source:IT Risk Notification No. สกช. 5/2566, 6.6, 6.10 and the third party rules (Thai text)
What it means for your mobile app
The SDKs and native libraries inside your app are software you ship. Each one needs a known version, a severity when a vulnerability appears, and a fix deadline you can prove.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Findings are rated, tracked as tickets and retested once the fix ships.
What stays with you
Patching servers and infrastructure, vendor contracts, exception approvals and risk acceptance decisions.
- Mobile Banking Security Notification No. 4/2568, 5.3.2(2) (Thai text)
Harden the app against tampering and old versions
What the text says
Maintain and improve the app to international standards and new threats. Ask only for the app permissions you need, and review them at every significant change. Do not serve old app versions that may carry vulnerabilities. Check for tampering every time the customer opens the app, and do not let a modified app run. Manage the computer session to prevent session hijacking, and obfuscate the source code so it cannot be read easily.
Source:Mobile Banking Security Notification No. 4/2568, 5.3.2(2) (Thai text)
What it means for your mobile app
Tampering, session hijacking and readable code are the base an attacker builds on. Each of these protections is a behaviour you can test against a modified build and a live session.
How Ostorlab helps
Mobile Shielding Scan attempts bypasses of root and jailbreak detection, anti-tampering and instrumentation, shows what the app does next, and gives you a hardening score. Authenticated testing covers session handling.
What stays with you
The version policy for old releases, permission requests and the choice of hardening products.
- Mobile Banking Security Notification No. 4/2568, 5.3.2(3); Technology Crime Notification No. 19/2568, 4.2.1(5) (Thai text)
Block rooted, jailbroken and risky device environments
What the text says
Do not let the app run on rooted or jailbroken devices. Do not let it run while risky applications are active, such as unnecessary accessibility services, remote control apps, or apps that can hide or steal what is on the screen. Avoid serving mobile banking on operating systems that an accepted security body such as Thailand Banking Sector CERT (TB-CERT) considers at risk. If you still serve those devices, warn the customer and cap transfers at 5,000 baht per day. When a new vulnerability appears, close it within a suitable timeframe or by a deadline the BOT sets.
What it means for your mobile app
Payment malware on a customer's phone is the threat these clauses target. Detection that does not stop the workflow is not enough, and forced-update and OS support policies are part of the control.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments and with overlays, attempts the bypasses and shows whether the app blocks the workflow, refuses to start or keeps running.
What stays with you
Deciding the OS support policy, the customer warnings and the limits applied to risky devices.
- Mobile Banking Security Notification No. 4/2568, 5.3.2(1) (Thai text)
Protect data at rest, in transit and on screen
What the text says
Avoid storing important customer data on the mobile device, and if you must store it, encrypt it to an accepted standard and destroy it when no longer needed. Show sensitive information only as far as necessary, mask passwords, and hide the screen when the app goes to the background. Use secure protocols and prove the server with certificate pinning or an equivalent method, and encrypt important data at the application layer so it cannot be intercepted or changed in transit.
Source:Mobile Banking Security Notification No. 4/2568, 5.3.2(1) (Thai text)
What it means for your mobile app
What the app writes to storage, shows on screen and sends over the network is where customer data leaks. All three are concrete, testable behaviours.
How Ostorlab helps
Ostorlab looks for tokens and personal data in local storage, caches, logs and screenshots, checks for screen masking and background blurring, and intercepts traffic even with TLS pinning to inspect what travels to the backend.
What stays with you
Data classification, key management on the backend and retention rules.
- Mobile Banking Security Notification No. 4/2568, 5.3.1(4); Technology Crime Notification No. 19/2568, 4.2.1(3) (Thai text)
Verify high-value transfers with face comparison
What the text says
Add a customer verification step for mobile banking transactions using face comparison with presentation attack detection that resists photos, videos and spoofed biometrics, for example liveness detection. The step is required for transfers of 50,000 baht or more in one transaction, cumulative transfers reaching 200,000 baht within one day, and requests to raise the daily transfer limit to 50,000 baht or more. Customers who cannot use face comparison, such as visually impaired customers, need a documented alternative with risk controls.
What it means for your mobile app
The threshold sits in the flow, not in a policy document. The server has to require the face step on the transaction, and the limit increase is a step-up event of its own.
How Ostorlab helps
Authenticated testing covers login, limit changes, transfers and step-up flows with your test accounts, including the API calls the app makes when it triggers the face step.
What stays with you
The biometric product, liveness calibration, the exemption process for customers who cannot use it, and the customer notices.
- Mobile Banking Security Notification No. 4/2568, 5.3.1(3) and (5); Technology Crime Notification No. 19/2568, 4.2.1(2) (Thai text)
Keep one account on one device and cap the limits
What the text says
Limit mobile banking to one user account per mobile banking service per institution, and to one mobile device. The limit applies per application when an institution runs more than one. Set a maximum daily withdrawal and transfer limit for each customer risk group; for customers under 15 years old the combined limit is no more than 50,000 baht per day. Where a customer asks to lift the limit, prove their identity and review the reason against clear criteria.
What it means for your mobile app
Device binding and the daily limits are server-side rules. If an old device, a copied session or a limit increase request can bypass them through the app or the API, the control is not real.
How Ostorlab helps
Authenticated testing checks device binding, session invalidation after a device change and the API calls behind limit changes, with your test accounts.
What stays with you
The risk groups, the limit values, and the exception process for customers who ask for more.
- Mobile Banking Security Notification No. 4/2568, 5.3.1(1) and (2); Technology Crime Notification No. 19/2568, 4.2.1(1) and 5 (Thai text)
Stop phishing links and answer fake apps
What the text says
Do not send links in SMS messages or email to customers. On social media, avoid links that ask for authentication or personal data. A link may be sent only when the customer asks for it each time, with a clear message that it is a one-off reply to their request. Monitor the official app stores for apps that fake or imitate yours, and have a response process with owners, takedown steps and timeframes, including for fake apps outside the stores. Keep a hotline for customers to report technology crime, in and outside business hours.
What it means for your mobile app
Phishing starts in the channels customers trust. The controls are a link policy you can verify in the messages you send and a takedown process you can rehearse.
How Ostorlab helps
Ostorlab tests the app and the APIs behind its account and payment flows for abuse that follows a phishing link, such as credential stuffing, session replay and broken authorization.
What stays with you
The messaging policy, the takedown process for fake apps and the customer hotline.
- Personal Data Protection Act B.E. 2562 (2019), section 37, and the PDPC notification on security measures B.E. 2565 (2022) (Thai text)
Meet the PDPA duties for personal data
What the text says
Use appropriate security measures to prevent loss, unauthorised access, use, change or disclosure of personal data, with organisational, technical and physical measures that match the risk, including access control and the ability to audit access. Notify the PDPC of a personal data breach without delay and within 72 hours of becoming aware of it, unless the breach carries no risk to individuals, and notify affected people when the risk is high. The security standard set by the PDPC notification is a floor that applies on top of the BOT rules.
What it means for your mobile app
Customer data leaves the bank through the app, its SDKs and its logs. A breach of that data starts the 72-hour clock, and app testing is how you find the exposures before someone else does.
How Ostorlab helps
Ostorlab looks for personal data and credentials in the app package, storage, caches, logs and screenshots, and reports what the app and its SDKs send to which backends.
What stays with you
Records of processing, the breach response plan, the 72-hour notification to the PDPC and the notices to data subjects.
Summary of public Bank of Thailand and PDPC texts, checked on 27 September 2026. The BOT texts are in Thai and are summarised here. The draft Digital Channel Security notification is not in force and is described as a draft. This page is not legal advice.
The BOT rules, control by control
The controls the BOT 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 test of internet-facing systemsIT Risk 6.7 | 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 |
| Security testing before go-live and on changeIT Risk 6.6, 7.2 | Mobile SAST on the binary and Mobile DAST on the running app, in CI/CD on every build. Details | Scan results per build, with decompiled source context, traffic and screenshots |
| Vulnerable components, patches and third-party SDKsIT Risk 6.6, 6.10 | 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 |
| Anti-tampering, session handling and obfuscationMobile Banking Security 5.3.2(2) | Modifies the binary, hooks the app and attempts to bypass tamper checks and session protections. Details | Evidence of which protections held and which were bypassed |
| Rooted, jailbroken and risky device environmentsMobile Banking Security 5.3.2(3) | Runs the app in rooted and jailbroken environments and with overlay or remote-control apps present. Details | Hardening score, and bypass evidence for each protection that failed |
| Certificate pinning and the APIs behind the appMobile Banking Security 5.3.2(1.3) | 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 |
| Keys and credentials in the app packageMobile Banking Security 5.3.2(1.1) | 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 |
| Data on the device: storage, caches, logs and screenshotsMobile Banking Security 5.3.2(1.1) and (1.2) | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks masking and background blurring. Details | File system evidence showing what was written, where and when |
| Face verification and step-up above the thresholdsMobile Banking Security 5.3.1(4) | Logs in with your test accounts and tests the transfer, limit and step-up flows, and the API calls behind them. Details | Findings on the step-up flows, with reproduction steps |
| One account, one device and daily limitsMobile Banking Security 5.3.1(3), (5) | Tests device binding, session invalidation after a device change and the API calls behind limit changes. Details | Session and device-binding findings, with request and response logs |
Ostorlab tests controls in the app and its APIs. Fraud monitoring, the customer hotline, incident response and reporting, remediation of devices and operating systems, risk-group decisions, breach notification to the PDPC, backups and recovery, governance and physical security stay with your teams.
BOT controls to test in your mobile app
A practical list for security and technology risk teams, based on the mobile banking security notification, the technology crime standards and the IT risk notification.
Annual test
Put the app and its internet-facing APIs in the yearly penetration test, and test again after significant changes.
Before go-live
Add a vulnerability assessment and, for internet-facing systems, an independent penetration test to the release process, with results signed off before go-live.
App hardening
Run the app as a modified build and check anti-tampering, root and jailbreak detection, session handling and blocking of old versions.
Risky devices
Test with accessibility, remote-control and screen-capture apps present, and check what the app does when the device is rooted or the OS is on the TB-CERT risk list.
Data and credentials
Look for keys, tokens and personal data in the app package, storage, caches, logs and screenshots, and check certificate pinning and app-layer encryption.
Face verification
Test that transfers of 50,000 baht or more, 200,000 baht cumulative in a day, and limit increases trigger face comparison on the server.
One account, one device
Verify device binding, session invalidation after a device change and the daily limits for each risk group.
Components and patches
Keep a versioned list of SDKs and native libraries, set patch deadlines by risk, and retest when a fix ships.
A suggested list, not a BOT 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.
- ประกาศธนาคารแห่งประเทศไทย ที่ 4/2568 เรื่อง การรักษาความมั่นคงปลอดภัยของการให้บริการทางการเงินและการชำระเงินบนอุปกรณ์เคลื่อนที่ สำหรับสถาบันการเงินBank of Thailand Notification No. 4/2568 on Mobile Banking Security for financial institutions. Signed 31 January 2025, published in the Royal Gazette on 7 February 2025. In force 30 days after the day following publication, and 60 days for the operating-system risk clause. Thai text
- ประกาศธนาคารแห่งประเทศไทย ที่ 17/2568 เรื่อง การรักษาความมั่นคงปลอดภัยของการให้บริการทางการเงินและการชำระเงินบนอุปกรณ์เคลื่อนที่ สำหรับสถาบันการเงินเฉพาะกิจBOT, published in the Royal Gazette on 7 August 2025. The same mobile banking security measures for state financial institutions. Thai text
- ประกาศธนาคารแห่งประเทศไทย ที่ 18/2568 เรื่อง การรักษาความมั่นคงปลอดภัยของการให้บริการทางการเงินและการชำระเงินบนอุปกรณ์เคลื่อนที่ สำหรับผู้ประกอบธุรกิจบริการเงินอิเล็กทรอนิกส์ที่ให้บริการ e-Money Mobile ApplicationBOT, published in the Royal Gazette on 7 August 2025. The same measures for e-Money mobile applications, with the one-account one-device limit applied per application. Thai text
- ประกาศธนาคารแห่งประเทศไทย ที่ 19/2568 เรื่อง มาตรฐานและมาตรการเพื่อป้องกันอาชญากรรมทางเทคโนโลยีสำหรับสถาบันการเงินBOT, dated 25 July 2025, published in the Royal Gazette on 7 August 2025, in force from 8 August 2025. Anti-fraud standards for banking apps: no links, one account on one device, face verification thresholds, anti-tampering, blocks on risky apps and a customer hotline. Thai text
- ประกาศธนาคารแห่งประเทศไทย ที่ สกช. 5/2566 เรื่อง หลักเกณฑ์การกำกับดูแลความเสี่ยงด้านเทคโนโลยีสารสนเทศ (Information Technology Risk) ของสถาบันการเงินและสถาบันการเงินเฉพาะกิจBOT, dated 16 October 2023, announced by letter of 9 November 2023 with the IT Risk Management and Third Party Risk Management implementation guidelines. Annual penetration testing for internet-facing systems, patch deadlines and secure development. Thai text
- ประกาศธนาคารแห่งประเทศไทย ที่ 57/2568 เรื่อง หลักเกณฑ์การบริหารจัดการภัยทุจริตดิจิทัล (Digital Fraud Management)BOT, dated 4 December 2025, published in the Royal Gazette on 16 December 2025, in force from 17 December 2025. End-to-end digital fraud management for financial service providers, replacing the 2023 fraud policy for them. Thai text
- Personal Data Protection Act B.E. 2562 (2019)Thailand, in force since 1 June 2022. Section 37 security measures and breach notification without delay and within 72 hours, and the PDPC notifications on security measures and breach notification, B.E. 2565 (2022). English translation published by the PDPC
- Consultation Paper: หลักการของการรักษาความมั่นคงปลอดภัยของการให้บริการทางการเงินผ่านช่องทางดิจิทัล (Digital Channel Security)BOT, July 2026, open for comment from 23 July to 24 August 2026. Draft requirements only: internet banking in scope, SMS one-time codes phased out for transactions, credit card and credit providers added. Not in force
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 BOT describes it
Start with a free scan of your app from the store, or book a demo to run shielding and logged-in tests of your app and APIs with our team.