Trust & security

Security & compliance

Last updated 27 October 2026 · Value Garage Private Limited · CIN U66190DL2025PTC453505
Report a vulnerability: security@finlenstech.com

FinLens lists the emails in a person's Gmail that are likely to carry their financial documents, with the text of each, with their consent, for the one business they approved, and retrieves the files that business asks for. This page sets out how that data is protected, for the security reviewer at that business. What an end user is promised is in the Privacy Policy.

Assurance

CASA is the independent assessment Google requires for restricted scopes; it is an assessment, not a certification. The platform is built to OWASP ASVS Level 2.

Limited Use

FinLens's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. A client that receives an index or documents is bound to the same requirements by our Partner Terms.

What we do not claim

• No ISO 27001 certification, SOC 2 report or third-party penetration test.
• No bug bounty programme. Reports go to the address below.
• Our incident-response runbook is written but has not yet been exercised, and there is no 24/7 on-call.
• No key-rotation schedule. Keys are versioned, so a rotation will not orphan existing records.
• No formal approval workflow for operator access.
• No end-user portal. A consent is withdrawn in the client's app, at Google, or through our grievance officer (see below).

What we access, and what we never do

A person approves FinLens on Google's own consent screen, after the business has shown them FinLens's standard disclosure. Nothing is read before that approval.

• Read-only. One scope, gmail.readonly, fixed in code. We cannot send, change or delete mail.
• An index of what seven fixed searches find: Gmail's own search, run on Google's side, selects the emails — proofs of identity, loan and property papers, investment statements, fixed-deposit advices and card statements the person received, and files they sent to banks, lenders, housing-finance companies and builders, each search over its own period, from ten years to 45 days. The searches' terms (subject and file-name words, file types, routine senders to leave out, and lender and builder domains for sent mail) are one configuration in our code, versioned, the same for every person and every client, and recorded with each check; no client input changes them, and no search has a cap. Mail in Spam, Trash, Drafts and Chats is never read. Embedded pictures (an image part with a Content-ID, such as a logo or a signature image) are not listed, and nor is a file larger than 25 MiB (26,214,400 bytes), the most a fetch takes. We judge no sender ourselves: there is no registry of institutions and no signature check of our own.
• The email's text, and the headers the index needs. Each message the searches find is read once, in full, with a field mask. Its text is the plain-text part, or the HTML part turned into plain text on our server (scripts and styles dropped, links kept), at most 100,000 characters, with no AI and no interpretation. Of its headers, only From (with the sender's name), To, Subject, the parts' Content-* lines and Gmail's own Authentication-Results line (the one Gmail adds at delivery, from mx.google.com, never one a sender could write) are decoded — an email's date is Gmail's own record of when it arrived; the rest — Cc and Bcc among them — are never decoded, kept, logged or passed on, though the email's text, delivered as written, may quote them. The conversation an email belongs to is passed on only as a reference made under the consent's own key, never Gmail's thread id. The text, the sender's name, Gmail's verdict and the conversation reference are given only under consents on version 6 or later of the standard disclosure.
• When, and how fast. Approval reads nothing: a consent's first check runs only when the client asks for its index, usually lists a few hundred emails, and is ready within a few minutes of that request; later checks run the same searches over the mail that arrived since the last index the client collected was made (or, if it collected none, over each search's own period). The index is written in pages of up to 500 emails as it is read, each sealed under the KMS key as it is written, so a worker holds at most one page in memory. Each part can be collected for 3 hours after it is ready. Gmail is read at about a hundred emails a minute — paced on Google's own prices, just under its per-user limit, so as not to be refused — and a request for files goes ahead of the listing; three workers run, one of them for requests for files alone, so one check holds up no one else's.
• An index first, then only what is asked for. A check returns an index of the email in scope. A file is fetched from Gmail only when the client asks for it by reference, while the consent lasts.
• One recipient: the business the person approved.
• No identity, no unlocking, no AI. FinLens accepts no name, PAN, date of birth or mobile number, opens no locked file, and sends nothing to any AI service.

The index gives, for each email, its date and time, the sender's name, its From and To addresses, its subject line, the text of the email, whether it was received or sent, which searches found it, for received mail Gmail's DKIM, SPF and DMARC results, a conversation reference, and each file's name, content type and size, with a sealed reference. It never carries Cc or Bcc, any other header, or Gmail's own message, thread or attachment ids. The client then receives each file it asks for, exactly as it was sent: a locked file is delivered locked, and no password is ever guessed, held or used by FinLens — though an email's text, delivered as the sender wrote it, may contain one, which FinLens neither looks for nor removes. Our Partner Terms require the client to treat that text as sensitive personal data and never log it, and, because no sender is checked by us, to scan every file it fetches for malware.

