HKMA e-banking rules: assess your mobile banking app before and after every release.
Module TM-E-1 of the HKMA Supervisory Policy Manual asks banks to run a rigorous independent assessment before launching or changing an e-banking channel, and to have qualified parties penetration-test internet banking and services delivered over the internet or a wireless network at least annually, on top of two-factor authentication for high-risk transactions. Since 2025 the E-Banking Security ABCD measures push banks to move logins and high-risk transactions to in-app authentication through a bound device instead of SMS one-time passwords. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the mobile app and the APIs it calls, on the build your customers download
- Tests login, one-time codes, step-up checks, device binding and session handling 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
- All authorized institutions (AIs) supervised by the HKMA. AIs designated as critical infrastructure operators also face statutory duties under the PCICSO
- Key dates
- TM-E-1 V.4 issued on 25 October 2024; E-Banking Security ABCD from 25 August 2025; the PCICSO in force since 1 January 2026
- Focus
- Independent assessment and annual penetration tests, mobile app controls, two-factor and in-app authentication, and C-RAF 2.0 cyber resilience testing
- Main reference
- HKMA Supervisory Policy Manual, module TM-E-1 "Risk Management of E-banking" (V.4)
The HKMA texts behind your mobile channel
TM-E-1 and the e-banking circulars sit alongside the cyber risk and operational resilience modules of the Supervisory Policy Manual, and since 2026 the PCICSO. The dates below are for the texts cited on this page.
- 3 November 2020
Cybersecurity Fortification Initiative 2.0
The HKMA upgrades its Cyber Resilience Assessment Framework and adds blue-team requirements to intelligence-led cyber attack simulation testing (iCAST). CFI 2.0 takes effect on 1 January 2021, with assessments phased across three groups of AIs.
- 31 May 2022
OR-2 Operational Resilience
SPM module OR-2 sets out the framework: identify critical operations, set a tolerance for disruption, and test severe but plausible scenarios, including failures at a third party or within its supply chain.
- 25 October 2024
TM-E-1 V.4
The current Risk Management of E-banking module is issued as a statutory guideline under section 7(3) of the Banking Ordinance: independent assessment before launch, annual penetration tests, 2FA for high-risk transactions, and specific controls for internet banking accessed via mobile devices.
- 29 November 2024
TM-C-1 cyber risk supervision
The HKMA issues its Supervisory Approach on Cyber Risk Management, confirming the C-RAF and iCAST as central tools for assessing and raising AIs' cyber defence maturity.
- 14 April 2025
E-Banking Security ABC
The HKMA expects customers with mobile banking apps to authenticate internet banking logins and high-risk transactions in-app through a bound device by default, instead of SMS one-time passwords. Device binding and re-binding move to facial recognition, and the implementation timeline runs from Q2 to Q4 2025.
- 25 August 2025
E-Banking Security ABCD
Deepfake detection is added to the framework, with immediate effect. The annex sets out good practices: strengthen device security, randomise liveness checks, add image analytics and monitor abnormal digital footprints.
- 1 January 2026
PCICSO in force
The Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653) comes into operation, imposing three categories of statutory obligations on designated critical infrastructure operators.
- 2 June 2026
Sectoral Code of Practice for AIs
The Monetary Authority's Code of Practice for AIs designated as critical infrastructure operators comes into operation, setting the baseline for the security management plan, the annual risk assessment with vulnerability assessment and penetration test, and the two-yearly audit.
The HKMA e-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. Section numbers and wording follow the HKMA's English documents.
- SPM TM-E-1, 3.3.1 to 3.3.3
Independent assessment and annual penetration tests
What the text says
As part of e-banking risk governance, senior management must ensure a rigorous independent assessment is performed before the launch of any new electronic delivery channel or a major enhancement to an existing service, validating that the service complies with applicable guidance and that sufficient risk management controls are actually in place. If the independent assessment policy does not include penetration tests, regular tests must be performed by qualified independent parties, assessing at a minimum the AI's internet banking and any financial services delivered over the internet or via a wireless network annually. A formal risk assessment is also expected at least annually.
Source:SPM TM-E-1, 3.3.1 to 3.3.3
What it means for your mobile app
A mobile banking app is an e-banking channel. The independent assessment, the annual penetration test and the annual review of emerging vulnerabilities should all cover it, including the APIs it calls.
How Ostorlab helps
Ostorlab runs an AI-agent pentest of the app and its APIs behind login, Mobile SAST on the APK, AAB or IPA, and runtime protection tests, repeatable on demand, so the same evidence is produced before launch, annually and on every release.
What stays with you
Choosing assessors, running the formal risk assessment and resolving material issues before launch.
- SPM TM-E-1, 7.1.1 to 7.1.4
Assess the mobile channel and its specific risks
What the text says
Internet banking accessed via mobile devices carries specific risks: security vulnerabilities of mobile platforms, malware or malicious apps that capture sensitive customer information, re-direct or conceal notifications or one-time passwords, or mislead customers into unauthorised transactions, loss or theft of devices, and lower customer security awareness. AIs should identify and assess those risks and put in place the relevant security measures, run customer education programmes for mobile devices, and make ongoing efforts to identify fake banking apps and notify customers. Where customers receive or generate one-time passwords on the same device they use for banking, additional security controls are required.
Source:SPM TM-E-1, 7.1.1 to 7.1.4
What it means for your mobile app
The app itself is in scope, not just the backend. Overlay malware, notification interception, tampering and fake apps are mobile-specific threats that your controls need to address.
How Ostorlab helps
Mobile SAST inspects the binary and its embedded SDKs, Mobile Shielding Scan tests root and jailbreak detection, anti-tampering and pinning at runtime, and the AI-agent pentest exercises the app and its APIs the way a fraudster would.
What stays with you
Fake app monitoring in the stores, customer education and your policy for devices that also receive one-time passwords.
- SPM TM-E-1, 4.1.1 to 4.1.8; circular "New Anti-Digital Fraud Measures: E-Banking Security ABC", 14 April 2025, Annex
Two-factor authentication and in-app authentication by default
What the text says
For internet banking, AIs should require two-factor authentication at least once to authenticate customers' identity for each login session before performing high-risk transactions, which include funds transfers to unregistered third-party payees, certain bill payments, and transfers of benefits or reward points to third parties. If a high-risk transaction is assessed to be suspicious, for example a large-value transfer shortly after device binding, an additional confirmation is expected. From 2025 the HKMA expects customers with mobile banking apps to authenticate internet banking logins and high-risk transactions through a bound device by default instead of SMS one-time passwords. New device binding and re-binding should use facial recognition or similarly stringent methods rather than SMS one-time passwords, with a cooling-off period and tightened fraud monitoring for high-risk transactions where SMS one-time passwords are still allowed.
What it means for your mobile app
The second factor has to be enforced by the server at every key step, and bound-device authentication changes how the app registers and trusts a device. Both are behaviours you can test.
How Ostorlab helps
Authenticated testing covers login and logout, one-time codes, step-up and in-app authentication flows, and the API calls behind them, with your test accounts.
What stays with you
Deploying bound-device authentication and facial recognition, the cooling-off rules, and customer communication.
- SPM TM-E-1, 4.4.1 to 4.4.3 and 5.3.3; circular "Enhancement to security of electronic banking services", 31 October 2023, item 8
Session controls and account activity tools
What the text says
For internet banking, AIs should put in place effective session management controls that disallow concurrent logins to an e-banking account unless there is a genuine need, and log key data about additional login attempts such as IP address, device type and geographical location. Customers should be able to review and monitor account activities, including login date and time, geographical location and device information, and search for high-risk activities over a reasonably long period, normally not less than 90 days. AIs should also offer an accessible channel to seek help and a mechanism to suspend an e-banking account promptly, with stringently authenticated reactivation.
What it means for your mobile app
Concurrent login handling, timeouts, token invalidation, the activity review screens and the suspension flow are testable behaviours, and the logs they produce are evidence.
How Ostorlab helps
Ostorlab tests login and logout, token refresh, timeouts and session invalidation, including concurrent login attempts, and checks what the app and its APIs write to storage, caches and logs.
What stays with you
The customer-facing activity tools, the suspension mechanism and log retention.
- SPM TM-E-1, 5.2.1 and 5.4.1 to 5.4.3; SPM TM-G-1, 3.4.1 and 5.3.1
Vulnerability assessment, threat monitoring and patch management
What the text says
AIs should run a systematic monitoring process for emerging security threats to their internet infrastructure, application systems and other components, and use automated tools, supplemented by manual techniques where needed, to perform periodic vulnerability assessment of internet infrastructure and internet banking systems, addressing the findings on a risk-based approach. Patch management procedures should cover systems and infrastructure components. TM-G-1 expects clear responsibilities so that patches and security updates are identified, assessed, tested and applied in a timely manner, and a hardware and facility inventory to control and track the hardware and software purchased and leased.
Source:SPM TM-E-1, 5.2.1 and 5.4.1 to 5.4.3; SPM TM-G-1, 3.4.1 and 5.3.1
What it means for your mobile app
The SDKs and native libraries inside your app are software you ship to customers, and the vulnerable component list can change with every release.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release after release. 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
Infrastructure scanning, patching servers and devices, and risk acceptance decisions.
- SPM TM-E-1, 5.3.1 and 5.3.2; sectoral Code of Practice under the PCICSO, 6.2.22
Secure development and source code review
What the text says
AIs should maintain an adequate level of application system security for their internet banking systems, including any apps, covering at least application design and development, testing and implementation, with reference to sound industry practices. Before launching an internet banking system or system changes, an adequate source code review should be performed to identify non-compliance with application security standards, code that may pose security threats or loopholes, and any malicious code. The review should be conducted by a party with relevant expertise who is independent of the developers. The PCICSO sectoral code adds a secure development process and protection of source code for critical computer systems.
Source:SPM TM-E-1, 5.3.1 and 5.3.2; sectoral Code of Practice under the PCICSO, 6.2.22
What it means for your mobile app
The review has to happen before release and also cover the third-party components that end up in the app bundle.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA binary with taint analysis across the app and its embedded SDKs, so code issues are found even when only the store build is available.
What stays with you
Secure coding standards, code ownership, and manual review of your own source.
- Circular "Managing cyber risk associated with third-party service providers", 21 December 2023; circular "Risk Associated with Third-party IT Solutions", 27 September 2024
Manage cyber risk from third-party services and software
What the text says
The HKMA shared a set of sound practices for managing cyber risk associated with third-party service providers, covering governance, due diligence, contractual controls and ongoing monitoring. After a global IT incident caused by a faulty update of a cybersecurity solution provider, the HKMA reminded AIs to manage third-party dependencies: testing of updates before deployment, control over automatic updates without user choice, and operational resilience against the failure of third-party IT solutions, including for AIs that rely on them for critical services.
What it means for your mobile app
A mobile banking app is assembled from third-party SDKs and services. Their update cycle and their failure modes are part of your risk, not only your vendor's.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and location in the app bundle, and shows what the app and its SDKs exchange with backends over the network. Retests show whether a vendor fix actually closed the issue.
What stays with you
Contracts, due diligence, vendor monitoring and the decision to keep or replace a provider.
- SPM TM-C-1, 3.5; circular "Cybersecurity Fortification Initiative 2.0", 3 November 2020; SPM OR-2, 4.3 and 7; circular "Strengthening Cyber Resilience amid Artificial Intelligence-Empowered Cyber Threats", 2 June 2026
C-RAF 2.0, iCAST and scenario testing
What the text says
Under the Cybersecurity Fortification Initiative, AIs assess themselves through the Cyber Resilience Assessment Framework: an inherent risk assessment, a maturity assessment, and for AIs with a medium or high inherent risk rating, intelligence-led cyber attack simulation testing (iCAST) that simulates real-life attacks. C-RAF 2.0 added blue-team requirements to iCAST, to measure detection, response and recovery functions. TM-C-1 confirms the C-RAF as the HKMA's tool for assessing whether cyber defence maturity is commensurate with risk. OR-2 separately expects scenario testing of severe but plausible disruptions, including failures at a third party or within its supply chain. In June 2026 the HKMA asked AIs to check whether their controls remain fit for purpose against frontier AI-capable attacks and to review the cyber resilience of third-party service providers.
What it means for your mobile app
iCAST is a whole-institution exercise run by qualified parties, not a mobile app scan. Closed app and API issues are the groundwork that keeps known weaknesses out of it.
How Ostorlab helps
Ostorlab does not run iCAST or other red-team exercises. It keeps the app and API items of your remediation plan closed and retests them, so wider assessments start from a cleaner base.
What stays with you
Scoping and running C-RAF and iCAST with qualified assessors, the blue-team exercise, and operational resilience scenario testing.
- Sectoral Code of Practice under the PCICSO, 2 June 2026, 6.3.4 to 6.3.7 and 6.4; PCICSO (Cap. 653), sections 24 and 25
PCICSO: statutory risk assessment, penetration test and audit
What the text says
Since 1 January 2026 the Protection of Critical Infrastructures (Computer Systems) Ordinance places statutory obligations on designated operators, and the Monetary Authority has issued a sectoral Code of Practice for AIs it designates as critical infrastructure operators. The computer-system security risk assessment must include all applications, hosts and network devices of the critical computer systems, and must include a vulnerability assessment and a penetration test. The penetration test should be carried out from the position of a potential attacker or based on threat intelligence, and cover network security, system software security, client-side application security and server-side application security. The first assessment is due within 12 months of designation and at least once every 12 months afterwards, with an independent audit at least once every 24 months. Reports must set out each finding with its priority and a treatment plan with timelines and responsible parties.
What it means for your mobile app
Client-side application security is explicitly named, so the mobile app is in scope of the statutory test, and each finding needs evidence and a tracked treatment plan.
How Ostorlab helps
Ostorlab tests the app and its APIs and produces per-finding evidence: replayable exploits, request and response logs, component inventories and retest results you can attach to the assessment report.
What stays with you
Appointing the qualified assessor and the independent auditor, network and infrastructure testing, and submitting the reports.
- SPM TM-E-1, 4.3.1, 4.4.5 and 5.1.1; Personal Data (Privacy) Ordinance (Cap. 486), Data Protection Principle 4
Protect customer data on the device and in transit
What the text says
AIs should adopt secure, internationally recognised strong encryption to protect customer information transmitted over external networks and highly sensitive information such as login credentials kept in storage, with sound key management practices. Customers should be warned of their obligations to take reasonable precautions to protect their devices and authentication factors. The SPM reminds AIs of the need to comply with the Personal Data (Privacy) Ordinance, under which data users must take all practicable steps to protect personal data against unauthorised or accidental access, processing, erasure, loss or use.
What it means for your mobile app
Tokens, credentials and personal data should not sit in clear text in app storage, caches, logs or screenshots, and transport protections should hold under attack.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections and pinning bypass, and finds secrets and credentials in the app package.
What stays with you
Data classification, key management, privacy notices, retention and breach handling.
Summary of public HKMA texts and the PCICSO sectoral code, checked on 27 September 2026. Section numbers and wording follow the English documents. This page is not legal advice.
HKMA rules and the PCICSO, control by control
The controls the HKMA 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 |
|---|---|---|
| Independent assessment and annual penetration testsTM-E-1 3.3 | 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 |
| Mobile channel risk assessment and runtime protectionsTM-E-1 7.1 | Binary SAST and runtime shielding tests for root, jailbreak, tampering and pinning. Details | Per-release component and protection findings, with bypass results |
| 2FA, in-app authentication and device bindingTM-E-1 4.1; ABC circular, Annex | Logs in with one-time codes and bound devices and tests step-up flows, including how they can be skipped or replayed. Details | Findings on login, step-up and binding flows, with reproduction steps |
| Session controls and concurrent loginsTM-E-1 5.3.3; circular of 31 October 2023 | Tests login and logout, token refresh, timeouts, session invalidation and concurrent login attempts. Details | Session and token findings, with request and response logs |
| Vulnerable components and fix deadlinesTM-E-1 5.4; TM-G-1 3.4.1 | Fingerprints statically compiled libraries, including native SDKs, and maps them to known vulnerabilities. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Secure development and source code reviewTM-E-1 5.3.1, 5.3.2 | Mobile SAST with taint analysis across the app and its embedded SDKs, on the APK, AAB or IPA. Details | Code-level findings with their location in the binary and the data path |
| Credentials embedded in apps and APIsTM-E-1 4.1.1; CoP 6.2.22 | 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 |
| Customer data on the device and in transitTM-E-1 4.3.1, 4.4.5, 5.1.1; PDPO | 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 |
| PCICSO risk assessment and penetration test evidenceSectoral CoP 6.3, 6.4 | Tests the app and APIs, tracks each finding to closure and retests, so your assessor can reuse the evidence. Details | Ticket history and retest results per finding, ready for the treatment plan |
| Preparation for C-RAF and iCASTTM-C-1 3.5; CFI 2.0 | Ostorlab does not run iCAST. It closes and retests the app and API items in your remediation plan. | Retest results for the app and API items before the exercise |
Ostorlab tests controls in the app and its APIs. SOC monitoring, incident response and reporting, exercises, iCAST and other red-team tests, backups and recovery, governance and physical security stay with your teams.
HKMA controls to test in your mobile app
A practical list for security and system risk teams, based on TM-E-1, the e-banking circulars and the PCICSO sectoral code.
Independent assessment
Put the mobile app, its APIs and the pre-launch review in the scope of the independent assessment, and keep the annual penetration test on the calendar.
Mobile-specific threats
Test for root and jailbreak, overlay and tampering, notification interception, screen capture and fake app detection on each release.
In-app authentication
Verify that bound-device authentication is enforced by the server for logins and high-risk transactions, and that any SMS one-time password fallback gets the cooling-off and monitoring the circulars expect.
Device binding
Test new binding and re-binding flows, including facial recognition steps, replay attempts and skipped checks.
Sessions
Check concurrent login rejection, timeouts, token invalidation, and the account activity history and suspension tools customers can see.
Components and deadlines
Keep a versioned list of the SDKs and libraries in each release, and set fix deadlines by severity.
Third parties
Map what each SDK and third-party backend receives, and re-test vendor fixes instead of trusting them.
Report, retest and keep evidence
Track findings to closure, keep retest results, and reuse them in PCICSO assessment reports and treatment plans.
A suggested list, not an HKMA 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, step-up and in-app authentication 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.
- Supervisory Policy Manual TM-E-1: Risk Management of E-banking (V.4)HKMA, 25 October 2024. Statutory guideline under section 7(3) of the Banking Ordinance. Independent assessment, annual penetration tests, 2FA, customer protection, and internet banking accessed via mobile devices (7.1)
- Supervisory Policy Manual TM-G-1: General Principles for Technology Risk Management (V.1)HKMA, 24 June 2003. Non-statutory guidance note. Authentication and access control, system security and patch management, and system development and change management; cited by the 2026 PCICSO sectoral Code of Practice
- Supervisory Policy Manual TM-C-1: Supervisory Approach on Cyber Risk Management (V.1)HKMA, 29 November 2024. Statutory guideline. The Cyber Resilience Assessment Framework and iCAST, incident response and recovery, and the Secure Tertiary Data Backup
- Supervisory Policy Manual OR-2: Operational Resilience (V.1)HKMA, 31 May 2022. Non-statutory guidance note. Critical operations, tolerance for disruption, and severe but plausible scenario testing, including failures at a third party or in its supply chain
- Cybersecurity Fortification Initiative 2.0, circular and AnnexHKMA, 3 November 2020, effective 1 January 2021. C-RAF 2.0, blue-team requirements for iCAST, and the phased assessment timelines for the three groups of AIs
- New Anti-Digital Fraud Measures: E-Banking Security ABC, circular and AnnexHKMA, 14 April 2025. Bound-device authentication by default instead of SMS one-time passwords, facial recognition for device binding and re-binding, and the Q2 to Q4 2025 implementation timelines
- E-Banking Security ABCD, circular and Annex: Good Practices for Countering Deepfake AttacksHKMA, 25 August 2025, immediate effect. Device security controls, randomised liveness checks, image analytics and abnormal footprint monitoring for identity verification
- Code of Practice for AIs designated as critical infrastructure operators under the PCICSOMonetary Authority, 2 June 2026, in operation the same day. Issued under section 8(1)(b) of the Protection of Critical Infrastructures (Computer Systems) Ordinance. Security management plan, annual risk assessment with vulnerability assessment and penetration test, and the 24-month independent audit
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 HKMA 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.