Reaching the loan data behind a PopKash account

Brandopedia Trade Corporation runs PopKash as a loan marketplace, so the records worth integrating aren't in one tidy ledger. A borrower's trail spans the partner lenders they apply to, plus the application, offer and repayment data PopKash keeps in the middle. That shape decides the route.

For a third party that wants a single view — a personal-finance app, a lender reconciling repayments, a credit shop scoring a consenting applicant — the dependable way in is consent-based interface integration against the app's own traffic. The country's regulated open-banking rail is still being written. It is not live yet. So we plan for that rail and build on the consent route now.

The bottom line: PopKash holds a compact but genuinely useful slice of a borrower's credit life, and most of it is structured the moment it appears on screen. We would read the app's authenticated traffic with the user's consent, normalize the loan and repayment fields into one schema, and hand back runnable source plus a documented feed. The marketplace fan-out is the only real complexity, and it is one we account for in the design.

What a PopKash account actually holds

Each row below is a surface a consenting borrower can already see in the app. The job is to read it cleanly, not to reach anything the user cannot.

Three authorized ways into that data

Three routes genuinely apply to PopKash. They differ in what they reach, how much effort they take, and how long they keep working without attention.

1. Consent-based interface integration

We read the app's authenticated HTTPS traffic with the borrower's consent and map the login, session and data calls into a clean adapter. This reaches everything in the table above and is the route that works today. Effort is moderate; durability depends on how often PopKash reshapes its front end, which loan apps do often, so we keep a monitor on it. Access is arranged with you during onboarding, against a consenting account.

2. Regulated account-information access (forward-looking)

Bangladesh Bank is drafting Open Banking Guidelines and a unified API standard, expected around mid-2026. Once that exists, a consented AIS-style rail becomes the cleanest long-run path for the bank-side loans PopKash routes to. We design the schema now so this slots in later without a rebuild. It is not a route to depend on in production yet.

3. User-consented credential access for a one-off export

When a team needs a snapshot rather than a live sync — a migration, a one-time reconciliation — a consenting user's session is enough to export their applications and schedule once. Low effort, no ongoing maintenance, but it is a point-in-time pull, not a feed.

For a live product the first route is what we would actually build, because it is the only one that returns PopKash's full borrower picture today and the schema carries straight over to the regulated rail when it arrives. Route three is the right answer only when a single snapshot is all the job needs.

Inside an application-status pull

An illustrative shape of the calls an adapter wraps. Field names are confirmed during the build against a consenting account, not copied from any published contract.

# Auth: a session token minted at login, refreshed before it expires.

POST /api/v1/auth/login
  { "phone": "+8801XXXXXXXXX", "otp": "######" }
  -> 200 { "access_token": "…", "expires_in": 1800 }

GET /api/v1/loans/applications?status=active
  Authorization: Bearer <access_token>
  -> 200 {
       "application_id": "APP-…",
       "lender":        "partner-…",   # marketplace routes to several
       "requested_amount": 5000,        # BDT, taka
       "term_days":     100,
       "dir":           0.0005,         # 0.05% daily, per the listing
       "status":        "disbursed",
       "schedule": [
         { "due_date": "2026-07-01", "principal": 50.0, "interest": 2.5 },
         { "due_date": "2026-07-02", "principal": 50.0, "interest": 2.5 }
         # … one row per day across a 90–180 day term
       ]
     }

# 401 -> token expired: re-run login once, then retry.
# Computed totals are reconciled to the ৳ against the app's own figure.

What ships at the end of the build

Everything below is tied to PopKash's real surfaces, not a generic package:

• An OpenAPI/Swagger specification for the normalized borrower endpoints — applications, offers, active loan, schedule, repayments.
• A protocol and auth-flow report covering the login, token and refresh chain, plus how the marketplace fan-out to partner lenders is handled.
• Runnable source for the key calls in Python and Node.js, with the daily-interest reconciliation built in.
• Automated tests that run against a consenting account so a front-end change is caught early.
• Interface documentation an engineer can follow without us.
• Compliance and retention guidance written against the Personal Data Protection Ordinance 2025 and the in-country data-residency rule.

Where teams plug this in

• A personal-finance app that wants one Bangladesh borrower view, pulling PopKash alongside wallet-linked loans the same user carries.
• A partner lender reconciling its own disbursements against the schedule and repayments a borrower sees in PopKash.
• A credit-decisioning team building features from a consenting applicant's application and offer history.
• An SME bookkeeping tool tracking outstanding loan balances and upcoming due dates as ledger entries.

Consent and the Bangladesh rulebook

