Trust Center

Client data is stored in a single-country, single-region deployment: Postgres running on an Oracle Cloud Infrastructure server in Mumbai, India. Nightly encrypted backups are copied to AWS ap-south-1 (Mumbai) - chosen specifically because it is a pinnable India region, kept outside the primary hosting provider so a single vendor incident cannot take out both the live database and its backups.

Every third party that touches platform data, and what it receives. We do not sell data, and we notify advisors before adding a new subprocessor to this list.

Advice and client communication are delivered in-app by default. The client portal is always the primary channel and involves no third party. WhatsApp is off unless an advisor enables it and the individual client adds and verifies their own number - no phone number reaches Meta before that.

When it is on, it carries only a nudge - that your advisor has sent something and to open the app. The recommendation itself - the stock, the action and the price - never leaves Niveshraai.

The client database itself is stored and queried only in India - it is never copied or replicated outside it. Three subprocessors process specific fields outside India - AI processing, transactional email, and WhatsApp delivery - each receiving only what is listed above for that row, never the client database.

Analytics on this marketing site runs on a self-hosted instance of Umami, on our own domain - no third-party analytics vendor receives visitor data. The product itself (the CRM advisors and their clients use) never loads any third-party analytics script, by standing policy.

Data is encrypted in transit everywhere (TLS, with HSTS enforced in production). At rest, client identity/KYC data is encrypted with AES-256-GCM under a key held by the application, so it stays ciphertext even in a database dump, and PAN numbers are stored masked and hashed rather than in the clear. Payment gateway credentials are encrypted separately, per advisor. The underlying storage volumes are additionally encrypted at rest by our cloud provider (AES-256, provider-managed keys), which covers the remaining ordinary contact fields (name, email, phone) against physical media compromise.

Key custody is being hardened, and we would rather say so than imply it is finished. Encryption keys are currently held in server configuration on the application host. Moving them into a dedicated secrets manager in the same India region, deliberately outside the tenancy that hosts the application - so that a restored backup can never be left as unreadable ciphertext - is underway and has been rehearsed end to end; see the progress note below.

Our own team’s access to client data is deliberately narrow: a separate internal console, isolated from the public internet, requires two-factor authentication before any data access, shows client personal information masked by default, and every instance of an admin viewing unmasked data is written to a tamper-evident, append-only audit trail that cannot be edited or deleted - enforced at the database level, not just by convention.

Niveshraai uses AI, from a single model provider, Anthropic, in exactly three places, listed below with exactly which fields each one sends. Nowhere else in the product calls an AI model.

No AI call made by Niveshraai ever includes a client’s name, PAN, contact details, holdings, or risk profile. None of the three features below have a reason to send them, and a pre-flight check on the compliance-review feature blocks the request rather than silently stripping the text if a PAN-format number is typed into it.

Sends: a ticker symbol, its exchange, and the company name. Purpose: drafting research commentary on a listed security. Nothing about any client is involved - this feature runs before any client is attached to the output.

Sends: the advisor’s own outgoing advice text, plus whether that advisor is currently PaRRVA-verified (a true/false flag). Purpose: screening the advisor’s own words against SEBI’s advertisement code before they reach a client - this is the advisor’s draft, not client data.

Sends: a model portfolio’s own parameters - name, investment horizon, rebalance frequency, benchmark, risk level, and constituent ticker symbols. Purpose: drafting the methodology description for a portfolio product, not for any individual client’s holdings in it.

We do not grant Anthropic permission to train on any data sent through these features. Read Anthropic’s own published commercial data-retention terms rather than our summary of them: privacy.claude.com - organization data retention.

Client data is backed up nightly to a separate cloud provider in the same region (see Data residency above) - a recovery point objective of 24 hours. A full restore drill measured a recovery time of roughly 2–4 hours (the restore itself takes minutes; most of that window is re-provisioning, DNS/TLS, and reconnecting third-party integrations) - measured on our staging environment, and re-run whenever the underlying infrastructure changes, including the planned move to a new production server. We log operational incidents and alert our team when one occurs; a written breach-notification commitment is in progress - see below.

The honest state of what is not finished yet, with a target rather than silence:

• Full data export (Q4 2026): a single advisor-triggered export of everything in their account, so leaving the platform never depends on us.
• Mandatory two-factor authentication for advisors (Q4 2026): already available today as an opt-in; becoming a requirement.
• Off-tenancy key custody (Q4 2026): encryption keys move from server configuration into a dedicated secrets manager held outside the hosting account, so that losing the hosting account cannot render a restored backup permanently unreadable. Rehearsed on our staging environment; completing at production cutover.

For a detailed security questionnaire response, or any question this page doesn’t answer, contact [email protected].

To exercise a data-protection right or raise a privacy grievance, our named Grievance Officer and the response times we commit to are listed in the Privacy Policy.