• We never store an email. Other headers and the part structure pass through memory and are never written to disk, and files no one asked for are never fetched. The text of an email, its subject line, names, addresses and file names exist at rest only in an encrypted index, each page for at most three hours, and a fetched file's name and From address only with that file, for the same three hours.
• We never read inside a document. No text extraction, no OCR, no parsing and no AI runs on any document or image. The software to do so is not installed.
• No person reads customer data. No one at FinLens reads a user's mail, an index or a document, and there is no manual review step for any of them.
• No third party receives an index or a document. Both are handled only on our own infrastructure and delivered only to the approved client.

Data lifecycle

The 3-hour and 6-month limits are hard ceilings: a service configured above either refuses to start, and a scheduled sweep deletes everything past its deadline. A consent given before this page's date keeps the twelve months it was given for.

Ending a consent

A consent ends at its term, or earlier in the client's app (our Partner Terms require one), at myaccount.google.com/permissions, or by writing to our grievance officer. Its Gmail grant is then revoked at Google and deleted, its reference key destroyed, so no reference the client holds can fetch anything more, and any index or delivery of it not yet pulled is deleted at once and no longer served. See Delete your data.

Security controls

• Envelope encryption. AES-256-GCM, a data key per record, wrapped by a master key in Google Cloud KMS. In production every service refuses to start without the managed key service. Each consent also has its own key for the references in its indexes, wrapped the same way and destroyed when the consent ends.
• No file on disk, and none opened. Files are handled as bytes in memory, with no temporary file, and FinLens never opens one. At rest an index or a document exists only as an encrypted database record.
• Tenant isolation in the database. PostgreSQL row-level security, enabled and forced, on every client-scoped table, for an application role that cannot bypass it.
• Signed credentials, short-lived tokens. A client's API secret only signs (HMAC-SHA256, with timestamp and nonce) a request for a bearer token. Tokens last one hour by default, one day at most, and are stored only as a digest.
• Allow-listed egress. Application services have no route out except an egress proxy that reaches Google's Gmail, OAuth and Cloud KMS hosts and onboarded clients' webhook hosts, and refuses private addresses. Outside it: the edge web server (TLS certificate renewal) and the operator console, reachable only through an SSH tunnel, with password and TOTP.
• Hardened containers. Read-only filesystems, all capabilities dropped, no-new-privileges. Only the edge server has a public port.
• Email fields leave only in the index and with a fetched file. Cc, Bcc, other headers and Gmail's own ids are forbidden in every API response, webhook and log line, enforced by schemas, tests and the logger. The email's text, the sender's name, Gmail's sender results and the conversation reference are forbidden everywhere except the index; subject, file name, From and To everywhere except the index and a delivered document, which carries its file's name and its email's From address. No log line carries any of them.
• Webhooks are HTTPS-only, signed, and carry no index and no document.
• Append-only audit trail, hash-chained so any edit is detectable.
• Engineering. Strict TypeScript, validation at every boundary, rate limiting, and an automated test suite on every change.

Infrastructure & data location

Customer data is stored and processed in India (Privacy Policy §11). FinLens runs as isolated containers on one server in Bangalore, hosted by DigitalOcean; the PostgreSQL database runs on that server. The master encryption key is held in Google Cloud KMS in Mumbai (asia-south1), and the database's nightly backup, encrypted under that key before it leaves the server, in Google Cloud Storage in Mumbai, where each backup is deleted within eight days. The site, the consent link and the API are served only over HTTPS. Cloudflare runs the DNS for our domain only: it answers lookups of our host names and carries none of the service's traffic.

Sub-processors

Two providers process data on our behalf: DigitalOcean, and Google Cloud for two services. A new one is listed here before it touches any data.

No index or document reaches a third party: there is no OCR, document-processing, AI or analytics vendor. Google is the source of the data, read at the user's direction, rather than a processor. Let's Encrypt receives only our host names, to issue TLS certificates, and Cloudflare answers DNS lookups for them; neither sees any data.

Our clients

Incident response & reporting a vulnerability

If something goes wrong

We follow a written incident-response runbook. One operator command ends every live consent at once: it revokes each Gmail grant at Google and tells each client. If a breach involves personal data, affected people are told without delay, through the business they came through, and the Data Protection Board of India receives full detail within 72 hours, as set out in the Privacy Policy.

Reporting a vulnerability

Write to security@finlenstech.com with enough detail to reproduce the issue, and give us reasonable time to fix it before publishing.

• We acknowledge a report within five working days.
• We will not pursue legal action against good-faith research that stays within scope, avoids privacy violations and does not degrade the service.
• We will tell you what we found and when it was fixed, and name you as the reporter if you would like that.

Please do not test against a real user's mailbox or a client's data.

Contact

Security reports · security@finlenstech.com
Privacy questions · privacy@finlenstech.com
Grievance officer (DPDP) · Suraj Agarwalla — privacy@finlenstech.com

Value Garage Private Limited · CIN U66190DL2025PTC453505
Registered office: Flat no. 26, Vandana Apartment, East Delhi, Delhi, India — 110092

Related: the Privacy Policy (an end user's rights) and the Partner Terms (a client's obligations).