NRB cyber resilience rules: assess your mobile banking app on every release.

1. 01

   NRB Information Technology Guidelines 2012, Information Security 2.6 and 2.7

   Assess security and test intrusions periodically

   What the text says

   Since information security is not one time activity, banks should institutionalize processes to regularly assess the security health of the organization and detect and fix the vulnerabilities. It is recommended to conduct penetration testing of the system periodically. Banks should harden their systems with the highest level of security settings in operating systems, firewalls and system software, change default passwords immediately, and install vendor updates and patches. (IT Guidelines, Information Security 2.6 and 2.7)

   Source:NRB Information Technology Guidelines 2012, Information Security 2.6 and 2.7

   What it means for your mobile app

   Periodic assessment is a baseline expectation, not a one-off project. The mobile app and the APIs behind it belong in that cycle.

   How Ostorlab helps

   Mobile SAST analyses the binary, including embedded SDKs, and Mobile DAST tests the running app; both can run in CI/CD. The AI-agent pentest tests the app and its APIs behind login, with a working exploit you can replay for each AI-agent finding.

   What stays with you

   Setting the frequency and scope, platform assessments of servers and network equipment, patching and reporting.

2. 02

   NRB Information Technology Guidelines 2012, Information Security 2.9 and 2.28

   Protect what mobile devices store and send

   What the text says

   Banks should consider the security of information that can be stored in mobile devices and encrypt transaction information and PIN or password from mobile devices to the bank's system while providing banking services using mobile devices. Additional controls such as daily and per-transaction limits should be defined for fund transfer facilities. Banks should deploy strong cryptography and end-to-end encryption to protect customer PINs, user passwords and other sensitive data in networks and in storage. (Information Security 2.9 and 2.28)

   Source:NRB Information Technology Guidelines 2012, Information Security 2.9 and 2.28

   What it means for your mobile app

   What the app writes to the phone and what it sends to the backend are both in scope, from tokens and personal data to transaction details.

   How Ostorlab helps

   Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and tests whether limits and checks are enforced by the backend, not only by the app.

   What stays with you

   Choosing the cryptography and key management, setting the limits, and the policy for compromised devices.

3. 03

   NRB Information Technology Guidelines 2012, Information Security 2.27 and 2.29

   Use more than one factor for critical actions

   What the text says

   Banks should implement more than one factor for authenticating critical activities such as fund transfers through internet banking, with an authentication methodology that matches the risk of internet banking. Online payment by card should be authenticated using a second factor, with instant alerts to customers by email, SMS or automated voice call. (Information Security 2.27 and 2.29)

   Source:NRB Information Technology Guidelines 2012, Information Security 2.27 and 2.29

   What it means for your mobile app

   The second factor has to be enforced by the server on every critical operation, including when the app or an attacker skips a step.

   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.

   What stays with you

   Choosing the authentication methods and alert channels, and enforcement in your core banking systems.

4. 04

   NRB Information Technology Guidelines 2012, Information Security 2.30

   Secure web applications and their encryption

   What the text says

   Banks should implement adequate security measures to secure their web applications from traditional and emerging cyber threats and attacks, and critical applications should employ the latest SSL encryption. (Information Security 2.30)

   Source:NRB Information Technology Guidelines 2012, Information Security 2.30

   What it means for your mobile app

   The APIs your app calls are web applications. They need testing for the same classes of attacks, plus up-to-date transport encryption.

   How Ostorlab helps

   Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), token misuse and abuse such as enumeration and replay, and checks for misconfigurations that weaken transport protections.

   What stays with you

   TLS configuration and certificates, network controls, and the application's business logic.

5. 05

   NRB Information Technology Guidelines 2012, Information Systems Acquisition, Development and Implementation 7.1, 7.2 and 7.4

   Build security into development and review the code

   What the text says

   User functional requirements, security requirements, performance requirements and technical specifications should be documented and approved by the appropriate level of management before software is developed. Information security requirements should be incorporated at each stage of the software development lifecycle, covering access control, authentication, transaction authorization, system activity logging, audit trail and data integrity. Banks are encouraged to conduct source code review of the application to find loopholes and defects, and all vulnerabilities found should be fixed before the system is implemented. (IT Guidelines, Information Systems Acquisition, Development and Implementation 7.1, 7.2 and 7.4)

   Source:NRB Information Technology Guidelines 2012, Information Systems Acquisition, Development and Implementation 7.1, 7.2 and 7.4

   What it means for your mobile app

   Security requirements belong in the backlog, and a release should not ship with known defects that a code review would catch.

   How Ostorlab helps

   Mobile SAST works on the APK, AAB or IPA with taint analysis across the app and its embedded SDKs, and runs in CI/CD. Findings are tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.

   What stays with you

   Security requirements, secure coding standards, manual reviews and release approval.

6. 06

   NRB Information Technology Guidelines 2012, Outsourcing Management 5.3, 5.5 and 5.10; Cyber Resilience Guidelines 2023, 64

   Manage outsourcing and third parties

   What the text says

   All outsourced operations should be subject to the bank's information security and privacy policy, and the bank should ensure that the service provider implements adequate internal controls, logical access control and physical security controls. Banks should establish a process for monitoring and controlling outsourcing activities. Where IT operations are outsourced outside the country, banks should consider country risk and clarify the jurisdiction for their data and the applicable regulations at the start of the arrangement. The Cyber Resilience Guidelines ask banks to request confirmation that third-party vendors and service providers, including ICT suppliers, meet their cyber resilience requirements, with contracts covering validation of security capabilities and supply chain risks. (IT Guidelines, Outsourcing Management 5.3, 5.5 and 5.10; CRG 64)

   Source:NRB Information Technology Guidelines 2012, Outsourcing Management 5.3, 5.5 and 5.10; Cyber Resilience Guidelines 2023, 64

   What it means for your mobile app

   The SDKs bundled in your app are third parties with their own backends. They belong in your vendor risk view and in your data jurisdiction decisions.

   How Ostorlab helps

   Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, shows which backends the app and its SDKs talk to, and maps vulnerable components to known vulnerabilities.

   What stays with you

   Contracts, due diligence, data jurisdiction decisions and vendor monitoring.

