What sits behind a ForiQarz login, and how to read it

Behind a ForiQarz login sits a short but dense record: a CNIC-verified borrower identity, an approved credit limit, an active loan, and a repayment schedule running 91 to 180 days. Foremost Financials (Pvt) Ltd runs the app as an SECP-licensed nano-lender — per Profit by Pakistan Today, the company picked up an Investment Finance Services licence to operate as a non-banking finance company in August 2025. That lifecycle — application, approval, disbursement, repayment — is exactly the state a third party wants to read or keep in sync, and this page maps how we reach it without going around the app's own rules.

The bottom line: for a Pakistani nano-lender there is no live UK-style consent rail to plug into yet, so the dependable path is reconstructing the app's own authenticated calls against an account whose owner has agreed to the read. The sections below name the records, the request shape, and the things we account for on a build like this.

Records a borrower's account holds

The data set is narrow, which is a help — it maps cleanly to a small normalized schema. Each row below reflects a surface the app itself presents to its user.

Getting at the ledger, within the rules

Two routes do the real work here; a third is a backstop, and a fourth is something to design toward rather than depend on.

Authorized interface integration / protocol analysis

We observe the app's own HTTPS traffic under the client's authorization, document the OTP-to-token-to-endpoint chain, and rebuild those calls as a clean client. Reachable: everything the app shows the user. Effort is moderate; durability holds until the front end changes, which is why we keep a check against the live responses. Access to a working account is arranged with the client during onboarding.

User-consented session access

The borrower authorizes the read, and we drive the same authenticated session on their behalf with a short-lived token. This pairs with the route above — the consent record is what keeps the pull defensible under SECP's data conduct rules. Durability tracks the token and OTP lifecycle.

Native export, where present

If the app or its web portal hands out a statement or PDF, we parse it as a slower cross-check on the live pull. Useful for reconciliation, not for anything real-time.

Open-banking consent, later

The State Bank of Pakistan has published an open-banking framework, but it is still maturing and does not yet give a nano-lender a live consumer consent rail. We shape the client so it can adopt that flow once it exists.

For ForiQarz the route we would actually run is the first two together: authorized interface integration driven by a consenting borrower account. It reads precisely what the app displays, and the consent record keeps it clean under Pakistani conduct rules. Native export is worth wiring where it exists as a periodic check; the SBP rail is a design target, not a thing to lean on today.

What a session request looks like

The shape below is illustrative — exact paths and field names are pinned during the build by reading the live traffic, not guessed. It shows the phone-number OTP exchange, a bearer token, and a read of the active loan with its schedule.

POST /api/v2/auth/otp/verify
{ "msisdn": "+9230xxxxxxxx", "otp": "******", "device_id": "<bound-device>" }
→ 200 { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }

GET /api/v2/loan/active            Authorization: Bearer <access_token>
→ 200 {
    "loan_id": "...",
    "principal": 10000, "currency": "PKR",
    "apr": 0.10, "tenure_days": 91,
    "disbursed_to": { "rail": "raast", "channel": "easypaisa" },
    "schedule": [
      { "due": "2026-09-18", "amount": 3416.43, "status": "pending" }
    ],
    "total_repayable": 10249.31
  }

# token nearing expiry → refresh, do not re-OTP unless the device binding fails
POST /api/v2/auth/refresh   { "refresh_token": "..." }

The representative figures (PKR 10,249.31 repayable, PKR 3,416.43 installment) are the app's own worked example for a 10,000 / 91-day / 10% APR loan; real values come from the approval, so the client treats them as variables, never constants.

What you receive

Each deliverable maps to a surface above, not to a generic checklist:

• OpenAPI/Swagger spec covering the auth exchange, active-loan read, schedule pull, and disbursement lookup.
• Protocol and auth-flow report documenting the OTP step, bearer-token refresh chain, and any device binding.
• Runnable source in Python or Node.js for OTP login, active-loan and schedule reads, and disbursement reconciliation — the endpoints you would actually call.
• Automated tests, including a contract check that fails loudly when a response field is renamed.
• Interface documentation plus data-retention and consent guidance aligned to SECP conduct rules and Pakistan's data-protection direction.

Where teams put this

• A multi-lender view that shows a borrower their ForiQarz balance and next due date alongside other facilities.
• A repayment-reminder service syncing the installment schedule and flagging a missed settlement.
• An affordability or credit-risk tool reading outstanding markup and on-time history before extending more credit.
• Internal finance reconciling disbursements where the payout rail differs between Raast, JazzCash and Easypaisa.

SECP, consent, and Pakistani data rules

