Reaching DhakaFin's loan-lifecycle records under borrower consent

Loans of roughly BDT 1,500 to 300,000 move through DhakaFin start to finish on the phone — apply, get scored, accept a plan, and receive funds in a bKash or Nagad wallet, with approval quoted at around five minutes for eligible users. Everything an integrator would want sits on the server behind that flow: who the borrower is, what they were offered, what they took, and what they still owe. The app does not hand that out in a structured form. The work here is turning those authenticated screens into records your own system can read, under the borrower's authorization.

What sits behind the borrower's login

The surfaces below are the ones the app's own description and screens expose. Each maps to a place in the loan lifecycle, which is what makes them worth normalizing.

How we actually reach it

Three routes apply to an app shaped like this, and they are not equal in effort or durability.

Authorized protocol analysis of the app's traffic

We observe the client-to-server calls the app makes — login, OTP exchange, plan list, loan detail, repayment schedule — under your authorization, and rebuild them as clean endpoints. This is the route that reaches the full lifecycle, including the disbursement status that never shows up in any export. Effort is moderate; the durability caveat is that DhakaFin can change its front end, which we plan for in maintenance.

Borrower-consented session access

A borrower who authorizes the work completes the app's OTP login; the issued session token then drives the same record pulls on their behalf. Lower effort, and the cleanest consent story for a single-borrower or onboarding use case. It is bounded to whatever that borrower can see.

Regulated open-banking consent (forward-looking)

Bangladesh Bank has signalled Open Banking Guidelines and standardised API protocols expected around mid-2026, with a working committee forming first. When that lands it becomes the most durable rail for consented financial data. Today it is not yet a live scheme, so we treat it as the path to migrate onto, not the one to wait for.

For most buyers the practical recommendation is the protocol-analysis route as the thing we build first, because it is the only one that returns the repayment schedule and the wallet payout state together; the consented-session route is what we add when the use case is per-borrower and you want the borrower in the loop. We design so the work can later sit on the regulated rail without a rebuild.

A call against the loan view

Illustrative shape only — exact field names and the auth handshake are confirmed during the build against live traffic, not guessed here.

POST /api/v1/auth/otp/verify
{ "mobile": "+8801XXXXXXXXX", "otp": "######", "device_id": "<app-instance>" }
-> 200 { "session_token": "ey...", "expires_in": 1800 }

GET /api/v1/loan/active
Authorization: Bearer <session_token>
-> 200 {
     "loan_id": "...",
     "principal_bdt": 50000,
     "apr_pct": 21.9,          # per listing's stated max APR
     "term_days": 180,
     "disbursement": { "rail": "bkash", "status": "paid", "amount_bdt": 50000 },
     "schedule": [
       { "due": "2026-07-27", "amount_bdt": 9233, "interest_bdt": 900 }
       /* daily accrual ~0.06%, normalized per instalment */
     ]
   }

# 401 -> token expired: re-run OTP verify, then retry with backoff

What lands in your hands

Each deliverable is tied to a DhakaFin surface above, not a generic checklist.

• An OpenAPI/Swagger spec covering the login, plan, active-loan, schedule and disbursement endpoints.
• A protocol and auth-flow report: the OTP-to-token chain, session lifetime, and refresh handling.
• Runnable source for the key pulls in Python or Node.js, including the bKash/Nagad payout normalization.
• Automated tests that assert the repayment schedule reconciles against principal and the stated accrual.
• Interface documentation, plus data-retention and consent-logging guidance for the KYC fields.

Consent and the Bangladesh rulebook

The dependable basis for any pull is the borrower's own authorization. On top of that, Bangladesh promulgated its Personal Data Protection Ordinance in November 2025, which classes financial data as sensitive and requires explicit consent for collection and cross-border movement; some provisions phase in over roughly 18 months from gazette. Bangladesh Bank's e-loan guidance also frames how consumer lending must run digitally — clear disclosure of rate, tenure and charges before consent, with OTP and multi-factor checks at login. We work consented and logged: consent records kept, access trails retained, KYC fields minimized to what the use case needs, and an NDA where the engagement calls for one.

