Taiwan's FSC and Bankers Association: test your mobile banking app the way the self-regulatory standards describe.
The Bankers Association's mobile app regulations require an annual test pass against the Mobile Application Basic Security Testing Baseline, code scans or black-box testing of the app and its application server, and OWASP MASVS L2 checks. They also require root and jailbreak detection that restricts non-designated transfers, and strict rules on where keys live. The e-banking standard adds session timeouts and transaction trust levels, and the FSC's December 2025 resilience blueprint pushes secure-by-design, software bills of materials and API security. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Runs the app in rooted, jailbroken, emulator and USB debugging environments and shows what the app does next
- Tests login, one-time codes, sessions and the APIs behind them with your test accounts
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Banks, financial holding companies and other financial institutions in Taiwan, including the fintechs the FSC supervises
- Key date
- Mobile app regulations in the version accepted by the FSC on 3 May 2024; e-banking security control standards in the 7 January 2026 version
- Focus
- Annual app testing, OWASP MASVS and Mobile Top 10 coverage, device protections, key storage and API security
- Main reference
- FSC Financial Cybersecurity Resilience Development Blueprint and the Bankers Association's mobile app and e-banking standards
The Taiwan texts behind your mobile channel
The FSC sets the policy and the blueprint; the Bankers Association writes the standards banks follow. The dates below are for the texts cited on this page.
- 27 December 2022
Financial Cybersecurity Action Plan 2.0
The FSC's 40-measure plan introduces digital identity verification with trust levels based on the ISO 29115 structure, alongside information security officers and third-party risk management.
- 3 May 2024
Mobile app regulations amended
The FSC accepts the Bankers Association's amended Regulations for Financial Institutions Providing Mobile Device Applications, with annual app testing, root and jailbreak detection, and key storage rules.
- September 2024
Mobile app security baseline V4.0
The Mobile Application Security Alliance publishes version 4.0 of the testing baseline, with L1, L2, L3 and F levels and references to OWASP MASVS v2.0.
- 11 November 2025
PDPA amendment
The Personal Data Protection Act is amended to add a general security maintenance duty and a broader breach notification regime. The enforcement date is to be set by the Executive Yuan and had not been set as of September 2026.
- 30 December 2025
Resilience blueprint
The FSC publishes the Financial Cybersecurity Resilience Development Blueprint: four axes, 29 measures and a four-year programme from 2026, including secure-by-design, SBOM and an API security baseline.
- 7 January 2026
E-banking standards, 1150107 version
The Bankers Association's Security Control Standards for Electronic Banking Services take effect in their 7 January 2026 version, with trust levels for transactions and a ten-minute session timeout.
- 6 May 2026
Internal control regulations amended
The regulations on internal control and audit systems for financial holding companies and banks are amended, with the information security officer's duties and a compliance deadline of 31 December 2027.
The Taiwan standards, 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. The association standards and the FSC measures are summarised from the Chinese texts.
- 金融機構辦理電腦系統資訊安全評估辦法 第3條至第5條、第8條；金融控股公司及銀行業內部控制及稽核制度實施辦法 第12條、第14條、第24條、第25條 (Chinese text)
Run the annual assessments and keep the evidence trail
What the text says
Classify the computer systems by importance and build an assessment plan for the whole estate, self-built and outsourced. Category 1 systems, which directly provide automated services to customers or materially affect operations, such as e-banking, branch counters, ATMs and SWIFT, need a security assessment at least once a year; a major security incident triggers a fresh assessment within three months. The client application checks include vulnerability scanning, source code scanning or penetration testing, sensitive data protection in memory and storage media, and key protection. The internal control regulations put the programme under the information security officer: a dedicated unit under the general manager, a vice-president-level officer reporting to the board every year, and half-yearly general self-checks for information units.
Source:金融機構辦理電腦系統資訊安全評估辦法 第3條至第5條、第8條；金融控股公司及銀行業內部控制及稽核制度實施辦法 第12條、第14條、第24條、第25條 (Chinese text)
What it means for your mobile app
Your mobile banking app sits inside a Category 1 system, so the annual assessment has to cover the app and the server it talks to, including data left in memory and storage and the keys on the device. The report goes to the audit unit and the board, and it is kept for five years.
How Ostorlab helps
The AI-agent pentest tests the app and its APIs behind login, with a working exploit you can replay for each finding. Mobile SAST analyses the binary, secrets scanning validates keys found in the package, and results are rated and tracked as tickets, so each assessment has fresh evidence per release.
What stays with you
The assessment plan, system classification, assessor qualifications, report approval and the internal control and audit trail.
- 金融機構提供行動裝置應用程式作業規範 第9條 (Chinese text)
Pass the annual baseline test and the OWASP L2 review
What the text says
Every year, take the app through testing by a qualified laboratory under the Mobile Application Security Testing Baseline, and pass it. Also run code scanning or black-box testing of the full functionality of the app and its application server and fix medium and high-risk vulnerabilities, and have an evaluation unit test the app and the server against the mobile app regulations and the OWASP Mobile Application Security Checklist L2. Reports from the laboratory and the evaluation unit must be reviewed and sent to the information security unit. Where a finding cannot be fixed, the information security unit may record it as an accepted risk with the assessment on file.
What it means for your mobile app
This is a fixed annual cycle with named methods: the baseline test, code scanning or black-box testing, and the OWASP L2 list. Medium and high-risk findings need a fix or a documented risk acceptance.
How Ostorlab helps
Ostorlab tests the app and its APIs against the OWASP Mobile Application Security Checklist L2 items, from binary analysis to logged-in flows, and retests after the fix. The results give you evidence for the review the information security unit has to perform.
What stays with you
Booking the qualified laboratory and the evaluation unit, decisions on risk acceptance, and the annual report review.
- 金融機構提供行動裝置應用程式作業規範 第10條 (Chinese text)
Test every change before it goes live
What the text says
When a new feature first goes live, when the system architecture changes, or when an existing feature changes, run code scanning or black-box testing and fix medium and high-risk vulnerabilities. For features related to the movement of funds, or to electronic transfers and transaction instructions that materially affect customers' rights, test against the OWASP Mobile Top 10 and fix medium and high-risk findings before the release goes live. If an emergency release is unavoidable, fix within a set period and keep controls in place until the fix ships.
What it means for your mobile app
Every release is a change event. Money movement features get the stricter OWASP Mobile Top 10 treatment and cannot go live with medium or high-risk findings.
How Ostorlab helps
Ostorlab runs automated scans from your CI/CD pipeline on every build and monitors store releases without manual triggers. Mobile SAST works on the APK, AAB or IPA with no source code needed, and the AI-agent pentest covers the transfer flows behind login.
What stays with you
Change classification, release approval and the controls for emergency releases.
- 金融機構提供行動裝置應用程式作業規範 第5條、第15條；行動應用App基本資安檢測基準 V4.0, 4.1.5.5 (Chinese text)
Handle compromised devices and protect the runtime
What the text says
When the app starts, if it detects a device that looks compromised, such as root, jailbreak or USB debugging, it must warn the user and restrict non-designated transfers and transaction instructions. When the app is used as the transaction re-confirmation mechanism for corporate high-risk transactions, the regulations require anti-intrusion measures (avoid compromised devices, verify app and library integrity, prevent screen overlay, resist reverse engineering), runtime protection (prevent repackaging and eavesdropping, block unauthorised code, block screenshots and extended screens, detect emulators, warn on debug mode) and sensitive data protection (memory and files, device-protected keys, anti-cloning). The testing baseline makes root and jailbreak detection, obfuscation, emulator detection, USB debugging detection and debug mode part of its optional F-class tests.
Source:金融機構提供行動裝置應用程式作業規範 第5條、第15條；行動應用App基本資安檢測基準 V4.0, 4.1.5.5 (Chinese text)
What it means for your mobile app
Detection alone is not enough: the app has to warn and restrict, and the protections have to survive a real bypass attempt, not just exist in the code.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted, jailbroken, emulator and USB debugging environments, attempts to bypass root detection, anti-tampering and TLS pinning, and shows whether the app blocks the workflow, refuses to start or keeps running. You get bypass evidence and a hardening score.
What stays with you
The policy for compromised devices and the choice and configuration of your shielding product.
- 金融機構提供行動裝置應用程式作業規範 第11條至第14條；金融機構辦理電子銀行業務安全控管作業基準 第6條 (Chinese text)
Store keys and one-time codes the way the regulations require
What the text says
Keys stored on the mobile device must sit either in a secure element that meets CNS 15408 EAL5, Common Criteria ISO/IEC 15408 v2.3 EAL5 or FIPS 140-2 Level 3 or higher, or be protected in software with white-box cryptography and code obfuscation, confirmed by an evaluation unit. When a key operation such as an OTP or TAC is used for transfers to non-designated accounts, the key must be confirmed to be on the customer-designated device. Downloads of sensitive data over the air need the user's identity confirmed and end-to-end encryption between the bank and the app. Keys held in a secure element need access control limited to trusted applications, and NFC payment data needs manual confirmation by the user. The e-banking standard applies its digital identity trust levels to the same flows.
Source:金融機構提供行動裝置應用程式作業規範 第11條至第14條；金融機構辦理電子銀行業務安全控管作業基準 第6條 (Chinese text)
What it means for your mobile app
The app has to prove where the key lives and that the customer's device is the one holding it. White-box crypto without obfuscation, or an OTP generated anywhere else, does not meet the text.
How Ostorlab helps
Ostorlab finds API keys, tokens and credentials in the app package and validates whether they work, inspects how keys and sensitive values are stored and protected on the device, and intercepts traffic, even with TLS pinning, to test the OTP and transfer flows with your test accounts.
What stays with you
Choosing the secure element or white-box design, the key lifecycle and the device binding process.
- 金融機構辦理電子銀行業務安全控管作業基準 第7條至第9條、第11條 (Chinese text)
Apply the e-banking standard to the mobile channel
What the text says
Mobile application systems provided to customers must follow the mobile app regulations. Internet-facing application systems must control sessions and cut a connection after ten minutes of inactivity, avoid injection and cross-site scripting flaws, and protect fixed passwords from being captured through embedded browsers. Transactions are split by risk: high-risk transactions, including non-designated transfers above the low-risk limit, need the highest trust level, and corporate high-risk transactions need additional measures such as transaction re-confirmation by two people, limits and immediate notification. Third-party data transmission and outsourced services must be covered by contracts that require compliance with the standard.
What it means for your mobile app
The ten-minute timeout, the login and transaction trust levels and the protection against embedded browser capture are concrete behaviours of the app and the backend behind it.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, including step-up flows, together with the API calls behind them. The AI-agent pentest tests the business logic of transfer flows.
What stays with you
Choosing the trust level for each service, transaction limits, corporate re-confirmation design and third-party contracts.
- 金融資安韌性發展藍圖 (Financial Cybersecurity Resilience Development Blueprint), measures 7 to 9, December 2025 (Chinese text)
Build security in, know your components, and secure the APIs
What the text says
The FSC's December 2025 blueprint encourages financial institutions to adopt secure software development, testing and deployment, with reference to NIST SSDF, OWASP SAMM and OWASP ASVS: risk assessment or threat modelling at the design stage, security controls embedded in development, and SAST and DAST tools integrated into the release pipeline. It also asks for software composition analysis to identify components, including open-source and third-party ones, produce a software bill of materials, and link it to vulnerability databases such as CVE or the CISA KEV catalogue, with a vulnerability monitoring and version update mechanism. A further measure develops an API security baseline covering partner and internal APIs, classified by data sensitivity, building on the OWASP API Security Top 10.
What it means for your mobile app
The app's SDKs and native libraries are the components the blueprint is talking about, and the APIs the app calls fall in scope of the coming API baseline. Per-release component data is the practical way to answer it.
How Ostorlab helps
Mobile SAST and DAST run in CI/CD on every build. SCA fingerprints statically compiled libraries, maps them to known vulnerabilities and lists the components and versions in each release. API testing checks authorization, token misuse and abuse such as enumeration and replay.
What stays with you
SDLC policy, threat modelling, the API inventory and governance, and decisions on version upgrades.
- 金融機構提供行動裝置應用程式作業規範 第3條、第4條、第7條、第8條 (Chinese text)
Control the release and watch for fake apps
What the text says
The release process for the app must be controlled by at least two people or two technical controls. Before each release, check that the permissions the app asks for match the service it provides, and have the information security, compliance and risk units approve the first release or any change in permissions, including the notices required under the Personal Data Protection Act. Publish the app's name, version and download location on the official website, and keep a mechanism to detect fake versions of the app and take them down or alert customers.
What it means for your mobile app
Permissions, release approval and clone detection are all app-level controls that can be checked against the build you publish.
How Ostorlab helps
Ostorlab lists the permissions the app requests and the SDKs and native libraries it contains, and monitors store releases so a new version does not slip through untested.
What stays with you
Release approval, the legal notices, takedown of fake apps and customer communication.
- 金融機構資通系統與服務供應鏈風險管理規範 第2條、第6條、第7條 (Chinese text)
Manage the SDKs and suppliers you ship
What the text says
The supply chain standard applies to core and Category 1 systems, and to other systems that provide internet-facing services, let suppliers reach sensitive data, or cost NT$10 million or more. Contracts must require suppliers to deliver systems and programs free of malware and backdoors, with security test results or a security commitment for the products and components they provide. Banks keep audit rights, must run security audits of key suppliers, and must review the security test results of what suppliers deliver during the contract.
What it means for your mobile app
A mobile banking app bundles third-party SDKs that talk to their own backends. They are suppliers in the text's sense, and their components belong in the security test results you review.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, maps them to known vulnerabilities, and shows what the app and its SDKs exchange with backends over the network.
What stays with you
Supplier contracts, due diligence, audit rights and risk acceptance.
- 個人資料保護法 第12條、第21條、第27條；金融監督管理委員會指定非公務機關個人資料檔案安全維護辦法 第6條、第9條、第10條、第13條、第14條 (Chinese text)
Protect personal data and be ready to notify
What the text says
Under the Personal Data Protection Act, a non-government agency that holds personal data files must take appropriate security measures to prevent theft, tampering, damage, loss or leakage, and must notify affected individuals after an infringement is investigated. The FSC's maintenance measures for the financial sector add the details: device and media rules, encryption and protected backups; for e-commerce service systems, user identity verification, data masking, secure internet transmission encryption, software verification and validation at development, go-live and maintenance, access control and monitoring for personal data files and databases, and monitoring of abnormal use; a security audit mechanism inside internal control; and records kept for at least five years. A major personal data incident must be reported to the FSC within 72 hours. The Act was amended on 11 November 2025 to add a general security maintenance duty and a broader breach notification regime, but the enforcement date had not been set by the Executive Yuan as of September 2026.
Source:個人資料保護法 第12條、第21條、第27條；金融監督管理委員會指定非公務機關個人資料檔案安全維護辦法 第6條、第9條、第10條、第13條、第14條 (Chinese text)
What it means for your mobile app
Passwords, tokens and personal data should never sit in clear text on the phone or travel unprotected to the backend, and the app should not log or expose them where other apps can read them.
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 whether the app can reach other customers' data through its APIs.
What stays with you
Data classification, breach response and notification, retention records and the security audit.
Summary of public Taiwan texts, checked on 27 September 2026. The Bankers Association standards and the FSC's personal data measures are summarised from the Chinese texts. The PDPA amendment of 11 November 2025 is not yet in force. This page is not legal advice.
Taiwan's rules, control by control
The controls the Taiwan 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 security assessment of Category 1 systems資訊安全評估辦法 第4條、第5條 | AI-agent pentest of the app and its APIs, behind login, on the build you ship, plus binary analysis and secrets scanning for the client application checks. Details | A working exploit you can replay for each AI-agent finding, scan results per build, and a coverage heatmap |
| Testing before go-live and on changes行動裝置應用程式作業規範 第10條 | 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 and USB debugging detection行動裝置應用程式作業規範 第5條、第15條 | Runs the app in compromised, emulator and debugging environments and attempts to bypass the protections. Details | Bypass evidence and a hardening score for each protection that failed |
| Keys, OTP secrets and key storage行動裝置應用程式作業規範 第11條至第14條 | Finds keys and credentials in the app package, validates whether they work, and checks how keys are stored and protected on the device. Details | Validated secrets, with the permissions and services they expose |
| Transaction trust levels and device binding電子銀行安控基準 第7條、第8條 | Logs in with one-time codes and tests MFA enforcement, step-up flows and the API calls behind transfers with your test accounts. Details | Findings on login and step-up flows, with reproduction steps |
| Session control and the ten-minute timeout電子銀行安控基準 第9條 | Tests login and logout, token refresh, timeouts, session invalidation and WebView protections. Details | Session and token findings, with request and response logs |
| Component inventory and SBOM韌性藍圖 measure 8 | Fingerprints statically compiled libraries, maps them to known vulnerabilities and lists components per release. Details | Component identity, version and location in the app bundle, per release |
| API security baseline for partner and internal APIs韌性藍圖 measure 9 | 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 |
| Data protection on the device and in transit個資法 第27條；金管會安維辦法 第9條、第10條 | 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 |
| Prioritised findings, risk acceptance and retests行動裝置應用程式作業規範 第9條 | Groups findings into tickets in the platform or in Jira and ServiceNow, retests after the fix, and keeps the risk acceptance record where a fix is not possible. | Ticket history and retest result for each finding |
Ostorlab tests controls in the app and its APIs. The annual laboratory test under the Mobile Application Security Testing Baseline, SOC monitoring, incident response and reporting, cyber exercises, backups and recovery, governance and physical security stay with your teams.
Taiwan's controls to test in your mobile app
A practical list for security and system risk teams, based on the Bankers Association standards and the FSC blueprint.
Assessment plan
Put the mobile app inside your Category 1 assessment plan, with the annual cadence and the three-month re-assessment rule after a major incident.
Baseline and OWASP L2
Book the qualified laboratory test and the OWASP Mobile Application Security Checklist L2 review, and fix or formally accept medium and high-risk findings.
Change testing
Test every new feature and architecture change before go-live, and run the OWASP Mobile Top 10 on transfer-related features.
Device protections
Run the app on rooted, jailbroken and debug-enabled devices, and check that it warns and restricts non-designated transfers as the text requires.
Keys and OTPs
Verify where the keys live, that white-box crypto is paired with obfuscation, and that the key is bound to the customer-designated device.
Sessions and WebView
Check the ten-minute timeout, session invalidation, and the protections against embedded browser capture, injection and cross-site scripting.
Components and APIs
Keep a component list with versions for every release, and test authorization and token handling on every API the app calls.
Data and reporting
Keep personal data out of storage, caches, logs and screenshots, and keep evidence for the self-checks, the annual report and the 72-hour notification duty.
A suggested list, not a Bankers Association 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.
- 金融資安韌性發展藍圖 (Financial Cybersecurity Resilience Development Blueprint)FSC, published 30 December 2025, document dated December 2025. Four axes and 29 measures over four years from 2026, including secure software development (measure 7), software supply chain transparency and SBOM (measure 8) and an API security baseline (measure 9). It succeeds the Financial Cybersecurity Action Plan 2.0. Chinese text
- 金融機構辦理電子銀行業務安全控管作業基準 (Security Control Standards for Electronic Banking Services of Financial Institutions)Bankers Association, 1150107 version of 7 January 2026, passed by the association on 26 June 2025 and accepted by the FSC with letter 金管銀國字第1140223782號. Trust levels for transactions, session control, WebView protections and third-party contracts. Chinese text
- 金融機構提供行動裝置應用程式作業規範 (Regulations for Financial Institutions Providing Mobile Device Applications)Bankers Association, version accepted by the FSC with letter 金管銀國字第1130209228號 of 3 May 2024, after the association passed it on 25 January 2024. Annual app testing, device protections, key storage and corporate re-confirmation. Chinese text
- 行動應用App基本資安檢測基準 V4.0 (Mobile Application Basic Security Testing Baseline V4.0)Mobile Application Security Alliance, September 2024. Levels L1, L2, L3 and F with 25, 31, 39 and 9 test items, referencing OWASP MASVS v2.0. The related specification, 行動應用App基本資安規範 V1.5, was published in March 2026. Chinese text
- 金融機構辦理電腦系統資訊安全評估辦法 (Regulations for Information Security Assessment of Computer Systems)Bankers Association, last amended 22 March 2018 with FSC letter 金管銀國字第10702710050號. Annual assessment of Category 1 systems, client application checks including memory, storage media and keys, and five-year records. Chinese text
- 金融機構資通系統與服務供應鏈風險管理規範 (Supply Chain Risk Management Standard for Information Systems and Services)Bankers Association, version accepted by the FSC with letter 金管銀國字第1150201525號 of 13 February 2026. Supplier security test results, malware and backdoor clauses, and audit rights. Chinese text
- 金融控股公司及銀行業內部控制及稽核制度實施辦法 (Regulations Governing the Implementation of Internal Control and Audit Systems of Financial Holding Companies and Banks)Amended 6 May 2026. Information security unit under the general manager, a vice-president-level information security officer reporting to the board, half-yearly self-checks, and a compliance deadline of 31 December 2027 for the amended governance items. Chinese text
- 個人資料保護法 (Personal Data Protection Act) and the FSC's maintenance measuresAct amended 11 November 2025, with new security maintenance and breach notification provisions whose enforcement date is to be set by the Executive Yuan and had not been set as of September 2026. The FSC's 指定非公務機關個人資料檔案安全維護辦法, last amended 14 December 2021, sets the 72-hour notification of major incidents and the e-commerce security measures. Chinese 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 Taiwan's standards describe
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.