Skip to content
Back to Bloom

Security Practices

How Bloom protects the data you choose to share with it.

Bloom — Security Practices

Last updated: 9 August 2026

How Bloom protects your financial data, in plain language. We describe only what is actually built.

Grievance Officer

Sahil Baid — Grievance Officer and Data Protection Officer for Bloom.

  • Email: grievance@mybloomapp.com
  • We acknowledge every grievance within 72 hours and aim to resolve within 30 days.
  • If you are not satisfied with our response, you may escalate to the Data Protection Board of India.

Where your data lives

  • All personal data is stored in India — the AWS Mumbai region (ap-south-1), through our hosting provider Supabase.
  • The only data that leaves India is the redacted payload sent to Anthropic in the United States when you use an AI feature. That is covered by a separate, explicit consent and described in detail in Privacy Policy §8 (/privacy).

Encryption

  • In transit — TLS on every network call.
  • At rest, infrastructure — the database and file storage are encrypted at rest by our hosting provider.
  • At rest, application layer — your chat messages and coach-memory facts are additionally encrypted field-by-field, with the key held outside the database. A stolen database dump shows unreadable ciphertext for those fields.

Being precise: that second, application-level layer covers chat and coach memory. Your other data — such as transactions — is protected by infrastructure encryption plus strict per-user access control, not by a second encryption layer. We would rather state this exactly than imply more than we do.

Access control

  • Row-level security on every table. The database itself enforces that a user can only read or write their own rows — it is not left to application code to remember.
  • No passwords. Sign-in is a one-time code sent to your email, so there is no password to leak or reuse. Signing out revokes every session on every device.
  • Server-side authorisation. Sensitive operations re-check your identity and your 18+ attestation on the server, not just in the app.

Sensitive-data minimisation

  • We never read your SMS. Bloom does not request the Android SMS permission.
  • PII redaction. PAN, Aadhaar, card numbers, IFSC codes, UPI VPAs, emails, phone numbers and long account numbers are pattern-redacted from your text before storage and before any AI call.
  • Statement PDF passwords are never stored. If your statement is password-protected, the password is used once, in memory, to unlock the file, and is then discarded — it is never written to our database.
  • Prompt-injection defence. Text that arrives from your data — merchant names extracted from statements, goal names — is sanitised before it reaches the AI, including look-alike and hidden-character forms, so it cannot smuggle instructions into the model.
  • No government IDs, contacts, photos, location, camera or microphone are collected at all.

Account-takeover defence

  • 24-hour cooling lock. After any new sign-in, the most sensitive operations — data export, account deletion, statement parsing and plan generation — are blocked for 24 hours, and the AI chat withholds your detailed financial data. A hijacked session cannot immediately read or exfiltrate everything.
  • Rate limits on sign-in codes, chat, uploads and plan generation, enforced on the server.
  • Audit logging of security-relevant events such as sign-ins, exports and deletions, storing only a coarse IP range rather than your full address.

How we verify this, rather than just intending it

  • Automated security regression tests run on every change. These pin specific security properties — that the data export decrypts your chat rather than shipping ciphertext, that erasure covers every table, that the AI-input sanitisers hold, that no marketing claim asserts a partnership we do not have. A change that breaks one of them fails the build.
  • Internal adversarial review. We deliberately attack our own product — prompt-injection attempts, attempts to read another user's data, attempts to bypass the age gate — and fix what we find before release.
  • Enforced compliance filters on AI output. Bloom's refusal to recommend specific products or promise returns is not left to the AI's good behaviour; it is a server-side filter applied to every response.

What we do not claim: Bloom has not undergone a third-party security audit or penetration test, and holds no security certification. If that changes, we will say so here, name the auditor, and date it.

AI disclosure

Bloom's chat replies and its AI Financial Plan are generated by an AI model (Anthropic's Claude), and are labelled as AI-generated inside the app. Bloom remains accountable for that output, including errors and omissions. AI output can be wrong — it can misread a statement or miscategorise a transaction — so check anything you intend to act on. This disclosure is made under SEBI (Investment Advisers) Regulations 18(9).

Education, not advice

Bloom is an educational personal-finance app. It is not a SEBI-Registered Investment Adviser, an IRDAI-licensed insurance broker, or a Chartered Accountant. Bloom never recommends a specific stock, mutual fund, insurance policy or broker by name, and never promises a return. Bloom earns no commission, referral fee or revenue share from any financial services provider — it has no such arrangements at all. For advice specific to your circumstances, consult a registered professional of your own choosing.

Responsible disclosure

Found a vulnerability? Email grievance@mybloomapp.com with the details. We will acknowledge within 72 hours, we will not pursue good-faith researchers, and we are happy to credit you.

Breach notification

If a breach affects your personal data, we will notify you and the Data Protection Board of India as required by DPDPA Sec 8(6).

Questions about this page? Email hello@mybloomapp.com.

Bloom is an educational personal-finance app, not a SEBI-Registered Investment Adviser. Nothing on this page or in the app is investment, tax, or insurance advice.