Bank Negara Malaysia (BNM) recently issued an updated Risk Management in Technology (RMiT) policy, replacing a previous version from June 2023. While the update spans a wide range of technology risk requirements, some of the most actionable changes sit in authentication, device binding, and fraud prevention controls.
Financial institutions operating in Malaysia, including banks, insurers, e-money issuers, and payment system operators, need to comply with it. This post breaks down the key authentication related requirements in the updated RMiT, and shows how modern identity and authentication infrastructure can help you meet them.
A bit of context first
BNM has been pushing financial institutions away from SMS OTP since 2022, when the central bank publicly directed major banks to start migrating to more secure authentication methods. The reasoning behind this was, fraudsters had developed tools to intercept and silently delete SMS authentication codes before customers even saw them. SIM-swap attacks allowed criminals to redirect those codes to a device they fully controlled.
In 2024, Malaysian banks collectively blocked over RM 399 million in fraudulent transactions, five times the amount actually lost to online fraud that year. The authentication upgrades worked.
The November 2025 update takes that progress and turns it into law. What was previously guidance or best practice is now a mandatory standard. And the requirements go further than before.
What has changed in the updated RMiT?
BNM's latest update consolidates and strengthens several earlier circulars and specifications, including the 2022 and 2024 fraud countermeasure specifications. The result is a single, comprehensive policy with sharper requirements around how financial institutions authenticate users and protect digital services.
Here are the four authentication areas your team needs to act on.
1. One device per user, by default
ensure secure binding and unbinding processes for restricting authentication of digital service transactions by default to one mobile device or secure device per account holder
RMiT Appendix 3 - Control Measures for Digital Services, paragraph 3(a)
This is a direct response to SIM-swap fraud and account takeover attacks, where fraudsters register a new device to an existing account and then drain it.The "default" framing matters. Customers can opt to use multiple devices, but they must explicitly request this and accept the associated risks. The institution cannot make multi-device the default.Practically, this means your onboarding and authentication flows need to track device registration, enforce a single binding by default, and have a clear, auditable process for customers who request exceptions.
2. Strong verification before a phone number can change
the registration of new mobile phone number or replacement of existing mobile phone number is only processed after applying robust verification methods to confirm the authenticity of the customer
RMiT Appendix 3 - Control Measures for Digital Services, paragraph 3(c)
This sounds simple, but in practice many institutions still allow phone number changes with nothing more than an OTP sent to the current number. That approach fails completely if the current number has already been compromised or the SIM swapped."Robust verification" in BNM's framing means methods that go beyond the channel being changed. Think identity re-verification, step-up authentication using biometrics, or in-branch confirmation for high-risk changes.
3. Cooling-off periods and transaction limits for new devices
apply appropriate verification and cooling-off period for first time enrolment of digital services or secure device and multiple successive high-volume transactions or other abnormal transaction patterns. Transaction limit increase must also be subject to appropriate verification.
RMiT Appendix 3 - Control Measures for Digital Services, paragraph 3(e)
This is a friction-as-a-feature requirement. A newly enrolled device should not immediately have full transaction capabilities. Institutions need to implement time-based restrictions and velocity controls that gradually unlock as the device and user behaviour establish a trust history.Combined with the fraud detection standards, which require real-time behavioural profiling and risk scoring, this creates a clear expectation: your authentication layer needs to be aware of context, not just credentials.
4. MFA that is more secure than unencrypted SMS
This is probably the most significant authentication requirement in the update, and it builds on years of BNM guidance pushing institutions away from SMS OTP:
deployment of MFA technology and channels that are more secure than unencrypted SMS…the MFA solution is resistant to interception or manipulation by any third party throughout the authentication process
RMiT Appendix 3 - Control Measures for Digital Services, paragraphs 5 and 6
And goes further to require that:
authentication code must be initiated and generated locally by the payer/sender using MFA... authentication code generated by payer/sender must be specific to the confirmed identified beneficiary and amount
This last point is transaction binding. The OTP or authentication code must be tied to the specific transaction details, not just to a session or login. This directly addresses "OTP redirect" attacks where fraudsters manipulate the transaction after the user has already authenticated.
RMiT Appendix 3 - Control Measures for Digital Services, paragraph 6(c) and 6(d)
BNM also explicitly requires institutions to:
offer to its customer a robust cryptographic key-based authentication such as digital certificate or passwordless as an alternative to existing password based authentication method
RMiT Appendix 3 - Control Measures for Digital Services, paragraph 9
This is a clear directive to move toward passkeys, hardware-backed authentication, or certificate-based methods.
How Authsignal helps you meet these requirements
Authsignal is built for specifically the authentication challenges the updated RMiT is designed to address.
Single device binding: Authsignal supports device-bound passkeys and cryptographic credentials that are tied to a specific device. Your enrollment flows can enforce the one-device-per-user default with clear mechanisms for customer-requested exceptions, all with a full audit trail.
Step-up authentication for sensitive changes: When a customer attempts to change a phone number, email, or registered device, Authsignal's rules engine can trigger a step-up challenge requiring biometric verification or a stronger second factor, independent of the channel being modified.
Risk-based cooling-off logic:You can integrate Authsignal with your fraud risk signals to enforce transaction limits and velocity controls during the cooling-off period after new device enrollment. As trust builds, limits can be relaxed automatically based on configurable rules.
Passwordless and certificate-based authentication: Authsignal's passkey implementation is a direct path to compliance with BNM's requirement for cryptographic key-based authentication as an alternative to passwords.
The bigger picture and next steps
Malaysia is ahead of much of the world on authentication regulation, but it is not alone in this direction. MAS in Singapore, RBI in India, and HKMA in Hong Kong are all pushing financial institutions toward device-bound, phishing-resistant authentication. The architecture required for RMiT compliance - cryptographic device binding, passkeys, transaction-level authentication - is where the entire region is heading.
If you have not already started your gap analysis, now is the time. Authentication controls: device binding, phishing-resistant MFA, transaction binding, and passwordless alternatives should be at the top of your list.
Authsignal's team can walk you through how our platform maps directly to the updated requirements and where the most common implementation gaps tend to show up.
Talk to our team or explore our documentation to get started.
Reference: Bank Negara Malaysia, Policy Document on Risk Management in Technology (RMiT), issued 28 November 2025. The full policy document is available here.
.svg)
