Reaching ShathiLoan's loan ledger under borrower consent

A ShathiLoan borrower registers with a mobile number, clears an 18-plus ID check, and then sees loan offers that carry a 91-to-240-day term and an 18–26% APR — all of it, per the app's own Play listing, held behind an OTP login on Maximerge's servers. That account is the asset worth integrating. The borrower sees a tidy summary screen; a partner system wanting to pre-qualify, reconcile, or report on that loan sees nothing unless it can reach the same records the app reads. This page sets out what those records are, the authorized way to pull them in Bangladesh right now, and what the studio hands back.

What ShathiLoan keeps behind a borrower's login

Each row below maps to a surface the app actually shows. Field names are confirmed during the build rather than copied from any published document.

Getting in: the routes that apply here

Three routes are realistic for this app. None of them asks the reader to clear a wall first — access is arranged with you while the project runs.

1. Authorized interface integration under borrower consent

We observe and document the app's own mobile traffic — the OTP-to-bearer-token exchange, then the calls that load offers, loan detail and the repayment schedule — and rebuild those calls as a clean, typed client. Reachable: everything the borrower can see in-app. Effort is moderate; durability depends on how often the app's front end shifts, which we plan for. We set up access through a consenting account you authorize.

2. User-consented session access

Where you only need one borrower's records at a time — say, a referral partner checking a customer's live loan — the borrower consents and we drive their authenticated session for that scope. Narrow, auditable, and a good fit for per-customer lookups rather than bulk sync.

3. The forthcoming open-banking / AIS route

Bangladesh Bank has signalled open-banking guidelines and a standardized API for roughly 2026. Once that exists, a consented account-information flow becomes the durable long-run path. It is not live, so we treat it as the migration target, not today's mechanism.

For this app, route 1 is the one we would build now: it reaches the full loan record, it runs on consent that is already valid, and we shape its client and schema so that swapping the transport for the national open-banking API later is a contained change, not a fresh project. Route 2 rides alongside it for single-borrower checks.

What lands in your repository

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

• An OpenAPI 3 description of the auth, offer, loan-detail and schedule operations as observed.
• A protocol and auth-flow report: the OTP verification, bearer-token issuance and refresh, and how the session is carried across loan calls.
• Runnable source — Python and Node.js — for OTP verify, loan listing and the repayment-schedule pull, with retry and token-refresh handling.
• An automated test suite, including a golden case built from the app's published worked example so the interest math is verified to the taka.
• Interface documentation a new engineer can follow, plus normalized-schema definitions.
• Compliance and retention notes: consent records, data-residency handling, and the opaque-reference scheme for identity fields.

A repayment-schedule pull, sketched

Illustrative only. Endpoint paths and field names are confirmed during the build, not lifted from any published spec.

# 1) Exchange the OTP for a short-lived bearer token
POST /api/v1/auth/otp/verify
   { "msisdn": "+8801XXXXXXXXX", "otp": "######" }
-> 200 { "access_token": "...", "expires_in": 3600 }

# 2) Read one loan's repayment schedule
GET /api/v1/loans/{loan_id}/schedule
   Authorization: Bearer <access_token>
-> 200 {
     "loan_id": "...",
     "principal": 20000,          # BDT, from the app's worked example
     "apr_pct": 25.0,             # listing states an 18-26 band
     "tenor_days": 150,
     "daily_interest": 13.70,     # principal * apr_pct/100 / 365
     "total_repayable": 22055,
     "status": "active"
   }

# On 401, refresh the token once and retry; back off on 429.
# Golden test asserts total_repayable == 22055 for the case above.
      

One loan, normalized

We flatten the per-app shapes into a stable record so your systems do not have to track the app's screen layout:

{
  "borrower_ref": "sha_9f3c...",   // opaque; no raw NID persisted
  "loan": {
    "currency": "BDT",
    "principal": 20000,
    "apr_pct": 25.0,
    "tenor_days": 150,
    "total_repayable": 22055,
    "schedule": [ { "day": 1, "interest": 13.70 }, ... ]
  },
  "consent": { "scope": "loan:read", "expires_at": "2026-09-18T00:00:00Z" }
}
      

Consent and the Bangladeshi rulebook

This is a regulated lending product, so the integration carries the lender's disclosure and consent posture, not just a token. Bangladesh Bank's e-loan directives require that the annual interest rate, tenure, repayment method and any charges be communicated before a borrower consents, and bar new charges without prior consent. We mirror that: every pull is scoped to what the borrower agreed to, with consent expiry and revocation honoured, and consent records logged.

