Wiring an API onto BD Sahaj Loan, Bangladesh's loan-matching app

One phone number gets a borrower a profile, a credit score, and a shortlist of loan offers drawn from five named partner lenders — and all of it sits on BD Sahaj Loan's servers, behind a single account. The app calls itself a loan marketplace rather than a lender, per its Play Store description: it collects who you are and what you earn, scores you, and routes you to institutions like FinCash, Asha Loan, PopKash, Brac Agami and Druto Cash. That makes the interesting data the matching layer — one borrower record fanned out into several lenders' offers. That layer is what an integrator usually wants, and it is reachable.

Borrower data the marketplace holds

These are the surfaces the app exposes to a logged-in borrower, named the way the app and its listing name them. The granularity column is what a single account actually yields.

The product terms quoted on the listing frame the offer rows: APR of roughly 15% to 36% and a minimum repayment of 61 days, as the app describes it, with the actual amount set by the partner's credit decision. Those are the fields the offer endpoint hands back, so they are the fields the normalized schema has to hold.

Reaching it, and which path holds up

Three routes genuinely apply to this app. They differ in what they reach and how long they keep working.

1. User-consented account access

A consenting borrower logs in; we read their profile, credit result, offers and application status as the app serves them. Reach is everything that account sees. Effort is low to moderate. Durability is high, because it rides the borrower's own credentials and consent rather than any undocumented trick. We set up a consenting test account with you at the start, so the build runs against real responses.

2. Authorized protocol analysis

We instrument the app and map the phone/OTP auth, the profile and offer endpoints, headers and token refresh, and the Adjust calls we then ignore. Reach is the full request and response surface. Effort is moderate. Durability is medium — a redrawn screen or a renamed field needs a re-check, which we account for in maintenance. This is the route that turns route 1 into a stable contract instead of screen-scraping.

3. Regulated open-banking consent (forward-looking)

Bangladesh Bank has said it intends to publish open-banking guidelines and a standardised API, with reporting putting the target around 2026 and a working committee expected first. When that lands, the partner-lender side could move to a consented, AIS-style feed. We design the consent layer so it can slot into that scheme later, but nothing about the current build waits on it.

For a marketplace this small and this self-contained, the quickest dependable result is route 1 read through the format route 2 documents: log in as a consenting borrower, pull profile and matched offers, and parse them against a wire format we've mapped so the client code survives the app's next front-end tweak. Route 3 is a design allowance, not a dependency — we keep the consent model ready for the day the national API actually ships.

What lands in your repo

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

• OpenAPI spec covering the real calls: phone/OTP auth, profile read, credit-result read, offers, and application status.
• Protocol & auth-flow report documenting the OTP token chain, header and cookie handling, refresh behaviour, and which Adjust traffic to filter.
• Runnable source in Python and Node.js for login, profile pull, offer aggregation across partners, and status polling.
• Normalized offer schema that flattens each partner's offer into one shape — amount, APR band, tenure, partner, status.
• Automated tests run against a consenting account, including OTP-expiry and empty-offer cases.
• Interface documentation and data-retention guidance aligned to Bangladesh's data-protection rules, with the consent record kept alongside.

A matched-offer pull, sketched

Illustrative shape only — exact paths and field names are confirmed against a consenting account during the build, not asserted here.

# 1) phone + OTP -> session token
POST /api/v1/auth/otp/verify
{ "phone": "+8801XXXXXXXXX", "otp": "418302" }
-> 200 { "token": "ey...", "expires_in": 900, "borrower_id": "bd_..." }

# 2) read the matched offers for this borrower
GET /api/v1/offers?status=matched
Authorization: Bearer ey...
-> 200 {
     "credit_band": "B",
     "offers": [
       { "partner": "FinCash",  "amount_bdt": 10000,
         "apr": 0.18, "tenure_days": 120, "state": "preapproved" },
       { "partner": "PopKash",  "amount_bdt": 8000,
         "apr": 0.27, "tenure_days": 90,  "state": "matched" }
     ]
   }

# normalized once, regardless of which partner returned it
Offer = { partner, amount_bdt, apr, tenure_days, state }

# token expiry is handled, not assumed
if resp.status == 401: token = refresh_via_otp(); retry()
      

Where teams point this

• A lending desk that wants the matched offers and APR bands in its own underwriting system instead of inside an app screen.
• A comparison or aggregator product pulling offer terms across BD Sahaj Loan and its peers into one table.
• A partner lender reconciling which applications it actually received against what the marketplace reported.
• A risk team syncing the credit-band result into a downstream decision engine.

Consent and the Bangladesh rulebook

