Reaching Kissht's loan ledger, EMI schedules and KYC records under consent

A single Kissht account can sit on a loan of ₹10,000 to ₹5,00,000, run a tenure of 6 to 60 months, and carry an APR the listing puts in the 17%–45% band — and every part of that lifecycle leaves a structured trace behind the borrower's login. There is a sanction record, an amortization schedule, a row of paid and upcoming EMIs, downloadable receipts, a KYC profile, and a bureau-sourced credit score the app shows for free. That is the material a lender, a debt-management product, or an internal finance team usually wants to read programmatically. This brief maps where each piece sits and the authorized way to reach it.

The bottom line: two different data planes are in play here, and they need two different methods. Bank-statement and income data that feeds underwriting moves on India's regulated consent rail; Kissht's own loan-servicing records do not travel on that rail and are read from the authenticated app instead. We build to both and hand back one normalized interface.

What the account actually holds

These rows track surfaces named the way the app and its help material name them, not a generic feature list.

How we reach each plane

Account Aggregator consent (regulated)

For the bank-statement and financial-information side, India's Account Aggregator framework is the built-for-purpose path. A consenting borrower authorizes a Financial Information User to receive data from Financial Information Providers through a licensed NBFC-AA, with a single revocable consent and no shared passwords. Reach is whatever the borrower's banks expose as FIPs; durability is high because it is a regulated, machine-readable rail. We handle the FIU onboarding and the consent-artifact design with you as part of the build.

Authorized interface integration of the servicing session

The loan ledger itself — sanction terms, the amortization schedule, paid-EMI receipts, account status — lives behind the app login and does not ride the AA rail. We analyze the authenticated session under your authorization, document the auth and token flow, and implement typed endpoints over those surfaces. This is the work that captures the records AA never carries.

User-consented export as a fallback

Where a borrower can already download the amortization schedule or a payment receipt, we can wire a consented-export step as a low-effort supplement — useful for one-off pulls or as a reconciliation check against the live integration, though it is manual and less current than the interface path.

What we would actually recommend for Kissht: run the interface integration as the primary feed because the loan-servicing data your team needs is only there, and bring the AA consent in alongside it for the income inputs that strengthen underwriting. The two are complementary rather than ranked — neither alone gives the full borrower picture.

What lands at the end

Each deliverable is tied to a real Kissht surface, not a template.

• An OpenAPI specification covering the loan-account, schedule, repayment and KYC reads as typed endpoints with example payloads.
• A protocol and auth-flow report: how the app authenticates the session, how tokens are issued and refreshed, and the request signing observed during the build.
• Runnable source for the core reads in Python and Node.js — account list, amortization pull, receipt fetch — with the partner-NBFC identifier modelled per account.
• Where AA is in scope, the FIU consent-flow wiring and a normalized mapping from the AA financial-information schema into your model.
• Automated tests against recorded fixtures, plus a re-validation harness for when the dashboard layout shifts.
• Interface documentation and data-retention guidance covering consent records and minimization.

A call against the servicing session

Illustrative shape, confirmed and pinned down during the build — field names and the exact auth sequence are settled against the live session, not assumed.

POST /session/refresh            # rotate the short-lived session token
  headers: { device-id, app-token }
  -> 200 { access_token, expires_in }

GET /loans                       # accounts behind the borrower login
  Authorization: Bearer <access_token>
  -> 200 [ { loan_id, lender: "Si Creva|MAS|Northern Arc|Piramal|SMFG",
             sanctioned, net_disbursed, tenure_months, rate, status } ]

GET /loans/{loan_id}/schedule    # amortization rows
  -> 200 { currency: "INR",
           installments: [ { seq, due_date, principal, interest,
                             balance, state: "PAID|DUE|UPCOMING" } ] }

# error handling we account for
# 401 -> token expired      : re-run /session/refresh, retry once
# 409 -> schedule recomputed: re-pull after a foreclosure/part-payment
# 429 -> throttle           : backoff, respect the dashboard's pacing

Consent and the regulatory frame

Kissht describes itself as working with RBI-registered NBFCs and routing bank-statement access through an authorized Account Aggregator. That sets the frame for us. On the AA side the dependable basis is the borrower's own explicit, revocable consent: scope is limited (the app notes one-time access to the latest statement, logged out after linking), expiry and revocation are first-class in the framework, and data minimization is the default. On the servicing-interface side the basis is the same borrower's authorization, carried as a documented consent artifact. We operate authorized, logged and data-minimized, hold the integration under NDA where the engagement needs it, and keep consent records so any pull is traceable to the permission that allowed it. The framework is overseen by the Reserve Bank of India; the consent layer is the part that makes this defensible rather than fragile.

Engineering notes specific to Kissht

