Reaching the loan ledger inside Kissht's app

Behind a Kissht login sits a per-borrower loan ledger — sanction amount, tenure, APR, the processing fee, and a dated EMI schedule that updates as instalments clear. The app puts that on a single dashboard where a user tracks EMIs and manages repayments, alongside a free CIBIL score and an EMI-card credit limit that behaves like a pre-approved line. That ledger is the asset a lending partner, a collections platform, or an aggregator wants to read in a structured form. This page covers what the app holds, the authorized way to reach it, and what we hand over.

The loan amounts run roughly ₹10,000 to ₹5,00,000 with an APR band of about 17% to 45%, per the Play Store description. Kissht reports 60+ million users in its own listing — we treat that as a marketing figure, not an audited count. What matters for integration is narrower and concrete: the structured records tied to one consenting borrower.

What sits inside a Kissht login

Each row below is a surface the app actually exposes to the signed-in user. Granularity is what an integration can realistically return per borrower.

Authorized routes to that data

Three approaches apply to Kissht, and they reach different things. We pick by what the borrower data is for.

Authorized interface integration of the app's own surfaces

The loan ledger, EMI schedule, EMI-card limit and the agreement copies Kissht stores are served by Kissht's own backend to the signed-in user. We map those calls — the auth handshake, the request and response shapes, pagination of the instalment list — under the account holder's authorization, and expose them as a clean API. This is the route that returns Kissht-specific records; nothing else reaches them.

RBI Account Aggregator consent flow

The bank statements and financial picture a loan draws on move through the regulated Account Aggregator network, launched in September 2021, on a standardised consent artefact. Where you want the durable, regulator-blessed feed of a borrower's bank-side data rather than Kissht's internal view, this is the cleaner long-run path. It is consent-scoped and revocable by design.

User-consented session export

For one-off or low-volume needs, a consenting borrower's session can be operated to pull their own statements, EMI schedule and KFS documents, with the email/SMS-delivered agreement PDFs as a fallback when a document is not in the app view. Lower engineering lift, less suited to continuous sync.

For most Kissht work we lead with interface integration for the in-app ledger and pair it with the Account Aggregator feed for the bank data — the first gives you Kissht's unique records, the second gives you a regulated, revocable line to everything around them. Access and onboarding for both are arranged with you during the build.

A look at the EMI-schedule call

Illustrative shape only — exact field names and the auth chain are confirmed during the build against a consenting account. The pattern is a bearer token from login, then a per-loan schedule fetch.

POST /v2/auth/token
{ "mobile": "+9198XXXXXXXX", "otp_ref": "<from OTP step>", "device_id": "<bound>" }
=> { "access_token": "ey…", "expires_in": 1800 }

GET /v2/loans/{loan_id}/schedule
Authorization: Bearer ey…
=> {
     "loan_id": "KS-…",
     "lender": "Si Creva Capital Services",
     "sanctioned": 125000, "net_disbursed": 116150,
     "apr": 41.0, "tenure_months": 24,
     "installments": [
       { "n": 1, "due": "2026-07-05", "emi": 7184, "principal": 3742,
         "interest": 3442, "status": "PAID" },
       { "n": 2, "due": "2026-08-05", "emi": 7184, "status": "DUE" }
     ]
   }

# Handle: 401 -> refresh token; 423 -> KYC re-verification pending;
#         429 -> back off, the schedule endpoint is rate-limited per session.

The example figures mirror the worked repayment case in Kissht's own listing (₹1,25,000 sanctioned, ₹1,16,150 net, 41% APR) — used here to show the schema, not as live data.

What lands in your repo

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI spec covering login/token refresh, the loan-list and per-loan schedule calls, disbursal records, KYC status and the CIBIL read.
• A protocol and auth-flow report: the OTP-to-bearer handshake, token lifetime, device binding, and how the session is kept alive for the schedule endpoint.
• Runnable source for the key endpoints in Python and Node.js, with a normalized loan object that flattens the five NBFC formats into one shape.
• Automated tests against recorded fixtures, plus the data-localization and retention notes the RBI directions call for.
• Interface documentation an in-house team can maintain after handover.

Consent, RBI rules, and where the data may travel

Kissht is a lending front end for RBI-registered NBFCs, so the work sits squarely inside Indian digital-lending rules. Three things shape the build. The Account Aggregator framework governs consent for the bank-side feed — every pull is shown to the borrower, scoped to a purpose and duration, and revocable, with the aggregator never decrypting the data. The RBI Digital Lending Directions (the 2025 directions replaced the 2022 guidelines) require borrower data to be stored in India, with anything processed abroad deleted and restored within 24 hours, and they keep disbursal off third-party accounts. The DPDP Act 2023 is the umbrella privacy regime for personal data. We operate authorized, logged, data-minimized access — verification state rather than raw KYC documents where the use case allows — with consent records retained and an NDA in place where the engagement needs one.

