Bank Negara Malaysia's RMiT: test your mobile banking app the way BNM describes it.
BNM's Risk Management in Technology policy document asks financial institutions for a quarterly vulnerability assessment of the network components that support critical systems, an annual intelligence-led penetration test that covers digital services including mobile, and controls for the app itself: a tamper-proof environment, device binding, MFA stronger than unencrypted SMS, and transaction-bound codes generated on the customer's device. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Checks root and jailbreak detection, anti-tampering and pinning, and what the app does when they trigger
- Tests login, one-time codes, step-up checks and session handling with your test accounts
- Follows the app into its APIs, even with TLS pinning
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Licensed banks, insurers, takaful operators, e-money issuers, payment system operators, merchant acquirers and remittance institutions regulated by BNM
- Key dates
- RMiT issued and effective on 28 November 2025; the text was reissued on 25 September 2026 with the NCII code of practice
- Focus
- Mobile app and API security, vulnerability assessment and penetration testing, authentication and fraud controls
- Main reference
- Risk Management in Technology (RMiT) policy document, BNM/RH/PD 028-98
The BNM texts behind your mobile channel
The RMiT policy document consolidates earlier e-banking and fraud specifications into one text. The dates below are for the texts cited on this page.
- September 2022
Five fraud countermeasures
BNM announces five key fraud countermeasures and a kill switch, including migration from SMS OTP to more secure authentication, tighter fraud detection rules, a cooling-off period for first-time enrolments and single-device binding for authentication.
- 1 January to 1 June 2025
PDPA amendments take effect
The Personal Data Protection (Amendment) Act 2024 comes into operation in three stages: 1 January, 1 April and 1 June 2025. The new data breach notification duty and the data protection officer appointment start on 1 June 2025.
- 31 October 2025
Customer information policy
BNM issues the Management of Customer Information and Permitted Disclosures policy document, effective the same day and superseding the version issued on 3 April 2023.
- 28 November 2025
RMiT, revised
The revised RMiT policy document takes effect, consolidating the e-banking and fraud specifications into one text. It supersedes the RMiT issued on 1 June 2023.
- 1 July 2026
RMiT FAQ updated
BNM updates its FAQ on the RMiT policy document, clarifying how institutions should read the revised clauses.
- 25 September 2026
NCII code of practice
BNM reissues the RMiT text with Appendix 12, the code of practice for banks designated as national critical information infrastructure entities under the Cyber Security Act 2024.
- Every quarter and every year
Testing cadence
Quarterly vulnerability assessments of the network components behind critical systems, annual intelligence-led penetration tests that cover mobile and external-facing applications, and an independent compromise assessment every three years.
The BNM 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.
- RMiT Appendix 4, Control Measures for Mobile Applications and Devices, paragraphs 1 and 2
Secure the mobile app and the device it runs on
What the text says
A financial institution must be aware of the risks associated with mobile applications and continuously assess them. Digital services involving sensitive customer information on mobile devices must be adequately secured: design the app to operate in a secure and tamper-proof environment, such as one that is not compromised, jailbroken or rooted; prohibit the app from storing customer information used for authentication with the application server, such as PINs and passwords, and centralise authentication and verification of keys and PINs at the host; make activation of the app subject to robust authentication; ensure secure provisioning and deprovisioning; and use reputable application distribution platforms.
Source:RMiT Appendix 4, Control Measures for Mobile Applications and Devices, paragraphs 1 and 2
What it means for your mobile app
Root and jailbreak detection, tamper resistance and where credentials live are named controls, not nice-to-haves. The checks have to hold at runtime, on the build customers download.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments, attempts to bypass root and jailbreak detection, anti-tampering and pinning, and shows whether the app blocks the workflow, refuses to start or keeps running. Ostorlab also looks for PINs, tokens and personal data in local storage, caches, logs and screenshots.
What stays with you
The choice of shielding product, the secure provisioning process and monitoring the app stores for fake applications.
- RMiT Appendix 3, Control Measures for Digital Services, paragraphs 4, 5, 6, 7 and 9
Use MFA stronger than unencrypted SMS, with codes generated on the device
What the text says
For financial and high-risk non-financial transactions, including registering a favourite beneficiary and all subsequent transfers to it, a financial institution must adopt multi-factor authentication, prompt users to verify the transaction details, and send timely notifications. The MFA must resist phishing, interception and manipulation, and the channels used must be more secure than unencrypted SMS. Where OTP is used, it must be dynamic and time-bound, bound to the transaction details, and generated from the customer's device and not from the bank's server. Institutions must also offer cryptographic key-based authentication, such as a digital certificate or passwordless, as an alternative to passwords.
Source:RMiT Appendix 3, Control Measures for Digital Services, paragraphs 4, 5, 6, 7 and 9
What it means for your mobile app
The second factor has to be enforced by the server on every financial transaction, and the code has to travel with the beneficiary and amount it approves. SMS alone no longer meets the text.
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. Ostorlab completes SMS, email or TOTP one-time codes with your test accounts and tests how the flows behave when a step is skipped or replayed.
What stays with you
Choosing and deploying the MFA and passkey or certificate methods, and managing the migration away from SMS OTP for your customer base.
- RMiT Appendix 3, Control Measures for Digital Services, paragraph 3
Bind the device and protect changes to customer details
What the text says
Registration and updates of mobile device and customer details used for authentication, such as mobile number, email and postal address, must be strengthened so that fraudsters cannot use stolen credentials to move funds. The controls include secure binding and unbinding of one mobile or secure device per account holder by default; immediate alerts when the account is accessed from a new device or when customer details change; robust verification before a new or replacement mobile number is registered; a cooling-off period for first-time enrolment and for abnormal transaction patterns; and verification for transaction limit increases.
Source:RMiT Appendix 3, Control Measures for Digital Services, paragraph 3
What it means for your mobile app
Phone number and email changes are the step scammers need before account takeover. The change, the alert and the cooling-off period all have to be enforced by the backend, not just shown in the app.
How Ostorlab helps
Ostorlab tests the API calls behind device registration, contact-detail changes, beneficiary registration and limit changes, including whether a second factor is required and whether the cooling-off or limit rules can be bypassed through the API.
What stays with you
The verification and cooling-off procedures themselves, and the alerting channels.
- RMiT Appendix 5, Control Measures on Cybersecurity, Part E: Application Programming Interface (API) Security, paragraph 1
Assess and harden your APIs
What the text says
API security must be commensurate with the potential risks. At a minimum: maintain a centralised API inventory covering all connections and dependencies; design APIs to handle high traffic and mitigate denial of service; follow secure coding practices, including validating third-party code and libraries, robust error handling, input validation and security headers; use robust encryption and key management; deploy anti brute-force mechanisms such as rate limiting and account lockout; implement strong authentication and authorisation; consider an API gateway; conduct periodic security assessments on APIs, including penetration testing and static or dynamic security testing; monitor API usage for suspicious activity; and have a process to revoke access tokens or API keys after a compromise.
What it means for your mobile app
Every API the app calls is in scope, including the ones behind login. Rate limits, lockout and token revocation are behaviours you can test, not just design documents.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
The API inventory, the gateway, API monitoring and the revocation process.
- RMiT Appendix 5, Part D: Vulnerability Assessment and Penetration Test (VAPT), paragraphs 1 to 6; RMiT paragraph 11.6
Run the VAPT cadence BNM sets
What the text says
A financial institution must have standard operating procedures for vulnerability assessment and penetration testing, with oversight of external testers, validation of event logs and data purging. It must perform a quarterly vulnerability assessment of external and internal network components that support all critical systems, and annual intelligence-led penetration tests on its internal and external network infrastructure, critical systems and digital services including web, mobile and all external-facing applications, using extreme but plausible attack scenarios and suitably accredited testers. New systems for new products or services must also be tested before they are introduced. Outcomes are documented and escalated to senior management. An independent compromise assessment is required at least once every three years, and a red team simulation at least once every three years.
What it means for your mobile app
The app and its APIs sit inside the annual intelligence-led test scope, and new digital services get tested before launch. Between those tests, every release is still a change to an internet-facing channel.
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 tracked as tickets and retested once the fix ships, so the app and API items of your remediation plan are closed before the annual test.
What stays with you
Scoping and running the quarterly assessments, the annual intelligence-led penetration test with accredited testers, the compromise assessment and the red team exercise.
- RMiT paragraphs 10.5, 10.6, 10.8, 10.9, 10.10 and 10.12
Build security into the SDLC and test before release
What the text says
The System Development Life Cycle must cover requirements, design, development, testing, deployment, change management, maintenance and decommissioning, and integrate security principles and requirements. Rapid development methods such as DevOps must automate the IT security compliance review and the discovery and testing of security vulnerabilities. System testing before deployment must be rigorous, and the scope may include application security testing. Changes to the source code of critical systems must be subject to adequate source code reviews. Where a third party develops or maintains a critical system, contracts must require secure by design principles and continued access to the source code.
Source:RMiT paragraphs 10.5, 10.6, 10.8, 10.9, 10.10 and 10.12
What it means for your mobile app
Every app release is a change to an internet-facing channel. Automated testing in the pipeline covers the before; scans of store releases cover the after.
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 Mobile DAST exercises the running app.
What stays with you
Security requirements, secure coding standards, manual code reviews and release approval.
- RMiT paragraphs 10.15, 10.17 and 10.18
Manage components, patches and end-of-life systems
What the text says
Systems, including digital services, must not run with known security vulnerabilities, on outdated platforms or on end-of-life technology. Institutions must maintain a current security baseline, continuously monitor and apply the latest patch releases in a timely manner, plan remedial action for systems approaching end of life, and get management approval for exceptions. The patch and end-of-life framework must set criteria, priority and turnaround time by the severity of the vulnerabilities identified. For third-party software, BNM encourages a Software Bill of Materials and an open-source software security policy, including robust testing of open-source software and timely vulnerability assessment.
What it means for your mobile app
The libraries and SDKs 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. Mobile SAST and SCA list the SDKs and native libraries in each release with their versions, and findings are rated critical, high, medium or low and tracked as tickets.
What stays with you
Patching servers and infrastructure, vendor maintenance contracts and risk acceptance decisions.
- Management of Customer Information and Permitted Disclosures, paragraphs 10.12, 10.26, 10.31, 11.8, 11.19, 11.20 and 11.25; Personal Data Protection (Amendment) Act 2024, section 12B
Protect customer information and handle breaches
What the text says
The Management of Customer Information and Permitted Disclosures policy document requires preventive and detective ICT controls against theft, loss, misuse or unauthorised access, modification or disclosure of customer information, access controls at application, database, operating system and network level, controls for information collected off-site and in transit, and secure disposal. A customer information breach that poses reputational risk, causes or is likely to cause significant harm, or involves a large number of customers must be reported to BNM immediately, investigated within three months, and reported to BNM within one working day after it is tabled to the board. Affected customers must be notified without undue delay. The PDPA amendments add the same duty to the Personal Data Protection Commissioner, with breach notification and data protection officer appointments effective from 1 June 2025.
What it means for your mobile app
Personal data written to the phone, its caches, logs or screenshots is part of your breach surface, and the APIs that carry it are where access control has to hold.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, and checks for misconfigurations that weaken transport and session protections. Each finding comes with file system or request and response evidence you can keep.
What stays with you
Data classification, key management, breach investigation, and notification to BNM, the Commissioner and customers.
- RMiT paragraphs 10.47, 10.48 and 10.49; Personal Data Protection (Amendment) Act 2024, section 5
Manage third parties and what they put in your app
What the text says
Before onboarding a third party, and throughout the engagement, a financial institution must conduct due diligence and maintain a service level agreement covering access rights, confidentiality, incident notification, business continuity and exit. It must formulate a roadmap to continuously monitor a third party's cybersecurity posture, measure the IT infrastructure footprint and customer information accessible to third parties, and incorporate third-party protocols into incident response. Under the PDPA amendments, the security principle now applies to data processors as well as data controllers.
Source:RMiT paragraphs 10.47, 10.48 and 10.49; Personal Data Protection (Amendment) Act 2024, section 5
What it means for your mobile app
A mobile banking app bundles third-party SDKs that talk to their own backends and may process personal data. They belong in your inventory, your third-party risk view and your processor agreements.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, and shows what the app and its SDKs exchange with backends over the network. It does not run third-party continuous monitoring.
What stays with you
Due diligence, contracts, the monitoring roadmap and processor agreements.
- RMiT Appendix 12, Code of Practice for NCII Entities, paragraphs 11.3.2 to 11.3.6
If you are designated as an NCII entity, meet the code of practice
What the text says
Banks designated by BNM as national critical information infrastructure entities under the Cyber Security Act 2024 must comply with Appendix 12 of the RMiT, which forms their code of practice. It requires cyber security guidelines for software and system development covering secure coding practices aligned with the OWASP Top 10, access control mechanisms within applications and requirements for regular updates and patches, enforced across the SDLC and third-party acquisitions. Security testing must be conducted during development, followed by penetration testing before deployment to a production or public-facing environment, including vulnerability scans, penetration tests and validation against secure coding guidelines.
Source:RMiT Appendix 12, Code of Practice for NCII Entities, paragraphs 11.3.2 to 11.3.6
What it means for your mobile app
For designated banks this adds a documented, testable secure development and pre-deployment testing path for the mobile channel.
How Ostorlab helps
Ostorlab maps to those pre-deployment checks: Mobile SAST on the build, Mobile DAST on the running app, SCA on the components, and an AI-agent pentest of the app and its APIs with a replayable exploit for each finding.
What stays with you
The secure coding guidelines, the governance committee approvals and the production deployment decision.
Summary of public BNM texts, checked on 27 September 2026. The RMiT text cited is the current revision, issued on 28 November 2025 and reissued on 25 September 2026. This page is not legal advice.
BNM rules, control by control
The controls the BNM 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 environment, tamper resistance and stored credentialsRMiT Appendix 4 | Modifies the binary, runs the app on rooted and jailbroken devices, injects hooks and attempts to bypass TLS pinning. Details | Evidence of which protections held and which were bypassed, and what the app wrote to storage |
| MFA stronger than unencrypted SMS, with transaction-bound codesRMiT Appendix 3, paragraphs 4 to 7 | Logs in with one-time codes and tests MFA enforcement, step-up flows and the API calls behind transactions. Details | Findings on login, step-up and transaction approval flows, with reproduction steps |
| Device binding and contact-detail changesRMiT Appendix 3, paragraph 3 | Tests the API calls behind device registration, phone and email changes, beneficiary registration and limit increases. Details | Request and response evidence for each bypass attempt |
| API inventory, rate limits, token revocation and periodic assessmentsRMiT Appendix 5 Part E | 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 |
| Quarterly vulnerability assessment and annual intelligence-led pentest of digital servicesRMiT Appendix 5 Part D | AI-agent pentest of the app and its APIs, behind login, on the build you ship, between the annual tests. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Secure SDLC and application security testing before releaseRMiT paragraphs 10.5 to 10.10 | 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 and traffic |
| Known vulnerabilities, patch deadlines and component inventoryRMiT paragraphs 10.15, 10.17 and 10.18 | 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 |
| Credentials embedded in the app packageRMiT Appendix 5 Part E | 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 information on the device and in transitMCIPD paragraphs 10.12, 10.26 and 10.31 | 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 |
| Compromise assessment and red teamingRMiT Appendix 5 Part D.6; RMiT paragraph 11.6 | Ostorlab does not run compromise assessments or red team exercises. It keeps the app and API items of your remediation plan closed and retested. | Retest results for the app and API findings in your remediation plan |
Ostorlab tests controls in the app and its APIs. SOC monitoring, fraud analytics, incident response and reporting, compromise assessment, red teaming, backups and recovery, governance and physical security stay with your teams.
BNM controls to test in your mobile app
A practical list for security and technology risk teams, based on the RMiT policy document and the customer information rules.
Mobile app protections
Run the app on rooted and jailbroken devices, attempt to bypass tamper detection and pinning, and check that PINs and passwords are not stored in the app.
MFA and one-time codes
Verify that MFA is enforced on financial and high-risk non-financial transactions, including favourite beneficiaries, and that codes are dynamic, bound to the transaction and generated on the customer's device.
Device binding and detail changes
Test the single-device default, the alerts on new devices, the robust verification for phone number changes and the cooling-off period.
APIs behind the app
Test authorization, rate limiting, lockout and token revocation on every API the app calls, before each release reaches production.
VAPT cadence
Put the app and its APIs in the annual intelligence-led test scope, test new services before launch, and keep the quarterly assessments running.
Components and deadlines
Keep a versioned list of the SDKs and libraries in each release, an SBOM where useful, and fix deadlines by severity.
Secrets and data on the device
Check the app package for API keys and tokens, and look for personal data in storage, caches, logs and screenshots.
Breach readiness and retest
Keep evidence for each finding, track it to closure, retest after the fix, and align the app's data handling with your MCIPD and PDPA breach procedures.
A suggested list, not a BNM 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.
- Risk Management in Technology (RMiT) policy documentBank Negara Malaysia, BNM/RH/PD 028-98, issued and effective 28 November 2025. The current text, reissued on 25 September 2026, adds Appendix 12, the code of practice for NCII entities. It supersedes the RMiT issued on 1 June 2023 and earlier e-banking and fraud specifications
- Frequently Asked Questions on the RMiT policy documentBank Negara Malaysia, updated 1 July 2026. Interpretations of the RMiT requirements, including the status of clauses marked "G"
- Management of Customer Information and Permitted DisclosuresBank Negara Malaysia, BNM/RH/PD 028-65, issued and effective 31 October 2025. Customer information controls, breach handling and permitted disclosures; supersedes the policy document issued on 3 April 2023
- Personal Data Protection (Amendment) Act 2024 (Act A1727)Laws of Malaysia, Royal Assent 9 October 2024, published in the Gazette on 17 October 2024. Adds the data breach notification duty and the data protection officer appointment, and extends the security principle to data processors
- Personal Data Protection (Amendment) Act 2024: Appointment of Date of Coming into Operation (P.U. (B) 522/2024)Ministry of Digital, gazetted 24 December 2024. The amended provisions come into operation on 1 January, 1 April and 1 June 2025
- Bank Negara Malaysia Annual Report 2023, Promoting Financial StabilityBNM. Records the five key fraud countermeasures and the kill switch announced in September 2022, including migration from SMS OTP to more secure authentication
- Bank Negara Malaysia Annual Report 2025, Promoting Safe & Efficient Payment & Remittance ServicesBNM. Card payment security standards shift away from SMS-based OTP, with SMS OTP retained as a fallback for a limited group of users; e-money issuer controls took effect in January 2025
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app against the BNM controls
Start with a free scan of your app from the store, or book a demo to run shielding and logged-in tests with our team.