Disbursement
Khepee instructs. Your rails move the money.
This is the most important boundary in the platform, and it is enforced by design rather than by promise: the payment interface has no method capable of moving funds into an account Khepee controls.
Why it matters
No custody means no prudential exposure
A technology provider that touches customer funds becomes a very different kind of regulated entity. Keeping funds entirely on your side is what allows Khepee to operate as a software vendor and keeps your compliance surface unchanged.
- Khepee holds no settlement account, no float and no client money
- Your institution remains the source of truth for every rupee moved
- No trust or escrow arrangement to negotiate or audit
- The constraint is structural — the interface simply has no such method
The flow
What actually happens at disbursement
Approval recorded
An officer approves, with the amount and terms. The state machine moves the application to approved.
Instruction constructed
Khepee builds the disbursement instruction with an idempotency key and records it.
Your rails execute
Your payment infrastructure moves the funds to the borrower’s account, under your control.
Status read back
Khepee reconciles against the status your systems report — never an assumed outcome.
Loan activated
On confirmation, the loan becomes active and the EMI schedule is generated.
Safety
A retry never disburses twice
Network failures during disbursement are the highest-consequence failure mode in lending software. Every instruction carries an idempotency key, and replaying it returns the original result rather than issuing a second payment.
- Idempotency keys required on every instruction
- Replays return the original outcome, not a new instruction
- Reconciliation runs on a schedule, so a lost response is detected rather than assumed
- Failures surfaced with the reason your rails reported, and safe to retry
Reconciliation
Your ledger and ours agree, because yours wins
Khepee never overwrites what your systems report. Where the two differ, your institution is authoritative and the discrepancy is raised for a human rather than silently resolved.
- Scheduled reconciliation against the status your rails report
- Discrepancies raised, never auto-corrected
- Every reconciliation attempt and outcome recorded in the audit trail
- Webhook or polling, whichever your infrastructure supports
Controls
Who can instruct a disbursement
Permission-gated
Only roles holding the disbursement permission can instruct one, and the permission is scoped to your institution.
KYC-gated
The state machine will not transition to disbursed without verified KYC. No override exists.
Limit-gated
The amount is re-validated against the regulatory and product ceilings at the moment of instruction.
Evidence
Every instruction and confirmation, permanently recorded
Disbursement is the event an examiner will look at hardest. Both the instruction and the confirmation are written to the append-only trail with the actor, the amount and the external reference.
- Instruction and confirmation recorded as separate immutable events
- The external reference from your rails retained for dispute resolution
- Amounts recorded in integer paisa, so no rounding ambiguity exists
- Traceable from the audit entry back to the approving officer and their reason
Khepee provides the technology; your institution provides the credit
Khepee is a technology service provider operated by Lacspace Corporation Pvt. Ltd. It is not a bank or financial institution, does not lend, does not accept deposits and does not hold customer funds. All credit decisions, pricing and lending terms are set by the partner institution licensed by Nepal Rastra Bank. Khepee makes no claim of NRB licensing, approval or endorsement.
Coming soon
Map disbursement to your existing rails
Bring your payment infrastructure and we will walk through exactly where the boundary sits.