Nepal Rastra Bank's new Artificial Intelligence Guidelines were drafted for "licensed institutions," but read the scope section closely and it becomes clear this document was written with payment system operators, wallets and fintech-linked services in mind just as much as traditional banks. Anyone building or running AI features for a bank, a microfinance institution, or a payment platform in Nepal now has a specific compliance checklist to work against — and it changes how outsourcing, vendor contracts and product launches get approved.
This piece looks at the guidelines specifically through a banking-and-fintech operational lens: what changes for payment service providers, what the outsourcing rules actually require, how this interacts with NRB's separate regulatory sandbox, and where fintech teams commonly get the compliance reading wrong.
In this article
- Scope: who exactly is covered
- Internal use vs. outsourced AI — the critical distinction
- Classifier: internal use or outsourcing?
- How this connects to NRB's Regulatory Sandbox
- Compliance checklist for fintech and payment teams
- Fraud detection and explainability — a specific tension
- Mistakes fintech teams make
- FAQs
Scope: who exactly is covered
The guidelines' scope section names payment system operators (PSOs) and payment service providers (PSPs) alongside commercial banks, development banks, finance companies, microfinance institutions, and Nepal Infrastructure Bank Limited. That places digital wallets, remittance platforms and payment gateways licensed by NRB squarely inside the same compliance framework as a Class A commercial bank — even though their AI use cases (fraud scoring on transactions, chat support, KYC automation) tend to look quite different from a bank's credit-scoring models.
The named use cases are credit scoring, fraud detection, customer service, risk management, and compliance monitoring — described as illustrative rather than exhaustive. For a payment provider, fraud detection and KYC-adjacent automation are usually where AI shows up first, which is why the risk-classification and explainability sections carry the most weight for this segment.
How NRB's guidelines separate internal AI use from outsourced AI services -- the distinction that determines whether board approval and an NRB notification are required.
Internal use vs. outsourced AI: the critical distinction
This is the single most consequential technical distinction in the guidelines for fintech teams, because it determines whether a product launch needs board sign-off and a regulator notification, or just internal documentation.
Internal use of third-party AI
Using AI tools or ready-made models for internal purposes — drafting documents, creating summaries, analyzing information — stays inside the institution and is not treated as outsourcing. Your own governance, risk and compliance policies apply, aligned with national regulation.
Outsourced AI service
When a third-party provider's AI actually delivers a service to your customers, it counts as outsourcing. This triggers due diligence on regulatory compliance, contract terms covering data security and auditability, formal board approval, and a notification to NRB's relevant supervision department before launch.
In practice: an AI copilot your compliance team uses to summarize documents is internal use. A vendor-built AI chatbot answering customer questions on your app, or a third-party fraud-scoring API making real-time decisions on transactions, is an outsourced AI service.
Classifier: internal use or outsourcing?
Answer the two questions below to get a starting-point read on which track your AI feature likely falls into. This is a planning aid, not a substitute for your institution's own compliance and legal sign-off.
Internal Use or Outsourced AI Service?
1. Does the AI system interact directly with your customers or make decisions that affect them (not just your internal staff)?
2. Is a third-party provider operating or running that AI system on your behalf, rather than your own staff using a tool internally?
How this connects to NRB's Regulatory Sandbox
Fintech teams testing a new AI-driven product often ask whether NRB's separate Regulatory Sandbox — finalized and in effect from May 14, 2026 under NRB's Payment Systems Department — offers a way to trial an AI feature before full AI-guideline compliance is in place. The sandbox lets banks, payment firms, remittance companies and fintech startups test new products under real market conditions with temporary relief from certain regulatory requirements, for a defined cohort window with a 45-day proposal submission period.
The two frameworks are complementary, not substitutes. Sandbox participation gives a controlled testing environment and a defined exit path — either regulatory approval to launch or, for non-licensed fintechs, a Sandbox Completion Acknowledgement they can use to partner with a licensed institution. It does not remove the AI Guidelines' governance, risk-classification, and disclosure expectations for whatever AI component sits inside the product being tested.
Practical read: If your AI-powered product is customer-facing and still experimental, applying to the sandbox first can be a lower-friction way to gather real usage data — but build your AI governance documentation in parallel, because you'll need it regardless of which track you launch through.
Compliance checklist for fintech and payment teams
| Area | What to have in place |
|---|---|
| Governance | Cross-functional AI steering committee (business, risk, IT, legal, audit); board-approved AI strategy and governance framework. |
| Inventory | A live catalogue of every AI system in production or pilot, each tagged high-risk or not, with a documented justification. |
| Vendor contracts | Clauses on audit rights, data usage, security standards, and termination for any outsourced AI service provider. |
| Disclosure | Customer-facing notices wherever AI is used in a decision, plus labeling for AI-generated content. |
| Bias testing | Documented fairness testing for credit, fraud and risk-scoring models, with independent validation for high-risk systems. |
| Incident process | A playbook distinguishing critical incidents (immediate report) from non-critical ones (quarterly report) to NRB. |
| Data privacy | Consent capture, data minimization, and a working opt-out under the Privacy Act 2075. |
| Annual reporting | NRB's standardized AI activity reporting template completed and ready to submit. |
Fraud detection and explainability: a specific tension
Real-time fraud models are one of the trickiest areas for payment providers under these guidelines, because speed and explainability naturally pull in opposite directions. A model that blocks a suspicious transaction in milliseconds is doing its job — but the guidelines also require that AI decisions be explainable to customers and auditable after the fact.
The practical resolution most institutions land on is a two-layer design: an automated model that acts instantly, paired with a logged, human-readable "reason code" trail that support staff can pull up immediately if a customer disputes a block. This satisfies both the operational need for speed and the transparency obligation, without slowing down the fraud check itself.
Mistakes fintech teams make
- Assuming a chatbot vendor's own compliance covers you. Even a reputable AI vendor's certifications don't remove your institution's obligation to do due diligence, get board approval, and notify NRB before an outsourced customer-facing AI service goes live.
- Skipping the "why is this not high-risk" documentation. If a system is classified as non-high-risk, the guidelines still require a written justification kept ready for regulators — an easy step to forget when a launch is moving fast.
- Treating fraud models as exempt from explainability. Speed-critical systems still need an audit trail and a way to explain a decision to an affected customer.
- Forgetting non-critical incidents. Minor model errors that get fixed quietly still need to be logged and reported to NRB quarterly, not just catastrophic failures.
Frequently asked questions
Do digital wallets and remittance apps count as "payment service providers" under this guideline?
The scope names payment system operators and payment service providers licensed by NRB. Any digital wallet, remittance platform or payment gateway holding a relevant NRB license falls within that category.
Does using OpenAI, Google, or Microsoft's AI models count as outsourcing?
It depends on how the model is used. If staff use it internally — drafting, summarizing, analysis — that is treated as internal use, not outsourcing. If that same provider's model is what actually delivers a customer-facing feature (a support chatbot, a scoring decision), it is treated as an outsourced AI service with the associated due-diligence and approval steps.
Can a fintech test an AI feature in the Regulatory Sandbox to skip AI Guideline compliance?
No. The sandbox offers temporary relief from certain regulatory requirements for testing purposes, with NRB oversight, but it is a separate framework from the AI Guidelines. Governance and risk-classification expectations for the AI component still apply, and sandbox participants remain subject to NRB's review during the testing period.
Who at a fintech or bank is accountable if an AI system causes customer harm?
The guidelines place ultimate accountability with the board of directors and senior management, not the technical team or an outsourced vendor alone.
New to the guidelines themselves? Start with the plain-language breakdown of what NRB actually published and who it covers.
Read: NRB's New AI Guidelines -- What Businesses Should Know →This article summarizes NRB's published Artificial Intelligence Guidelines and Regulatory Sandbox framework for general awareness. It is not legal or regulatory advice. Licensed institutions should refer to official NRB documentation and consult compliance and legal counsel before making implementation decisions.
Discussion