Getting structured data out of DBBL's Rocket wallet, the authorized way

Every Rocket account is a Bangladesh Bank–regulated mobile wallet tied to Dutch-Bangla Bank's core systems, and it keeps a running per-user ledger: a balance, a dated statement, P2P and merchant movements, bill and top-up records, and transfers to and from a linked DBBL bank account. That ledger reaches the user through three thin front ends — the app, the *322# USSD menu, and SMS — and each is a place an integrator can read from once the account holder authorizes it. This brief maps what sits behind those screens and the route we take to pull it into a clean feed.

The short version: the richest data is the statement carried in the app session, and the most durable low-dependency surface is the USSD menu. For most Rocket jobs we build against the app traffic and read the USSD path in as a second reader, both feeding one normalized schema. Everything below is what we found looking at how Rocket actually presents its data, plus the rules that shape how we reach it.

The data behind a Rocket wallet

Rocket names its features the way the DBBL documentation does — Cash-in, Cash-out, Balance Inquiry, Statement Inquiry, Merchant Pay, and so on. Mapped to what an integrator would consume:

Authorized ways into Rocket's data

Three routes genuinely apply here; which we lean on depends on the handset mix and the depth of history you need.

Interface integration of the app traffic

Protocol analysis of the request/response between the Rocket app and the DBBL MFS backend, under the account holder's authorization. This is the deepest surface — full statement detail, balances, and transfer records. Effort is moderate; durability is tied to app releases, so we re-validate when the client is updated. We set up a consenting wallet or test account to build against together with you during onboarding.

USSD and SMS channel implementation

The *322# flash menu (with its callback-and-PIN step) and the SMS channel to 16216 return balance and recent activity on any handset, no internet needed, per DBBL's Rocket documentation. Narrower fields than the app, but stable — USSD menus change rarely — and useful where users are on basic phones or offline.

User-consented session export

Where a customer wants their own history out, the account holder authorizes and we operate within that session to export statement and balance data, keeping consent records against it.

In practice the app-traffic route is the one we build against for Rocket, because it exposes the full statement — dated entries, transaction type, counterparty, fee and reference — that balance-only channels can't give you. The USSD path earns its place where a user is on a basic handset or offline; we wire it in as a second reader against the same schema rather than a separate product.

A statement pull, in practice

Sketch of the shape we build against for a dated statement, with the USSD balance path noted below it:

# Illustrative. The shapes below were confirmed against a consenting
# Rocket wallet during the build, not taken from a DBBL published spec.

POST /mbs/txn/statement
Host: <rocket-mfs-backend>
Authorization: Bearer <session-token>     # issued after PIN + device binding
Content-Type: application/json

{
  "msisdn":      "01XXXXXXXXX",   # account holder's registered number
  "accountType": "GENERAL",       # or SALARY / STIPEND — fee rules differ
  "from":        "2026-06-01",
  "to":          "2026-06-30",
  "lang":        "EN"             # app is bilingual; BN returns Bangla labels
}

--> 200 OK
{
  "balance": { "available": "1240.50", "currency": "BDT" },
  "entries": [
    { "ts":"2026-06-28T14:11:00+06:00", "type":"CASH_OUT",
      "channel":"AGENT", "amount":"-500.00", "fee":"-9.00", "ref":"..." },
    { "ts":"2026-06-27T09:02:00+06:00", "type":"P2P_IN",
      "counterparty":"01XXXXXXXXX", "amount":"+300.00", "fee":"0.00" }
  ]
}

# Balance-only fallback, no internet:
#   *322#  ->  flash menu  ->  Balance  ->  system calls back  ->  enter PIN
      

Two things this snippet makes concrete: the entry type has to be normalized (cash-in, cash-out, P2P, bill pay, merchant pay, top-up, salary, remittance) so downstream code isn't parsing Bangla or English label strings, and the fee column is real data, not derived — DBBL's charges differ by channel and account type.

What lands in your repository

• An OpenAPI/Swagger spec for the Rocket surfaces you need — statement, balance, transfer, bill and merchant pay.
• An auth-flow report covering the PIN plus device-binding session-token chain on the app path, and the *322# callback-PIN flow.
• Runnable source in Python and Node.js for balance inquiry, a dated statement pull, and a transfer read.
• A normalized transaction schema with stable enums for every Rocket transaction type, so Bangla and English labels don't fork the data.
• Automated tests against a consenting wallet, including the account-type fee variants and bilingual label cases.
• Interface documentation and data-retention/consent guidance written for Bangladesh Bank's MFS rules.

Consent and the Bangladesh rulebook

Rocket sits under Bangladesh Bank's Regulatory Guidelines for Mobile Financial Services, 2022, administered by the Payment Systems Department, with BFIU KYC and AML obligations layered on top. Privacy is governed by Bangladesh's Personal Data Protection Act, reported enacted in 2026 with some sections phased in, so we treat data minimization and retention limits as live requirements rather than nice-to-haves. A formal consumer-consent open-banking regime is still at the draft stage — Bangladesh Bank has floated rules to open digital payments to non-bank players — so the dependable basis we build on today is the account holder's own authorization. Consent scope is read-focused (statement, balance, transfers), revocable by the holder, and we keep consent and access logs against every pull. NDAs where the engagement calls for one.

