Precisa.in
Democratising Risk Profiling - AI statement analysis
Once a bureau score comes back clean, there's a natural tendency to fast-track the file. But CIBIL scores measure repayment history - they have zero visibility into circular fund flows, mule account patterns, or structuring behaviour.
Under RBI's KYC Master Direction and PMLA obligations, NBFCs are required to conduct AML due diligence at origination, not reactively after delinquency.
The five patterns that matter most at this stage, circular transactions, dormant account reactivation, cash structuring below ₹50,000 CTR thresholds, UPI mule signals, and income-expenditure mismatches against GST, are all visible in the bank statement before a rupee is disbursed.
Precisa's AML Analysis module flags all five automatically, across 850+ Indian bank formats, with a documented audit trail that satisfies CIMS reporting requirements.
Run AML before the bureau check. Not after.
Tally needs every single one mapped to a ledger head before it can do anything useful.
Converting the PDF was never the hard part. The hard part is what comes after manually deciding whether each transaction goes under Sales, Sundry Debtors, Direct Expenses, or one of the dozens of other GL heads your client uses.
Get one wrong and your trial balance won't tally. Then your accountant spends hours in reconciliation tracing back a single misclassified entry, when they should be finalising the books.
Precisa's Tally GL Converter solves this at the source.
Upload the bank statement. Import your GL file to bring in all your ledger codes. Map transactions to GL heads in bulk via the Counterparties tab or go line by line on the Transactions tab if needed. Review everything under the GL Tags tab. Then export a file that goes straight into Tally. No reformatting. No manual entry.
Bank statement to Tally-ready file in minutes, not hours.
Free to start. No credit card. No setup. Used by 1,000+ clients across 25+ countries.
Most Indian lenders collect ITR as a compliance requirement. Upload the document, note the declared income, move on. The document is treated as evidence of income, not as a source of analytical signal.
That is leaving a significant amount of credit intelligence on the table.
An ITR document contains declared income by head — salary, business income, capital gains, other sources. It contains depreciation claims that reveal asset ownership. It contains interest income that indicates liquid savings. It contains loss carryforwards that tell you about the business's recent trajectory.
When you read an ITR properly, it tells you things the applicant may not have disclosed in conversation: multiple income sources, business losses in prior years, property income that suggests undisclosed liabilities, or capital gains that indicate asset sales the borrower hasn't mentioned.
More importantly, it gives you a third data point alongside the bank statement and the GSTR. In a clean application, all three tell the same story. In a fraudulent or misrepresented one, they diverge. The divergence is the signal.
We launched ITR analysis in Precisa because our lending clients kept telling us the same thing: they were collecting ITRs but not extracting value from them. Analysts were reading declared income from the summary page and ignoring everything else. Automation changed what was practical to extract.
If you are building lending workflows for Indian borrowers: treat ITR as a cross-verification tool, not a compliance box. The delta between what it shows and what the bank statement shows is where the credit decision actually lives.
We build financial document analysis software for Indian lenders. Over the past two years, the fraud patterns we see in bank statements submitted for loan applications have changed significantly.
The old version of document fraud was easy to catch. A scanned PDF with the wrong font. A balance column that didn't add up. A statement with inconsistent date formatting. A trained analyst would spot it in 15 minutes.
The new version is harder. Generative AI tools can now produce bank statements with correct running balances, plausible transaction histories, consistent formatting, and clean PDF metadata. The document passes every visual check. There is nothing obviously wrong with it.
The detection has to shift from "does this look right" to "does this behave right."
What does that mean in practice? You look at transaction sequencing. Does money move through this account the way it would for someone with this income profile, at this bank, over this time window? You look at counterparty patterns. Are the UPI inflows consistent with a salaried employee or do they look like layered deposits from multiple sources? You look at circular flows. Do funds leave and return within a few days in a pattern that inflates apparent turnover?
The same shift is now happening with GST returns and ITR documents submitted alongside loan applications. A fabricated GSTR-3B can show Rs.80 lakh monthly turnover when the bank statement shows Rs.12 lakh in credits. An ITR can declare income that bears no relationship to what actually moved through the account.
The fix is cross-document verification - checking each document not just for internal consistency but against every other document in the application file.
This is the problem Precisa is built for. Bank statements, GSTR, ITR — analysed together, not in isolation.
We process financial documents for lenders and NBFCs across India. One pattern shows up more consistently than any other in MSME loan applications: a mismatch between what the GSTR shows and what the bank statement shows.
GSTR-1 records sales invoices raised. GSTR-3B records tax paid. The bank statement records what actually moved. In a legitimate business, these three should tell roughly the same story. Turnover declared in GSTR should broadly align with credits in the bank account.
When they don't align, it is almost always one of three things.
The business is real but has undisclosed cash transactions that don't appear in either document. Common in retail and distribution businesses.
The GSTR is inflated — GST invoices raised without corresponding sales, sometimes to build a credit profile, sometimes for input tax credit fraud.
The bank statement is fabricated or manipulated to match an inflated GSTR.
Each of these has a different risk profile for the lender. The first might still be a viable borrower. The second and third are fraud.
The only way to tell them apart is to analyse both documents together with enough granularity to see where the numbers diverge and why. Monthly aggregates are not enough. You need transaction-level bank data aligned against invoice-level GST data.
This is why we built GST analysis into Precisa as a standalone product — not as a checkbox alongside bank statement analysis but as a structured cross-verification tool. Lenders who run both together before sanctioning catch the divergence before it becomes an NPA.
If you are building credit infrastructure for MSME lending in India, this is the single highest-return document check to add to your underwriting workflow.
This is not a Precisa product pitch. It is something we think more people in Indian fintech should understand.
Financial document tampering in India has evolved through roughly three generations in the past five years.
Generation 1: Basic PDF editing. Someone opens a bank statement PDF in an editing tool, changes a balance or a credit amount, saves it. Detectable by metadata inspection — the modification date doesn't match the creation date, or the editing software signature is visible in the file properties. An analyst who knows where to look catches this in under two minutes.
Generation 2: Print-scan-reprint. The edited document is printed and rescanned, which strips the original metadata. Harder to catch on metadata alone. Detection shifts to font consistency checks, pixel-level analysis of text rendering, and checking whether transaction reference numbers follow the bank's known format.
Generation 3: AI-generated statements. No original document is modified. A synthetic statement is created from scratch. Font is correct. Metadata is clean. Reference numbers follow the right pattern. Running balances add up. The only detection route is behavioural — does the transaction pattern make sense for this borrower profile?
Most Indian NBFCs and lenders have detection capabilities for Generation 1. Some have tools for Generation 2. Almost none have systematic Generation 3 detection built into their underwriting workflow.
The same generational progression is happening with GST returns and ITR documents. Generation 1 GST fraud ,manually edited PDFs , is well understood. AI-synthesised GST documents that pass format checks are not yet on most lenders' radar.
The fix is not a single tool. It is a cross-document verification habit: bank statement, GSTR, and ITR checked against each other at the transaction and declaration level. Documents can be fabricated individually. Fabricating all three with internal consistency across all signals is significantly harder.
At 1,000 clients and 150 million transactions processed, we've become a mirror of India's real financial patterns.
Here's what the DATA shows (not what credit scores tell you):
💰 INCOME REALITY:
→ Only 34% have stable monthly salaries
→ 41% have irregular income (gig/freelance/business)
→ 25% have BOTH salary + side hustle
→ Average undeclared side income: ₹23,400/month
🚨 FRAUD PATTERNS:
→ 12.3% of statements show tampering
→ Peak fraud: Month-end + festival season
→ Cooperative bank statements: 3.2X more fraud attempts
💳 DEBT BEHAVIOR:
→ Average borrower has 3.7 active loans
→ Hidden debt (not in CIBIL): 31% of cases
→ BNPL usage: 47% of millennials (unreported)
🏦 BANKING HABITS:
→ 73% use 2+ banks regularly
→ Pattern: Salary in Bank A, expenses in Bank B
→ Account switching: Every 2.3 years
How do you catch a fraudster who forged the "perfect" bank statement? Our AI caught it in 2.7 seconds.
The scam: A loan applicant submitted pristine-looking salary statements showing ₹3.2L monthly income. Clean CIBIL. Regular deposits. Everything checked out.
What our system detected:
❌ PDF created April 2024, claiming transactions from 2023
❌ Font inconsistencies in amount fields
❌ Weekend salary credits (employer closed)
❌ Metadata showed 4 Photoshop edits
Result: ₹45L fraud attempt blocked.
Across 1,000+ NBFCs and banks using Precisa:
→ 150M+ transactions analyzed
→ ₹1.2 Cr in prevented fraud
→ 97% detection accuracy
→ 2.7 seconds average detection time
The difference? AI doesn't get tired. It checks 47 fraud parameters on every statement. Every. Single. Time.
Are you still relying on manual review to catch financial fraud?
-
1
This is a strong fintech trust story because the real product is not just statement analysis. It is risk infrastructure sitting between lenders and bad financial decisions.
The fraud examples make the positioning much sharper: forged PDFs, metadata edits, salary pattern mismatch, hidden debt, and account behavior all point to something bigger than manual review replacement. This feels closer to a verification layer for financial truth.
One thing I would pressure-test is the product brand around Precisa. It is clean, but if the product becomes the fraud/risk layer behind banks, NBFCs, and lending workflows, the name has to carry serious security and infrastructure weight.
Vroth .com would fit that direction well because it feels harder-edged and more risk-focused, while leaving room for fraud detection, transaction intelligence, borrower verification, statement analysis, and financial risk infrastructure under one stronger brand.
Comment