Step 01
Step 1
Every transaction passes through a vectorised enrichment pipeline as it arrives.
AI InsightsRetail
Transactions & insights.
Every transaction tagged with category, merchant, intent, and tax bucket — automatically.
The problem
Why this exists.
Bank statements are noise. The same Swiggy charge shows up as 'SWIGGY*ORDER 432' on one card and 'BHARATPE-MERCH123' on another.
Manual tagging dies the moment a user falls behind a week. We want enrichment that runs the moment a row lands.
How it works · 3 steps
From input to outcome.
- Step 02
Step 2
Output: L1 category, L2 category, merchant, intent (UPI / EMI / fuel / etc.), GST / TDS / cess where applicable, city, state.
- Step 03
Step 3
Anomaly score on each row — unusual spend surfaces in your weekly read without you asking.
Under the hood
The models and routes behind it.
Models called
API routes
- GET /api/v1/transactions
- POST /api/v1/transactions/categorize
Compliance posture
- Enrichment runs server-side on hashed merchant strings; raw narration never leaves your tenant.
- DPDP §12 — every enrichment record is erasable along with the source transaction.
- Anomaly flags are advisory; we never auto-block a vendor.
Interactive demo · mocked at the edge
See it work.
Categorise a transaction (mock)
Loading the demo…
What it's not
We classify transactions and flag anomalies — we do not file disputes or call your bank. Disputes still go through your card-issuer or UPI app.
Related · features & stories