Getting borrower and repayment data out of PayRupik

Sayyam Investments Pvt Ltd runs PayRupik as a non-deposit-taking NBFC registered with the Reserve Bank of India, operating out of Guwahati, Assam, per its own corporate site. The product is narrow and well-defined: personal loans up to ₹2,50,000, tenures of 91 to 180 days, and a maximum APR of 35.04% as the Play Store listing states it. That tight shape is exactly what makes the data worth integrating — a small set of fields per borrower, each one that changes on a schedule you can model.

The honest version of the brief is short. India already has a regulated rail for this kind of financial data, so the lead route is consent-based account aggregation, with authorized protocol work against the app's own session as the close-to-the-source alternative. Below is what is reachable, how we reach it, and what you get back.

Authorized routes into PayRupik's data

Three routes genuinely apply here. They differ in how close to the source they sit and how durable they are when the app changes.

1. Account Aggregator consent (NBFC-AA)

India's AA framework went live commercially in 2021 and now moves loan data — active accounts, EMI status, repayment records — between regulated institutions through an RBI-licensed consent manager. For a PayRupik loan held by Sayyam Investments as a Financial Information Provider, this is the cleanest path: the borrower approves a scoped, time-boxed consent, and structured loan-account data flows encrypted to the consuming side with an audit log attached. Effort is moderate, durability is high because the rail is regulated rather than scraped. We register the FIU connection and wire the consent handshake as part of the build.

2. Authorized protocol analysis of the app session

When you need the exact view the borrower sees in-app — the live schedule, the next due date, the in-progress application state — we map the app's own request traffic under the account holder's authorization. This reads the mobile client's REST calls, reconstructs the auth and token chain, and turns it into a documented, callable client. Closer to source, faster to first data, but it tracks the app's front end, so it needs a maintenance touch when releases shift the flow.

3. User-consented credential access for one-off pulls

Where a single export is enough — a pilot dataset, a reconciliation snapshot — a consenting borrower can authorize a one-time session pull. Light to stand up, no standing infrastructure, useful as a bridge while an AA connection is provisioned.

For most teams the AA consent route is the one we would build on first: it is the rail Indian regulators expect lending data to travel, it carries its own consent and audit trail, and it does not break when PayRupik ships an app update. Protocol analysis comes in where you need the in-app-live view that the aggregator feed does not expose at the same granularity. The one-off route is a stopgap, not a foundation.

What sits behind a PayRupik account

These reflect what PayRupik itself describes collecting and showing — KYC at onboarding, a clear pre-confirmation charges summary, and a fully digital servicing flow. The charges row maps directly to the representative example the app publishes: on a ₹10,000, 120-day loan it discloses a 4% processing fee, 18% GST on that fee, ₹1,152 interest and ₹11,624 total repayable.

What lands in your repo

Every engagement ends with something runnable, not a slide deck. For PayRupik that means:

• An OpenAPI / Swagger spec describing the loan, repayment-schedule, KYC-status and application-state surfaces as normalized resources.
• A protocol and auth-flow report — the token issue and refresh chain, session handling and error semantics observed for whichever route you choose.
• Runnable source (Python or Node.js) for the key endpoints: pull a loan, fetch its schedule, read repayment state, check application stage.
• Automated tests against captured fixtures, plus a normalized JSON schema so PayRupik data drops into a multi-lender model cleanly.
• Interface documentation and a data-retention / consent-handling note aligned to the rules below.

A worked example: pulling a repayment schedule

Illustrative shape from mapping the loan-servicing surface; field names are normalized in the delivered client and confirmed during the build.

GET /v1/loans/{loan_id}/schedule
Authorization: Bearer <session_token>     # token + refresh chain documented in the report
Accept: application/json

200 OK
{
  "loan_id": "PR-...",
  "principal_inr": 10000,
  "tenure_days": 120,
  "apr_pct": 35.04,
  "status": "active",            # active | closed | overdue
  "instalments": [
    { "seq": 1, "due_date": "2026-07-28", "amount_inr": 2906, "state": "paid" },
    { "seq": 2, "due_date": "2026-08-28", "amount_inr": 2906, "state": "due"  }
  ],
  "outstanding_inr": 8718
}

# error handling we document and the client retries on:
# 401 -> refresh token, replay once
# 409 -> consent expired, re-trigger AA consent handshake

On the AA route the same fields arrive as a consented FIP data block rather than a direct call; the delivered client normalizes both into one schedule object so downstream code does not care which rail produced it.

Consent and the RBI rulebook this falls under

This is regulated lending data in India, so the basis is the borrower's own explicit consent, captured and logged. The Account Aggregator framework provides that consent layer through a licensed NBFC-AA — scoped purpose, an expiry, and revocation the user controls. On top of it, the RBI (Digital Lending) Directions, 2025 consolidated the earlier 2022 digital-lending guidelines and require need-based, consented data collection with an auditable trail; data-handling obligations are aligned with the DPDP Act, 2023. We build to those: consent records kept, data minimized to the fields you actually use, KYC documents not cached by default, and an NDA where the engagement needs one. Compliance here is how the integration is built, not a hurdle bolted on after.

