How TransactIQ is built
Bank statement analysis looks like a single API call. Underneath, it is a five-stage pipeline with failure modes at every boundary. This page describes how TransactIQ is structured and the four architectural principles that shape every stage.
The five stages
Every statement TransactIQ processes moves through the same five stages. Each stage has its own failure modes; each is instrumented and observable.
Ingest
The borrower's bank statement arrives as a PDF, an image scan, a password-protected file, or a multi-page fax-origin document. TransactIQ accepts all of them. No pre-conversion, no client-side OCR step, no format-normalisation handoff. The file goes straight to the pipeline.
Parse
The OCR and structure-recognition layer resolves the document into a canonical transaction ledger — date, narration, debit, credit, running balance — regardless of bank, layout, or print quality. This is the layer where incumbent vendors degrade on PSU and cooperative-bank formats; TransactIQ is engineered for exactly those inputs.
Categorise
Every transaction is typed by rail (UPI, NEFT, RTGS, IMPS, cheque, NACH, cash) and by counterparty class (merchant category, employer pattern, lender, tax authority, family transfer). Narration parsing is India-specific — not a localisation of US or European models.
Engineer features
The categorised ledger becomes the input to the credit signal engine — bounce prediction, salary consistency, EMI aggregation, round-tripping, mule-account patterns, cash-flow volatility, and the four-layer synthetic financial statement construction. Outputs are signals, not summaries, so the lender's credit model consumes them directly.
Deliver
Results are returned via synchronous, asynchronous, or webhook modes — whichever fits the lender's decisioning workflow. Batch endpoints serve daily or hourly ingestion volumes. Every processed statement carries a tamper-evident audit trail for SAR response and regulator review.
Four architectural principles
The same principles that shape TransactIG's reconciliation engine shape TransactIQ's BSA pipeline. Explicitly stated so customers can judge us against them.
Deterministic over probabilistic
Every output is rule-traceable. There are no opaque model scores in the decisioning path that a credit team cannot explain to a regulator. Where ML is used — narration parsing, layout recognition — its role is classification inside a rule-governed pipeline, not as the final credit signal.
India-first, not localised
The OCR is trained on Indian bank formats. The narration parser understands Indian rail grammar (UPI handles, NEFT reference codes, IMPS beneficiary names). The credit signals are tuned for Indian underwriting surfaces. Nothing is ported from US or European BSA products with a currency swap.
Config-driven, not rebuild-driven
Every lender's policy — what counts as a salary, what bounce-rate threshold triggers manual review, how aggressively to attribute personal-vs-business transactions — is a configuration over a common engine. Upgrades apply across tenants. No bespoke engineering backlog per NBFC.
Operated where the data lives
TransactIQ runs inside the lender's VPC or inside Terra Insight's Mumbai AWS tenant, depending on the deployment tier. In no case does a customer statement leave the India data plane. RBI IT governance direction on data localisation is met by architecture, not by process.
Want the deeper architecture briefing?
Early-access partners receive a detailed architecture walkthrough and a direct engineering contact through the integration window.
Request early-access briefing