6.19 UPI / POS transaction-based underwriting

A large segment of India’s SMEs — small retailers, restaurants, salons, clinics, D2C brands, small-merchant service providers — earn their revenue through UPI / POS transactions that don’t always show up cleanly in GST returns (because the business is below GST registration threshold) or in bank statements (because settlements are batched and netted).

For these borrowers, transaction-level UPI / POS data is often the single richest underwriting signal. This page covers the practical use.

Borrower archetypes

Archetype	Primary revenue rail	Typical thin areas
Small retail counter (kirana, garment shop, mobile-accessory)	UPI receipts + cash + some card	No GST (below threshold); thin bank-statement complexity
Restaurant / café / cloud kitchen	UPI + Swiggy / Zomato + POS swipes	GST registered but reports may understate; receipts via aggregator
Salon / beauty / wellness	UPI + card swipes	Often no GST; cash component high
Clinic / diagnostic centre	UPI + card + insurance reimbursements	GST registered; receivables from insurance complicate cash-flow
D2C brand (own Shopify / Instagram-led)	Payment gateway (Razorpay / Cashfree) + COD	GST registered usually; bank shows daily PG settlements
Small merchant on food / kirana app	App platform settlement	Aggregator settlement is primary rail
Tuition / coaching service	UPI / cash	Often no GST; thin bookkeeping
Service technician / repair shop	UPI / cash	Often no GST; high cash component

Data sources

A. UPI inflow via AA

The borrower’s bank account (current or savings used for business) accumulates UPI receipts. AA fetch returns the transaction narration, counter-party VPA, and amount.

Signals extractable:

Average daily UPI inflow.
Number of unique payer VPAs per month — proxy for unique customer count.
Concentration — top 10 payer share.
Pattern (consistent / lumpy / seasonal).
Time-of-day distribution (proxy for peak hours).
Day-of-week pattern.
Vintage of UPI usage on this account.
Refund / reversal pattern.

Vendors: AA TSP (Setu / FinBox); BSA layer categorises.

B. POS settlement via merchant dashboard

For borrowers with physical POS terminals (Razorpay POS, Mswipe, Innoviti, Pine Labs, Mosambee, etc.), the merchant’s PSP dashboard shows:

Settlement-by-settlement breakdown.
Per-card, per-UPI swipe details.
Refunds / disputes.
Per-terminal breakdown (multi-terminal borrowers).
Settlement-to-bank mapping.

Acquisition:

Borrower-uploaded CSV / Excel export.
API where PSP supports merchant API.
Bank-side: PSP settlements show as identifiable batches; BSA categorisation surfaces them.

C. Payment gateway settlement (for D2C / online)

For online / D2C borrowers, payment gateway dashboards (Razorpay, Cashfree, PayU, Billdesk) show:

Per-transaction order details.
Gross orders + refunds + disputes + net settlement.
Card type / UPI / netbanking / wallet mix.
Daily settlement to bank.

D. Aggregator settlement (for food / kirana / micro-merchant)

For borrowers on Swiggy / Zomato / Dunzo / Blinkit / etc., aggregator-side settlement reports show:

Order volume, GMV, commissions, settlement amounts.
Cancellation / refund rates.
Ratings and reviews.

E. POS-derived footfall (where instrumented)

Some modern POS terminals + camera systems generate footfall counts. Increasingly relevant for retail / hospitality.

Composite decision framework

For a UPI/POS-led borrower with thin GST / Tally data, the decision composes:

Activity confirmation from UPI/POS volume.
Customer-base size from unique payer count / unique-order count.
Operational consistency from time-pattern.
Recent trend from monthly aggregate trajectory.
Field FI confirming the business is physically present and operating.
Reference checks with 3 suppliers + 2 neighbours (customer references hard for small-merchant retail where customers are anonymous).
Promoter consumer bureau (existing-credit behaviour).
Bank statement (whatever’s available) for EMI / bounce / balance patterns.

Sample rule additions

Rule: `UPI_INFLOW_MIN_PER_DAY`

Purpose: minimum activity threshold for UPI-led borrower.
Data source: AA-fetched UPI receipts on operating account.
Logic: average daily UPI inflow over last 90 days.
Threshold: >= ₹5,000 / day for A on < ₹10 lakh ticket; >= ₹20,000 / day for A on ₹10 – 25 lakh ticket.
Action: contribute to grade.
Audit evidence: AA aggregate.

Rule: `UPI_UNIQUE_PAYERS_MIN_PER_MONTH`

