A Compliance Officer’s Guide to BNM RMiT and Asia’s Mobile Banking Rules
Most technology risk programmes in banking are mature at the perimeter and thin at the edge. Network controls are documented, access reviews are scheduled, penetration tests are booked. Then someone asks what protects the banking mobile app itself once it is installed on a customer’s phone, and the answer arrives less confidently.
That question is now an explicit supervisory expectation across most of Asia and the EU. This guide sets out what the rules actually ask for, what an examiner will want to see, and where the evidence comes from.
What Non-Compliance Currently Costs
Before the requirements, the enforcement record. BNM RMiT compliance is not a paper exercise, and the regulator has been demonstrating that with money.
Sources: Bank Negara Malaysia enforcement announcements (2024, 2025); Regulation (EU) 2022/2554 (DORA); IBM Cost of a Data Breach Report 2025.
The Malaysian figures deserve a precise reading, because precision is the point. In August 2024, BNM imposed an administrative monetary penalty of RM4.32 million on one domestic banking group after repeated unplanned downtime on its mobile banking platform breached the availability thresholds in the RMiT policy document. A second institution was penalised in the same action. In July 2025, BNM imposed a further RM7.29 million across three more institutions, again citing the RMiT policy document among the instruments breached. All of these are published enforcement actions, and any compliance team can locate them in minutes.
Those penalties were for availability failures, not mobile app security failures. That is exactly why they matter: BNM has already shown it will convert a single RMiT paragraph into a seven-figure ringgit penalty.
The regulator’s own language has been unambiguous. BNM stated that it expects all financial institutions to maintain a high level of technology resilience and that it will not hesitate to take supervisory and enforcement action when institutions fall short. The banking mobile app control measures sit in the same policy document as the availability thresholds, under the same enforcement powers.
Elsewhere the exposure scales with the balance sheet. Under DORA, in force across the EU since January 2025, financial entities face fines of up to 2% of total annual worldwide turnover, with daily penalties of up to 1% of average daily turnover for continuing non-compliance. In Singapore, the Financial Services and Markets Act gives MAS consolidated penalty powers over breaches of its notices. And the commercial cost sits underneath all of it: IBM’s 2025 research puts the average financial services breach at USD 5.56 million, second only to healthcare, with incidents taking longer than 200 days to contain costing over a million dollars more than those contained faster.
What BNM RMiT Actually Requires of a Banking Mobile App
RMiT is a broad technology risk document, and its mobile provisions are easy to miss inside it. The current version took effect on 28 November 2025, and the reissue renumbered the clauses, so control themes are more durable references than paragraph numbers.
Stripped to what applies to a banking mobile app, RMiT expects five things.
The app resists reverse engineering and tampering. Control measures for digital services address protection of the application against unauthorised modification and analysis. In practice this means mobile app hardening: obfuscation, code and data encryption, and integrity verification of the shipped binary.
The app detects compromised devices. Rooted and jailbroken operating systems, emulators and instrumentation frameworks must be identified, with a defined response. A detection that logs but does nothing will be questioned.
Credentials are never stored in the application. PINs, passwords and authentication secrets must not be retained on the device in retrievable form. This is one of the most commonly failed items in assessment, and one of the easiest for an examiner to verify independently.
Security is built in before release, not after. Secure development requirements mean vulnerabilities are identified pre-release, through mobile application security testing rather than post-incident discovery.
Security events are logged, retained and produceable. Detections must generate records that survive long enough to be reviewed, with controlled access to them.
The Same Five Controls, Five Rulebooks
If you operate in more than one market, the useful discovery is how little the substance varies. The instruments differ, the language differs, the control set barely moves.
The Risk Management in Technology policy document, current version effective 28 November 2025, with control measures for digital services set out across its appendices. Enforced through administrative monetary penalties under the FSA, IFSA and DFIA, with a published track record of use.
The Technology Risk Management Guidelines, alongside the legally binding Notice on Cyber Hygiene, covering secure application development, protection of customer-facing digital services and incident reporting on a compressed clock. Penalty powers consolidated under the Financial Services and Markets Act.
Supervisory Policy Manual guidance on electronic banking and mobile malware risk, expecting authorised institutions to protect mobile applications against tampering and malware, and to detect compromised device environments. Supervisory rather than penalty-led, but examined closely.
Circular 982 on information security management as amended by Circular 1140, requiring application security controls specific to electronic services, with the 2025 circulars adding fraud management, enhanced authentication and restrictions on operating in unsecured device environments.
The Digital Operational Resilience Act, applicable since 17 January 2025, covering ICT risk management, resilience testing and third-party oversight, with the heaviest penalty regime of the group at up to 2% of global annual turnover.
The practical consequence for a multi-market institution is worth stating plainly. You are not running five compliance programmes for your banking mobile app. You are running one control set and producing evidence in five formats.
Mapping Controls to Evidence
The gap that costs institutions time in examination is rarely the control. It is the evidence. An examiner does not accept that a banking mobile app is hardened; they ask to see what was applied, to which build, when, and by whom.
| Control expected | Where it appears | Evidence an examiner asks for |
|---|---|---|
| Resistance to reverse engineering | RMiT digital services controls · MAS TRM secure development · BSP application security · OWASP MASVS | The protection policy applied per app, plus a decompilation result showing what is and is not recoverable |
| Anti-tampering and anti-repackaging | RMiT mobile application controls · HKMA SPM · BSP e-service controls | A demonstration on a device: a modified build refusing to run, and the log entry it generated |
| Compromised environment detection | RMiT rooted and jailbroken device controls · MAS TRM · BSP unsecured device restrictions | Detection coverage list, configured response per condition, and evidence it works offline |
| No credentials stored on device | RMiT prohibition on storing PINs and passwords · MAS TRM data protection · local privacy law | Static analysis output for the current release, plus your key rotation record |
| Pre-release vulnerability testing | RMiT secure development · MAS TRM secure SDLC · BSP IT risk management · DORA resilience testing | Scan results per build from the CI/CD pipeline, with remediation tracked to closure |
| Logging, retention and access control | RMiT security event logging · MAS TRM monitoring · DORA incident reporting | Retained detection logs, retention period, and the role-based access model over them |
The question that ends most mobile app examinations is simple. Show me, on a device, that a modified copy of your app does not run, and show me the record it created when it tried.
Three Banking Mobile App Findings That Recur in Examination
Detection without response. The app identifies a rooted device and writes a log entry, then continues to operate normally. The control exists on paper and does nothing in practice. Every detection needs a defined, documented action.
Protection that drifted. Hardening was applied at launch, then a release went out without it because the step lived in someone’s manual checklist. If protection is not part of the automated build, it will eventually be skipped, and the release it was skipped on is the one that gets examined.
Credentials removed but never revoked. A secret is stripped from the current version while the old version remains downloadable and the key remains live. Removing is not revoking, and examiners increasingly check prior releases.
Where SecIron Fits
SecIron builds the banking mobile app controls these frameworks ask for, and the records that evidence them. We work with banks and financial institutions across the region, including in markets governed by BNM RMiT, MAS, HKMA and BSP.
Evidence that testing happened before release
IronScan runs static and dynamic assessment against OWASP, CVE and CWE inside your CI/CD pipeline, covering the pre-release testing expectation in RMiT, MAS TRM, BSP and DORA. Findings arrive with remediation guidance, and every build produces a dated report you can hand to an examiner.
The controls themselves, applied to every build
IronWall delivers mobile app hardening against the first three control families directly: layered code protection and obfuscation with three-layer encryption for reverse engineering protection, anti-tampering and anti-repackaging for integrity, and RASP for root, jailbreak, emulator, hooking, injection and debugger detection that continues to work offline.
It applies to the compiled binary in the build process, with no SDK and no source code changes, so protection cannot drift out of a release. Deployment is available on-premise, which keeps application binaries inside your own perimeter and removes a chain-of-custody question before your auditor raises it. Explore IronWall →
The logs your examiner will ask to see
IronSky records every detection in real time with attack source tracing and device fingerprinting, giving you retained, reviewable evidence with role-based access over it. This is the control family most institutions can describe and fewest can demonstrate.
For the technical background behind these controls, see What Is Mobile App Hardening? A Complete Guide for Security Teams.
Conclusion
The banking mobile app is now one of the more scrutinised items in a technology risk programme, and one of the least evidenced. The controls themselves are well defined and consistent across BNM RMiT, MAS TRM, HKMA guidance, BSP circulars and DORA. What separates a clean examination from a finding is usually whether the institution can produce, on a device and on request, proof that the controls are live in the build that shipped.
Institutions that automate the control and the record together stop preparing for examinations, because the evidence is generated as a by-product of shipping.
Ready to meet your banking standards?
Talk to us about what BNM RMiT, MAS TRM, BSP or DORA requires of your banking mobile app, and what evidence you would need to produce tomorrow. We will map your current release against the control families above and show you what hardening changes, with no source code changes required to find out.
Recent Posts
A Compliance Officer’s Guide to BNM RMiT and Asia’s Mobile Banking Rules
September 10, 2026
What Hackers See When They Decompile Your App
September 3, 2026
Solutions
Resource
About Us