Two things shape the build, and we handle both rather than passing them to you.

• Multiple partner NBFCs mean a borrower's accounts can differ in agreement, fee structure and disbursal record. We carry a lender identifier per loan and normalize schedule and fee fields across Si Creva, MAS Financial, Northern Arc, Piramal and SMFG India Credit into one schema, so downstream code is not guessing which issuer a row belongs to.
• The amortization schedule and outstanding balance move after every EMI and any part-payment or foreclosure. We design the sync to re-read on debit events and reconcile against the downloadable schedule, and we set a layout-change check so a redesigned LOANS tab surfaces as a caught failure, not silent drift.
• The in-app credit score is a rendered bureau value, not stored Kissht data. We read the displayed score and its date and label it as derived, so it is never mistaken for a first-party field.

Access to a consenting account or a sponsor sandbox is arranged with you during onboarding; it is part of how the project runs, handled on our side with your sign-off.

Pricing and how it runs

Delivery lands in one to two weeks. Source-code delivery starts at $300: you get the runnable integration, the spec, the tests and the docs, and you pay after delivery once you are satisfied with what arrived. Prefer not to host it yourself? Run it as a pay-per-call API instead — you call our endpoints, pay only for the calls you make, and there is no upfront fee. You bring the app name and what you want out of its data; access, consent setup and compliance paperwork are arranged with you as the project runs. Start the conversation at /contact.html and tell us which records you need.

Where teams put this

• A competing lender consolidating a customer's existing Kissht exposure and EMI calendar before offering a top-up or balance transfer.
• A personal-finance app folding the borrower's loan schedule into a unified debt and cash-flow view.
• A collections or reconciliation team matching paid-EMI receipts against the lender ledger automatically.
• An underwriting flow combining AA bank-statement inputs with the live repayment record for a fuller affordability picture.

Interface evidence

Store screenshots we reviewed while mapping the surfaces above. Select to enlarge.

What was checked, and where

Mapped over June 2026 against the app's own Play Store listing and description, its public help and privacy material, and primary references on the consent framework it relies on. Cross-checked the Account Aggregator roles and the RBI oversight against government and regulator sources below.

• Kissht Quick Personal Loan App on Google Play (package com.fastbanking)
• Account Aggregator framework — Department of Financial Services, Ministry of Finance
• Sahamati — the Account Aggregator collective
• RBI on the regulatory framework for account aggregators (Rajeshwar Rao)

Mapped by the OpenBanking Studio integration desk, June 2026.

Neighbouring apps in the same data space

Other Indian instant-lending apps hold comparable account data, which matters when a single integration needs to span more than one lender. Names are listed for context only.

• KreditBee — flexi and personal loans for salaried and self-employed borrowers, with its own schedule and repayment records.
• Fibe (formerly EarlySalary) — short-tenure personal loans holding EMI and disbursal data behind a login.
• CASHe — AI-scored personal loans with an in-app credit and repayment ledger.
• Navi — personal loans and more under a single account with structured loan records.
• MoneyView — instant personal loans plus account-level repayment tracking.
• Freo (formerly MoneyTap) — a line-of-credit product where interest accrues on the drawn amount.
• Branch — app-based small-ticket loans with their own servicing data.
• mPokket — small loans aimed at students and young earners, account-bound.
• LazyPay — pay-later and personal credit with transaction and repayment history.
• True Balance — small-ticket lending with in-app loan and KYC records.

Questions integrators ask

Does the loan servicing ledger come through the Account Aggregator rail, or somewhere else?

No. The Account Aggregator framework carries bank statements and other financial-information from FIPs to a consenting lender; it does not surface Kissht's own loan-servicing records. Sanction terms, the amortization schedule and paid-EMI receipts live in the authenticated app session, so we reach those by interface integration under your authorization and use AA only for the bank-statement inputs.

Can you capture the CIBIL score that Kissht shows free inside the app?

The in-app credit score is a rendered view from a bureau pull tied to the borrower's KYC, not a stored field you own. We map the screen and the call behind it so an integration can read the displayed score and its refresh date, and we document that it is a derived bureau value with its own consent basis rather than first-party Kissht data.

The app works with several partner NBFCs — does that change the integration?

It does. A loan booked under Si Creva, MAS Financial, Northern Arc, Piramal or SMFG India Credit can carry a different agreement, fee line and disbursal record, so we model the lender identifier per account and normalize the schedule fields across NBFCs into one schema instead of assuming a single issuer.

How current is a pulled EMI schedule and how do you keep it from drifting?

The amortization schedule and outstanding balance change after every payment and any foreclosure, so a one-off pull goes stale. We design the sync to re-read after debit events and reconcile against the downloadable schedule, and we set a re-validation pass for when the dashboard front end changes layout.