The surprising finding from building alternative-data credit infrastructure was where engineering time went: the infrastructure, not the model. The difficult work was making data collection, validation, feature engineering, and lender workflow interfaces operate reliably together.
Building Saarathi's credit assessment engine showed us that data infrastructure took far longer to solve than modeling. The model architecture was clear early in product design. The data stack needed repeated iteration as we encountered the realities of Indian SME financial data.
Layer 1: Data Collection
Alternative credit data in India is collected mainly through Account Aggregator bank access, GSTN data, and UPI transaction history. Each follows a different integration pattern.
Account Aggregator access is the most reliable route to current bank statements. It obtains data directly from the Financial Information Provider (bank), under regulatory oversight, using the format set by the RBI's AA technical specifications. Data quality still varies across FIPs. Some provide categorized transactions, while others return raw descriptions requiring downstream parsing. The collection layer therefore needs explicit FIP-specific handling rather than one universal parser.
GSTN credit data generally comes through a licensed GST Suvidha Provider (GSP) with API access. Key inputs include GSTR-3B monthly liability declarations, GSTR-1 outward supply details, and filing status history. GSTR-3B usually helps credit assessment more because it reflects the borrower's declared turnover. GSTR-1 cross-checks counterparties and is more useful for invoice verification.
UPI transaction history is the least standardized source. No central UPI repository provides an API. History may come through the bank statement for account-linked payments or, under some consent frameworks, from UPI app providers. Bank statements capture account-linked activity well but may miss payments split across apps or accounts.
Layer 2: Data Validation
Raw data is not credit-ready. Validation establishes data quality before feature computation begins.
Bank statement checks should confirm that the covered period matches the requested window, flagging partial statements rather than accepting them silently. They should also reconcile opening balance, transactions, and closing balance within tolerance, and detect duplicate records, including duplicates created when some FIP implementations retry certain transaction types.
GST checks include validating the GSTIN format and state prefix, comparing GSTR-3B turnover with bank inflows for material gaps, and flagging returns filed well after their due dates as potential compliance irregularities relevant to credit assessment.
Validation should have two levels: hard validation for failures that block assessment, and soft validation for anomalies passed to the model as signals. A severe statement reconciliation failure warrants rejection and re-fetch. A minor GSTR-to-bank turnover mismatch should be a model signal, not an automatic rejection.
Layer 3: Feature Engineering
Feature engineering turns validated data into model inputs. It also encodes much of the domain knowledge required for SME credit risk assessment.
Bank statement features can include rolling measures such as average monthly inward credits over the last 90 days, their standard deviation, the minimum-to-maximum inward credit ratio, and days with zero inward credits. Behavioral measures include recurring outward payment regularity, overdraft frequency and size, and the account balance trajectory.
GST features cover filing regularity, turnover direction, and the ratio of ITC claims to output tax liability. This ratio roughly reflects supply chain depth and input cost management. Consistent ITC relative to turnover suggests normal operations, while sudden changes may signal disruption.
Seasonality needs specific treatment. Without adjustment, slow months can look like stress and peak months like strength. For businesses with consistent multi-year patterns, the feature layer should calculate season-normalized metrics. Short assessment windows provide less history, so the model should receive uncertainty from limited seasonality calibration.
Layer 4: Integration Interface
The integration layer connects the credit assessment pipeline to the NBFC's loan origination system. NBFCs see this layer most directly, and its requirements reflect both technology and workflow.
The API must manage AA consent, status callbacks during asynchronous fetching, and structured credit output mapped to the NBFC's appraisal memo fields. If that output needs extensive translation into the LOS, integration effort and adoption friction increase.
The assessment must enter the NBFC's workflow at the point where it can affect a decision. Before basic application review, it lacks context. After a preliminary credit committee decision, it is less useful for that application, though it may inform future policy. Integration should target the decision point, not merely place the output in the record.
The Complete Stack
The stack functions as a chain. Weak validation creates noisy features, which produce unreliable model outputs and reduce trust among credit teams. The bottleneck moves to the weakest layer, and that layer sets the quality ceiling for the system.
Alternative-data credit technology is therefore not mainly a modeling problem. Standard tools make the modeling layer implementable. The most iteration-intensive work is the domain-specific, India-specific, SME-lending-specific data infrastructure.
Assess borrowers in minutes.
Saarathi's API connects to your loan origination system in one day and returns a scored credit file in under three minutes.