Reaching the ledger behind a bKash account

By reported market-share figures, close to two in every five mobile-money transactions in Bangladesh run through bKash — and every one of those accounts sits on a server-side ledger. Balance, a running statement of send-money, cash-out, merchant payment, add-money and recharge entries, a real-time limit counter, an inbox of transaction notices, and a separate remittance record that money-transfer inflows land in. That is the material a lender, an accounting tool, a payroll system or a reconciliation service wants to read on a customer's behalf. The work here is getting it out in a structured, repeatable shape under the account holder's authorization.

The short version of the recommendation: for most teams we would build the consented interface integration first, because it reaches the live balance and the complete statement rather than only the slices the in-app export hands back, and it does not wait on a national standard that is still being written. The downloadable remittance statement is worth wiring in as a reconciliation cross-check, and a regulated open-banking path stays on the roadmap for whenever Bangladesh Bank publishes its guidelines.

Getting at the account ledger

Two to three routes genuinely apply to bKash. They differ in what they reach, how durable they are, and what we set up to run them — onboarding and access are arranged with you as part of the project, not asked of you up front.

Consented interface integration / protocol analysis

We map the authenticated traffic of the bKash app for a consenting account and rebuild the request and response shapes as a clean interface. This reaches the live balance, the full statement across transaction types, the Check Limit counters, and the inbox. Durability is good as long as the maintenance pass tracks front-end changes. This is the route we would lead with.

User-consented session access

The account holder logs in with their PIN and the first-login OTP; the integration drives that authorized session to pull statement and balance on their behalf, data-minimized to only the fields a use case needs. Lighter to stand up than a full traffic map, narrower in what it returns, and tied to the consent the user grants.

Native export as a reconciliation feed

bKash exposes an in-app Statement and a downloadable remittance statement — last 30 days, 180 days, the tax year, or a custom range, as the app describes it, delivered within a stated turnaround. It is not real time and it is coarser than the live surfaces, but it is a dependable cross-check to reconcile a live pull against. We treat it as a verification feed, not the surface a live integration runs on.

What sits behind a bKash login

These are the surfaces a bKash account actually carries, named the way the app names them where it does.

What lands in your repo

The deliverable is a working integration for the surfaces above, not a slide deck. Concretely, for bKash:

• An OpenAPI / Swagger specification covering the balance, statement, limit and remittance endpoints as a normalized interface.
• A protocol and auth-flow report: the session bootstrap, the PIN and OTP handling, token issuance and the one-hour refresh window, written against the surfaces we actually map.
• Runnable source for the key calls in Python or Node.js — statement query, balance read, limit check, remittance pull — with retry and pagination wired in.
• Automated tests against captured fixtures so the parser survives label and locale changes.
• A normalized schema that folds the statement and the separate remittance record into one ledger model, with BDT amounts and Bengali-script counterparty names handled consistently.
• Interface documentation plus data-retention and consent-record guidance for running it in production.

A statement pull, sketched

Illustrative shape. Field names are confirmed against captured traffic for a consenting account during the build; the auth handshake mirrors the grant pattern bKash documents publicly for its checkout flow.

# 1) Session bootstrap. bKash's published checkout flow documents an
#    OAuth2-style grant returning an id_token used as the Authorization
#    header; token life is one hour (per the bKash checkout guide).
POST /token/grant
  headers: { username, password, x-app-key }
  body:    { app_key, app_secret }
  -> 200 { id_token, token_type, expires_in: 3600, refresh_token }

# 2) Statement query for a consenting account, date-bounded.
GET /account/statement?from=2026-05-01&to=2026-05-31
  headers: { Authorization: id_token, X-Pin-Session:  }
  -> 200 {
       balance: { available, currency: "BDT", asOf },
       limit:   { dailyRemaining, monthlyRemaining },     # Check Limit
       entries: [
         { trxId, type, amount, fee, counterparty, balanceAfter, ts }
         # type in: SendMoney | CashOut | Payment | AddMoney | Recharge | PayBill
       ]
     }

# 3) Remittance is a separate record, not a statement row:
#    { receivedAt, originCountry, settlementBank, mto, amountBDT }

def fresh(tok):
    # renew before the 3600s window closes so long syncs don't drop mid-pull
    if tok.expires_in < 120:
        tok = grant()
    return tok
      

Consent, and where Bangladesh Bank sits

bKash is licensed and supervised by Bangladesh Bank under its Mobile Financial Services Regulations, with customer onboarding tied to e-KYC against the Election Commission database. That is the operating environment, and we work inside it: authorized access only, scoped to a consenting account, with consent records and access logs kept, data minimized to the fields a use case needs, and an NDA where a client wants one.

There is no national open-banking or unified-API standard live in Bangladesh yet. Local reporting describes Bangladesh Bank planning open-banking guidelines and standardized API protocols, with a working committee expected to form and guidelines targeted around the middle of this decade — a forward-looking item, not present law. So the dependable legal basis a bKash integration rests on today is the account holder's own consent, not a regime that has not arrived. When the standard does land, the same interface we build maps onto it; until then it would be a mistake to wait for it.

