Data protection
The data is the borrower’s, held in trust
A lending platform accumulates the most sensitive information a person has: identity documents, income, address, family circumstances. Treating that as an asset rather than a liability is how institutions end up in the news.
At rest
Field-level encryption, not just disk encryption
Disk encryption protects against a stolen server. It does nothing against a leaked database dump, which is the realistic threat. Personal fields are individually encrypted with AES-256-GCM.
- AES-256-GCM per field, with a key held separately from database credentials
- Ciphertext carries a key version, so rotation is possible without data loss
- Names, phone numbers, addresses, dates of birth and document numbers all covered
- Adding a field to the personal-data list brings it under encryption and audit automatically
Searchability
Encrypted, and still searchable
The usual objection to field-level encryption is that you can no longer look anything up. Khepee stores a deterministic HMAC alongside each encrypted value, so exact-match lookups work without decrypting anything.
- Login by phone number works without decrypting the user table
- Duplicate detection across a tenant without exposing any value
- The index is keyed with the same secret, so a database leak alone does not reverse it
- Used only for high-entropy values, where a deterministic index is safe
Purpose limitation
Every read declares why
Access control answers “may you?”. Purpose binding answers “why are you?”. Khepee requires both, and records the second.
- Seven lawful purposes, as a fixed enumeration
- A personal-data endpoint called without a purpose is rejected outright
- The purpose is written to the audit trail with the actor and timestamp
- Patterns of access are reviewable — an officer reading files they have no case for is visible
Access boundaries
Khepee’s own staff cannot read your borrowers’ data
The super-admin role — the one Khepee’s platform team holds — is deliberately not granted the borrower personal-data permission. This is a design constraint rather than a policy, and adding it would be a reviewable code change.
- Khepee staff can operate the platform, read the audit trail and diagnose faults
- They cannot read borrower names, phone numbers, addresses or documents
- Support work proceeds on request ids and hashed identifiers
- Partner institution staff see only their own institution’s borrowers
In transit and on device
The other places data can leak
Transport
TLS everywhere with HSTS preloading, strict transport headers and a restrictive content security policy.
Logs
A redaction list strips credentials and personal fields before anything reaches disk, as a safety net behind the rule that they are never logged.
On device
Session tokens in the platform keychain, never in plain storage. No borrower personal data cached on the phone.
Object storage
Documents addressed by key and served through short-lived signed links, never left publicly reachable.
Exports
Bulk export requires a distinct permission and a declared purpose, and personal fields are excluded unless the purpose requires them.
Browser
Console pages set no-store and no-referrer, so a URL containing an identifier is never handed to a third party.
Retention
Bounded, documented and not indefinite
Keeping data forever because deletion is difficult is the default failure mode. Retention periods are defined, documented and applied.
- Borrower records retained for five years after loan closure, consistent with AML expectations
- Audit entries retained for the relationship and the statutory period after it
- KYC verifications carry an expiry rather than remaining valid indefinitely
- Retention is stated in the privacy policy rather than left implicit
Key management
Rotation is a supervised runbook, never a quick change
Changing the encryption key without migrating the data makes every borrower record unreadable and stops anyone logging in, because the blind indexes are derived from the same secret. So the tooling deliberately refuses to do it automatically.
- A documented, staged procedure with a verified snapshot before anything changes
- Dual-key reads during migration, then a controlled cut-over
- Blind indexes recomputed rather than re-encrypted
- The old key removed only after a full verification cycle
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
Send us your data protection assessment
We would rather complete your standard assessment early than discover a blocker in month three.