Pulling a borrower's PaisaGhur loan ledger into your own stack

Behind a CNIC-linked phone login, PaisaGhur keeps a per-borrower loan record: principal, tenor, a markup rate, an approval state, and an installment schedule with due dates. The lender, Quark Financials Pakistan, sits on the SECP whitelist of digital lending apps (the list republished as of 5 December 2025), and the app moves money out to EasyPaisa, JazzCash, or a bank account. That payout, and the repayment line behind it, is the data most integrators actually want. The reachable route is authorized analysis of the app's client-to-server interface, run with your written go-ahead. We map it, then hand back source you can run.

Records the app keeps server-side

Every row below comes from a surface a PaisaGhur borrower sees in the app. We name the domain, where it originates, how granular it is, and what an integrator does with it.

Authorized ways to reach the ledger

Three routes genuinely fit this app. None of them touch a borrower's credentials without consent.

1 · Protocol analysis of the app's interface

We observe the app's own HTTPS calls during an authorized build, reconstruct the request and response shapes for login, application status, loan detail, the repayment schedule, and disbursement, and wrap them as a clean API. Reach is wide; this is where the full ledger lives. Durability is moderate, because the response shapes follow the app's release cadence. Onboarding and the authorization paperwork are arranged with you at the start of the project, not asked of you up front.

2 · User-consented session access

A borrower signs in with their CNIC-linked number and OTP, consents, and we drive that authenticated session to read their own loan records. This is the cleaner footing for per-borrower aggregation, and it keeps the data subject in the loop. Reach is whatever that borrower can see in-app.

3 · Native schedule export, where present

If the app surfaces a downloadable repayment schedule or a statement document, we parse it as a low-effort fallback. We confirm whether that export exists during the build rather than assuming it; treat this as a supplement to route 1, not a standalone.

For most PaisaGhur work we would run route 1 to capture the whole ledger and lean on route 2 wherever the integration is genuinely per-borrower and consent-anchored, since a borrower-driven session is the sturdiest basis under Pakistani law as it stands. Route 3 is only worth wiring when a real export turns up.

What a repayment pull looks like on the wire

Illustrative, reconstructed from the app's own client traffic during a build; field names are normalized in delivery, and the markup figure mirrors the example calculation in the app's own listing.

# Reconstructed shape — not a published contract.
POST /api/v1/auth/otp/verify
  { "msisdn": "+9233xxxxxxx", "otp": "######", "device_id": "<android-id>" }
  -> 200 { "access_token": "...", "expires_in": 3600, "borrower_id": "..." }

GET /api/v1/loan/active           Authorization: Bearer <access_token>
  -> 200 {
       "loan_id":      "...",
       "principal_pkr": 5000,
       "tenor_days":    90,
       "markup_apr":    12.57,
       "status":        "DISBURSED",
       "disbursed_to":  { "rail": "JAZZCASH", "wallet_masked": "03xx****" },
       "schedule": [
         { "due_date": "2026-07-15", "amount_pkr": 5154.9, "state": "PENDING" }
       ]
     }

# Handling we build in:
#   401  -> token expired, refresh via the OTP session, retry once
#   429  -> back off; the app throttles repeated status polls
#   rail in {JAZZCASH, EASYPAISA, BANK} -> one normalized disbursement object

What lands at the end of the build

Each deliverable maps to a real PaisaGhur surface, not a generic checklist.

• An OpenAPI / Swagger spec covering the auth handshake, loan detail, repayment schedule, and disbursement endpoints.
• A protocol and auth-flow report: the OTP-to-token chain, header and device-id handling, token lifetime, and where the schedule and disbursement objects diverge.
• Runnable source for the key calls in Python or Node.js, including the normalized disbursement record across the three rails.
• Automated tests that assert schedule state transitions and flag a drifted response shape after an app update.
• Interface documentation plus data-retention and minimization guidance for CNIC-linked fields.

Things we account for on a PaisaGhur build

Two parts of this app shape the engineering, and we handle both as part of the work.

• OTP-gated sessions and token lifetime. The whole ledger sits behind a phone-and-OTP login with a bounded token. We build the sync around that lifetime so a long collection run renews its session cleanly instead of expiring mid-pull, and we keep the OTP step on the consenting borrower's side.
• Three disbursement rails, one record. Payouts and repayments cross EasyPaisa, JazzCash, and bank accounts. We collapse the three into a single disbursement object with a rail field, so your reconciliation logic reads one shape rather than branching per wallet.
• SECP nano-loan caps in the model. Single-app and aggregate exposure are capped under SECP's nano-lending circulars, and tenor is held to 90 days. We model the ledger knowing a borrower's PaisaGhur balance lives inside that aggregate cap across apps, and flag it in the schema.
• Front-end churn. When Quark ships a new app build the response shapes can shift, so we leave a contract-check step in the handoff that catches drift before it breaks a running sync.

Authorization, SECP rules, and Pakistani data law