Details we plan around

Things specific to bKash that the build accounts for, so they do not surface as surprises:

• OTP and PIN session shape. The app uses a first-login OTP and a per-transaction PIN prompt. We design the session bootstrap around both, so the integration re-authenticates cleanly when bKash rotates a session instead of wedging on a PIN challenge mid-sync.
• Bangla and English in the same account. Users switch the interface between Bangla and English at will. We normalize statement labels and Bengali-script counterparty names into one schema and keep numerals consistent, so amounts and types parse the same regardless of the language a given account is set to.
• Fee math, not just net movement. bKash shows an auto-calculated service charge and a projected new balance before a transfer completes. We model that fee logic so reconciled records reflect the charge the user actually saw, not only the net amount that moved.
• Token lifetime. The documented auth token expires after roughly an hour. We build the refresh loop around that window so long statement backfills renew silently rather than dropping partway through.

Where teams put this

• A lender pulling a consenting applicant's statement and remittance history to corroborate income before a digital nano-loan or BNPL decision.
• An accounting or expense tool syncing a small merchant's bKash bill-pay and recharge activity into its books automatically.
• A payroll or disbursement service confirming available balance and remaining limits before initiating a batch of payouts.
• A personal-finance app folding a user's bKash ledger in alongside their bank accounts for one combined view.

Screens we mapped

Store screenshots of the surfaces referenced above. Tap to enlarge.

How this was put together

Checked in June 2026 against the bKash Play Store and bkash.com descriptions, the company's published payment-gateway documentation for the auth handshake, Bangladesh Bank's MFS regulation circular, and local reporting on the remittance-statement feature and the country's open-banking plans. Concrete numbers above are attributed to those sources or hedged where a value is not publicly disclosed; nothing here is asserted as a confirmed internal endpoint.

• The Daily Star — bKash remittance statement feature and its fields
• bKash Tokenized Checkout integration guide — grant token, id_token, token validity
• Bangladesh Bank — Mobile Financial Services Regulations
• The Business Standard — Bangladesh's planned open-banking system

Compiled by the OpenBanking Studio integration desk · reviewed June 2026.

Other wallets in the same picture

Same category, frequently named together in a unified-integration brief because a single customer often holds more than one. Neutral context, not a ranking.

• Nagad — Bangladesh Post Office's mobile wallet; holds cash-in, cash-out, send-money and recharge records behind its own login.
• Rocket — Dutch-Bangla Bank's MFS; carries fund transfers, bill payments and utility records per account.
• Upay — UCB-backed wallet with transfers, bill pay and top-ups, also reachable by USSD.
• MCash — Islami Bank Bangladesh's mobile money service with account balance and transaction history.
• iPay — digital wallet holding stored balance and payment history for its users.
• TAP (Trust Axiata Pay) — wallet with send-money, payment and bill records under one account.
• SureCash — payment platform used for disbursements and bill collection, with per-user ledgers.
• Cellfin — Islami Bank's digital app combining wallet and bank-linked transaction data.

Questions integrators ask about bKash

Can you separate remittance entries from ordinary send-money in a bKash statement?

Yes. bKash keeps a distinct remittance record carrying the receipt date and time, country of origin, settlement bank, money-transfer organisation and the BDT amount, separate from the general statement of send-money, cash-out and payment rows. We map both into one normalized ledger so inbound remittance and ordinary transfers are queryable side by side.

Which regulator governs a bKash integration, and is there an open-banking standard to build against?

Bangladesh Bank licenses bKash under its Mobile Financial Services Regulations, with e-KYC tied to the Election Commission database. A national open-banking and unified-API standard is reportedly being drafted, with a working committee planned and guidelines targeted around mid-2026 per local reporting, so it is not yet something to build against. Today the dependable basis is the account holder's own consent to authorized access.

How far back can you pull bKash transactions?

The in-app Statement shows recent activity, and bKash's downloadable remittance statement covers the last 30 or 180 days, the tax year, or a custom range as the app describes it. A consented interface integration can page deeper than the in-app default window; the exact retained depth is confirmed against a consenting account during the build rather than assumed.

We already accept payments through bKash checkout — can you reuse that for account data?

Partly. bKash's published checkout documentation describes the grant-token handshake that returns an id_token used as the Authorization header, with a one-hour token life, and that auth pattern informs how we build the session layer. Reading an account holder's own balance and statement is a separate consented surface from accepting a payment, so the data route is scoped on its own.

Source-code delivery starts at $300: the runnable endpoints, the OpenAPI spec, automated tests and the protocol report, paid only once it is delivered and working in your environment. If you would rather not host anything, call our endpoints and pay per call, with nothing upfront. Either way the build runs in one to two weeks. Tell us which bKash data you need and we will scope it — start at /contact.html.