Loan-account data inside SmartQarza, and the consented route in

SECP has named SmartQarza one of only three nano-loan apps that cleared its Circular 10 requirements, according to Dawn's reporting. That single fact shapes the whole integration: the loan ledger behind this app is a regulated, disclosure-bound data set, not a loose cache. Every borrower has a Key Fact Statement on file, a fixed repayment schedule, and a disbursement that landed in a named bank account or wallet. Reaching that data cleanly is a question of consent and protocol work, and both are routine here.

The short version: the data worth syncing is the per-borrower loan record — what was approved, on what terms, what has been repaid, and what is outstanding. We reach it by analysing the app's own authenticated traffic under the account holder's consent, and we keep the capture narrow enough to sit inside the rules SmartQarza already operates under. The rest of this page walks the data, the routes, and what arrives at the end.

Where SECP rules draw the consent line

Pakistan does not run a single mandatory consumer account-aggregation scheme of the UK or Brazil kind. What it does have is specific. The State Bank of Pakistan published its Open Banking Framework and the Raast instant-payment rails, and SECP — the regulator for non-bank lenders like Gold Lion Financials — has issued a stack of digital-lending circulars that govern exactly what an app like this may hold and share.

Two of those rules drive our design. SECP's 2022 circular requires a Key Fact Statement before any disbursement and forbids lenders from reaching a borrower's contacts or gallery, even with consent. Its 2024 update tightened residency and disclosure further; borrower data must stay on infrastructure inside Pakistan. So the legitimate basis for our work is the borrower's own authorization to retrieve their own records, and the capture is built to honour the residency and minimization rules rather than work around them. The Personal Data Protection Bill remains a draft, so consent and SECP's circulars — not a general data-protection statute — are the live framework today.

What a SmartQarza account actually stores

These rows reflect surfaces the app exposes to its own logged-in user, drawn from its Play description and walkthroughs of the apply-and-repay flow. Granularity is what an integrator should expect to retrieve per borrower.

Per the Play listing, loan principals run PKR 2,000 to 50,000 over 91 to 180 days, with a stated APR band of 10%-274%. Those numbers are the borrower's own contract terms, which is why the KFS fields matter more than any single repayment total — they let downstream systems rebuild the amortization rather than trust a rounded figure.

Routes to the loan-account data

Three approaches genuinely apply to this app. They are not equal, and we say plainly which one carries the work.

1 · Consented protocol analysis of app traffic

We observe how the SmartQarza client authenticates and which calls return the loan record, working from a consenting borrower's session under their authorization. This reaches everything the app itself shows — KFS, schedule, disbursement, balance — at full fidelity. Effort is moderate; durability depends on the client's release cadence, which we account for in maintenance. Access to a test account is arranged with you during onboarding, not asked of you up front.

2 · Native KFS / statement export

SECP forces the lender to deliver the Key Fact Statement by screenshot, email and SMS. Those artifacts are a low-effort, durable fallback for the contract terms even when no live session is in play. They do not carry running balance changes, so this route complements rather than replaces the first.

3 · Bank-side reconciliation via Raast / statement

Because money moves out to a bank account or wallet, the disbursement and each repayment also exist on the banking side. Where a borrower consents to share that statement, we use it to confirm the in-app ledger against actual settlement — useful for collections and dispute work.

For most buyers, route 1 is what we build the integration on: it is the only path that returns the live, structured loan ledger SmartQarza shows its own user. Route 2 anchors the contract terms and survives front-end churn, and route 3 closes the loop on money actually moved. We usually ship the first with the second wired in as a verification check, and add the third only when reconciliation is in scope.

A repayment-schedule pull, sketched

Shape only — field names and the exact auth handshake are confirmed during the build against a consenting account, not asserted here. It shows the pattern: phone-plus-OTP login yields a bearer token, then the active-loan call returns the schedule as discrete installments.

POST /api/v1/auth/otp/verify
{ "msisdn": "+9230xxxxxxxx", "otp": "######", "device_id": "<app-instance>" }
-> 200 { "access_token": "ey...", "expires_in": 1800 }

GET /api/v1/loan/active
Authorization: Bearer ey...
-> 200 {
  "loan_id": "GLF-...",
  "principal_pkr": 5000,
  "apr_pct": 10,
  "tenor_days": 91,
  "disbursed_to": { "rail": "easypaisa", "ref": "..." },
  "schedule": [
    { "installment": 1, "due": "2026-07-17", "amount_pkr": 1708.22, "status": "due" },
    { "installment": 2, "due": "2026-08-17", "amount_pkr": 1708.22, "status": "scheduled" }
  ],
  "outstanding_pkr": 5124.66
}

# token lifetime is short; the sync re-auths on 401 rather than
# assuming a long-lived session, and parses KFS labels in EN and UR.

The example mirrors the app's own published loan math — a PKR 5,000 principal at 10% over 91 days repaying 5,124.66 in three installments — so the parsing target is concrete, not invented.

What lands at the end of the build

Everything is tied to the surfaces above, not a generic kit:

