Document collection · India
Ask once.
Their statements
arrive.
FinLens collects a customer's financial documents from their own Gmail, with their permission, and hands them to the one business that asked for them — yours. You get the files, plus the data read out of them, on a link that expires in three hours.
No upload step. No screenshots of net-banking. No shared passwords.
How the mailbox is read. The customer grants access on Google's own consent screen. FinLens requests gmail.readonly — read-only — and no wider Gmail scope, so it cannot send, change, label or delete mail. It asks Gmail only for PDF attachments from recognised financial senders.
Where the documents go. To one business: the one your customer approved by name on a FinLens page. No other party receives them.
FinLens's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. The Privacy Policy sets out what that means line by line.
- document the PDF, unlocked
- account holder read from the PDF
- statement period read from the PDF
- subject line never leaves FinLens
- sender address never leaves FinLens
What the picture shows: an example statement email. Everything greyed out stays in the mailbox — the subject line, the sender's address, the message id and the body have no field in anything FinLens can return, and a test walks every response we produce and fails the build if one of them appears. The highlighted line is the attachment. The document itself crosses, with the details read out of it, to the one business your customer approved; its filename does not.
Where this is today. The platform is built and deployed to a test environment, not to production. Google has not granted verification, so the consent screen still carries an unverified-app warning. 11 of the 187 senders in our registry are verified — each promoted only after a real message from it was captured and its signature checked. The other 156 issue no queries at all, so mail from them is not read rather than read unchecked. Coverage grows as senders are confirmed. We would rather you read this here than find it in a trial; the full version, control by control, is on the Trust page under what is not true yet.
How it works
One API call in,
documents out.
Six steps. Your customer sees two of them, and the second one names you.
post /v1/sessions
You ask
Send four identity fields — name, PAN, date of birth, mobile — and the document types you need. You get a link back.
consent · at google
They allow Gmail access
Google's own screen asks for read-only Gmail access. If they decline, nothing happens.
consent · on the finlens page
They approve you, by name
A FinLens page names your company, the document types, and how far back we look. Nothing is fetched before this.
fetch
We look, narrowly
We ask Gmail only for PDF attachments from recognised financial senders. After fetching, we check each message's cryptographic signature and drop what fails.
unlock · extract
We open what we can
Protected statements open with passwords derived from the identity you sent. The text is read on our own systems. No person reads it.
get /v1/sessions/:id/documents
You collect
The webhook tells you it is ready; you pull. Three hours later everything we produced is deleted.
What you receive
The documents themselves,
and what we read out of them.
The document
The original PDF — unlocked where we could open it, in its original form where we could not. A file you could not open is still a file you asked for, so it ships either way, with a specific reason attached rather than a generic "locked".
The extracted data
Account holder, account or policy number, statement period, balances, transactions, holdings. Machine-read from the document. It is not analysis, scoring or opinion, and the source PDF governs if the two ever disagree.
The webhook notifies; it does not deliver. Your endpoint is told a session is ready and you fetch from the API. A webhook outage therefore costs you nothing — but the pull window is the retention window. A nightly batch job will find nothing.
What we read
Narrow at the query,
not after the fact.
The limit is applied when we ask Gmail, so mail outside it is never retrieved rather than retrieved and discarded. That is the difference between reading less of a mailbox and only ever fetching documents.
| Scope | How far back |
|---|---|
| Recognised financial senders | 18 months |
| Institutions you name in the request | Full history |
| Insurers | Full history |
Every query carries the same gate — has:attachment filename:pdf — on every tier, without exception. Mail that does not carry a PDF is never requested, so it never enters our systems.
Naming an institution that is not in our registry fails when you create the session, loudly, before the link is minted — rather than being scanned to zero results after your customer has already consented. The resolved scope comes back in the response and is restated on the approval page, so you can compare what you asked for against what your customer was shown.
A From header is trivially forged, so we treat it as a way to ask for less and never as proof. Authenticity is established after fetching, from the message's cryptographic signature.
What we never do
The list that matters
is the short one.
Several of these are enforced by code rather than by policy. The interface through which anything leaves our systems has no field for a subject line, a sender address, a filename, a Gmail message id, a mailbox credential or a derived password — and a test walks every response we can produce and fails the build if one ever appears.
- We never sell your customer's data, and never use it for advertising.
- We never use it to judge credit-worthiness, and never supply it for lending decisions.
- We never train AI or machine-learning models on email or documents.
- We never fetch personal, non-financial mail — the query cannot express it.
- We never ask for more than read-only access. FinLens cannot send, change or delete mail.
- We never hand you the mailbox: no credential, no token, no standing access.
- No person at FinLens reads your customer's mail. There is no human-in-the-loop step.
- We never share documents with any party other than the one business your customer approved.
Google user data. FinLens requests one scope and no others: gmail.readonly. Its use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. The Privacy Policy takes each requirement in turn, under Google user data & Limited Use, and says how FinLens meets it. A customer can withdraw at Google at any time, and Data deletion explains the routes.
What FinLens does not do
The parts we would rather
you knew before signing.
Some documents will not open
HDFC savings, Yes Bank and Canara key statement passwords off a Customer ID; SBI Card and HDFC credit cards off the card number; LIC and most life insurers off the policy number. None of those is derivable from four identity fields, so those documents arrive unopened, naming the identifier that would have worked.
Some can never open
CAMS and KFintech mailback statements use a password the investor chose. No derivation will ever produce it, so they are marked permanently unopenable rather than consuming attempts on every request.
Gmail only
No Outlook, no Yahoo, no IMAP. A customer whose statements go to another provider cannot be served at all.
Tax is one document
The ITR-V acknowledgement, and nothing more. AIS, TIS and Form 26AS are portal downloads that never arrive by email, and a Form 16 in a mailbox came from a payroll vendor rather than the tax department.
Talk to us
Tell us what you
collect today.
The useful first conversation is about which documents you ask customers to upload today, and what happens when they do not. We will tell you plainly which of them we can fetch and which we cannot.
Partnerships · hello@finlenstech.com
Security · security@finlenstech.com
Privacy · privacy@finlenstech.com
Grievance officer · Suraj Agarwalla — suraj@maximoney.in
FinLens is operated by Value Garage Private Limited, CIN U66190DL2025PTC453505, registered at Flat no. 26, Vandana Apartment, East Delhi, Delhi — 110092, India. More about the company is on the About page.