Purpose: customer base size / concentration.
Logic: count of unique payer VPAs / month over last 90 days.
Threshold: >= 100 for A (retail); >= 30 for service (per-customer-value higher).
Action: per grade.

Rule: `POS_SETTLEMENT_CONSISTENCY`

Purpose: POS-led businesses with sudden volume drop signal trouble.
Logic: monthly POS settlement volume over last 12 months — coefficient of variation.
Threshold: <= 50% CV for A.
Action: per.

Rule: `MARKETPLACE_NET_AFTER_RETURNS_MIN`

Purpose: marketplace-led borrowers — net economics matter, not gross.
Logic: average monthly net settlement (gross minus returns minus fees) over 90 days.
Threshold: per ticket size band.

Rule: `TRANSACTION_VS_BANK_RECON`

Purpose: UPI/POS settlements should reconcile with bank credits.
Logic: claimed transaction settlements / bank-side identified settlements.
Threshold: within 10%.
Action: REFER on divergence; explain.

Fraud patterns specific to UPI / POS

Pre-loan UPI inflation

Borrower instructs friends / family to send UPI to the operating account in the weeks before underwriting. Pattern: sudden volume spike 2 – 4 weeks before the data fetch.

Mitigation: look at 12-month trend, not 90-day. Flag sudden spikes against baseline.

Round-tripping between own accounts

Borrower has multiple bank accounts (own + family); cycles UPI between them to inflate inflow.

Mitigation: counter-party analysis. If payer VPAs concentrate to a few that are linked to the borrower’s PAN / Aadhaar / address, net out.

POS round-tripping

Borrower swipes own credit card on own POS terminal repeatedly. Inflates POS revenue without real customers.

Mitigation: card-number repeat pattern; flag if same card / VPA appears repeatedly at high volume.

Marketplace account multi-pretence

Borrower has multiple marketplace seller accounts (one main + several test) and claims them all as “their seller accounts” inflating volume. Or alternatively hides a suspended primary and shows secondary.

Mitigation: verify account-holder names per marketplace; check standing.

Fictitious POS terminal

Borrower claims a POS terminal exists but doesn’t; supplies fabricated PSP report.

Mitigation: cross-verify with bank settlement credits identifiable to the claimed PSP.

Refund-flooding

Borrower processes large transactions then refunds them next day to claim revenue. PSP reports show gross; net is much lower.

Mitigation: always look at net (post-refund) for assessment.

Use case: small kirana applying for ₹3 lakh line

Application: small kirana in Mumbai, no GST (below threshold), no Tally.
Borrower’s primary account: small savings account; AA-fetched.
UPI inflow: ~₹6,500 / day average; ~145 unique payers / month; consistent pattern over 12 months.
POS terminal (Razorpay): ~₹3,000 / day average swipe; declining slightly (UPI absorbing the volume).
Bank statement: ABB ₹18k; 0 bounces; ₹2 lakh term loan repaying cleanly.
Bureau (proprietor): 742 CIBIL; 1 credit card clean.
Field FI: kirana visited, owner present, stock substantial, 9-year signage.
References: 3 suppliers confirmed (wholesale grain, oil, daily-needs supplier — long-term relationships).

Decision: APPROVE ₹3 lakh line, 45-day tenure, 24% rate. Thin-file premium reflects the diligence cost; cohort-level expected default ~3.5%.

What the platform must support

AA UPI categorisation by counter-party type, payer-vintage, refund flag.
PSP dashboard ingestion — Razorpay / Cashfree / Pine Labs / Mswipe / Innoviti vendor adapters.
PG dashboard ingestion for D2C borrowers.
Marketplace settlement ingestion for online sellers.
Aggregator-platform settlement for food / kirana / micro-merchant borrowers.
Cross-platform reconciliation (bank-credit identifiable to PG / PSP / marketplace settlement).
Round-tripping detection in UPI counter-party analysis.

Limitations of transaction-based underwriting

Volume vs profit — UPI volume doesn’t show borrower’s net margin. A high-volume kirana with thin margin may not service larger loans well.
Seasonality — many transaction-led businesses are seasonal; need 12-month data minimum.
Cash component invisible — many small-merchant businesses still have material cash flow not in UPI / POS. Borrower’s claim about cash is hard to verify.
DPDP carefully — UPI counter-party data exposes the borrower’s customers; minimise retention and use only for stated purpose.

6.14 Thin-file underwriting.
6.15 Unconventional data sources.
6.20 Marketplace-seller deep dive.
4.3 Account Aggregator — UPI data via AA.
4.8 Mandates and repayments — UPI AutoPay for collections.