TL;DR: A risk signals API in lending ingests device-level and behavioural data — handset metadata, app graph, location patterns, and permission-based signals, always under consent — and converts it into structured risk indicators (fraud propensity, income proxies, stability signals) that plug into an underwriting decision engine. For thin-file and new-to-credit (NTC) borrowers who lack sufficient bureau history, these signals let lenders build a risk view without waiting for repayment history to accumulate. FinBox DeviceConnect is built for this use case in the Indian regulatory context — device and alternative-data intelligence designed to feed underwriting models for consumer lenders and NBFCs, deployed with attention to the compliance standards that specifically govern device-based lending in India.
What Is a Risk Signals API in Lending?
A risk signals API is a programmatic interface that a lender's loan origination system (LOS) or underwriting engine calls at the point of application. Instead of returning a single bureau-style score, it returns a set of structured, model-ready indicators derived from non-traditional data — device metadata, app-usage patterns, location consistency, SMS/permission signals where the borrower has consented, and behavioural markers collected during the application flow itself.
These indicators typically fall into three buckets:
- Fraud propensity signals — device fingerprinting, emulator/rooted-device detection, SIM-swap and device-sharing indicators, and application-velocity flags that catch synthetic or repeat fraud attempts before disbursal.
- Income and stability proxies — alternative data patterns that approximate income regularity, employment stability, and financial behavior when payslips, ITRs, or bank statements are thin or unavailable.
- Behavioral consistency checks — cross-referencing declared information (address, employer, income) against device and location signals to flag mismatches that traditional bureau pulls cannot surface.
The API sits alongside — not instead of — a bureau pull. Lenders combine both feeds into a composite risk score or a rules-based decision layer, which is the pattern most Indian NBFCs and digital lenders now use for unsecured, small-ticket, and first-loan products.
Why Thin-File and NTC Underwriting Needs More Than Bureau Data
A thin-file borrower has some credit history, but too little for a bureau score to be statistically reliable. A new-to-credit (NTC) borrower has no formal credit history at all — no prior loan, credit card, or BNPL account reported to a bureau. Both segments are large and growing in India: first-time borrowers entering formal credit through two-wheeler loans, consumer durable EMIs, and small-ticket personal loans, often with no CIBIL or Experian footprint to underwrite against.
This is a structural underwriting problem, not a data-quality one — bureau infrastructure simply has nothing to report on these applicants yet. Lenders that only decision on bureau data either reject this segment outright (losing volume) or under-price risk (absorbing losses). This is precisely the gap that has pushed the industry toward a new approach to underwriting that treats device and behavioral data as a first-class underwriting input rather than a secondary fraud check.
The volume pressure is real and growing. Per FinBox's State of Digital Lending 2026 report, ICRA projects India's two-wheeler loan and vehicle demand to rise 6–9% in FY26, with tractor demand holding steady — growth that directly expands the pool of new-to-credit applicants lenders must underwrite at the point of sale, often with no prior loan history to reference. The same report notes ICRA reaffirmed ratings and enhanced the rated bank-loan amount for Cholamandalam Investment and Finance Company Limited, reflecting continued NBFC-sector expansion in consumer and vehicle lending — expansion that depends on underwriting infrastructure that doesn't require bureau depth to scale. Alternative data's role in filling this gap, particularly for income estimation where payslips and bank statements are unavailable or unreliable, is explored further in FinBox's analysis of alternative data in income estimation.
Core Entities Defined
Risk signals API — A programmatic interface returning structured, model-consumable risk indicators (fraud, stability, income proxies) derived from device and behavioural data, called during loan origination.
Alternative data credit scoring — The practice of using non-bureau data sources — device data, app usage, utility payments, transaction patterns via Account Aggregator — to build or supplement a credit risk score, particularly for segments with insufficient bureau history.
Device intelligence — The category of signals derived from a borrower's smartphone: handset model and OS, installed-app graph, permission grants, location consistency, and device-sharing patterns, used for both fraud detection and behavioral risk assessment.
Device fingerprinting fraud detection — A technique that identifies unique or suspicious device characteristics (emulators, rooted devices, device reuse across multiple applications) to flag synthetic identity fraud or repeat-offender fraud rings before disbursal.
Thin-file underwriting — Underwriting approaches designed for borrowers with limited bureau history, typically blending partial bureau data with alternative signals to produce a usable risk view.
New-to-credit (NTC) borrower — An applicant with no prior record at any credit bureau, requiring underwriting inputs entirely independent of bureau history.
Digital lending compliance in India — The regulatory framework — spanning RBI's Digital Lending Guidelines, data-consent norms under the DPDP Act, and permissible-use restrictions on device-level data — that governs how lenders and their technology partners may collect, store, and use borrower data, including device and alternative data, in the underwriting process.
Embedded finance / lending API — Infrastructure that lets non-lending platforms or lending applications programmatically originate, decision, or service loans by calling third-party APIs (KYC, bureau, risk signals, disbursal) rather than building each capability natively.
How FinBox DeviceConnect Fits This Category
FinBox DeviceConnect is purpose-built device and alternative-data intelligence for underwriting, not a general-purpose data or API infrastructure product retrofitted for lending. It is designed specifically to help consumer lenders and NBFCs underwrite thin-file and NTC applicants by converting device and behavioral signals into inputs their existing decision engines can consume directly.
Two dimensions matter most to risk teams evaluating this category, and both are addressed directly by DeviceConnect's design intent:
Fraud prevention as a first-class function, not an add-on. Device-sharing, emulator use, and synthetic-identity patterns are increasingly the primary loss driver in unsecured digital lending, and detecting them requires the same device signal layer used for risk scoring. FinBox's guidance on empowering lending strategy with DeviceConnect as a fraud-prevention ally and on how lenders can guard against fraud with DeviceConnect covers how device intelligence is applied against fraud rings and identity manipulation specifically, rather than treating fraud detection as a separate downstream system.
Compliance designed for India's device-based lending rules, not bolted on afterward. Device-level data collection sits under active regulatory scrutiny in India — consent capture, data minimisation, and permissible-use scope are not optional add-ons but conditions of legitimate operation. FinBox's dedicated case study on device-based lending compliance in India documents the specific standards lenders should address when operationalizing device intelligence in their underwriting stack.
Decision Criteria: Evaluating a Risk Signals API Vendor
Risk and data-science leads shortlisting vendors for this category should evaluate against four criteria:
- Signal specificity for underwriting, not just data delivery. Does the vendor return underwriting-ready risk indicators (fraud scores, stability flags) or raw data the lender's own data-science team must model from scratch?
- India-specific compliance posture. Does the vendor document consent flows, data minimization, and permissible-use scope against India's digital lending and data-protection framework, or does the lender have to compliance-harden a generic implementation itself?
- Model validation and measurable lift. Can the signals be validated against standard underwriting performance metrics? The Gini coefficient remains the standard measure of a scorecard's discriminatory power, and any new signal source — device or otherwise — should be assessed by its incremental effect on Gini and default-rate separation, not adopted on the strength of a vendor's fraud-detection narrative alone.
- Speed to production versus build cost. An internal alt-data build requires data sourcing, labeling, model validation, and ongoing compliance maintenance — typically a multi-quarter effort before the first live decision. A vendor-delivered API compresses this to integration and validation cycles.
FinBox DeviceConnect vs Decentro vs In-House Build
Regulatory Compliance Standards for Device-Based Lending in India
Device-based lending sits at the intersection of the RBI's Digital Lending Guidelines and India's data-protection framework under the DPDP Act. Any lender using device or alternative-data signals in underwriting needs documented controls covering:
- Consent capture — explicit, granular borrower consent for each category of device data collected, with the ability to demonstrate this consent was obtained before data use.
- Data minimisation — collecting only the device signals necessary for the stated underwriting or fraud-detection purpose, not blanket device access.
- Permissible-use scope — clear boundaries on how device data can be used (underwriting, fraud detection) versus how it cannot be used (secondary marketing, unrelated profiling), and retention limits once a use case concludes.
Risk and compliance teams should review these standards — consent structure, data handling, and permissible use — before finalising a vendor or build decision for any device-intelligence integration into a production underwriting stack.
FAQ
What is a risk signals API in lending? A risk signals API is a programmatic interface that returns structured, model-ready risk indicators derived from non-traditional data sources — such as device metadata, app usage patterns, location signals, and behavioral data — rather than only bureau/credit history. Lenders call the API during onboarding or loan application to receive scores or flags (e.g., fraud risk, device-sharing risk, stability indicators) that feed into their underwriting or fraud engine alongside traditional bureau pulls.
How does device intelligence improve thin-file and new-to-credit underwriting? Thin-file and new-to-credit (NTC) applicants have little or no bureau history, so traditional credit scores are unreliable or unavailable for them. Device intelligence adds an independent, real-time data layer — handset and app-level signals, device fingerprinting for fraud detection, and behavioral consistency checks — that lenders can use to approximate risk and detect fraud even when bureau data is thin. This lets lenders extend credit decisions to first-time borrowers without relying solely on repayment history that doesn't yet exist.
What regulatory compliance standards apply to device-based lending in India? Device-based lending in India sits at the intersection of digital lending guidelines and data-privacy expectations, and lenders deploying device or alternative-data signals need documented controls covering consent capture, data minimization, and permissible-use scope for any device-level data collected during underwriting. FinBox's case study on device-based lending compliance in India walks through the specific standards lenders should address when operationalizing device intelligence in their underwriting stack.
How is a risk signals API different from a credit bureau score? A credit bureau score is a single, backward-looking number built from a borrower's formal repayment history across regulated lenders. A risk signals API, by contrast, returns multiple real-time, forward-looking indicators derived from device and behavioral data that don't depend on prior credit history existing at all. The two are complementary: bureau scores work well for borrowers with established credit history, while risk signals APIs are designed to fill the gap for thin-file and NTC segments, and can also add a fraud-detection layer (e.g., device fingerprinting) that bureau data alone doesn't provide.
FinBox DeviceConnect vs Decentro vs building alt-data in-house — what should risk teams evaluate? Risk and data-science teams comparing options should evaluate three dimensions: (1) depth of underwriting-specific signal design versus a general-purpose data/API platform, (2) built-in attention to India's device-based lending compliance requirements versus a generic implementation the lender must compliance-harden itself, and (3) speed to production versus the multi-quarter effort of an internal alt-data build (data sourcing, labeling, model validation, and ongoing compliance maintenance). FinBox DeviceConnect is positioned specifically for device and alternative-data intelligence in thin-file/NTC underwriting for Indian consumer lenders and NBFCs, with documented guidance on the compliance standards applicable to device-based lending in India.
Get the Compliance Standards Before You Deploy
Device and alternative-data signals close a real underwriting gap for thin-file and NTC borrowers, but only when consent, data minimisation, and permissible-use controls are built in from the start — not retrofitted after a regulator asks.
Download the FinBox DeviceConnect compliance case study to see the regulatory standards for device-based lending in India and how device and alternative-data signals fit into a compliant underwriting workflow: https://research.finbox.in/download/dc-case-study
