Digital KYC

Know your customer, provably

KYC is mandatory before any disbursement. Khepee treats that as an architectural constraint rather than a policy reminder — there is no route through the platform that reaches a disbursement without it, and no flag that creates one.

Documents

The identity documents Nepali borrowers actually hold

  • Citizenship certificate

    The primary identity document for most borrowers. Front and back capture, with issuing district and date recorded.

  • National ID

    Accepted as primary proof of identity as rollout continues.

  • Passport

    Primary proof, useful for borrowers without a citizenship certificate to hand.

  • Driving licence

    Accepted as supporting evidence alongside a primary document.

  • Voter ID

    Accepted as supporting evidence where your policy permits.

  • Selfie & liveness

    Matched against the document photograph, with the vendor kept behind an interface.

The gate

There is no bypass, because none was built

The constant that governs this is not configurable, and the state machine has no edge that skips verification. This is asserted by a test that walks every possible route from draft to disbursed.

  • KYC verification is a precondition of the disbursement transition
  • No administrative override exists, at any privilege level
  • An expired verification returns the application to review
  • The gate is covered by a test that blocks the build if it is weakened
no bypass exists

Storage

Documents encrypted, and never publicly addressable

Document images are stored as object keys, not URLs, and served through short-lived signed links. Document numbers are encrypted at field level, with a deterministic index so they remain searchable without being decrypted.

  • AES-256-GCM field-level encryption on document numbers and personal fields
  • Images addressed by key; signed on demand, never left publicly reachable
  • A deterministic HMAC index enables duplicate detection without decryption
  • Retention bounded and documented, not indefinite by default

Verification workflow

Who decides, and on what basis

  1. Capture

    The borrower photographs their document in the app, with on-device guidance for glare and framing.

  2. Automated checks

    Format, expiry and, where enabled, liveness — returned as a result with a score, not a verdict.

  3. Officer review

    Your officer sees the document and the automated result, and makes the call.

  4. Decision recorded

    Verified or rejected. A rejection requires a written reason before it will save.

  5. Borrower informed

    Told clearly what happened and, if rejected, what to do about it.

Vendor independence

Your KYC provider, not ours

Every external capability sits behind an interface with a mock driver as the default. Nothing real is wired in until you have chosen it and the decision is recorded. Switching provider later is an implementation of one interface, not a rewrite.

  • A single `KycProvider` interface: verify in, result out
  • No vendor enabled by default — the platform ships on a mock driver
  • Your existing provider can usually be used, if you already have one
  • Provider choice is per-institution, not platform-wide

Purpose limitation

Collected for lending, used only for lending

NRB requires that borrower data collected during the lending process be used only for that process. Khepee enforces it: every read of a personal field must declare a purpose from a closed list, and that purpose is written to the audit trail.

  • Purposes are a fixed enumeration, not free text
  • A request without a purpose is rejected, not defaulted
  • Khepee’s own administrators are not granted permission to read borrower personal data
  • Every access is attributable to a named person and a stated reason

Coming soon

Review the KYC workflow with your compliance team

The verification workflow is usually the first thing a compliance officer wants to inspect. We are happy to start there.