Lenders can now access a lot more data, a lot more seamlessly. But they face challenges in converting it into actionable intelligence. While the data rails have been standardised, each lender has different policies/ products/ processes (their underwriting harness, lets call it), and thus require different insights from the same data. That is the gap, not the data.
GST, Account Aggregator, Bureau, ITR. All now accessible in a single flow.
Lenders carry a lot of baggage and rigidity in their policies, SOPs, workflows - the underwriting harness that has accrued over years
A risk-averse lender won't rebuild its policy architecture around every new data source.
Fit new data into each lender's existing harness (its fields, formats and policy structures) today.
Expose richer intelligence that the lender can grow into when ready.
The credit tenets: same across lenders irrespective of their underwriting harness/ lending product
Locked into legacy fields, no analysts. Wants new data in the shape and form it already uses.
Potential in-house models, battle-hardened formats. Wants clean inputs, not opinions.
Open to change, no data team. Can use ready-made intelligence modules.
Open and capable. Wants the raw material to build its own intelligence.
Was initially considering pre-built ability, intent and identity modules. But sameness at the question isn't the same as sameness at the answer. A standardized tenet-level aggregation kills the lender's ability to have its own weights.
Standardization should stop at the highest level where lenders genuinely don't differ. Platform-authored modules can still exist on top as an option, but only as a default combination of signals that are configurable by the lender
Standardize facts and signals, not lender requirements.
Observed and computed stay strictly separate.
A score is okay, a decision is not.
Every number must decompose to source facts.
Configuration over customization. Customization exits the platform.
Don’t hard-code structures experts themselves might debate about.
One mapper per source. The only code in the platform that knows source formats.
Each mapper parses the source’s payloads and writes facts and event records onto the canonical entity graph (L2).
The source-to-entity mapping is many-to-many: GST, for eg, maps identity onto the Business entity, creates filing records, invoice-level transaction records, and counterparty references (check out L2 for details on entities and records)
Consequence: A new data source is a new mapper and nothing else. It writes facts into schemas that already exist, so the layers above just get richer inputs.
“What each source says” → “What we know about each real-world thing, with receipts.”
Standardized representation of entities and facts/records, along with relationships between them.
Master entities — Business, Person, Account, Counterparty — resolved across sources and connected to each other by their relationships.
Event records — Transaction, Filing, Invoice — are never merged, only linked to the right master entities.
Facts are observed-only: value, source, timestamp, confidence. Anything computed, even a sum, goes to L3
Source-versus-source disagreement → fraud signal; derived-versus-fact → corroboration gap.
Why a graph: makes relationships first-class objects with their own facts and signals, allowing underwriting against them. Also makes structural fraud, like circular invoicing, easier to catch.
A lender-agnostic, source-agnostic computation over the graph, each with provenance and confidence.
Tiered computation: base aggregates → signals → composite signals. Every step is recorded and explainable to source.
Pure signals are facts about the entity alone and can be precomputed. Contextual signals (like FOIR) need borrower × proposed loan terms, and are computed at query time.
Because signals are lender-agnostic, they could get reused in unplanned ways: GST might be used for a compliance module now, but counterparty modules for another lender later.
A composition of signals answering a credit question.
The core component of this layer is a composition engine that can aggregate signals into a module/ composite score with open weights.
Platform-authored: standardized compositions that are like the platform’s catalog of pre-built modules
Lender-authored: retrofit modules/ custom scorecards built with the same composition engine (exposed to the lenders as a tool).
Output always has constituent signals. A standardized composite score could also be offered. If it is, it should have a published lender-agnostic methodology.
Out of scope: scores that provide default probability
A module can be the granularity level at which per-team access is configured.
Config only, no computation: product templates × lender overlays.
Products are defined by stripping down to attributes: repayment source, what’s underwritten, receivable and payer identification, self-liquidating or not, etc.
A product template defines what questions to ask: which modules, signals, entities, relationships matter
A lender overlay defines lender config: standard or lender-authored modules, team visibility, raw signals or summaries, channels, LOS mapping, etc.
A setup is a product × lender pair. A second product is cheap, a new lender cheaper.
Web, API and batch are just three wrappers of one internal API, not three products.
The API that gets exposed to API lenders in the future is just a wrapper on the internal API the V1 web app calls. So "Launching APIs" is just auth + docs, not a rebuild.
Batch is the same queries on a schedule. No new pipeline.
Access control (lender/ team/ module visibility) should be enforced at this shared API layer, so it gates all the channels simultaneously.
Corroboration is a by-product of co-locating facts on resolved entities.
Sources carry important info about the origin of the data being used. But making the sources themselves canonical makes the system inflexible towards new sources, and conflicted between multiple sources.
Instead, if the atomic facts carried by the sources are made canonical, while sources continue to provide provenance to the data/computations, we get a system that benefits from the sources (even from their redundancies) without being bound by them.
Data redundancy between sources is itself a source for:
Entity schema · signal definitions and methodology · module composition engine · product template schema · provenance format.
Module configuration (weights, mappings, scores) · product templates (defined as attribute profiles) · module visibility per team · consumption pref (raw signals to summaries) · delivery channel.
Genuinely bespoke logic should be built by the lender on the raw signal API. The platform should never fork per lender.
A deployment is a product template × lender overlay pair. A new product is a new row. A new lender, a new column. Both reuse existing machinery in some form.
New data source → one new mapper (L1). Nothing above notices.
New lender → one overlay (L5), plus a retrofit view if the lender's system is rigid (L4). L1–L3 untouched.
New lending product → a new product template (L5); sometimes a new signal or entity subtype (L3/L2).
New intelligence module → just a new composition over existing signals (L4).
New consumption channel → a new wrapper on the same internal API (L6).
GST ingestion built for working-capital compliance modules can later feed supply-chain counterparty modules from the same tables.
The share of an onboarded lenders' volumes employing this layer defines the value add, and the usability of the product.
Without it, it is gonna be an unused pipe that creates no value irrespective of how beautiful/ sophisticated it might be.
Onboarding cost of a new lender/product must trend down over time (as the reuse ratio of existing entity/record types, signals, modules, etc goes up).
Without it, its a services business masquerading as a platform.
An onboarded lender launching a second product on the platform