The lender is a non-banking finance company licensed by the Securities and Exchange Commission of Pakistan. SECP runs the public whitelist of digital lending apps and the nano-lending circulars (Circular 03 of 2023 and the nano-lending follow-ups), which set disclosure, pricing, confidentiality, and app-security requirements. Borrower defaults are reported to the State Bank's eCIB, so the loan record carries credit-reporting weight.

Pakistan's open-banking layer is still being built. Raast, the State Bank's instant-payment rail, moves money but a consent-based account-information regime on the SBP and SECP roadmap is not live yet, so the dependable footing here is the borrower's and your own written authorization rather than a regulator-run data-sharing scheme. On privacy, the country has no enacted comprehensive statute: the Personal Data Protection Bill 2023 remains a draft, with a National Commission for Personal Data Protection only proposed. We work to that draft's direction anyway, authorized and logged access, consent records kept, CNIC-linked fields minimized and retained only as long as the integration needs them, and an NDA where the client wants one.

Where integrators actually use this

• Unified credit view. A lender or aggregator pulls a consenting borrower's active loans and schedules nightly to fold PaisaGhur into one exposure picture across apps.
• Collections workflow. Pending installments and their due dates feed a dunning queue, with paid-state changes flowing back as they clear.
• Settlement reconciliation. Disbursement records are matched against EasyPaisa or JazzCash settlement so a payout that never landed gets caught quickly.

Screens we mapped

Store screenshots we worked from. Select one to enlarge.

How this brief was put together

We read the app's own Play listing for its loan terms, rails, and operator, then cross-checked the lender against the SECP whitelist and the nano-lending circulars, and reviewed where Pakistan's open-banking and data-protection rules currently stand. Primary sources opened:

• SECP — White List of Digital Lending Apps (as of 5 December 2025)
• SECP — Circular 03 of 2023, requirements for NBFCs in digital lending
• ProPakistani — SECP shares updated whitelist of approved lending apps (Dec 2025)
• Google Play — PaisaGhur listing (Quark Financials Pakistan)

Mapped by the OpenBanking Studio integration desk, June 2026.

Other Pakistani nano-loan apps in the same orbit

Same SECP-whitelisted category, listed for ecosystem context — an aggregator integrating PaisaGhur usually wants several of these under one normalized schema.

• Paisayaar (JingleCred) — nano cash loans with the same CNIC-and-OTP onboarding and wallet disbursement.
• Aitemaad (4Sight Finance) — small short-tenor loans, instant in-app decisioning.
• Hakeem (Walee Financial Services) — Shariah-conscious nano financing on a comparable schedule.
• SmartQarza (Goldlion Financial) — instant personal loans with EasyPaisa and JazzCash payout.
• Barwaqt (Seedcred Financial Services) — high-volume nano lender with a similar repayment ledger.
• Daira (Finleap Financial Services) — digital nano loans with app-based KYC.
• Fauri Cash (Pakisnova Microfinance) — quick-disbursement cash loans.
• QarzMitra (Fintech Gharana) — short-term lending on the same whitelist.
• CashBazar (Bluesky Financial Services) — nano loans with wallet settlement.
• JazzCash and EasyPaisa — the wallets themselves, both with in-app advance and lending features and the rails PaisaGhur pays out to.

Questions integrators ask about PaisaGhur

Can you pull the repayment schedule separately from the disbursement record?

Yes. They sit on different screens in the app and we map them as separate objects, an installment list with due dates, amounts and paid or pending state, and a disbursement record carrying the rail and a masked wallet or account. Downstream you can reconcile one against the other without re-parsing a single blob.

Which regulator sits over PaisaGhur's data, and does that cap what we can reach?

The lender, Quark Financials Pakistan, is a non-banking finance company licensed by the SECP, which also runs the public whitelist of digital lending apps and the nano-lending circulars. SECP rules shape disclosure, pricing and confidentiality; they do not block an authorized, borrower-consented pull of that borrower's own loan records.

Does the OTP login mean a person has to be present for every data pull?

For the user-consented route, the borrower authenticates once with their CNIC-linked number and an OTP, and we drive the resulting session, so a fresh human OTP is not needed on every call until the token expires. For a longer-running sync we design around that token lifetime so it renews cleanly rather than dropping mid-collection.

How do you handle disbursements split across EasyPaisa, JazzCash and bank accounts?

We normalize all three into one disbursement record with a rail field, so a payout to a JazzCash wallet, an EasyPaisa wallet or a bank account reads the same way in your system and the reconciliation logic does not have to branch per rail.

Builds here run a one-to-two-week cycle. You can take it as runnable source — the API source plus its OpenAPI spec, the tests, and the interface docs, from $300, invoiced only after delivery once you have checked it works — or skip hosting and call our endpoints on a pay-per-call basis with nothing upfront. Tell us it is PaisaGhur and what you want out of its ledger, and we line up access from there: start a PaisaGhur integration.