What we plan around on a Kissht build

Two specifics that shape how the integration is engineered:

• Five lenders, one borrower. A single Kissht user's loans can be booked under Si Creva, MAS Financial, Northern Arc, Piramal or SMFG India Credit, each with its own agreement format and disbursal trail. We normalize them into one loan object so your code never branches on which NBFC underwrote a given loan.
• India-resident pipeline. Because the directions require data to stay on Indian servers, we stand the extraction and any cache up on India-resident infrastructure from the start, so freshness and the 24-hour restore rule are handled rather than retrofitted.
• Consent and session windows. The Account Aggregator consent has a validity period and the in-app session token expires fast; we design the sync around both so a feed does not quietly lapse, and when Kissht ships an app update we re-map the changed calls as part of upkeep.

Access — a consenting account or a sponsor sandbox — is set up with you during onboarding, as part of the project rather than something you hand over first.

Pricing and how a build runs

A Kissht integration ships in a one-to-two-week cycle. You can take it as source-code delivery starting at $300 — runnable API source plus the spec, tests and interface docs, and you pay only after delivery once the build does what you needed. Or run it as a pay-per-call hosted API: we host the endpoints, you call them, and you pay per call with nothing upfront. Tell us the app and what you want out of its data; we handle the route, access and compliance. Start the conversation on the contact page.

Screens from the app

Public Play Store screenshots, shown for interface reference.

Sources and method

This brief was put together from the app's Play Store listing and its own site, the RBI material on the Account Aggregator network and digital-lending directions, and confirmation that Si Creva is an RBI-registered NBFC. Data-surface claims come from what the signed-in app shows; the auth and field shapes are confirmed during a build, not asserted as fact here. Primary references:

• Kissht Quick Personal Loan App — Google Play listing
• RBI — Guidelines on Digital Lending (FAQ)
• Dept. of Financial Services — Account Aggregator framework
• Si Creva Capital Services — lending partner behind Kissht

Mapped by the OpenBanking Studio integration desk, June 2026.

Other Indian lending apps in the same data space

Same category, similar data shapes — useful if you are building one feed across several lenders. Listed for context, not ranked.

• KreditBee — flexi and personal loans for salaried and self-employed users; holds a comparable loan ledger and EMI schedule.
• Freo (formerly MoneyTap) — a line-of-credit model where interest applies to the drawn amount; holds limit, draw and repayment records.
• PaySense — instalment personal loans for thin-file borrowers; per-loan schedule and disbursal data.
• Fibe — salaried-focused short-term loans; loan, EMI and KYC state behind login.
• CASHe — app-based personal loans with its own credit score; loan and repayment ledger per user.
• Navi — personal and home loans fully in-app; sanction terms and EMI schedule data.
• Branch — small-ticket instant loans; loan status and repayment history per account.
• True Balance — small-credit and bill-pay app; loan and limit records behind sign-in.
• moneyview — personal loans with an in-app tracker; sanction, EMI and disbursal records.

Questions integrators ask about Kissht

Which Kissht data can a borrower-consented integration actually return?

With the account holder's consent we can map the surfaces the app shows that borrower: sanction terms (amount, tenure, APR, processing fee), the running EMI schedule and paid/overdue status, disbursal records net of fees, the in-app credit limit, KYC and PAN verification state, the free CIBIL score, and the post-sanction KFS and loan-agreement documents.

Does the RBI Account Aggregator route cover Kissht's own loan ledger?

The Account Aggregator network moves a borrower's bank and financial-institution data with consent, so it is the durable route for the surrounding financial picture a Kissht loan draws on. Kissht's internal ledger — its EMI schedule, the EMI-card limit, the agreement copies it stores — is reached through authorized interface integration of the app's own surfaces, with the borrower consenting. Most builds use both.

How do the RBI Digital Lending Directions affect where the data is stored?

Indian digital-lending rules require borrower data to sit on servers in India, and anything processed abroad must be deleted and restored to India within 24 hours. We keep the extraction pipeline and any cache on India-resident infrastructure so the integration matches that constraint rather than fighting it.

A borrower holds loans under more than one of Kissht's NBFC partners — does that change the build?

It does, and we account for it. A single Kissht user's loans can be booked under different lenders — Si Creva, MAS Financial, Northern Arc, Piramal or SMFG India Credit — each with its own agreement format and disbursal trail. We normalize those into one schema so downstream code sees a consistent loan object regardless of which NBFC underwrote it.