• An OpenAPI/Swagger spec for the loan-account endpoints — auth, active loan, schedule, history.
• A protocol and auth-flow report: the OTP-to-token chain, header requirements, token lifetime, and the 401 re-auth path.
• Runnable source for the key calls in Python or Node.js, with KFS parsing that keeps principal, interest, fees and due dates separate and handles English and Urdu labels.
• Automated tests covering a live loan, a settled loan, and a token-expiry refresh.
• Interface documentation a borrower-servicing or collections team can hand to its own engineers.
• Data-retention and residency guidance written against SECP's in-Pakistan storage rule.

A normalized loan record

The endpoints feed one stable shape, so SmartQarza data can sit beside other lenders without per-app special-casing:

{
  "source": "smartqarza",
  "borrower_ref": "<hashed-cnic>",
  "loan": {
    "id": "GLF-...",
    "principal_pkr": 5000,
    "apr_pct": 10,
    "tenor_days": 91,
    "status": "active",
    "outstanding_pkr": 5124.66
  },
  "disbursement": { "rail": "bank|jazzcash|easypaisa", "settled_at": "..." },
  "installments": [ { "n": 1, "due": "2026-07-17", "amount_pkr": 1708.22, "paid": false } ]
}

Things we account for in the build

Concrete to this app, and handled on our side:

• Residency. SECP bars storing borrower data on cloud infrastructure outside Pakistan. We keep captured data and any hosted endpoint on in-jurisdiction storage, so the integration matches the rule the lender already lives under rather than creating a new exposure.
• Bilingual KFS. The Key Fact Statement is presented in English and Urdu. We build the parser to read both label sets and normalize amounts, so the schedule reconstructs correctly regardless of which language view the field came from.
• Minimized surface. Because the same circular forbids contact and gallery access, we scope capture strictly to the loan-account surfaces and never touch device-permission data — the integration stays clean of anything SECP has ruled off-limits.
• Short sessions. The token in front of the loan calls is short-lived, so we design the sync around re-authentication on expiry instead of assuming a standing session that would quietly stop returning data.

Screens we mapped against

Public Play Store screenshots used to orient the data model. Select to enlarge.

What was checked, and when

This mapping rests on the app's own Play Store description, SECP's published digital-lending circulars, the State Bank's open-banking and Raast pages, and contemporary reporting on which nano-loan apps remain licensed. Primary sources opened: SECP Circular 15 of 2022 and Circular 12 of 2024; the SBP Raast page; and Dawn on SECP's licensing. No endpoint, identifier or figure here is asserted beyond what those sources show.

Mapped by the OpenBanking Studio integration desk · 17 June 2026.

Other Pakistani lending and wallet apps in the same data picture

Same market, comparable per-borrower records — listed for ecosystem context, not ranked. A unified integration treats SmartQarza as one source among these.

• JazzCash — mobile wallet with micro-loan features; holds wallet balance, transfers and small-credit records.
• Easypaisa — wallet plus lending; account, payment and short-credit data per user.
• Barwaqt — nano-loan app with application, schedule and repayment-history records.
• Paisayaar — another SECP-cleared nano lender; loan terms and repayment status per borrower.
• Abhi — salary-advance product; disbursement and deduction records tied to employment.
• Daira — short-term cash lending with KFS and installment data.
• Fauri Cash — quick small-loan app holding application and repayment surfaces.
• Zindigi — digital banking and lending; account, card and credit data.
• Digi Khata — ledger and bookkeeping app holding informal credit and payment records.

Questions integrators ask about SmartQarza

Can you separate principal, interest and fees the way SmartQarza's Key Fact Statement does?

Yes. SECP requires every digital lender to show a Key Fact Statement before disbursement, listing the approved amount, annual percentage rate, tenor, and each installment with its date. We capture those fields as discrete values rather than one repayment figure, so principal, interest, fees and due dates come out separable and reconcilable against what the borrower agreed to.

Does reaching this data require touching the borrower's contacts or photo gallery?

No. SECP's 2022 digital-lending circular bars lenders from accessing a borrower's phone book, contact list or gallery even with consent. Our capture is scoped to the loan-account surfaces only — application, KFS, disbursement and repayment — and never device-permission data, which keeps the integration on the right side of that rule.

Disbursement and repayment move through a bank account or a JazzCash or Easypaisa wallet — how do you reconcile that?

Funds land in a linked bank account or a JazzCash/Easypaisa wallet, per the app's own flow, so the in-app record and the money movement live in two places. We model the loan ledger from the SmartQarza side and leave a join key (loan id, amount, timestamp) that lines up against a bank or Raast statement, so a collections or reconciliation system can match the two without guessing.

We run loan-servicing software and want daily repayment status from SmartQarza — is that something you build?

That is a common ask. We deliver a hosted endpoint or runnable source that returns each open loan's outstanding balance, next due date and last payment, refreshed on the schedule you set. A working build of this scope usually lands in one to two weeks once the route is agreed and a consenting account is available to test against.

Most SmartQarza builds run a one-to-two-week cycle. Take it as runnable source — the OpenAPI spec, the auth-flow report and working endpoint code — priced from $300 and paid only after delivery, once it runs for you; or skip hosting entirely and call our endpoints, paying per call with nothing upfront. Give us the app name and what you want from its data on our contact page and we will scope the route, arrange test access with you, and start.