Risk management

Controls that hold when nobody is watching

A control that depends on someone remembering is not a control. The ones that matter are the ones the system will not let you break — and those are the ones Khepee is built around.

Credit risk

One policy, applied identically

The largest source of unexplained credit variance in a manual operation is the human distribution of judgement. Codifying the policy does not remove judgement — it removes the accidental variation around it.

  • A configured scorecard applied to every application without exception
  • Factor-level contributions visible, so a decision can be explained
  • Officer override permitted where your policy allows, and always recorded with a reason
  • Score version retained with the decision, so history stays interpretable

Compliance risk

Limits that cannot be exceeded, even by mistake

Regulatory limits are enforced at four independent layers. A single refactor, a single careless migration or a single direct database write cannot get a non-compliant loan into the book.

  • A decision function that is the only place a limit is evaluated
  • Schema-level rejection at the API boundary
  • A service-layer clamp when a product is configured
  • A database-level hook that rejects an over-limit product on write
NRB CEILING

Operational risk

Duties that stay segregated

Role-based access control with deny-by-default. A role receives exactly the permissions listed for it, and permission alone is not sufficient — the tenancy guard still decides which records it applies to.

  • Four roles with explicitly enumerated permissions
  • Permission grants the action; the tenancy guard grants the record
  • Khepee’s own administrators cannot read borrower personal data
  • Two-factor authentication available for staff, and account lockout on repeated failure

Evidence

An append-only record of everything

The audit trail cannot be edited or deleted — those operations are blocked at the model layer, and 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 stored as a hash within the trail
  • Every personal-data read recorded with its declared purpose

Fraud risk

The controls that catch the common cases

  • Duplicate applications

    Detected against an encrypted deterministic index before submission, across the whole tenant.

  • Session theft

    Refresh tokens rotate on use. A replayed token revokes the entire session family and forces re-authentication.

  • Enumeration

    Login failures are uniform and timing-equalised, so the API cannot be used to discover who has an account.

  • Double disbursement

    Idempotency keys on every instruction; a replay returns the original result rather than paying twice.

  • Insider access

    Every personal-data read is attributable to a named person and a stated purpose, and is reviewable.

  • Data exfiltration

    Bulk export requires an explicit permission and a declared purpose, and is logged.

Technology risk

The risks we carry, stated plainly

Any honest risk section includes the vendor’s own exposures. These are ours, and how they are managed.

  • Key management — PII key rotation is a supervised runbook, never an ad-hoc environment change
  • Availability — recovery objectives defined in the agreement rather than assumed
  • Concentration — your data is exportable in full at any time, so we are not a single point of failure
  • Change — compliance-critical logic is covered by tests that block a release if weakened

Coming soon

Send us your risk questionnaire

We would rather answer your standard vendor risk assessment early than discover a blocker in month three.