Connecting to a Daira borrower's loan ledger

A Daira loan runs from PKR 2,000 to PKR 50,000 over a cap of 90 days, repaid in installments through Easypaisa or JazzCash — and every one of those terms, as the app's Play listing describes it, lives as a structured record behind the borrower's account. That account is the thing worth integrating. The credit limit a borrower is assigned, the daily markup rate, the installment schedule printed in their Key Fact Statement, the moment cash lands in a wallet: each is a field a lender's own systems, a collections workflow, or a credit-data partner would want to read and keep in sync. This page maps that data, the authorized route to reach it, and what we hand over.

The bottom line is short. Daira holds a clean, regulator-shaped loan record for every borrower, and the practical way in is the borrower's own authenticated session, captured and turned into a stable interface. The open-banking rail matters for the bank-and-wallet side, but its account-information standards in Pakistan are not finished yet, so we treat the consented app session as the load-bearing route and let the framework slot in as it firms up.

Borrower data Daira holds and where it lives

These rows reflect surfaces the app actually exposes to a logged-in borrower, named the way Daira and SECP name them.

Routes to a Daira loan ledger

Two routes carry the real work today; a third and fourth fill specific gaps.

Authorized protocol integration of the app session

We map Daira's mobile traffic under the account holder's authorization: the mobile-number-plus-OTP login, the bearer token it returns, and the calls that serve the loan, the KFS and the repayment list. This reaches the complete per-borrower view in one place. Effort is moderate — most of it is mapping the auth handshake and the loan endpoints, then writing fixtures. Durability tracks app releases; when Daira ships an update we re-capture the affected calls. Access is arranged with you during onboarding, against a consenting account or a test profile.

SBP open-banking consent for the wallet and bank leg

State Bank of Pakistan published an open-banking framework in 2022 covering API-based, consent-driven sharing of account and payment data. Account-information services sit in scope and the Raast sandbox lets participants test them, but the technical standards are still being finalized, as SBP's own materials and independent trackers describe. We follow that work and design the wallet-side sync so it can move onto the standardized consent rail without reshaping your schema once it is published.

Borrower-consented credential access

For one-off or low-volume pulls, the borrower drives their own Daira session and we read the same loan-and-repayment data through it. Same surface as the first route, lighter setup, suited to a single reconciliation or a support lookup rather than a standing sync.

Native KFS artifact capture

SECP requires Daira to deliver the Key Fact Statement by screen, video and email or SMS. Where live access is not set up, we parse that artifact for a single-loan snapshot. It is a point-in-time copy, not a live ledger, so it backs up the live routes rather than replacing them.

For most teams the honest recommendation is the first route. The borrower's authenticated session already carries the limit, the KFS and the repayment state together, which is exactly the record a lender-adjacent system needs, and it does not wait on a standard that has not shipped. Fold the open-banking consent rail into the wallet leg once SBP's account-information standard settles; keep the KFS parser around for snapshots and audits.

A look at the loan-status call

Illustrative shapes from a build of this kind — field names are confirmed during the engagement, not published by Daira. The numbers mirror the worked example in the app's own listing (PKR 10,000 over 90 days at 0.01%/day, total payable 10,090, three installments).

# 1) Session: mobile number + OTP, exchanged for a short-lived bearer token.
POST /v1/auth/otp/verify
  { "msisdn": "+92XXXXXXXXXX", "otp": "######" }
  -> { "access_token": "…", "expires_in": 3600 }

# 2) Active loan + Key Fact Statement for the consenting borrower.
GET /v1/loans/active
  Authorization: Bearer <access_token>
  -> {
       "credit_limit_pkr":   50000,
       "principal_pkr":      10000,
       "markup_rate_daily":  0.0001,        # 0.01%/day in this example
       "tenor_days":         90,
       "total_payable_pkr":  10090,
       "installments": [
         { "no": 1, "due": "2026-07-19", "amount_pkr": 3363.33, "status": "due" },
         { "no": 2, "due": "2026-08-18", "amount_pkr": 3363.33, "status": "scheduled" },
         { "no": 3, "due": "2026-09-17", "amount_pkr": 3363.34, "status": "scheduled" }
       ],
       "disbursement": { "channel": "easypaisa", "ts": "2026-06-19T09:12:04Z" }
     }

# Token expiry returns 401 -> one OTP-backed refresh, never a re-login loop.

The repayment list is a separate call keyed to the same loan id, returning each posting with its rail (Easypaisa or JazzCash), amount and cleared state — that is what an arrears or reconciliation job reads.

What lands in your repo

Concrete artifacts, each tied to a Daira surface above:

• An OpenAPI 3.1 specification covering the auth exchange, the active-loan/KFS read, the repayment list and the application-status poll.
• A protocol and auth-flow report: how the OTP-to-token handshake works, token lifetime, the 401 refresh path, and where the app pins or signs requests.
• Runnable source in Python and Node.js for login, fetch active loan with KFS, list repayments, and poll application status — not stubs, code that runs against the captured fixtures.
• A normalizer that flattens the bilingual (English/Urdu) KFS into one language-independent schema with a source-locale tag.
• Automated contract tests built from recorded responses, so a Daira app change that breaks a field fails a test before it reaches your data.
• Interface documentation plus data-retention and consent notes written against SECP's in-country storage rule.

Rules, residency and consent

