NRB AI Guidelines: How Nepal's Banks Must Audit AI

Nepal Rastra Bank published the NRB AI Guidelines in December 2025, and with them came the first written expectation in Nepal that AI systems inside licensed institutions get looked at by someone who did not build them. The document is short, but it asks for AI-specific threat modelling, regular security testing, a documented high-risk classification and, for high-risk systems, independent third-party validation. This piece walks through what those guidelines actually require, how they line up with the OWASP LLM Top 10 as it stands in 2026, and what an independent review of a Nepali AI product involves in practice.

Why an outside reviewer, and why the timing has changed

Most AI features in Nepal today were built by the same three or four people who are now being asked to sign off that they are safe. That is not a criticism of those engineers. It is a structural problem. The person who wrote the retrieval pipeline is the worst possible person to ask whether that pipeline leaks another customer's data, because they will test the paths they built and not the paths they never imagined.

An AI security audit is an outside team spending a fixed number of days trying to make your product do something it should not do, then writing down exactly how they did it. It is not a scan. Automated scanners do not find prompt injection hidden in a PDF attachment, and they do not notice that your agent's database credential has write access to the payments table. AI features also rarely arrive alone: they usually ride in on a wider digital transformation programme whose threat model was written before any model was in the picture.

Two things changed the timing for Nepali teams. First, the surface got big. Nepal Rastra Bank's payment systems indicators record 30.10 million mobile banking users and 27.70 million wallets as of mid-July 2026, against 27.74 million and 26.77 million a year earlier. QR-based payments alone ran 69.59 million transactions worth NPR 189.91 billion in the month to mid-July 2026, up from 40.24 million transactions worth NPR 113.20 billion in the same month of 2025. Every chatbot, fraud model and document-reading feature bolted onto those payment rails inherits their blast radius.

Second, the regulator wrote it down. NRB's Banks and Financial Institutions Regulation Department published Artificial Intelligence Guidelines in December 2025, covering commercial banks, development banks, finance companies, microfinance institutions, Nepal Infrastructure Bank, and payment system operators and service providers. Section 9.1 says that for high-risk AI systems it is recommended to have independent third-party validation of outcomes. Section 6.4 asks for regular security audits, penetration testing and AI-specific threat modelling. That is a review requirement in everything but name.

What the OWASP LLM Top 10 says in 2026

The OWASP Gen AI Security Project published the 2026 edition of the Top 10 for LLM Applications in early August 2026. The ranking method was 75 percent practitioner voting and 25 percent weighting from 6,639 real incidents drawn from public vulnerability databases and an AI-harm database, which is why the movement in the list is worth reading rather than skimming.

2026	Risk	2025 rank	Move
LLM01	Prompt Injection	1	Unchanged
LLM02	Sensitive Information Disclosure	2	Unchanged
LLM03	Excessive Agency	6	Up 3
LLM04	Supply Chain	3	Down 1
LLM05	Data and Model Poisoning	4	Down 1
LLM06	Unbounded Consumption	10	Up 4
LLM07	Misinformation	9	Up 2
LLM08	Hidden Context Exposure	7	Down 1, renamed
LLM09	Vector and Embedding Weaknesses	8	Down 1
LLM10	Improper Output Handling	5	Down 5

Three of those movements matter for how a review is scoped.

Excessive Agency climbing from sixth to third is the list catching up with what teams actually shipped over the past two years. A model that answers questions and a model that holds an API token, a database connection and a memory store are different products with different worst cases. If your feature can send money, cancel a booking, email a customer or write to a table, agency is your top finding, not prompt injection.

System Prompt Leakage became Hidden Context Exposure. The old name suggested the risk was someone reading your clever instructions. The new name covers everything the model can see and the user cannot: retrieved documents, tool schemas, injected customer records, prior turns from other sessions. Recovering a tool schema is usually more useful to an attacker than recovering a system prompt.

Improper Output Handling fell from fifth to tenth and this is the one people misread. It fell because more teams now sanitise, not because model output stopped being untrusted input. If your product renders model output as HTML, passes it to a shell, or concatenates it into SQL, it belongs at the top of your own list regardless of where OWASP puts it.

The underlying weakness behind LLM01 has a formal identifier now, CWE-1427, Improper Neutralization of Input Used for LLM Prompting, which helps when findings have to land in a tracker that expects CWE references.

What an AI security assessment actually covers

Prompt injection and the trust boundary

Direct injection, where a user types instructions into a chat box, is the easy half. The half that breaks products is indirect: instructions hidden in a document the model reads, a web page it fetches, a support ticket it summarises, a CV it screens. In a review, the tester plants a payload in a source your pipeline treats as data and checks whether it gets executed as instruction.

