How a ShubidhaLoan loan record gets from the app into your system

Every approved ShubidhaLoan borrower ends up with a server-side loan record: a principal somewhere between BDT 2,000 and 600,000, a term of 91 to 180 days, and an APR the app caps at 18 percent, all per the app's Play Store listing. None of that sits on the phone. It lives behind api.shbidhaloan.com — the host named in the app's own privacy policy — and the handset is just a window onto it. That single fact is what makes an integration here worth doing, and it shapes how we would go after the records.

ShubidhaLoan is an independent lender aimed at Bangladeshi business-account holders, and worth one disambiguation up front: it is not BRAC Bank's similarly named BBL Shubidha. Different operator, different package, different backend. This brief is about the app at com.shbidha.loan.swift.shbidhaloan and the loan data it keeps on its own server.

Bottom line: the data an integrator wants — loan balances, repayment schedules, application status — is real and structured, and it travels over the app's authenticated traffic. The route that actually works is a consented borrower session paired with a mapped capture of the app's backend calls.

What records sit behind a ShubidhaLoan account

The surfaces below come from the app's published behaviour and its privacy policy. They are grouped by where a borrower meets them in the app and what an integrator would do with each.

Authorized paths to the records

Two routes carry real weight on this app, with a third worth naming as a thin fallback. None of them depends on a regulated data-sharing scheme, because Bangladesh has not stood one up yet.

Authorized protocol analysis of the app traffic

ShubidhaLoan talks to api.shbidhaloan.com over HTTPS, so we run a TLS capture against a consenting test handset or account, map the token exchange and the JSON loan endpoints, and document the request and response shapes. Reachable: the same loan, schedule, status and disbursement payloads the app itself reads. Effort is moderate — most of it is in mapping the auth chain and pinning the endpoint paths. Durability is tied to app versions; a release can move things, which is a maintenance item rather than a blocker. We set up the capture rig with you during onboarding, against an account you control.

User-consented account session

With a borrower's own login, the integration reads exactly what that logged-in user can see and nothing more. This is the cleaner basis legally and operationally: consent is explicit, scope is the borrower's own records, and there are no stored credentials when it is built around the live session. It pairs naturally with the capture above — the session supplies the token, the map supplies the endpoints.

Data-subject access as a fallback

Under Bangladesh's draft data-protection framework a borrower can in principle request their own data and deletion, and the app's privacy policy already describes a deregistration path. That gives a paper trail but not a usable stream, so we treat it as a backstop for one-off records, not something to build the integration on.

For ShubidhaLoan specifically, the combination we would actually build is the consented session driving a mapped capture of the backend. The app is mobile-only with a single JSON host and a heavy permission model, so a borrower's own login plus a tight endpoint map gives the full loan record while keeping the device and SMS surfaces out of reach — which is both the safest and the most maintainable shape here.

What a loan-record request looks like

Illustrative only — the shape below reflects a consented capture build and a normalized field set; live paths and the exact token scheme are mapped per app version. Mobile-number plus OTP authentication is the expected pattern given the app's identity fields and Bangladesh Bank's e-loan rule that digital loans use OTP or two-factor sign-in.

POST https://api.shbidhaloan.com/v1/auth/token
  { "msisdn": "+8801XXXXXXXXX", "otp": "######" }
  -> 200 { "access_token": "ey...", "expires_in": 3600 }

GET https://api.shbidhaloan.com/v1/loans/active
  Authorization: Bearer {access_token}
  -> 200 {
       "loan_id": "BD-...-0007",
       "principal_bdt": 60000,
       "apr_pct": 18.0,
       "term_days": 180,
       "disbursed_on": "2026-04-12",
       "outstanding_bdt": 41250,
       "status": "active",
       "schedule": [
         { "due": "2026-05-12", "amount_bdt": 10875, "status": "paid" },
         { "due": "2026-06-12", "amount_bdt": 10875, "status": "due" }
       ]
     }

# On expiry: re-issue via the OTP flow rather than caching credentials.
# 401 -> token expired/invalid; 423 -> account locked after failed OTP.

What lands at the end of the build

Everything is tied to the surfaces above, not a generic template:

• An OpenAPI / Swagger spec covering the token exchange, active-loan read, repayment schedule and application-status endpoints as mapped on the target build.
• A protocol and auth-flow report: the MSISDN-plus-OTP to bearer-token chain, refresh behaviour, and any header or signature scheme the app applies.
• Runnable client source in Python and Node.js for sign-in, the active-loan pull, schedule retrieval and status polling, with retry and token-refresh handling.
• A normalizer that flattens the loan and installment payloads into one clean schema, with BDT amounts and Bengali-script field labels resolved.
• Automated tests that run against a consenting test account, plus interface documentation and data-retention guidance matched to the app's own policy.

The normalized shape you would code against

We collapse the per-version payloads into a stable model so your code does not chase field renames between app releases.

Loan {
  loan_id            string
  principal          { amount: 60000, currency: "BDT" }
  apr_pct            18.0
  term_days          180
  disbursed_on       date
  outstanding        { amount: 41250, currency: "BDT" }
  status             active | closed | overdue
}
Installment {
  loan_id            string
  due_date           date
  amount             { amount: 10875, currency: "BDT" }
  state              paid | due | late
}

Consent and the Bangladesh rulebook