Daira operates as an NBFC under SECP's digital-lending regime. Circular 12 of 2024 — which SECP describes as consolidating its earlier 2022–2023 digital-lending circulars — sets the Key Fact Statement disclosure (loan amount, APR, tenor, installment amounts and dates, all fees) in both English and Urdu, and requires that borrower data not be stored on cloud infrastructure outside Pakistan. We design to that residency rule directly: capture, fixtures and any retained data stay on infrastructure inside the jurisdiction.

SBP's open-banking framework is the other half of the picture. It defines consent-based, API-driven account and payment sharing, with account-information services in scope, but the account-information technical standards are still being finalized. The reliable legal basis for reaching a borrower's Daira data right now is that borrower's own authorization, recorded and revocable. We run authorized, documented, consent-bound access only — consent scope is written down, expiry and revocation are honored, access is logged, data is minimized to the job, and we work under NDA where a client needs it.

Engineering notes for a Daira build

Things we account for on this specific app:

• In-country residency. Because SECP bars storing borrower data outside Pakistan, we keep the build environment and any captured data on infrastructure within the jurisdiction, and we document the data path so a client's compliance team can trace it.
• Bilingual KFS. The Key Fact Statement ships in English and Urdu; we map both into one schema and tag the locale, so a downstream ledger never has to branch on language.
• Per-borrower rate, not a constant. The listing is explicit that the assigned credit limit and markup rate move with creditworthiness, so we model rate and limit as account-level fields read live, never as a hardcoded value.
• OTP session lifecycle. Daira logs a borrower in by mobile number and OTP; we build the sync around that short-lived token with a single clean refresh on expiry, so a long-running job does not stall on a re-login.
• App-update drift. When Daira releases a new build, the affected calls are re-captured and the contract tests re-run before anything reaches your side, so a renamed field surfaces as a failing test, not bad data.

Where teams plug this in

• A collections or CRM tool that needs live installment due-dates and arrears state per borrower.
• An accounting sync reconciling Easypaisa and JazzCash repayment postings against the loan ledger.
• A credit-data or aggregator partner pulling per-borrower limit and repayment history under recorded consent.
• An internal BI funnel running application → approval → disbursement, for drop-off and approval-rate reporting.

Working with us, and what it costs

A working Daira integration — the runnable source, the OpenAPI spec and the protocol report — starts at $300, and you pay only after we deliver it and you have confirmed it runs. If you would rather not operate the capture-and-refresh logic at all, we host the endpoints and bill per call, with no upfront fee. Either way the build cycle is one to two weeks. Tell us the app and what you want out of its data, and start a project on the contact page — access and the compliance paperwork are arranged with you as part of the work.

Screens from the app

Store screenshots, for reference to the surfaces above. Select to enlarge.

Other Pakistani lenders in the same data shape

Same category, same kind of per-borrower loan record — useful when a client wants one normalized interface across several apps rather than Daira alone.

• Barwaqt — short-term cash-loan app holding loan amounts, tenors and repayment status per borrower.
• SmartQarza — SECP-licensed nano-lender with a comparable loan-and-installment ledger.
• Paisayaar — small-ticket cash loans with disbursement and repayment records mirroring Daira's.
• Qistbazaar — buy-now-pay-later instalment data for consumer goods, an adjacent repayment-schedule shape.
• Abhi — earned-wage-access platform holding advance and payroll-linked repayment records.
• Fauri Cash — fast cash-loan app with limit, markup and due-date fields like Daira's.
• MoneyTap — personal-loan app holding credit-line and repayment-history records.
• PakCredit — digital lender with per-user loan accounts and installment schedules.

Questions integrators ask about Daira

Which Daira records can be normalized into one schema?

The per-borrower set: assigned credit limit and markup rate, the active loan with its Key Fact Statement (principal, tenor in days, installment amounts and due dates, total payable, APR), the disbursement event, repayment transactions made through Easypaisa or JazzCash, and the application-to-approval status. Identity attributes captured at registration sit alongside, consent-bound and minimized.

Does Daira sit under SBP open banking or SECP rules?

Daira is licensed as an NBFC under SECP's digital-lending regime, where Circular 12 of 2024 sets the Key Fact Statement disclosure and requires borrower data to stay on infrastructure inside Pakistan. SBP's open-banking framework covers account and payment data sharing, but its account-information technical standards are still being finalized, so the dependable basis today is the borrower's own authorization.

How do you handle the bilingual Key Fact Statement Daira issues?

SECP requires the KFS in both English and Urdu, delivered as screen, video or email/SMS. We capture both, map the fields to a single language-independent schema, and tag the source locale so downstream systems read one consistent record regardless of which the borrower saw.

Can you host the Daira loan-status endpoint instead of us running it?

Yes. We can run the integration on our side and expose the loan, KFS and repayment lookups as hosted endpoints billed per call, so your team consumes a stable interface without operating the capture and refresh logic yourselves.

What we checked, and when

We read Daira's Google Play listing for its loan terms, repayment rails and the SECP license string it prints; FinVolution Group's launch announcement for the operator and corporate backing; SECP's digital-lending circular for the Key Fact Statement and data-residency rules; and SBP-aligned open-banking material for the status of account-information sharing in Pakistan. Primary sources:

• FinVolution Group — launch of Daira in Pakistan (Oct 2024)
• SECP — Circular 12 of 2024, requirements for NBFCs in digital lending
• Pakistan open-banking status — SBP framework tracker
• Daira — Google Play listing (com.finleap.daira)

Mapped by the OpenBanking Studio integration desk, June 2026.