The finding is rarely "the model was fooled". The 2026 edition starts from the assumption that models will be fooled. The finding is that being fooled had consequences, because nothing sat between the model deciding something and the system doing it.

Data leakage and PII handling

This is where Nepali products fail most often, and the failures are boring: full customer records pasted into a prompt when three fields would do; chat transcripts written to a logging service nobody classified; a vendor API called with production data during a demo; personal data sitting in stored prompts forever because retention was never configured.

The Privacy Act, 2075 (2018), dated 18 September 2018, requires consent before personal data is collected and limits its use to the purpose it was collected for. NRB's AI Guidelines go further for licensed institutions: explicit consent before customer data is used in AI systems, a clear opt-out that does not cost the customer essential services, and data minimisation backed by a formal retention policy covering training data, outputs, audit trails and model documentation.

Model and dependency supply chain

Where did the weights come from, who can push a new version, and what happens when the vendor changes the model behind the same API name? A review traces the chain: base model provenance, fine-tuning data, orchestration libraries, the vector database client, the embedding model, and every place a version is left unpinned. Model artefacts pulled from public hubs are executable content and deserve the same scrutiny as any other dependency.

Access control and agent permissions

The test is simple and rarely passes. Enumerate every credential the AI system can reach, then ask what the worst single call with that credential does. Agents inherit the permissions of the service account they run under, so a read-only assistant with a read-write connection string is a read-write assistant that has not yet been asked nicely. The usual fixes are scoped tokens per tool, human confirmation for irreversible actions, and rate limits per user rather than per API key. That inventory normally lives in the same place your cloud and deployment pipeline already records secrets and service accounts, which is why the exercise is quick for teams who kept that documentation current and painful for everyone else.

Retrieval, embeddings and tenant isolation

Multi-tenant retrieval is the quiet one. If tenant filtering happens after the vector search instead of inside it, similarity ranking can surface another organisation's chunk before the filter runs, and one careless logging line will print it. Reviews check filter placement, index partitioning, exposure through embedding inversion, and whether deleting a document actually removes its vectors.

Mapping the list to a real product

Take a loan-enquiry assistant at a Nepali bank. It answers product questions, reads uploaded salary slips, and looks up the customer's own account. Here is how the abstract list becomes a test plan.

Risk	What it looks like here	What the reviewer checks
Prompt Injection	Text inside an uploaded salary slip tells the assistant to expose its lookup tool	Payloads in every ingested file type and OCR path
Sensitive Information Disclosure	Assistant returns another customer's balance after a vague query	Identity binding between the session and the account lookup
Excessive Agency	Lookup tool accepts an arbitrary account number	Server-side enforcement that the account belongs to the caller
Supply Chain	Unpinned orchestration library auto-updates in production	Lockfiles, provenance, vendor model version pinning
Hidden Context Exposure	Tool schema and internal product codes recovered through conversation	What the model can see versus what the user may learn
Improper Output Handling	Answer rendered as HTML inside the web widget	Escaping, content security policy, markdown sanitisation
Unbounded Consumption	One user drives the monthly token budget in an afternoon	Per-user quotas, timeouts, cost alerting
Misinformation	Assistant states an interest rate that is not in the product sheet	Grounding, refusal behaviour, disclosure that AI was used

That last row is a regulatory item as much as a quality one. NRB's guidelines require customers to be told when AI is used in decisions affecting them, require accessible explanations of how those decisions are made, and require AI-generated content to be labelled.

Where Nepal's rules land

• NRB Artificial Intelligence Guidelines (December 2025). The board and senior management stay accountable for AI outcomes. Licensed institutions classify each system as high-risk or not before deployment, against five criteria: serious harm, broad impact, minimal human oversight, risk to individual rights, and use of sensitive data such as biometrics. AI risks go into the risk register with named owners and mitigations. Audit trails are recommended to align with ISO/IEC 42001.
• Outsourcing. Using a third-party AI tool internally for drafting or analysis is not outsourcing. Buying a service whose delivery depends on the vendor's AI is. That path needs due diligence, contract terms on data security and auditability, board approval, and notification to the relevant NRB supervision department, which is as much an IT consultancy exercise as a technical one.
• Incident reporting. Critical AI incidents, including major failures, data breaches and significant algorithmic bias, are reported to NRB under the IT Guidelines, 2012 and the Cyber Resilience Guidelines, 2023. Non-critical incidents are documented internally and reported quarterly. An annual return on AI activities goes to the supervision department on NRB's Annex A template.
• Privacy Act, 2075 (2018). Consent, purpose limitation and confidentiality of personal data, with criminal penalties for breach. It applies whether or not you hold an NRB licence.
• National Cyber Security Policy, 2080 (2023) and the National AI Policy, 2082, endorsed by cabinet on 11 August 2025. Together they set direction on identifying and protecting national critical infrastructure, and on privacy and citizens' rights in AI use.
• EU AI Act, if you have EU users. The two dates are commonly run together and they are a year apart. Under Article 113, Chapter V, the obligations on providers of general-purpose AI models, has applied since 2 August 2025. The Article 50 transparency duties applied from 2 August 2026, the Regulation's general application date. Regulation (EU) 2026/1744, the Digital Omnibus on AI adopted on 8 July 2026, then moved the stand-alone high-risk obligations under Annex III to 2 December 2027 and high-risk AI embedded in already-regulated products under Annex I to 2 August 2028. Nepali outsourcing vendors are usually pulled in as suppliers to a customer who is in scope, which makes it a contract problem before it is a legal one.

