Security

Tenant isolation at the database layer, passwordless sign-in, single active session, and an honest list of the certifications we do not hold.

Reference Last reviewed 5 min read

On this page — 10 sections

Most bank and NBFC evaluations open with a security questionnaire. This page answers the substantive parts of one upfront, including the questions where the answer is “we do not have that.”

Position as at 22 August 2026.


The shortest true summary

TatvaRatings holds public rating disclosures, plus a customer’s own watchlists and notes. Customers do not upload data to it. There is no loan book in the platform, no borrower file, and no personal data beyond the user accounts of the people who sign in.

That single fact removes most of what a security questionnaire is designed to protect against. It does not remove the need for the controls below, and it does not entitle us to claim certifications we do not hold.


Tenant isolation

The platform is multi-tenant on PostgreSQL. Isolation is enforced at the database layer by PostgreSQL Row-Level Security, not only in application code.

The connection used to serve customer requests runs as a restricted database role without BYPASSRLS. Row-level policies bind every query in that session to the tenant it belongs to.

The practical consequence is the one that matters in a review: if a developer forgets a tenant filter in a query, the query returns zero rows. It does not return another tenant’s rows. The failure mode of a coding mistake is an empty result, not a cross-tenant disclosure.

Application-layer checks exist as well. They are a second layer, not the only one.


Authentication and sessions

Passwordless one-time codes. Sign-in is by a single-use code sent to a work email address. There is no password to set, rotate, reuse, phish out of someone, or find in a breach corpus, because there is no password.

Single active session per user. A second sign-in invalidates the first. A shared credential therefore does not produce two concurrent users — it produces one person repeatedly ejecting the other, which surfaces the sharing rather than hiding it.

Roles resolved per request. A user’s role is read from the database on each request rather than carried inside the token. Revoking or changing access takes effect on the next request, not at the next token expiry.

No self-service signup. There is no public registration path. Access is provisioned to an organisation, and users are provisioned inside it. How access is arranged →


Separation of staff and customer surfaces

Staff and administrative surfaces sit on a separate access path from customer routes. They are not a hidden mode of the customer application reached by a role flag on the same URLs.


What data actually exists in the platform

CategoryHeld?Detail
Public rating disclosuresYesRating actions, borrowers, rated facilities, lender-wise annexure rows, key financials and rating drivers, parsed from publicly published press releases. Sources →
Customer watchlists and notesYesCreated by the customer’s own users inside their tenant.
User accountsYesName, work email, organisation, role.
Customer loan book or borrower filesNoThere is no upload path for customer data.
Personal data about borrowers or individualsNoThe corpus is company records from public disclosures.
Payment card dataNoNot collected or processed by the platform.
Credit bureau data or supervisory returnsNoNo non-public source of any kind is used.

Because customers do not upload data, the standard question “what happens to our data if we leave?” has a short answer: the only customer-originated content is the watchlists and notes their own users created, and those are deleted on request.


Where the source data comes from

Every record traces to a publicly published rating press release, with the source agency, source document and publication date carried alongside it. No supervisory returns, no bureau data, no confidential lender submissions. Methodology →


What we do not have

Stated plainly, because a procurement team will ask and an evasive answer costs more than a straight one.

  • No ISO 27001 certification. We do not hold one and do not claim one.
  • No SOC 2 report. We do not hold one and do not claim one.
  • No published penetration test report. We make no pen-test claim.
  • No uptime SLA figure on this site. Any availability commitment is a contractual matter, agreed in writing, not a number advertised here.
  • No regulatory status. TatvaRatings holds no registration, licence, recognition or approval from the RBI or SEBI. It is not a credit rating agency, not a credit information company, and not a reporting institution under any supervisory framework.
  • No agency relationship. No partnership, endorsement, authorisation or affiliation with any credit rating agency.

If a certification is a hard gate for your organisation, tell us early. That is a legitimate procurement requirement and we would rather know at the first exchange than at the fourth.


Security questions this page does not answer

Some questions are properly answered in a contract or under NDA rather than on a public page — hosting region and infrastructure detail, backup and retention schedules, incident response commitments, sub-processor lists, and any availability undertaking.

Send your questionnaire and we will complete it as it is written, marking anything we do not have as not held rather than as not applicable.

Talk to us →


Privacy

How personal data is handled — user accounts, notes, and the contact form — is set out on Privacy. The short version is that the corpus itself contains no personal data, and personal data at TatvaRatings is limited to the people who use it.


  • Privacy — personal data handling, DPDP-aware
  • Terms — terms of use
  • Data limits — what the dataset does not cover
  • Sources — where the documents come from
  • About — who is behind this

Tell us the borrower, bank or sector you would start from. We will tell you what the current corpus can and cannot answer for it.

Talk to us