7. 07

   Payment Systems Related Unified Directives, 2082, Directive 3 (Nepali text); Cyber Resilience Guidelines 2023, Section IV

   Secure the electronic payment system

   What the text says

   The Payment Systems Related Unified Directives, 2082 are the consolidated rules for institutions licensed to carry out payment-related work, issued under section 45 of the Payment and Settlement Act, 2075 (2019). Their Directive No. 3 covers the operation and security of the electronic payment system, and the Cyber Resilience Guidelines apply the same cyber resilience standards to A, B, C and D class BFIs, payment system operators and payment service providers. (Payment Systems Related Unified Directives, 2082, Directive 3, Nepali text; CRG, Section IV)

   Source:Payment Systems Related Unified Directives, 2082, Directive 3 (Nepali text); Cyber Resilience Guidelines 2023, Section IV

   What it means for your mobile app

   A wallet or payment app and its APIs are the electronic payment system that customers touch. The security of that operation is a named subject in the payment directives.

   How Ostorlab helps

   Ostorlab tests the payment app and the APIs behind accounts, payments and balances, behind login, on the build you ship, and keeps evidence per release.

   What stays with you

   Licensing conditions, operational rules and reporting to NRB under the payment system directives.

8. 08

   NRB Cyber Resilience Guidelines 2023, 135 to 148 and 160

   Run a comprehensive testing programme

   What the text says

   The CRG expects a comprehensive testing programme, developed with a risk-based approach, reviewed and updated regularly, with issues prioritised, resolved and validated, and tests carried out by independent parties, internal or external. It should include vulnerability assessments and static and dynamic code reviews. Vulnerability assessments should be conducted before deploying or redeploying services that support critical functions, and on running services and applications on a regular basis. Vulnerability scanning should cover external-facing services as well as internal systems and networks, rotating between environments. (CRG 135 to 148 and 160)

   Source:NRB Cyber Resilience Guidelines 2023, 135 to 148 and 160

   What it means for your mobile app

   A release is a change to an internet-facing service. The programme has to cover it before deployment and keep covering it afterwards.

   How Ostorlab helps

   Ostorlab runs automated scans from your CI/CD pipeline on every build, monitors store releases without manual triggers, and keeps results per build and per release. Findings are rated critical, high, medium or low.

   What stays with you

   The programme itself, its risk-based scope, internal systems and networks, and who signs it off.

9. 09

   NRB Cyber Resilience Guidelines 2023, 142 and 155 to 164

   Test intrusions across the application portfolio

   What the text says

   Penetration tests should be performed to identify vulnerabilities that may affect systems, networks, applications, people or processes, simulating actual attacks. They should be conducted regularly and whenever there are major updates to or deployment of systems. Banks should perform security assessments and tests at all stages of the system development life cycle and at any level, business, application and technology, for the entire application portfolio, including mobile applications. Best practices and automated tools should support fixing weaknesses and ensuring compliance with approved policies and configurations. Red team testing, based on threat scenarios, is also part of the CRG's testing scope. (CRG 142 and 155 to 164)

   Source:NRB Cyber Resilience Guidelines 2023, 142 and 155 to 164

   What it means for your mobile app

   Mobile apps are named in the portfolio, and major updates trigger testing. Annual testing alone does not cover a channel that ships every few weeks.

   How Ostorlab helps

   The AI-agent pentest runs on the build your customers download, tests the app and its APIs behind login, and gives you a replayable exploit for each AI-agent finding plus a coverage heatmap. Ostorlab does not run red team exercises.

   What stays with you

   Scheduling pen tests and red team exercises, scoping them, and acting on findings across non-app systems.

10. 10

    NRB Cyber Resilience Guidelines 2023, 54(d), 54(e) and 71(d)

    Require MFA for critical systems and encrypt data

    What the text says

    The CRG says critical systems, processes and roles should all require multi-factor authentication, wherever supported. It also asks for strong data and information protection controls, including data encryption commensurate with criticality, sensitivity and risk assessment, and encryption in line with recognised standards and processes covering algorithm, key length, key generation and key management. (CRG 54(d), 54(e) and 71(d))

    Source:NRB Cyber Resilience Guidelines 2023, 54(d), 54(e) and 71(d)

    What it means for your mobile app

    The MFA rule is not only about customer login: admin panels and back-office roles that reach customer data are in scope. What the app stores on the device, what it sends and what the backend keeps all need protection you can evidence.

    How Ostorlab helps

    Authenticated testing checks MFA enforcement and step-up flows, while static and dynamic analysis look for tokens and personal data in storage, caches, logs and screenshots, and find API keys and credentials in the app package.

    What stays with you

    Deploying MFA across internal and customer-facing systems, cryptography choices, data classification and key management.

Summary of public NRB texts, checked on 27 September 2026. The payment system directives and the Unified Directives are published in Nepali and are summarised, not quoted, on this page. This page is not legal advice.