For frameworks, the two most useful references outside OWASP are NIST AI 600-1, the Generative AI Profile released on 26 July 2024 with twelve risk categories, and MITRE ATLAS for adversary tactics against AI systems. Neither is mandatory in Nepal. Both make a report legible to an auditor or to an enterprise customer's procurement team.

What a review engagement looks like

A first review of a single AI feature runs eight to twelve working days. Platforms with several agents, multiple tenants or an in-house model run longer. Fees are quoted in NPR against reviewer-days, so a scoping conversation is really a conversation about how many days the surface deserves.

Phase	Typical days	Output
Scoping and access	1	Written scope, rules of engagement, test environment, data handling agreement
Architecture and threat model	2	Data flow diagram, trust boundaries, credential inventory, risk classification against NRB's criteria
Hands-on testing	4 to 6	Injection, leakage, agency, isolation and output-handling test cases with reproduction steps
Reporting	2	Findings ranked by exploitability and impact, mapped to the LLM Top 10 and CWE, each with a fix
Retest	1	Verification of fixes and a closure letter you can hand to a customer or a supervisor

What a reviewer should ask for before day one: architecture notes or a whiteboard photo, the system prompts as deployed, the tool and function definitions, a list of every data source the model reads, the service accounts and their permissions, retention settings for prompts and logs, and a non-production environment with realistic but non-live data. A team that cannot produce the credential inventory within a day has already learned something.

Two things a review is not. It is not a guarantee, and any reviewer offering one is selling something else. And it is not a substitute for your own regression tests: the report's value decays as you ship, which is why the pattern that works is an annual full review plus a short delta review whenever a new tool, model or data source is added. If you want a day estimate for a specific feature, describe what it does and what it can touch and the scope follows from that.

How to get more out of the engagement

1. Decide before scoping whether the system is high-risk under NRB's five criteria. It changes the depth of the work, and you need the written justification either way.
2. Give the reviewer a non-production environment with real-shaped data. Testing against sanitised toy data finds toy bugs.
3. Do not fix findings quietly during the test window without telling the reviewer. It corrupts the retest and buries the root cause.
4. Book the retest at the start. A report without a verified close-out is worth much less to an enterprise buyer.
5. Ask for findings mapped to whatever taxonomy your customers' procurement questionnaires use, rather than accepting whichever one the reviewer prefers.

Frequently asked questions

Is an AI security audit different from a normal penetration test?

It overlaps but does not replace one. A standard test covers the web and API layer: authentication, injection, access control, configuration. An AI security audit adds the model layer, where the input is natural language, the output is untrusted, and the system may take actions on its own. Most products need both, which is why NRB's guidelines ask licensed institutions for regular penetration testing alongside AI-specific threat modelling.

We only call an external model API. Do we still need a review?

Yes, and often more than teams who host their own model. Calling a vendor API moves model risk to someone else and leaves you every other risk: what you put in the prompt, what you do with the output, what the model is allowed to call, how long you keep transcripts, and which vendor terms apply to your customers' data. For an NRB-licensed institution, whether that vendor arrangement counts as outsourcing is itself a question worth settling in writing before anyone asks.

How often should we repeat it?

Annually as a baseline, plus a short review whenever the system gains a new tool, a new data source, a new tenant model, or a different underlying model version. NRB expects high-risk systems to be monitored more frequently than others and re-assessed when functionality, operations, or the regulatory and technological environment change materially.

Can the team that built the feature review it?

They should test it, and they will find real problems. But they cannot review it in the sense a regulator or an enterprise customer means, because independence is the point of the exercise. NRB's guidance on high-risk systems recommends independent third-party validation of outcomes for exactly this reason.

What if we are not a bank?

The NRB guidelines will not bind you, but the Privacy Act, 2075 will, and enterprise customers increasingly ask for a recent third-party report before they sign. Health, education and remittance-adjacent products in Nepal are now receiving the same security questionnaires that banks started receiving years ago, only sooner in the sales cycle.