ForiQarz sits under the SECP's regime for NBFC digital lending — the same regime behind the whitelist of licensed lending apps and its disclosure rules on fees, tenure, installments and collection conduct. Our work runs read-only and consent-anchored: the borrower agrees to the read, the consent is logged with scope and a timestamp, and the token's lifecycle bounds it. Revocation drops the session. We pull only the fields a use case needs, keep nothing beyond the retention the client sets, and work under an NDA where the engagement calls for one. Pakistan's Personal Data Protection Bill 2023 is approved by cabinet but not yet enacted, so we treat its consent, access and erasure expectations as the direction of travel and build to them now rather than waiting.

Build notes specific to ForiQarz

Two things shape this integration more than anything else, and we handle both as part of the build:

• Phone-number auth with short-lived tokens. Login starts at an OTP on the borrower's number, then runs on a bearer token that expires. We design the sync around the refresh window and any device binding so a long-running pull re-authenticates cleanly instead of stalling on an expired token.
• Payout across more than one rail. Funds land in a mobile wallet or a bank account, and Raast settlement makes the channel vary loan to loan. We normalize the disbursed_to field so a wallet payout and a bank payout reconcile against one ledger, and the schedule lines up against the actual settlement.
• Per-loan term spread. APR ranges widely by approval and the installment math follows from it; we map each loan's rate and tenure into the normalized schedule so downstream balances compute correctly rather than off a fixed assumption.

Front-end churn is expected on apps that ship often, so the test suite carries a check against live responses — a renamed field shows up as a failed test, not as quietly missing data.

Screens from the listing

Store screenshots, useful for reading the on-device flow before traffic capture. Click to enlarge.

Neighbouring apps in Pakistan's lending market

The same loan-account shape recurs across Pakistan's licensed nano-lenders, which is why a single normalized schema tends to cover several at once. Named here for context, not ranked:

• Barwaqt (Seedcred Financial) — short-term cash loans with a similar application-to-repayment ledger.
• SmartQarza (Goldlion Financial) — nano-loans with comparable limit and schedule records.
• Paisayaar (JingleCred Digital Financial Services) — personal loans in the PKR 10,000–50,000 band.
• Aitemaad (4Sight Finance) — digital lending with the same KYC-and-credit-limit pattern.
• Hakeem (Walee Financial Services) — small-ticket credit and repayment tracking.
• Fauri Cash (Pakisnova Microfinance) — instant nano-loans with wallet disbursement.
• Abhi — earned-wage and salary-advance balances rather than installment loans.
• Zaroorat Cash — short-term cash advances with a dated repayment plan.

Questions integrators ask

Once a borrower consents, what can a unified system actually read from ForiQarz?

The account state the app shows that user: CNIC-verified identity, the approved credit limit, active loan terms (principal, APR and tenure as the Play listing describes them), the dated repayment schedule, disbursement records, and the on-time history that raises future limits. We expose those as normalized read-only fields.

Is there a regulated open-banking consent rail in Pakistan for this, or is it interface work?

The State Bank's open-banking framework is still maturing, so the working route for an SECP-licensed nano-lender is authorized interface integration against a consenting account rather than a live account-information rail. We build the client so it can move onto an open-banking consent flow if and when that becomes available.

How do you keep the connection alive through ForiQarz's OTP login and short-lived tokens?

We document the phone-number OTP step and the bearer-token refresh chain, then design the sync around that refresh window and any device binding so the session re-authenticates cleanly instead of dropping mid-pull. A contract test flags a field or flow change as a failed check.

ForiQarz pays out to JazzCash, Easypaisa or a bank over Raast — can the integration reconcile across those?

Yes. We normalize the disbursement channel so a payout to a wallet and one to a bank account reconcile against the same ledger, and the repayment schedule lines up against actual settlements regardless of which rail moved the money.

Source for the ForiQarz auth-and-loan client lands in your repo from $300, billed only after delivery once the endpoints pass your checks. If hosting it yourself is not what you want, the same integration runs as a pay-per-call hosted API with no upfront fee. Tell us the app name and what you want from its data — access and compliance are arranged with you — and we will scope the build, usually a one-to-two-week cycle, from the contact page.

What was verified on ForiQarz

Reviewed in June 2026 against the app's own Play Store listing and worked loan example, the SECP whitelist of licensed digital-lending NBFCs, Pakistan Today's report on Foremost Financials' licence, and current Pakistani data-protection commentary. Where a figure could not be independently confirmed it is attributed to the app's listing rather than stated as fact.

• ForiQarz on Google Play
• SECP whitelist of digital lending apps run by licensed NBFCs
• Profit by Pakistan Today — SECP grants Foremost a digital-lending licence
• ICLG — Pakistan data-protection law (Personal Data Protection Bill 2023 status)

OpenBanking Studio · interface mapping, reviewed 2026-06-19.