The bKash DSO account, and the authorized way into its records

Every bKash Distribution Sales Officer signs into the DSO app against an active DSO account, and behind that login sits the daily money movement for bKash's distribution chain — the layer between bKash Limited and the agents who run cash-in and cash-out across Bangladesh. Third-party app-store listings describe that chain as roughly five thousand sales officers covering on the order of three hundred thousand agents. For a distributor, an MIS team, or a platform settling against bKash, the value is not the screens. It is the e-money ledger, the B2B transfer trail and the field-coverage data those screens are drawn from.

The bottom line: the DSO account is a single authenticated identity that returns a distributor's balances, a searchable statement, and the geotagged field activity of the agents under it. We reach those by analysing the app's authenticated traffic with the account holder's authorization, normalize the Bengali-language responses, and hand back a clean client. That is the route below.

Records a DSO login exposes

Each row maps a record the app surfaces to where it originates in the DSO flow, how fine-grained it is, and what an integrator typically does with it.

Authorized routes into the DSO ledger

Three routes genuinely apply here. They differ in what they reach and how long they hold.

Consented protocol analysis of the DSO app

Working from a DSO account whose holder authorizes the work, we observe and reconstruct the app's authenticated calls — onboarding, session, balance, statement, B2B initiation, field data. This reaches everything in the table above. Effort is moderate; durability depends on app releases, so we build a check that flags when the response shape shifts. Access is arranged with you at onboarding against a consenting account or a sponsor sandbox — that setup is part of the project, not something you assemble first. This is the route we would build the integration on, because it is the only one that returns the DSO ledger and field data rather than just fund movement.

Binimoy / IDTP for inter-MFS movement

Bangladesh Bank's Interoperable Digital Transaction Platform, Binimoy, was launched in November 2022 (as reported by national press) and lets value move between participating MFS operators, banks and PSPs, bKash among them. Where the job is cross-wallet settlement rather than reading the DSO ledger, this regulated rail is the right path. It does not return statement lines, check-ins or POI data — it standardizes the transfer, not the read.

Native in-app capture as a fallback

The statement view supports searching for a specific transaction. Where a one-off extract is all that is needed, we automate capture of what the app itself presents. It is the narrowest option and we treat it as a backstop, not a primary feed.

How the session and statement calls behave

The shape below reflects the real flow the DSO app drives — SMS OTP onboarding, an account-number-plus-PIN session, then balance, statement and B2B. Endpoint and field names are settled during the build; the structure is what matters here.

# Illustrative — names confirmed during the build, not published constants
POST /dso/v1/session/start
  { "msisdn": "<DSO account number>", "channel": "DSO_APP" }
  -> { "otpRef": "...", "expiresIn": 120 }          # SMS OTP issued

POST /dso/v1/session/verify
  { "otpRef": "...", "otp": "######", "menuPin": "****" }
  -> { "accessToken": "...", "ttl": 900 }            # device-bound

GET /dso/v1/statement?from=2026-05-01&to=2026-05-18
  Authorization: Bearer <accessToken>
  -> { "items": [ { "txnId": "...", "type": "B2B",
                    "amount": "১২,৫০০.০০",
                    "counterpartyAgent": "...", "ts": "..." } ],
       "emoneyBalance": "...", "cashBalance": "..." }

# Bangla-numeral amounts normalized to 12500.00 on extraction.
# 401 -> token expired: re-verify within the OTP window if cached,
#        otherwise restart session (binding is per device).
      

What lands in your repo

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

• An OpenAPI/Swagger spec covering session start/verify, balance, statement query and B2B initiation.
• A protocol and auth-flow report: the SMS-OTP onboarding, the account-number-plus-menu-PIN session, token TTL and device binding, and the press-and-hold B2B confirm semantics.
• Runnable source — Python and Node.js — for the statement pull, balance read and a guarded B2B initiation path.
• Automated tests that run against a sandbox or a consenting DSO account.
• A normalized schema doc, including Bangla-numeral and date normalization, and the field-data shape for check-ins and POI points.
• Data-retention and access-logging guidance aligned with MFS Regulations 2022 and BFIU expectations.

Authorization and Bangladesh Bank oversight

bKash operates as a payment service provider under Bangladesh Bank's Payment Systems Department, governed by the Mobile Financial Services Regulations, 2022 (which replaced the 2018 framework, per Bangladesh Bank's published circular), with AML/CFT obligations under the Bangladesh Financial Intelligence Unit. Bangladesh does not run an Account Aggregator or open-data consent statute equivalent to those in India or the UK, so a consumer data-rights mandate is not the basis here. Authorization is concrete instead: the DSO account holder consents, the studio works under contract and NDA, access is logged, and only the records you asked for are extracted. Binimoy is the regulated platform for inter-MFS fund movement and we treat it strictly as that — a transfer rail, not a backdoor to the ledger.

