RiskStac and ULI

A functioning farm could lack conventional income evidence, consistent land records or bureau history. Specialist agricultural information needed to become something an institution could interpret within its appraisal process.

The agricultural context combined weather, soil moisture, vegetation, historical yield and parcel-level signals. The product task was to connect that specialist analysis with the output a lender needed, rather than ask the institution to assemble disconnected indicators.

My remit covered the assessment capability and its standardised information-sharing requirements. The record describes the integration work, but does not supply a publishable lender acceptance example or historical API response. The current contract model is therefore a proposal, not retrospective production evidence.

I worked with lender and data-partner requirements to bring assessment information into institutional appraisal. The product team supplied the agricultural output and handoff requirements. RBIH supplied national infrastructure; lenders retained underwriting, approval and disbursement.

The borrower supplied information and applicable consent. Keeping these responsibilities separate was necessary to describe the service honestly: access to agricultural data, an assessment output and a credit decision are different contributions.

The documented contribution is the agricultural-assessment product and lender-information handoff. The source does not publish a standalone appraisal-quality, credit-risk or NPA evaluation.

A useful integration carries information the next team can act on. For another specialist-data product I would begin with the receiving workflow, then define the output, responsibility and exception questions at that handoff. Data volume alone would not answer whether the institution could use it.

The Professional Profile reports 167 satellite indices. That describes input breadth; it does not establish a calibrated credit score, underwriting quality or personal model authorship. International credit-data work is documented in the separate Brazil/Malaysia case.

The source identifies standardised APIs and ULI information-sharing work as the route from the agricultural assessment to the lender workflow. It does not identify every service used, an accepted schema or one specific historical exception decision. The ULI catalogue and later public documentation cannot fill that gap.

RiskStac’s October 2026 public proposition presents farm-credit reports, repayment-risk mitigation and farm-progress monitoring using satellite, IoT, weather, climate and soil-health information. It is post-tenure context, not proof of historical interface ownership or every present capability.

Silent generated overviews of the October 2026 ULI platform, updates and service catalogue. No authenticated task was executed; these are infrastructure references, not Priyam’s delivery recordings.

Silent generated overview of the 13 October 2026 public RiskStac pages, not authenticated lender use.

ULI connects lenders to multiple data and service providers through common interfaces, reducing the need for repeated bilateral integrations. The platform began as the Public Tech Platform for Frictionless Credit pilot in 2023 and was renamed ULI in August 2024. This is RBIH’s national infrastructure context, distinct from my agricultural-risk product contribution.

The public journey describes integration and setup, aggregation of information, processing under agreements, and metered usage/billing. It is a published operating model rather than a live loan test. Product setup, assigned credentials and whitelisting precede data access; the platform does not replace lender underwriting.

The account-aggregator/Perfios guide describes a ReBIT FIU 2.0 consent sequence: create a consent handle, inspect its status and retrieve permitted information when the conditions are met. A consent status is not a credit approval.

A separate DGV/Amul service describes OTP handling, transaction identifiers and milk-volume/income-consistency information. Its documented OTP expiry is ten minutes, with three generation and three verification attempts. That contract is not assumed to apply unchanged to the newer Kamdhenu or Aavin services.

Published operational guidance separates sandbox and production subscriptions and requires lender/provider IP and URL whitelisting. Assigned credentials and token configuration belong to onboarded institutions; no access secrets or personal test data are shown here.

The next-generation land-records guide returns HTTP 202 with a request identifier in RECEIVED state, then describes polling and a multi-stage pipeline. A request may be technically accepted while the underlying service is still preparing or may ultimately fail. A later HTTP 200 can carry a failed result in the body, so transport success is not business success.

The guide suggests one-to-two-second polling and a typical two-to-eight-second processing range. These are documentation claims, not a measured end-to-end loan SLA. A duplicate request identified by LRS1001 returns the prior request identifier, preserving an idempotency boundary.

Published pages differ on supported-state counts and staging routes. Introduction, overview, catalogue and update-card lists use different counts; they are kept as dated views rather than added into one coverage figure.

The October 2026 capture shows six update cards. They describe available or piloted infrastructure services, not an authenticated borrower console or evidence that every named lender and provider completed a loan. The MoRTH card has a dated pilot; the other cards do not supply a comparable launch date.

The land-record update lists eleven states: Madhya Pradesh, Uttar Pradesh, Maharashtra, Tamil Nadu, Andhra Pradesh, Odisha, Tripura, Chhattisgarh, Assam, Gujarat and Karnataka. The service catalogue and dashboard use thirteen-state counts, while documentation has other backend counts. Different page dates and definitions are unresolved.

The captured service map contains 128 catalogue rows across six categories, 55 providers and 190 linked references. The dashboard separately displays 143 services and 64 providers. Catalogue rows, links, dashboard services and unique providers are different units; neither view is converted into a personal outcome.

The categories span identity, assets, credit, documents, income and value-added services. The breadth explains the integration setting for agricultural-risk information, without implying that every listed service was used in my project.

The annual report and public references describe national platform progress. They are included to explain the environment in which an agricultural-risk integration operates; none is a Priyam-led national outcome.

At 31 March 2025, RBIH reported 44 lenders, 60+ data services and 12 loan journeys. Its annual report gives 2.1 crore+ API hits, ₹60,000 crore+ disbursement and 12 lakh+ loans, explicitly spanning fully digital and partly assisted journeys. These are platform totals with their original units, not unique users or proof that every loan was fully digital.

The August 2026 dashboard displays 2.50 crore monthly API requests, peak 31.8 TPS, average 12.19 TPS, 100% availability and zero unplanned downtime hours. Published response-time examples are 211 ms for property data, 4,454 ms for registration-certificate data and 2,397 ms for a credit-score service. The dashboard does not provide evaluation methodology, so these remain displayed metrics rather than an independent service test.

The 2024–25 annual report described future expansion to more regulated entities and services and a B2C interface. It also discussed consented gig-worker work-history, earnings and performance information with platforms such as Rapido, Namma Yatri and Uber and lending partners. Those were institutional pilot or forward-plan descriptions, not projects attributed to me.

The July–September 2024 RBIH newsletter and the RBI digital-public-infrastructure speech explain standardised, consent-based access and the planned national rollout. Their event and publication dates differ. The relevant material is the lending-infrastructure context; unrelated newsletter projects and central-bank technology programmes are not added to my portfolio.

The 2026 public page lets an institution inspect farm-credit reporting, monitoring and the advertised repayment-risk/insurance proposition, then reach an enquiry or business-login entry.

The gallery records those current panels and their stated satellite, IoT, weather, climate and soil-health inputs. No authenticated lender journey, live risk calculation, backend recommendation or testimonial outcome was tested.

This authored contract model proposes parcel context, observation dates, missing inputs, freshness and assessment provenance for lender review. It explains a current approach; it is not a historical RiskStac API response, accepted scorecard or verified list of delivered controls.

I would validate parcel matching and appraisal usability separately from predictive performance, turnaround and credit outcomes. Each needs a defined cohort and baseline. The five-question plan below has not been executed.

The original programme reach and lending-time reports remain unresolved: 500K+ is variously farmers or loans, and the under-thirty-minute claim has no supplied start/stop definition. No matched borrower cohort or independent NPA evaluation is available.

Responsibility map for the documented product remit and the infrastructure around it. This is not a production system schema.