Security
Written into the code, not into a policy
Security claims are cheap. What follows is a description of specific mechanisms, including the ones that constrain us — because a vendor that only lists its strengths has not thought about its threat model.
Credentials
Borrowers have no password at all
A credential that does not exist cannot be phished, reused across sites or leaked in someone else’s breach. Borrowers authenticate with a phone number and a one-time code; staff use a password with optional TOTP.
- Argon2id for staff passwords — memory-hard, so a leaked hash table is expensive to attack
- One-time codes hashed at rest, time-limited and attempt-capped
- Rate limiting on codes keyed to the phone number rather than the IP address
- Account lockout after repeated failures, with a uniform, timing-equalised failure response
Sessions
A stolen refresh token destroys the session it came from
Refresh tokens rotate on every use and are grouped into a family. Presenting one that has already been exchanged means it leaked — and since we cannot tell the attacker from the legitimate client, the whole family is revoked.
- Only hashes are stored, so a database leak does not hand over live sessions
- Rotation on use, with reuse treated as proof of compromise
- Detected reuse revokes every session for that user and is audited
- Clients serialise refreshes so concurrent requests cannot trip the detection
Authorisation
Permission grants the verb; tenancy grants the record
These are separate checks on purpose. Permission alone would let an officer at one institution read another institution’s applications. Tenancy alone would let a borrower approve their own loan.
- Deny by default — a role holds exactly the permissions enumerated for it
- Four roles: platform admin, institution admin, institution officer, borrower
- Tenant scope taken from the signed token, never from a request parameter
- A cross-tenant lookup returns 404, never 403 — a 403 would confirm the record exists
Multi-tenancy
Isolation verified rather than asserted
Every tenant-scoped query is built through a helper that applies the tenant clause. An automated check scans routes and services for any query that bypasses it.
- A single helper constructs every tenant-scoped filter
- A compliance script flags queries that mention neither the helper nor a tenant key
- Borrower records scoped to the institution they applied to, never pooled
- Any new tenant-scoped endpoint requires an isolation test before it ships
Application security
The ordinary controls, done properly
Input validation
Schema validation at every API boundary, with the parsed value replacing the raw one so no unvalidated input reaches a model.
Injection
Strict query mode, so a typo in a filter key cannot silently widen a tenant-scoped query into a cross-tenant one.
Transport
TLS with HSTS preload, strict CSP, no-sniff, frame-deny and a restrictive permissions policy.
Rate limiting
Global, per-route and per-identifier limits, with credential endpoints held to a much tighter budget.
Payload limits
A capped request body size — the cheapest defence against memory-exhaustion posts.
Secrets
Environment-only, validated at boot. The process refuses to start with a mock provider or an echoed OTP in production.
What we have not done yet
The gaps, stated before you ask
Khepee is pre-launch. A security page that implies a mature programme at this stage would be the first thing to distrust.
- No independent penetration test yet — one is scheduled before any production borrower data exists
- No SOC 2 or ISO 27001 certification, and we will not imply otherwise
- Vendor integrations are unwired by default; each will need its own security review
- Availability commitments will be defined in the partnership agreement, not assumed here
Disclosure
If you find something, tell us
We would much rather hear about a vulnerability from you than from an incident. Good-faith research reported through our disclosure channel will not be met with legal threats.
- A dedicated security address, monitored
- Acknowledgement within two business days
- No legal action against good-faith research that follows the policy
- Credit given to reporters who want it
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
Put us through your security review
Send the questionnaire. We will answer it fully, including the questions where the answer is “not yet”.