The dependable basis for every route here is the borrower's own explicit consent — which is also what the Personal Data Protection Ordinance 2025 requires. Per The Daily Star's reading, the ordinance was gazetted in late 2025 and frames people as the owners of their data, though its complaint and penalty machinery is not expected to switch on until around 2027. We treat the consent obligation as live regardless, with a recorded consent scope, a defined expiry, and a clean revocation path.

Two further rules shape how we host and operate. Bangladesh Bank's e-Loan guidelines, issued in 2026, require customer and loan data to stay on infrastructure inside Bangladesh — so the integration can run in-country. And the open-banking API standard the central bank is still drafting is where a regulated account-information route will eventually come from; until it lands, we do not present it as settled. Access is logged, data is minimized to the job, and an NDA covers the work where you need one.

What we plan around in PopKash

A few app-specific things we account for, so they do not surface as surprises later:

• Marketplace fan-out. Because applications route to several partner lenders, a borrower's full picture spans more than one backend. We build a per-lender adapter and normalize amounts and terms into one schema, so two loans from two providers reconcile into a single view.
• Daily-interest math in taka. Repayment is daily accrual at 0.05% over a 90–180 day term. We encode the exact day-count and ৳ rounding so the totals we compute match the figure the app shows the borrower, not a close approximation.
• Front-end churn. Consumer loan apps revise their screens and flows frequently. Each release ships with a monitor that flags a changed layout or endpoint, so we patch the adapter before the feed drifts.
• Onboarding and access. The build runs against a consenting account or a sandbox; that access is arranged with you during onboarding, not something you have to hand over before we begin.

What the PopKash screens reveal

The public store screenshots already expose the application flow, the loan terms and the repayment view we map. Tap to enlarge.

Other apps on the Bangladesh lending shelf

Where teams ask us to integrate PopKash, they usually carry a few of these too, which is why we design the schema to hold more than one source:

• bKash — the country's largest mobile wallet; its loan, offered with City Bank, holds small instant-credit balances and repayment status per user.
• Nagad — a major mobile financial service with payment, savings and loan facilities behind each account.
• Aamartaka — a loan and credit-card comparison marketplace, close in shape to PopKash, holding application and offer data across providers.
• Phandora Credit — a personal-loan app with per-user loan amounts, terms and repayment records.
• eRin — salaried-borrower personal loans with application and installment data per account.
• Shadhin Fintech Solutions — a lending service holding loan applications and disbursement records.
• City Bank digital loan — the bank-side credit product surfaced through bKash, with structured loan and repayment data.
• mPokket — a regional instant-loan app holding per-user credit lines and repayment schedules.

Questions integrators ask first

PopKash is a marketplace, not the lender — so whose data does an integration actually reach?

The records PopKash itself holds: a borrower's profile and NID-based onboarding, every loan application and the offers shown against it, plus the active loan's daily-interest schedule and repayment history. Where an application is routed to a partner lender, we model that lender as its own adapter so the full picture reconciles into one borrower view.

Can this run through Bangladesh's open-banking rail instead of the app's own interface?

Not dependably yet. Bangladesh Bank is still drafting its Open Banking Guidelines and a unified API standard, expected around mid-2026, so a regulated account-information rail isn't something to build production on today. The working basis is the borrower's own consent, with the AIS route added later once the standard lands.

How does the daily-interest repayment schedule come across?

Per loan, as a list of installments — due date, principal and the daily interest accrued at the 0.05% rate the listing quotes. We encode the day-count and taka rounding so computed totals match what the app shows the borrower down to the ৳.

Given the data-residency rules, where does the integration get hosted?

Bangladesh Bank's e-Loan guidelines keep customer and loan data inside the country, and the Personal Data Protection Ordinance 2025 requires explicit consent, so we can host the build on infrastructure in Bangladesh, log access, and keep the data set minimized to what the job needs.

Bringing us onto a PopKash job

Source-code delivery starts at $300 and is billed only after the build is in your hands and you are satisfied with it. If you would rather not run anything yourself, the same endpoints are available as a hosted API you pay for per call, with nothing up front. A typical PopKash build takes one to two weeks. Tell us the app and what you want from its data at our contact page and we will scope it back to you.

How this brief was built

Checked in June 2026 against the app's store listing and Bangladesh's current financial-data rules. Primary sources opened for this write-up:

• PopKash on Google Play — operator, loan terms (DIR 0.05%, APR cap, 90–180 day term), feature set.
• The Daily Star — Bangladesh Bank clears digital e-loan up to Tk 50,000, on the 2026 e-Loan guidelines and in-country data residency.
• The Business Standard — Bangladesh plans an open-banking system, on the draft guidelines and unified API timeline.
• The Daily Star — Personal Data Protection Ordinance 2025 takeaways, on consent and the delayed enforcement window.

Mapped by the OpenBanking Studio integration desk, June 2026.