On personal data, Bangladesh's draft Personal Data Protection Act 2023 received in-principle cabinet approval in late 2023 but is not yet enacted, so there is no in-force national data-protection statute to point to. We operate to its direction regardless — data minimization, an opaque borrower reference instead of raw identifiers, and data-residency handling consistent with the central bank's expectation that loan data stays on infrastructure inside Bangladesh. NDAs are in place where the engagement needs them.

Things this build has to get right

Four specifics from this app that we account for, rather than leave to chance:

• The app's stated envelope — ৳10,000 to ৳150,000 over 91 to 240 days, per its listing — is wider than the Tk 50,000, 12-month band in Bangladesh Bank's e-loan directive. We model the loan-product schema to carry the app's actual terms and a separate flag for which regulatory envelope a given loan falls under, so neither figure is silently hard-coded.
• Interest is simple daily accrual: principal × APR ÷ 365 × days, as the worked example spells out. We replicate that arithmetic and pin it with a golden test (৳20,000, 150 days, 25% → about ৳22,055) so our output reconciles to the app's figures exactly.
• Auth is mobile-OTP with a short-lived bearer token. We design the sync cadence around the token's lifetime and refresh it mid-run, so a longer pull does not stall on an expired session, and we re-validate the flow when the app's front end changes.
• KYC pulls in NID-class identifiers. We key everything to an opaque borrower reference and avoid persisting raw national-ID values, which keeps the data set minimal and easier to handle under the draft privacy regime.

Screens we mapped

The listing's screenshots, as reviewed during this write-up:

What was checked

Reviewed in June 2026: ShathiLoan's Play listing for its loan terms, account flow and contact details; Bangladesh Bank coverage on e-loan directives and the planned open-banking framework; and reporting on the draft Personal Data Protection Act 2023. Primary sources opened:

• The Daily Star — banks cleared to launch e-loan up to Tk 50,000
• The Business Standard — Bangladesh plans an open-banking system
• The Daily Star — revisiting the draft Personal Data Protection Act 2023
• The Business Standard — Dana Fintech and digital credit scoring

Mapped by the OpenBanking Studio integration desk, June 2026.

Nearby apps in Bangladesh's lending and wallet space

Same-category apps an integrator often wants to normalize alongside ShathiLoan. Listed for context, not ranked.

• bKash — the dominant mobile wallet; its in-app nano-loans (with City Bank) hold per-user loan and repayment ledgers.
• Nagad — a large MFS provider with wallet balances, transfers and emerging credit lines.
• Rocket — Dutch-Bangla Bank's mobile money service, holding account and transaction history.
• Upay — a mobile financial service with wallet and payment records.
• Dana Fintech — an embedded-lending and credit-scoring platform that produces alternative-data loan decisions for partner lenders.
• eRin — a personal-loan app for salaried borrowers with application and repayment data.
• Shadhin — a fintech lender whose borrowers repay via cards or wallets like bKash and Rocket.
• BBL Shubidha — BRAC Bank's app for end-to-end digital retail loans, holding application and assessment records.
• Phandora Credit — a personal-loan app offering small-ticket credit with repayment scheduling.
• KK Loans — an instant mobile-loan service with per-user loan records.

Questions integrators ask about ShathiLoan

Does ShathiLoan's data go through Bangladesh's open-banking system yet?

Not yet. Bangladesh's open-banking framework is still being drafted; Bangladesh Bank has said it plans open-banking guidelines and a standardized API around 2026. The working route today is authorized interface integration under the borrower's consent, built so it can move onto that scheme once it lands.

Can you reproduce ShathiLoan's interest and repayment maths?

Yes. The app publishes a worked example, a 20,000 BDT loan over 150 days at 25% APR repaying about 22,055 BDT, and we encode that as a golden test so our schedule output reconciles to the taka.

What identity data does the integration touch, and how is it handled?

Registration uses a mobile number and an NID-class ID for the 18-plus check. We key records to an opaque borrower reference and avoid persisting raw national-ID values, in line with data minimization.

How does access to a ShathiLoan account get arranged?

Through a consenting borrower account or a session you authorize. We set that up with you during onboarding alongside any NDA, so the build runs against the real loan and repayment screens.

Working with us

Source-code delivery starts at $300, billed only after the integration is in your hands and working to your satisfaction; if you would rather not run anything yourself, the same loan and repayment endpoints are available as a hosted, pay-per-call API with nothing upfront. You give us the app name and what you need from its data — access and any compliance paperwork we arrange with you. Tell us what you are after on our contact page and we will scope a one-to-two-week build.