Trust Center

Security & Compliance

Grappi sits between your product and India's regulated financial rails, so we hold broker credentials, consent artefacts and portfolio data on your behalf. This page describes the controls that are actually running in production today, the frameworks we design against, and — just as plainly — what is still on the roadmap. We hold no security certification and no independent audit or penetration test has been performed. Anything not listed as Live below is not yet in place, and we would rather you knew that before you integrated than after.

How we protect your data

Controls that are live today

Written for the engineer who has to sign off on us. Each item below is a property of the code in production, not an aspiration.

Encryption

Anything that would let someone act as your customer is sealed before it is written to disk.

  • Broker API credentials and RTA session cookies are encrypted at rest with AES-256-GCM envelope encryption — a per-record data key, itself wrapped by a master key held outside the database.
  • The API never returns them. Read paths null the credential column at the query, so a sealed secret cannot leave the platform through a response body, a log line or an error.
  • Card and UPI details never reach Grappi infrastructure. Payment flows run through Razorpay, and the callback signature is verified with HMAC-SHA256 using a constant-time comparison.
  • Production data is stored on infrastructure located in India.

Authentication & access

Credentials are stored in a form that is useless to anyone who reads the table.

  • API keys are stored only as SHA-256 hashes. The plaintext key is shown exactly once, at creation, and cannot be recovered afterwards — not by you, not by us.
  • Session tokens and one-time passwords are stored only as hashes. There is no plaintext column to leak.
  • Passwords are salted per user and verified in constant time.
  • Broker two-factor seeds are never stored. Your customer's 2FA with their broker stays intact and under the broker's control: Grappi passes a code through at connect time and keeps nothing that could generate another one.
  • API keys are scoped to the endpoints they need, and each key can carry its own IP allowlist and browser-origin allowlist.

Tenant isolation

Two independent layers, because application-level scoping alone fails the moment one query forgets a filter.

  • Every tenant-scoped query carries its tenant filter in application code, and the broker, consent and portfolio paths run inside a transaction-local tenant context rather than trusting a caller-supplied identifier.
  • PostgreSQL Row-Level Security is enabled and forced on the consent, audit, wallet, ledger and usage tables. The policy fails closed: with no tenant context set, those tables return nothing.
  • The application connects as a non-superuser database role, so it cannot bypass those policies.
  • Extending forced row-level security to every remaining tenant-scoped table is in progress — see the roadmap below.
  • Per-tenant rate limits apply to API traffic, and write operations accept an idempotency key so a retried request cannot double-execute.

Auditability

A log you can delete is not an audit log.

  • The audit log is append-only at the database grant level: the application role holds INSERT and SELECT on it and nothing else. There is no UPDATE and no DELETE to call.
  • Records are hash-chained — each entry commits to the hash of the entry before it — so a removed or rewritten record breaks the chain and is detectable rather than silent.
  • Row-level security is forced on the audit table too, so one tenant cannot read another tenant's history.

Consent & privacy

On India's rails, authorisation is a consent artefact, not a flag in your database.

  • Requests that touch an individual's financial data must be backed by a purpose-coded consent artefact, following the DPDP Act and the Account Aggregator consent framework.
  • Artefacts are verified fail-closed on every request. Missing, expired, revoked, or purpose-mismatched — the request is denied. There is no permissive default.
  • Consent records live in the audit and consent tables, under forced row-level security, so the decision trail is reconstructable.
  • Application secrets are supplied through environment configuration at deploy time and are not part of the application source.

Regulatory alignment

Designed against, not certified under

These are the frameworks that shape our control set. We are deliberately precise about the verb: aligned to and designed against mean we build to the requirement. Certified would mean an accredited third party had examined us and said so, and no one has. Nothing on this page is a certification, attestation or audit opinion.

Indian frameworks

SEBI CSCRF

The Cybersecurity and Cyber Resilience Framework is the control set our clients are measured against, so we design the platform to survive their diligence: governance, access control, encryption, tenant segregation, logging and incident response. We are not a SEBI-registered intermediary and do not self-certify under CSCRF.

RBI IT-outsourcing expectations

Regulated clients who outsource IT services carry audit, inspection and exit-plan obligations that reach their service providers. We build to be audit-ready for that: documented controls, a reconstructable audit trail, and data you can take with you.

CERT-In directions

The 2022 directions set India's incident-reporting and log-retention expectations. Centralised log retention is being built out now and is listed honestly in the roadmap below.

DPDP Act 2023

Consent is purpose-coded and verified per request; you are the data fiduciary for your end customers and we process their data only on your instruction. Rights, retention and grievance handling are set out in our Privacy Policy.

Global frameworks guiding the control set

NIST CSF 2.0

Used as the organising spine for our control set — Govern, Identify, Protect, Detect, Respond, Recover. It is where our own gap analysis is scored.

OWASP ASVS

Used as the application-level checklist for authentication, session handling, access control, cryptographic storage and error handling.

ISO/IEC 27001

A roadmap target, not a held certification. We have no ISMS certified today and say so plainly.

Grappi is a technology provider to regulated entities and is not itself a SEBI-registered intermediary or an RBI-regulated entity. Where a framework binds you rather than us, we aim to give you the artefacts your own regulator will ask for. This page is not legal advice.

Compliance roadmap

What is done, and what is not

Most trust pages only list wins. Yours is a procurement decision, so here is the whole board. Status words are the meaning — colour and shape only help you scan.

Control status as at 6 October 2026. Reviewed each quarter.
ControlStatusDetail
Envelope encryption for broker and RTA credentialsLiveAES-256-GCM, master key held outside the database.
Hash-chained, append-only audit logLiveINSERT/SELECT grants only; tamper-evident chain.
Fail-closed consent verificationLivePurpose-coded artefacts checked on every request.
Multi-factor authentication (TOTP) for platform administratorsIn progressDesigned and being implemented. Not yet enforced on admin sign-in.
Forced row-level security on every tenant-scoped tableIn progressEnabled and forced today on the consent, audit, wallet, ledger and usage tables; being extended to the rest.
Centralised log retention and alertingIn progressShipping application and access logs to retained, queryable storage.
Independent VAPT (vulnerability assessment and penetration test)PlannedNo third party has tested the platform to date.
ISO/IEC 27001 ISMS and certificationPlannedNo ISMS is in place and no certification is held.
SOC 2 Type IIPlannedNo SOC 2 report exists, and no observation window has begun.

Report a vulnerability

Responsible disclosure

If you have found a weakness in Grappi, we want to hear about it directly and we will not come after you for telling us.

How to reach us

Email support@grappi.ai with enough detail to reproduce the issue — endpoint, request, expected versus actual behaviour. This is the address named in our Privacy Policy, so it is monitored today. security@grappi.ai reaches the same team once that mailbox is live.

We aim to acknowledge every report within 72 hours and will keep you updated while we investigate and fix.

What we ask

  • Give us a reasonable window to fix the issue before publishing.
  • Use your own workspace and sandbox credentials. Do not access, modify or retain another tenant's data.
  • No automated scanning, load testing or denial-of-service against production.
  • No social engineering of our staff, customers or upstream providers, and no physical intrusion.

Recognition

We do not run a bug bounty programme and do not pay for reports today. We would rather tell you that up front than waste your time.

What we do offer: we credit researchers who report in good faith, by name or handle, with your permission — and we will tell you when the fix ships.

Questions from your security team?

Send us the questionnaire. We will answer what is true, say "not yet" where it is not, and point you at the roadmap item instead of inventing a control.