Engineering judgment we bring to this build

Two things about PayRupik specifically shape how we engineer it.

• Short loan lifecycles. With tenures of 91 to 180 days, a loan can open, run and close inside a single quarter. We set the sync cadence and the consent-refresh window so disbursal, EMI movement and closure are all captured while consent is live — otherwise a loan can be born and repaid between two coarse polls and never properly recorded.
• KYC sensitivity. PayRupik collects PAN and address proof at onboarding. We map only the identity fields and statuses an integration needs, keep raw documents out of any cache by default, and document exactly what is read so a data-protection review has nothing to dig for later.
• Front-end drift. On the protocol route, an app release can move the request map. When that happens we re-run the captured traffic against the new build and patch the client before it fails quietly in production, rather than waiting for missing data to surface downstream.

Access for any of this — a consenting account or a sponsor sandbox — is arranged with you during onboarding. It is part of the project, handled on our side with you, not a checklist you clear before we start.

Where teams put this to work

• A balance-sheet lender or co-lending partner syncing PayRupik exposure and repayment state into its own servicing system.
• A collections or recovery platform that needs live due-date and outstanding fields to time outreach.
• An underwriting team running a pilot that folds PayRupik loan history into a credit model alongside bank-feed data.
• A personal-finance app giving a user one view of every loan they hold, PayRupik included.

Screens we mapped

Public Play Store screenshots we reviewed while sketching the surfaces above. Tap to enlarge.

Among India's lenders

PayRupik sits in a crowded instant-credit category. The names below hold comparable per-user lending data; for a client running a multi-lender model, a unified integration normalizes all of them into one schema.

• KreditBee — short-term personal loans with a wide ticket range and its own app-held repayment records.
• Freo (formerly MoneyTap) — a credit-line product where interest accrues on drawn amounts, so utilization and draw history are the live data.
• CASHe — salaried-borrower lending with an in-house scoring layer alongside bureau data.
• Moneyview — instant personal loans with structured eligibility and repayment data per account.
• Navi — app-first personal loans holding loan and EMI records server-side.
• PaySense — instalment personal loans with per-user servicing data.
• Bajaj Finserv — broad lending across personal loans and EMI financing with rich account state.
• Fibe — personal loans up to larger tickets, repayment data held per borrower.
• mPokket — small-ticket lending aimed at students and young earners.

Questions integrators ask about PayRupik

Can we read EMI and repayment status from a PayRupik loan account?

Yes. A live PayRupik loan carries a disbursed principal, a tenure between 91 and 180 days, a schedule of dues and a running repayment state. Through Account Aggregator consent those loan-account fields move from the lender as an FIP; through authorized protocol work against the app's own session we read the same schedule the borrower sees in-app. Both surface principal, due dates, paid-versus-outstanding and closure.

Which RBI regime governs pulling this data in India?

Two apply. The Account Aggregator framework (NBFC-AA, RBI-licensed) is the consent rail for moving financial data between regulated institutions. The RBI (Digital Lending) Directions, 2025 — which consolidate the 2022 digital-lending guidelines — plus the DPDP Act, 2023 govern need-based collection, explicit consent and an auditable trail. We design the integration to sit inside those records, not outside them.

PayRupik tenures are short — does that change the sync design?

It does. A loan can open and close inside three to six months, so the interesting state changes fast. We set the polling cadence and the consent-refresh window so disbursal, EMI movement and closure are all captured while the consent is live, rather than discovering a loan only after it has already been repaid.

We want PayRupik repayment data for an underwriting pilot — how does the build run?

You give us the app name and the fields the pilot needs; access against a consenting account or a sponsor sandbox is arranged with you during onboarding. You get an OpenAPI spec, runnable source for the loan and repayment endpoints, a protocol and auth-flow report, automated tests and interface docs, normally inside one to two weeks.

How this was checked

Sources reviewed on 28 June 2026: the PayRupik Play Store listing and Sayyam Investments' corporate site for the product shape and NBFC status; the Government of India's Account Aggregator reference and the RBI's digital-lending notification for the consent rail and the rulebook. Loan terms quoted are as the app and its operator publish them.

• PayRupik on Google Play (in.hanafintech)
• Sayyam Investments — about / NBFC status
• Account Aggregator Framework — Dept. of Financial Services
• RBI — Guidelines on Digital Lending (notification PDF)

Reviewed 28 June 2026 by the OpenBanking Studio integration desk.

Source built for PayRupik ships in one to two weeks. You pay from $300 on delivery, once the code checks out — or skip the upfront entirely and pay only for calls against our hosted endpoints. Tell us the app and the data you need at our contact page and we handle the route, the access and the build.