This is the part to get right, because the data is personal and financial. The borrower's own authorization is the basis of the work — they consent, they can revoke, and the build is scoped to one consenting account at a time. Bangladesh has no live open-banking consent scheme to ride yet; Bangladesh Bank's standardised API is, by its own reporting, still being drafted with a target around 2026. Separately, Bangladesh's Personal Data Protection Ordinance was reported approved in late 2025, and we treat its consent and minimization expectations as the operating standard rather than waiting for every implementing rule. Practically that means: we pull only the fields the integration needs, we log access and keep the consent record, the partner roster and any borrower data stay inside agreed retention windows, and we work under NDA where the client needs one. Nothing here describes getting around the app's login — the borrower opens the door.

What we plan around on this build

Two things about this specific app shape the engineering, and we handle both inside the project.

• One borrower, many offer shapes. The marketplace fans a single profile out to FinCash, Asha Loan, PopKash, Brac Agami and Druto Cash, and there is no reason to expect every partner returns an identical offer object. We normalize those into one schema during the build, so two partners' offers don't force two code paths downstream.
• OTP-bound sessions. Auth is phone-number plus one-time code, so the session can lapse mid-run. We design the token handling around OTP expiry and re-issue, with retry on the 401, so a longer sync doesn't quietly stall halfway.
• Front-end churn. A consumer loan app gets its screens redrawn often. We build the parser so a changed offer card is a config update, not a rewrite, and re-validate the surface as part of maintenance.

Access — a consenting account or a sandbox — is arranged with you during onboarding. It is part of how the project runs, not a hoop to clear before we will look at the app.

What the app's own screens show

Store screenshots from the listing. They show the onboarding, profile and offer surfaces the integration reads.

What was checked, and by whom

This brief reads the app's own Play Store description for its data, partners and product terms, and cross-checks the Bangladesh regulatory picture against reporting on Bangladesh Bank's open-banking plans and the country's digital-lending market. Reviewed 19 June 2026 by the OpenBanking Studio integration desk. Primary sources opened:

• The Business Standard — Bangladesh plans to introduce an open banking system
• The Business Standard — how open banking could be Bangladesh's next frontier
• BSS — BRAC Bank launches Bangladesh's first digital loan app, Shubidha
• The Business Standard — Dana Fintech on digital credit scoring in Bangladesh

The wider Bangladesh lending-app picture

Same lane, named for ecosystem context — not ranked. Each holds data a unified integration could sit across.

• bKash Loan — nano and small loans inside the bKash wallet, in partnership with City Bank; holds disbursement and repayment records per user.
• Nagad — mobile financial service with wallet balances, transfers and emerging credit products.
• BRAC Bank Shubidha — described as Bangladesh's first end-to-end digital loan app; holds application, approval and repayment state.
• BRAC Shafollo — digital lending for underserved borrowers, with its own application and disbursement ledger.
• Dana Fintech — alternative credit scoring built on digital footprints; holds derived scores rather than raw bank balances.
• Phandora Credit — consumer personal-loan app offering small-ticket amounts with in-app application records.
• FinCash — a named BD Sahaj Loan partner; holds its own borrower applications and loan terms.
• PopKash — another named partner; carries per-borrower offer and repayment data.
• Druto Cash — partner lender on the marketplace, with its own application pipeline.

Questions integrators ask

BD Sahaj Loan says it isn't the lender — so whose data can you actually reach through it?

The marketplace layer. It holds the borrower's own profile, the credit assessment it runs, and the offers it matches from partners like FinCash and PopKash. That borrower-facing data is what the integration reads; the partner banks' core systems sit behind their own walls and aren't the target.

Bangladesh has no live open-banking scheme yet — what does the build actually run on?

A consenting account plus protocol analysis of the app's own traffic. Bangladesh Bank's standardised open-banking APIs are still being drafted, reported as targeted for 2026, so the dependable basis today is the borrower's own authorization, not a public scheme.

The package id is con.bdsahaj.loan and the developer is a foreign LLC — does that complicate the work?

No. Per its Play Store listing the publisher is Jamsons Holdings LLC and the id is con.bdsahaj.loan; where the company is registered doesn't change the build, since we map the app's endpoints, OTP session and Adjust analytics directly.

Can the matched offers be normalized across all the partner lenders?

Yes. Each partner returns its own offer shape, so we fold them into one schema — amount, APR band, tenure, partner, status — and your code reads a single contract instead of five.

Getting started

A working build of the BD Sahaj Loan surface — login, profile, and the normalized offer list — usually lands within one to two weeks of a consenting account being in place. You can take it either way: we deliver the runnable source and documentation for a fixed fee from $300, which you pay after delivery once you're satisfied with what arrived; or you skip the source entirely and call our hosted endpoints, paying only per call with nothing upfront. Either way you hand us two things — the app name and what you want out of its data — and the access and compliance pieces are arranged with you as part of the work. Start the conversation at /contact.html and tell us which fields matter to you.