Engineering details we account for

Specific things about this app that shape how we build, all handled on our side:

• The B2B path is a deliberate two-step: PIN, then a press-and-hold confirm. We model both as explicit steps the backend expects, so an automated transfer is accepted exactly as a manual one is rather than failing a confirm the server is waiting for.
• The interface is Bengali-only and amounts come back in Bangla numerals. We normalize digits, thousands separators and dates to plain decimals and ISO dates in the extracted schema, so downstream systems never parse Bangla glyphs.
• The balance-hide privacy feature blanks the value on screen. We read it from the authenticated data response, not the rendered view, and recheck that mapping when the app updates.
• Onboarding is SMS-OTP and the session is device-bound. We design session handling around that binding and the menu-PIN lifecycle so the integration stays stable, and arrange a consenting account or sandbox with you during onboarding.

Engaging us

A working bKash DSO client — statement pull, balance read and a guarded B2B path, with its OpenAPI spec and tests — comes back inside one to two weeks. You can take it as source-code delivery from $300, where the code, report and tests are handed over and you pay only after delivery once you are satisfied; or as a pay-per-call hosted API, where we run the endpoints and you are billed per call with nothing upfront. Give us the app name and the records you need and we scope it from there — start the conversation here.

Where teams put this data to work

• A distributor finance team reconciling each DSO's e-money balance against the ERP every morning, with mismatches flagged before the field day starts.
• Rule-driven B2B top-ups: when an agent's float drops below a threshold, an automated BITUBI transfer is initiated and logged.
• A field-ops view that joins agent check-ins and POI geodata with the distributor's CRM to see coverage gaps by territory.
• Settlement matching that lines up statement entries against bank or Binimoy transfer records to close the day cleanly.

Other MFS apps in the same data picture

A distributor or aggregator rarely sits on one wallet. These same-category apps hold comparable balance, transfer and agent data, and a unified integration usually spans several of them. Names are listed for context only.

• Nagad — Bangladesh Post Office-operated MFS; per-user balances and transaction history behind an authenticated account.
• Rocket — Dutch-Bangla Bank's MFS, with a wide ATM and agent footprint and account-level statements.
• Upay — UCB-backed wallet with balance, send-money and bill-payment records per account.
• mCash — Islami Bank's MFS, an early Binimoy participant, holding account ledgers and transfers.
• TallyKhata — Sheba Fintech's bookkeeping and payments app with merchant ledger and transaction data.
• iPay — an e-wallet covering recharge, send-money and bill payments tied to a user account.
• Dmoney — a digital payment platform with disbursement and collection records.
• SureCash — a payment platform used for disbursement programmes, holding beneficiary and transfer data.

App screens

From the public store listing — the balance, statement and B2B surfaces referenced above. Select to enlarge.

What was checked

This brief draws on the app's own description (balance, statement, B2B/BITUBI, tap-and-hold confirm, SMS-OTP onboarding), its public store listing for the field-force surfaces (agent check-in, position, POI capture), Bangladesh Bank's published MFS regulation, and national reporting on the Binimoy interoperability platform. Reviewed May 2026 by the OpenBanking Studio integration desk.

• bKash DSO on Google Play
• Bangladesh Bank — Mobile Financial Services Regulations, 2022 (PSD circular)
• The Daily Star — launch of the Binimoy transaction platform
• The Financial Express — how the inter-MFS Binimoy system works

Questions integrators ask about bKash DSO

Does the DSO app's balance-hide setting stop us from reading the e-money figure?

No. The hide toggle only affects what the screen renders; the balance value still arrives in the authenticated data response. Our client reads it there and normalizes the Bangla-numeral amount to a plain decimal, so reconciliation is unaffected.

How is the B2B (BITUBI) tap-and-hold confirmation reproduced in an automated client?

The PIN entry followed by the press-and-hold confirm is a deliberate two-step the backend expects. We model both steps explicitly in the generated client rather than collapsing them, so a programmatic B2B transfer is accepted the same way a manual one is.

Bangladesh has no Account Aggregator-style data regime — what makes this integration authorized?

Authorization rests on the DSO account holder's consent plus a contract and NDA with the studio, with access logged and data minimized. Bangladesh Bank's Binimoy platform is the regulated rail for inter-MFS fund movement, not for ledger read, so DSO statement and field data are reached by consented protocol integration.

Can you scope a bKash DSO build from just the app name and what we need out of it?

Yes. The app name and the records you want — say B2B history plus daily e-money balance — are enough to start; a consenting DSO account or sandbox and the compliance paperwork are arranged with you as the project runs.