Where a Rocket build gets fiddly

The *322# menu doesn't behave like a clean request/response API: it uses an out-of-band step where the system calls the handset back and the user enters the PIN on that call. We model that callback explicitly so an integration doesn't assume a single synchronous exchange; on the app path we instead handle the device-binding and session-token issuance.

Charges vary by account type and channel — a general account cash-in is free while a salary or stipend account is charged, and cash-out runs at a lower rate from a DBBL ATM than from an agent point, per DBBL's published Rocket charges. We encode those fee rules per account type and channel so reconciliation lands on the same numbers the ledger shows. The linked DBBL core-banking account is also a separate rail from the wallet, so we map the wallet↔bank movement on both sides rather than as one entry. Access to a consenting account is arranged with you as part of getting started; it isn't something you need in hand before we'll take the work.

What gets built on this

• Nightly accounting sync: the Rocket statement pulled into a bookkeeping ledger, entries mapped to typed enums.
• Agent and merchant reconciliation: cash-out and merchant-pay entries matched against float and settlement.
• Payroll confirmation: for salary and stipend accounts, checking disbursements landed per employee.
• Treasury view: reconciling wallet↔linked-DBBL-account transfers across both rails.

Screens we mapped

The Rocket screens we referenced while writing this — tap to enlarge.

Sources and method

Written after reading DBBL's own Rocket service and balance-inquiry pages for the feature and channel names, Bangladesh Bank's MFS regulatory guidelines for the supervisory frame, and trade-press coverage of the draft rules opening digital payments to non-bank players. The package identifier com.dbbl.mbs.apps.main is as listed on Google Play, and market-share figures (Rocket around 11–12% of MFS transactions, behind bKash and Nagad) are as reported by 2026 industry press, not our own measurement. Citations:

• DBBL — Rocket services
• DBBL — Rocket balance inquiry / *322#
• Bangladesh Bank — MFS regulatory circular (PSD)
• The Business Standard — draft rules for non-bank payment players

Mapped by the OpenBanking Studio integration desk · July 2026.

Other MFS wallets in Bangladesh

Same-category apps an integrator often needs to reach alongside Rocket. Naming them for context, not ranking.

• bKash — the largest MFS wallet by transaction share; balances, statement, P2P and merchant pay.
• Nagad — Bangladesh Post Office–linked wallet with digital KYC; similar wallet ledger and bill pay.
• Upay — UCB-backed wallet holding balances, transfers and utility payments.
• SureCash — wallet used heavily for stipend and disbursement flows.
• MCash — Islami Bank's MFS wallet with transfers and bill pay.
• Trust Axiata Pay (tap) — wallet with P2P, merchant and bill data.
• TallyPay — Bank Asia–linked wallet covering payments and transfers.
• OK Wallet — ONE Bank's MFS wallet with a comparable transaction ledger.

Reaching several of these under one normalized schema is a common ask; the same route work applies. To scope a multi-wallet feed, get in touch.

Questions integrators ask about Rocket

Is Rocket's statement data reachable through the app, or only the *322# USSD menu?

Both are live surfaces. The mobile app session carries the fuller statement — dated entries with transaction type, counterparty, amount, fee and reference — while the *322# flash menu and the SMS channel return balance and recent activity on any handset without internet, per DBBL's Rocket documentation. We can build against either, and usually read both into one normalized schema.

Can the transfer between a Rocket wallet and a linked DBBL core banking account be integrated?

Yes. Rocket exposes a wallet-to-bank and bank-to-wallet movement against the account holder's own linked DBBL account or debit card. That is a separate rail from the in-wallet ledger, so we map both sides and reconcile the transfer rather than treating it as a single entry.

Which Bangladeshi regulator and rules apply when integrating a Rocket account?

Rocket operates as a mobile financial service under Bangladesh Bank's MFS Regulations, 2022, administered by its Payment Systems Department, alongside BFIU KYC and AML obligations and Bangladesh's Personal Data Protection Act on the privacy side. A formal consumer-consent open-banking regime is still in draft, so the dependable basis we work from is the account holder's own authorization, logged and data-minimized.

If we only need balance and statement, not the whole wallet, is that a smaller build?

It is. Balance and statement come from a narrow set of Rocket surfaces, so a read-only export of those two — plus the transaction-type normalization — is a tighter scope than covering cash-in, cash-out, bill pay, merchant pay, top-up and remittance together. We quote that reduced surface accordingly, usually inside the one-to-two-week cycle.

Rocket work runs on a short cycle — a scoped wallet-and-statement integration is a one-to-two-week job once we have a consenting account to build against. The delivery package is runnable source for the key Rocket surfaces, an OpenAPI spec, the auth-flow report and automated tests, at a fixed fee from $300 that you pay only after it runs for you and you're satisfied. If you'd rather not host anything, call our Rocket endpoints instead and pay per call with nothing upfront. Send the app name and what you want out of its data and we take it from there — start at /contact.html.