There is no live account-information scheme in Bangladesh to consent into; open banking here is still at the policy-drafting stage inside Bangladesh Bank. So the dependable basis for this work is the borrower's own authorization and your authorization to act, recorded and logged, not a regulated rail. That is a feature, not a gap: consent scope is the individual's own loan records, it is revocable, and we hold consent records to show it.

Digital lending in Bangladesh does carry concrete rules we build around. Bangladesh Bank's e-loan directives make a Credit Information Bureau check part of approval, require OTP or two-factor sign-in, and require charges to be disclosed in advance — the last of which matches the app's own promise that interest and fees are shown before a loan is confirmed. On the privacy side, the Data Protection Act 2023 is still a draft (cabinet gave in-principle approval in late 2023 and it remains pending enactment, per data-protection coverage of the bill), so we operate to its direction: data minimized to what the integration needs, NDAs where the client requires them, and retention mirrored to the app's stated windows — SMS data deleted within about 24 hours and account data within about 12 hours of deletion, as the privacy policy describes.

Engineering calls particular to this app

Two things on ShubidhaLoan need a deliberate decision, and we handle both on our side.

• We keep the heavy permission surfaces out. The app collects contacts, SMS content filtered for financial keywords, device identifiers and approximate location for its risk model. A loan ledger does not need any of that, so we scope the integration to the account endpoints only and never pull the contact book or message store. That keeps the build inside data-minimization and away from the app's most sensitive captures.
• We plan for app-update drift. Because the records live behind a single mobile-only backend, a new release can shift endpoint paths or adjust the token flow. Our maintenance plan re-captures against a consenting test account after each app update and diffs the endpoint map, so a changed path is caught and patched before anything in production breaks.
• We normalize currency and script at the edge. Amounts come through in BDT and some fields surface in Bengali; the delivered client resolves both into the schema above so downstream code sees consistent labels and a single currency representation.

Screens we worked from

Store screenshots used while mapping the app's flows. Tap to enlarge.

How this was put together

We read the app's Google Play listing and its published privacy policy at api.shbidhaloan.com, then cross-checked the regulatory picture against Bangladesh open-banking and data-protection coverage. The loan terms and identity fields are the app's own; the backend host is the one its privacy policy names; the regime status reflects current reporting, not a settled scheme. Specific sources opened during the review:

• ShubidhaLoan on Google Play — loan range, term, APR, eligibility.
• ShubidhaLoan privacy policy — backend host, data collected, retention windows.
• The Business Standard: open banking in Bangladesh — scheme status.
• DataGuidance: Bangladesh Data Protection Act 2023 — draft status of the privacy law.

Reviewed 2026-06-18 by the OpenBanking Studio integration desk.

Where ShubidhaLoan sits among Bangladesh lenders

Names a buyer integrating ShubidhaLoan tends to ask about next, each holding similar account-level data that a single normalized integration can sit across. Listed for context, not ranked.

• BBL Shubidha — BRAC Bank's end-to-end digital retail loan app; per-customer applications and repayment schedules behind a bank backend.
• bKash Loan — City Bank nano loans inside the bKash wallet, with loan and EMI records tied to the wallet balance.
• Nagad — mobile financial-services wallet carrying per-user transaction and lending records.
• Sonali Digital Nano Loan — paperless short-term loans up to BDT 50,000 through the Sonali e-Wallet, with in-wallet repayment data.
• Midland MDB Digital Nano Loan — bank-app nano loans with disbursement and repayment records in midland online.
• eRin — salary-based personal loans from BDT 10,000 to 50,000 with short repayment schedules.
• Super Cash — small-ticket online lender holding applicant and repayment records.
• KK Loans — online micro-loan platform with per-user application and repayment data.
• Dhaka Credit — cooperative credit-union loan app with member loan and event-notification records.

Questions integrators ask about ShubidhaLoan

Which ShubidhaLoan records can a consented integration actually read?

The loan ledger (principal, APR, term, outstanding balance), the installment schedule, application status, disbursement events, and the identity fields the borrower already sees in the app, pulled from the app backend through the borrower's own session. The device, SMS and contact surfaces the app also collects are left out by default.

Does Bangladesh have an open-banking scheme we would plug into?

Not a live one. Open banking in Bangladesh is still at the policy-drafting stage at Bangladesh Bank, so the integration rides the borrower's consent and your authorization rather than a regulated account-information rail. Digital lending itself follows Bangladesh Bank's e-loan directives, including a mandatory CIB check, OTP or two-factor authentication, and advance disclosure of charges.

How do you handle the heavy permission collection (SMS, contacts, device IDs)?

We do not touch it. Reading a loan ledger does not depend on those signals, so we scope the integration to the account endpoints only and mirror the app's own retention, which its privacy policy states as SMS deleted within about 24 hours and account data within about 12 hours after deletion.

What happens when ShubidhaLoan ships an app update?

Because it is app-only with a single backend host, an update can move endpoints or change the token flow. We re-capture against a consenting test account and diff the endpoint map, usually inside the one to two week maintenance window, before production sees a break.

Working with us

Pricing is simple on this one. You can take the work as source you run yourself — a documented client for ShubidhaLoan's loan and repayment endpoints, the OpenAPI spec and the tests — from $300, billed only after delivery once you are satisfied. Or skip hosting entirely and call our endpoints, paying per call with nothing up front. Either path runs on a one to two week cycle, and all we need to begin is the app name and what you want out of its data; access and the compliance paperwork are arranged with you as part of the engagement. Tell us which records matter at /contact.html and we will scope it.