Security

Specifics, because “bank-grade” means nothing.

You are being asked to put your borrowers’ records into somebody else’s system. These are the mechanisms, described precisely enough that your IT reviewer can argue with them.

Tenant isolation: Every table that holds tenant data carries a tenant key with a foreign key to the tenant, and every query path is scoped by it at the data layer rather than by each caller remembering. No option exposed anywhere disables that predicate. Row-level security is enabled underneath as a second line.
Data scope within a tenant: A role carries a scope — own, branch, region or the whole tenant. Lists, reports and exports are filtered by the acting user's scope, so a branch manager's export contains their branch.
Role-based access: Permissions are granted to roles and roles to users; every route checks a named permission before it does anything. Screens that a role cannot use are not in its menu, and the underlying route refuses independently — a hidden menu item is not a control.
Two-factor authentication: Time-based one-time passwords, per account. Sessions carry an idle timeout and an absolute lifetime.
Audit trail: Every mutation writes an append-only record: who, when, and the before and after state. Sanction, disbursement and rejection are immutable events — a correction is a reversing entry, never an edit.
Personal data: Aadhaar is stored masked to the last four digits; the full number is never persisted. Report exports mask personal identifiers by default, and the two places that emit a full PAN — the credit bureau submission file and the DNBS-2 large-borrower schedule — do so because the recipient cannot match the record without it, each behind its own permission.
Financial records: Postings are immutable. There is no code path that updates or deletes a financial transaction; corrections are reversals, which is what makes the ledger auditable at all.
Credentials and secrets: Passwords are hashed with bcrypt, never stored or recoverable. Two-factor seeds and the credentials for every external integration you configure — bureau, eNACH, eSign, CKYC — are encrypted at rest with AES-256-GCM under a key held outside the database, so a copy of the database alone does not yield a working credential.
Request limits: Every route is rate limited on a shared counter rather than per server, so the limit is the same whichever instance answers. A caller that exceeds it gets a 429 and the standard headers saying when to retry, rather than a silent failure or a slow one.

Hosting and continuity

Where it runs, and what we will confirm in writing

Hosting region, backup frequency, retention and the recovery objectives are settled per engagement and stated in the agreement. We would rather write them into your contract than publish a figure here that your reviewer cannot hold us to.

Data location

Deployed in an Indian region. The specific provider and region are confirmed at contracting.

Retention

Regulatory records are never hard-deleted. Retention periods follow the Companies Act and the RBI directions applicable to your class of NBFC.

What we do not claim

The list most vendors leave off

A security page is easy to write and hard to verify, so here is the part that is checkable: what is absent, and why.

We hold no ISO 27001, SOC 2 or PCI DSS certification, and no RBI approval or registration — Lenviq is software licensed to lenders, not a regulated entity.

We publish no availability figure, because we do not yet measure one over a period long enough to be worth stating.

We name no customers and quote no endorsements — we would rather show the product than a logo wall.

If any of these becomes true, it will appear here with the date it became true. Until then, an absent claim is worth more to you than a confident one.