Getting borrower and repayment records out of Aitemaad

A live Aitemaad loan is not one number. It is a principal, a daily markup line accruing from 0.01 to 0.75 percent per day (the rate range the app publishes), an outstanding balance, a due date, and a repayment thread that settles through Easypaisa or Jazzcash. That bundle is what a third party actually wants when it integrates a nano-lending app — not a marketing summary, the row-level ledger behind one borrower's login. This brief maps where those rows live and the authorized way to read them.

Bottom line: the dependable read here is the app's own authenticated session, captured against a consenting account. The loan list, the installment schedule and the repayment history are all there, keyed to a mobile-number login. The State Bank open-banking framework matters chiefly for the Easypaisa and Jazzcash settlement leg, where it offers a consent-based confirmation that does not break when the app's front end shifts.

The borrower records sitting behind the account

Each surface below is something a borrower sees inside Aitemaad, mapped to what an integrator does with it. The naming follows the app's own description of its flow.

Authorized ways into the loan ledger

Three routes genuinely apply to Aitemaad. Each one runs under the client's authorization, with access arranged during onboarding.

1 · Protocol analysis of the authenticated app traffic

The mobile client signs in with a mobile number and one-time code, holds a bearer token, and calls the endpoints that render the loan list and repayment schedule. We map that exchange against a consenting test account and build typed clients for it. Reachable: the full authenticated surface. Effort: moderate. Durability: needs a re-validation pass when the app ships a new front end — something we wire into maintenance.

2 · SBP open-banking-framework consent on the rails leg

Disbursement and repayment touch bank and wallet rails. The State Bank framework, with the 1LINK Open API Gateway and Raast underneath, gives a standards-based, consent-bound way to confirm those movements. Reachable: settlement and account-confirmation data on the rail side. Durability: high, because it follows a published standard rather than a UI. We handle the TPP onboarding with you.

3 · User-consented credential access

Where the integration serves the borrower directly, they authorize the pull and we read their own statement through their session. Narrower in scope, lighter to stand up, and clean on consent.

For Aitemaad specifically, route 1 is what we would build the core read on — the ledger and the schedule live in that authenticated traffic and a single consenting account reaches them. Route 2 earns its place on the money-movement side, where a standards-based confirmation outlasts app updates. Route 3 fits a borrower-facing product. We say which one carries the integration in the kickoff, against your actual use case.

A login-and-statement pull, sketched

Illustrative only — field names and the token shape are confirmed during the build against a live consenting session, not asserted here as Aitemaad's published contract.

POST /auth/otp/verify
{ "msisdn": "+9230xxxxxxxx", "otp": "######" }
-> 200 { "access_token": "ey...", "expires_in": 1800 }

GET /loans?status=active
Authorization: Bearer ey...
-> 200 {
  "loans": [
    { "loan_id": "AIT-...",
      "product": "cash_loan",
      "principal_pkr": 10000,
      "markup_rate_daily": 0.001,        # 0.1%/day, app's own worked example
      "accrued_markup_pkr": 300,         # 10000 * 0.001 * 30 days
      "outstanding_pkr": 10300,
      "due_date": "2026-07-26",
      "as_of": "2026-06-26T00:00:00+05:00"  # accrual timestamp travels with the row
    }
  ]
}

# error handling we plan for:
# 401 -> token expired mid-sync, refresh via OTP session and resume
# 429 -> back off; the ledger endpoint is rate-shaped per device

The worked figures mirror the example the app itself publishes: PKR 10,000 over 30 days at 0.1 percent per day is PKR 300 of markup, PKR 10,300 to repay. Carrying the as_of stamp is the part that keeps a downstream total honest, because the markup line moves every day.

What lands in your repo

Delivery is source you can run, not a slide deck. For Aitemaad that means:

• An OpenAPI 3 spec covering the auth, loan-list, schedule and repayment-history surfaces.
• A protocol and auth-flow report: the OTP-to-bearer chain, token lifetime, and the refresh behaviour we observed during the build.
• Runnable client source in Python and Node.js for the key endpoints, with the daily-markup accrual handled correctly.
• A normalizer that folds the cash-loan and mobile-installment products into one schema.
• Automated tests against recorded fixtures so the accrual math and reconciliation are checked, not assumed.
• Interface documentation plus data-retention guidance shaped to the SECP requirement that borrower data stay inside Pakistan.

Operating inside SECP and SBP rules

Aitemaad is a SECP-licensed NBFC, per its store listing, so the integration is built to the SECP digital-lending circulars. Those circulars cap total recoveries against the principal, bar lenders from reaching into a borrower's phone book or photo gallery, and — in the tightening the regulator pushed through — require borrower data to be held on infrastructure inside Pakistan. That last point is a design constraint we honour: storage and processing for the integration stay in-jurisdiction. On the money-movement side, the SBP open-banking framework sets the consent model, with explicit, scoped, revocable authorization for any rail-side data. We keep consent records and access logs, minimize the fields pulled to what the use case needs, and sign an NDA where the work touches borrower-level detail. The regulator's recent moves on nano-loan tenure mean the term math is itself a moving target; we read terms from the live ledger rather than hard-coding them.