Things we account for in the build

Two specifics on this app shape how the integration is engineered.

• The OTP-gated session expires, so we design the sync around token lifetime — detecting the 401, re-running the verify step, and resuming without dropping a record rather than letting the session silently lapse.
• Disbursement can land on bKash or Nagad, two different wallet rails with their own status semantics; we normalize both into one payout record so funding confirmation does not depend on which wallet a borrower used.
• Interest accrues on a daily basis against a 91–180 day term, so we model the accrual in the integration and reconcile each pulled instalment back to principal, which catches schedule drift early.

Access and authorization are arranged with you during onboarding; the build runs against a consenting borrower account or traffic you authorize. Front-end changes are handled by a re-validation step we keep in maintenance.

Pricing

Runnable source for the DhakaFin endpoints starts at $300, and you pay only after it is delivered and you are satisfied it works. If you would rather not host anything, the alternative is our pay-per-call hosted API — you call our endpoints, pay per call, and there is no upfront fee. Typical delivery is one to two weeks. Tell us the app and what you need from its data and we will say which model fits — start at /contact.html.

Where teams use this

• A collections or BNPL partner syncing live repayment schedules to drive reminders and settlement maths.
• A treasury function matching bKash and Nagad disbursements against funding records each day.
• A credit-data team capturing the plan a borrower was shown versus the plan they accepted, for audit.
• An onboarding flow that, with borrower consent, reads their active-loan state to avoid over-lending.

Interface evidence

The app's own screens, as listed on its store page — the surfaces the integration reads from.

How this was checked

Reviewed against the app's Play Store listing and operator details, and against Bangladesh's current lending and data rules, in June 2026. Primary references: the app on Google Play; Bangladesh Bank's e-loan rollout via The Daily Star; the country's open-banking timeline via The Business Standard; and the Personal Data Protection Ordinance 2025 summarized by The Daily Star.

OpenBanking Studio integration desk · mapping reviewed 2026-06-27.

Similar apps in the same data space

Other Bangladeshi lending and wallet apps hold comparable records, which is why a single normalized integration tends to pay off across more than one of them. Named neutrally, for context:

• bKash Loan (with City Bank) — small instant loans inside the bKash wallet, with repayment ledgers.
• Nagad — mobile financial service with balances, transfers and disbursement records.
• eRin (Dhaka Bank) — end-to-end digital nano-loan with KYC and instalment data.
• Drutoloan — collateral-free loans aimed at MSMEs, holding business-borrower records.
• Super Cash — small consumer loans operating across several markets including Bangladesh.
• SoLo — consumer borrowing with user-set terms and repayment tracking.
• Shadhin Fintech — online loan applications and borrower profiles.
• Dhaka Bank personal loan — bank-side application and account records.
• FinCoach — personal-finance and lending-adjacent borrower data.

Questions integrators ask

Which DhakaFin records can be reconciled against the in-app repayment schedule?

The repayment schedule, the principal-plus-interest breakdown, and the per-instalment ledger. DhakaFin describes a maximum APR of about 21.9% and a daily interest rate near 0.06% over a 91 to 180 day term, so the schedule is recomputable; we mirror that accrual logic in the integration so each pulled instalment ties back to the disbursed principal.

How do you handle the split between bKash and Nagad disbursements?

Payouts can land on either wallet rail, so the two are modelled as separate disbursement channels with a shared normalized record. We map the wallet identifier, amount, timestamp and status from each rail into one schema, which is what most reconciliation and collections systems actually want to read.

What governs borrower consent for this data in Bangladesh?

Bangladesh promulgated its Personal Data Protection Ordinance in November 2025, which treats financial data as sensitive and requires explicit consent. The dependable basis for any pull is the borrower's own authorization; we keep consent records, log access, and minimize the KYC fields carried so nothing sensitive is moved without a reason.

Does the borrower have to be involved for a consented pull?

For a consented-account route, yes — the integration runs against a borrower who has authorized it, typically by completing the app's OTP login so a session token is issued. The app name and what you need from its data are enough to start; access and authorization are arranged with you during onboarding.