From Application to Approval in Three Minutes: The Technical Architecture

When the borrower completes the consent flow, parallel fetches begin. Account Aggregator data, GST data, and other sources arrive at different speeds, while validation and feature preparation continue. The pipeline must keep moving because a borrower who waits beyond the three-minute window may look elsewhere.

This piece explains the technical architecture behind reliable sub-three-minute credit assessment on alternative data. Real data pipeline constraints determine whether that threshold is achieved consistently or only occasionally.

Where Credit Assessment Time Goes

Model inference is not the bottleneck. Data collection and validation consume the time, with the Account Aggregator consent and fetch sequence often the longest single step.

After a borrower authorizes AA sharing, the network fetches data from the relevant FIP (Financial Information Provider, typically a bank). FIP response time is outside the AA platform's control. A well-maintained FIP returns data in seconds; an unoptimized one may take 30 to 90 seconds or longer before timeout and retry. In our benchmarks, AA fetch latency represents roughly 40 to 60 percent of assessment time when data is available.

GST API retrieval follows a different pattern. The GSTN data layer is fairly consistent for one GSTIN lookup, usually in the 5 to 15 second range. Latency varies between monthly GSTR-1 data and quarterly GSTR-3B aggregates, and also depends on filing status over recent months.

Parallel Fetching by Design

Parallelizing every possible fetch is central to sub-three-minute assessment. Dispatch AA, GST, and bureau requests together, not sequentially. Sequential fetching adds every source's latency; parallel fetching pays only the slowest source's cost.

Many early pipelines still begin sequentially because that is easier to debug. Parallel fetching requires partial state management: the model must use data already received when needed, while timeouts and fallback logic handle sources that miss their response window.

Timeout and fallback logic is required. An AA fetch that exceeds 90 seconds must not block assessment indefinitely. Define minimum viable data requirements, including whether GST-plus-UPI can support a partial assessment without bank statement data. The system should decide this dynamically rather than wait for a source that may never respond.

Feature Engineering Under Pressure

Feature engineering contains much of the technical work, but it can also introduce pipeline delays.

Behavioral features from 90 days of bank statement data require transaction parsing, categorization, rolling statistics, pattern-shift detection, and seasonality normalization. The computation is modest, but clean parsed input is essential. Through AA, data arrives in multiple formats because FIPs vary in compliance with the account statement schema. Parsing and normalization can therefore consume meaningful time.

We pre-process format variants with a schema layer for common deviations from the AA FI-Data specification. This library records known quirks by FIP and is updated as new variants appear. Without it, exceptions handled during feature computation add latency and create branching that is difficult to test fully.

With clean feature vectors, inference runs in under five seconds. For this feature set, gradient-boosted tree computation is negligible beside fetch latency. Optimize ingestion and normalization, not the model architecture.

Speed vs. Consistency

Assessment speed and consistency are in real tension. Shortcuts in validation may produce fast results with greater uncertainty because input quality was not verified. A fast assessment on bad data can create more risk than a slower assessment on verified data.

We validate critical signals before feature engineering, using rules proportionate to each signal's model weight. High-weight features such as account balance trajectory and inward credit regularity receive strict checks. Failed checks flag an anomaly instead of producing a score from corrupted inputs. Failed lower-weight signals are dropped, not flagged, so assessment continues with valid data.

This does not disregard data quality. It is priority-weighted validation that preserves speed while guarding against the most consequential failures.

What Slows Systems at Scale

In early pilots with NBFC partners, the biggest latency surprises were outside compute. They came from the API integration layer between our assessment system and the lender's loan origination system, or LOS.

Data sent from the lender's LOS to our API often contains formatting errors in GSTIN, mobile number, or PAN. Invalid fields enter a validation exception path before fetching starts. That path was slower than the happy path, and inconsistent LOS data entry created a long tail of slow assessments hidden by average latency.

We fixed this by normalizing inputs at the API entry point and moving PAN/GSTIN validation to the lender's LOS through API documentation updates. Malformed inputs should not be handled expensively downstream. Both changes were required.

Three Minutes as a Design Constraint

We treat three minutes as a hard design constraint, not a benchmark. If a pipeline change pushes P95 assessment time above three minutes for a typical application, it does not ship. This disciplines prioritization: slow new data sources carry an architectural cost that must be weighed.

This constraint has deferred signal types that might add predictive value at higher latency. For now, speed and reliability take priority. As AA infrastructure matures and FIP response times improve, more latency budget will become available. Our pipeline design accounts for that improvement.