Compliance
Regulation as architecture
Most lending systems treat compliance as a policy document and trust people to follow it. Khepee encodes it. Every regulatory number is a versioned constant in one file, enforced server-side, and covered by tests that fail the build if a rule is weakened.
The starting point
Only licensed institutions may lend
Under Nepali law, lending is restricted to Banks and Financial Institutions licensed by Nepal Rastra Bank. A software company cannot originate loans on its own account, and Khepee does not attempt to.
- The partner institution is the lender of record on every loan
- Every tenant in the platform carries an NRB licence number on file
- A tenant cannot be activated without one — the model layer rejects it
- Khepee holds no licence and claims none
Loan ceilings
Four independent layers, so one refactor cannot remove the limit
NPR 500,000 for salary and business account holders; NPR 200,000 for other account holders. A partner may configure a lower limit for its own products. It can never configure a higher one.
- A single decision function — the only place a limit is evaluated
- Schema-level rejection at the API boundary before anything reaches a service
- A service-layer clamp applied when a product is created or edited
- A database hook that refuses to persist an over-limit product, even on a direct write
Tenure
Thirty-six months, and not a day more
The maximum term is three years. It is enforced with the same layering as the amount ceilings, and the stricter of the product cap and the regulatory cap always wins.
- Enforced at the decision function, the schema, the service and the model
- A product may set a shorter maximum; it cannot raise the regulatory one
- Validated again at the moment of approval, not only at application
- Covered by tests that assert 36 passes and 37 fails
The KYC gate
No disbursement without verified identity
This is the invariant we are most careful about. The application state machine has no edge that reaches disbursement without passing through KYC review, and there is no override flag at any privilege level.
- KYC verification is a structural precondition, not a checklist item
- A test walks every possible route through the state graph and asserts each one passes KYC review
- If that test fails, the build fails — the rule cannot be quietly removed
- Expired verifications return the application to review rather than proceeding
Purpose limitation
Borrower data collected for lending, used only for lending
NRB requires that data gathered during the lending process serve only that process. Khepee makes this real rather than documentary: every read of a personal field must declare a purpose from a closed list, and the purpose is written to the audit trail.
- Purposes are a fixed enumeration, never free text
- A request without a purpose is rejected, not silently defaulted
- Khepee’s own super-admin role is deliberately not granted permission to read borrower personal data
- Every access is attributable to a named person and a stated reason
Fund custody
Money never flows through Khepee
The payment interface exposes methods to instruct a disbursement and to read back the status your rails report. It exposes no method capable of moving funds into an account Khepee controls. The constraint is architectural, not contractual.
- No settlement account, no float, no client money
- The partner institution is the source of truth for all money movement
- Amounts handled as integer paisa throughout — never a floating-point value
- Every instruction and confirmation recorded as separate immutable events
Audit trail
An examiner can be walked through it unprepared
Every state change, decision, disbursement and personal-data read is written to an append-only log. Updates and deletes are blocked at the model layer; in production the database user should hold insert and read rights only.
- Corrections are new entries — nothing is ever overwritten
- Actor, role, timestamp, reason and ruleset version on every entry
- Personal data appears as a hash, so the trail can be shown without exposing borrowers
- One request id ties a support ticket to the exact events behind it
When rules change
A regulatory change is a same-week change
Every regulatory number lives in one file with a version stamp. When NRB revises a directive we update the constant, bump the ruleset version, record the change, and every surface picks it up together.
- One file holds every regulatory constant, with citations
- A version stamp recorded on every audit entry, so past decisions stay interpretable
- A documented changelog of what moved and when
- Shared contracts verified in CI, so no client can drift from the server
Regulatory context
Three things worth stating plainly
P2P lending is not permitted
NRB has issued a consultative document and a white paper, but no regulation. Khepee does not operate a peer-to-peer model and will not until the regulator opens that route.
The regulatory sandbox exists
NRB opened a sandbox for supervised live testing of new fintech models. That is the correct route for anything the current rules do not contemplate — not a workaround.
SME digital lending is separate
The digital lending framework contemplates credit to small and medium businesses up to a higher ceiling. That is a distinct product configuration with its own constants, not an extension of the retail limits.
Verify every figure on this page with your own counsel
The limits, caps and requirements described here reflect our understanding of NRB’s digital lending framework at the time of writing, and they drive constants in our code. Regulations change, and directives are amended. Before you go live, your compliance function and Nepali legal counsel must verify each figure against the current directives and circulars. Where a directive and this page disagree, the directive governs — tell us, and we will change the code first and the page second.
Compliance by engineering is not the same as regulatory approval
Everything described here is how Khepee’s software is built. It is not a statement that Khepee is licensed, approved, registered or endorsed by Nepal Rastra Bank or any other regulator, and it is not legal advice. Khepee is a technology service provider operated by Lacspace Corporation Pvt. Ltd.; it does not lend, does not accept deposits and does not hold customer funds. Partner institutions remain responsible for their own regulatory compliance, and should verify every figure here against the current NRB directives with their own counsel.
Coming soon
Bring your compliance officer to the first meeting
The architecture is easier to evaluate than to describe. We will walk your compliance function through the enforcement points directly.