Engineering realities we plan around

Two things about Aitemaad shape how we build:

• Two products, two clocks. The cash loan accrues daily markup over a short term; the mobile installment runs monthly over up to a year, on a different rate basis. We model them as separate schedules under one borrower object so a balance read never blends the two, and we reconcile each against its own accrual rule.
• The accrual window is live. Because markup ticks daily, a balance is only true as of a timestamp. We design the sync to capture and carry the as-of moment, so a figure pulled in the morning is not silently compared against an evening one downstream.
• The front end will change. Lending apps re-skin their flows often. We isolate the captured contract behind a thin client and wire a re-check into maintenance, so a UI refresh is a small fix rather than a silent data outage.

Access is arranged with you during onboarding — the build runs against a consenting account or a test handset you provide, and the compliance paperwork is handled as part of the engagement, not asked of you up front.

How this brief was put together

Mapped in June 2026 from the app's own Play Store description (products, rates, repayment rails, operator and SECP licence reference) and from primary regulatory and payments sources for Pakistan. The SECP digital-lending position is read from the regulator's 2024 circular set; the rails and consent model from the State Bank of Pakistan's open-banking material and the 1LINK gateway. Sources opened:

• SECP Circular 12 of 2024 — updated requirements for NBFCs in digital lending
• Dawn — SECP tightens rules for nano-lending apps
• State Bank of Pakistan — Raast instant payment system
• Open Banking Tracker — Pakistan framework overview

Mapped by the OpenBanking Studio integration desk, June 2026.

Other Pakistani lending and BNPL apps in the same data space

A unified integration usually spans more than one lender, so the same approach maps cleanly across these peers. Names are listed for ecosystem context, not ranked.

• Paisayaar — short-term nano loans and BNPL; holds a similar per-borrower ledger and repayment schedule.
• Fauri Cash — quick small-amount loans, with application and approval state behind a login.
• SmartQarza — nano-loan app carrying outstanding-balance and due-date records per user.
• Hakeem — small, short-tenure digital loans by a financial-services operator.
• Money Tap — mobile credit line with limit and drawdown data behind the account.
• QistBazaar — BNPL for consumer goods; installment plans and item-level financing records.
• BaadMay — deferred-payment BNPL, with purchase and repayment ledgers.
• JazzCash lending — in-app small-loan feature inside a major wallet, tied to wallet history.
• Easypaisa — wallet with microfinance loans up to PKR 50,000 and rich transaction data.

Screens we mapped

Store screenshots used while tracing the flow. Tap to enlarge.

Questions integrators ask about Aitemaad

What sits behind a borrower's Aitemaad account that an integrator can read?

The authenticated surface carries the loan ledger (principal, daily markup, outstanding balance and due date), the application and approval state, the mobile-installment schedule, repayment transactions settled through Easypaisa or Jazzcash, and the credit-limit tier that rises with on-time payment. Identity is keyed to the mobile number and CNIC captured at registration, as the app describes its sign-up flow.

Which regulator and rules shape an Aitemaad integration?

Aitemaad runs as a SECP-licensed NBFC, per its store listing, so the SECP digital-lending circulars apply: caps on recoveries, restrictions on phone-book and gallery access, and a requirement that borrower data stay within Pakistan. Where bank and wallet rails are touched, the State Bank of Pakistan open-banking framework and the 1LINK gateway set the consent model. We build to all of these.

Does the daily-markup accrual cause reconciliation drift?

It can. Markup accrues per day (the app cites rates from 0.01 to 0.75 percent per day), so a balance read at midnight differs from one read at noon. We capture the accrual basis and the as-of timestamp on every ledger pull so downstream totals match the in-app figure rather than guessing it.

Can you cover both the cash-loan and the mobile-installment products in one integration?

Yes. The two products have different term and limit math, so we model them as distinct schedules under one borrower object and normalize them to a shared schema, which keeps the cash loan up to PKR 50,000 and the longer mobile-installment plan reconciling through the same endpoints.

Working with us

Once you give us the app name and what you need from its data, the rest is ours to run, and a typical Aitemaad build lands in one to two weeks. Source-code delivery starts at $300: runnable clients, the OpenAPI spec, tests and interface docs, billed only after delivery once you are satisfied with what arrives. If you would rather not host anything, call our endpoints instead and pay per call, with nothing up front. To scope the Aitemaad ledger pull against your use case, tell us what you need on the contact page and we will come back with a concrete plan.