What an integrator can pull from Islami Bank mCash

Dial *259# from any of Bangladesh's four big mobile networks, key in a four-digit PIN, and an mCash wallet opens its balance and mini-statement — the same per-user ledger a third-party system wants to read on a schedule. That ledger, plus the richer history the smartphone app holds, is the thing this brief is about. mCash is the Shariah-compliant mobile financial service of Islami Bank Bangladesh PLC, in market since 2012 per the bank's own mCash page, and an integrator usually wants two things from it: a current balance and a clean, typed transaction list.

The bottom line is short. mCash keeps a real, per-account ledger behind a PIN, reachable two ways — the app and the dial-string menu. We reach it the way we reach any consumer wallet: against a consenting account, mapping the app and USSD traffic into a documented interface, and handing you source you can run. The rest of this page is the specifics — what data, which route, and what arrives in your repository.

What sits inside an mCash wallet

Every row below is a surface mCash actually exposes to its own users, drawn from the app's feature set and Islami Bank's mCash documentation. Granularity is what we have seen the channel return, not a guarantee for every account state.

Authorized ways into the ledger

Bangladesh has no consumer open-banking consent regime of the UK or Brazil kind, so the route here is interface integration on the account holder's own access, not a regulator-issued AIS token. Three approaches genuinely apply.

Authorized interface integration of the app session

We analyze the mCash app's authenticated traffic — login, PIN and second-factor exchange, then the balance and statement calls — and rebuild those calls as a small, documented client. This is the richest source: full typed history with counterparties. Effort is moderate; durability holds until Islami Bank changes the front end or the auth flow, which we account for with a re-validation step (see build notes). Access is set up with you during onboarding against a consenting account.

USSD *259# capture as a fallback

The dial-string menu returns balance and a short mini-statement over a channel that barely changes and works without a smartphone. It is lower-fidelity — fewer fields, English-only labels — but it is a sturdy backstop when the app build shifts. We wire it as a secondary reader so a balance check keeps working through an app update.

User-consented credential operation

Where you operate on behalf of the account holder (a bookkeeping or lending workflow with their consent), we run the integration under that consent, with consent records and logging built in. This is the model that fits most third-party use of a personal wallet.

For mCash specifically we would lead with the app-session integration and keep the *259# reader behind it for resilience; the wallet ledger is the same object whichever way it is read, so pinning the build to that object keeps it stable while Bangladesh's transfer rails keep shifting underneath.

What we plan around on this build

Two things about mCash shape the engineering, and we handle both as part of the work.

• Two channels, one ledger. The app session and the *259# menu return the same balance and statement at different fidelity. We normalize them to one schema (amount, type, counterparty, timestamp, currency) so downstream code does not care which channel served a given read, and we design the fallback so a balance check survives an app-front-end change.
• PIN plus a second factor on every action. Bangladesh Bank's MFS rules require a four-digit PIN and a second factor for each transaction-grade action. We build the session and re-challenge handling around a consenting account's credentials, arranged with you at onboarding, and keep a re-validation pass for when the OTP or 2FA step is revised.
• Interoperability churn is real. mCash sat in the Binimoy launch cohort and is now exposed to the October 2025 NPSB interoperability rails; transfer semantics and fees move with policy. We scope those as mapping updates against a stable wallet read, not a rebuild, so a rail change does not break your feed.

What lands in your repository

Delivery is concrete and tied to mCash's surfaces, not a generic kit:

• An OpenAPI/Swagger spec for the wallet read surface — balance, mini-statement, paged history — with BDT currency and the typed transaction model.
• A protocol and auth-flow report: the PIN / second-factor / session-token chain for the app, and the *259# menu walk for the fallback.
• Runnable source for the key endpoints in Python or Node.js, including the channel fallback and statement pagination.
• Automated tests against recorded responses, plus a normalization layer that maps both channels to one schema.
• Interface documentation and data-retention guidance written for an MFS holding personal financial records under Bangladesh Bank oversight.

A balance-and-statement read, sketched

Illustrative only — field names are settled during the build, and this runs against a consenting account, never a public endpoint.

# mCash wallet read (illustrative) — consenting account, two-channel fallback
import os, requests

session = mcash_login(
    msisdn="8801XXXXXXXXX",          # registered mCash number
    pin=os.environ["MCASH_PIN"],     # 4-digit PIN + second factor, per Bangladesh Bank rules
)

def balance():
    r = session.get("/wallet/balance")
    if r.status_code == 423:         # PIN / 2FA re-challenge
        session.refresh_2fa()
        r = session.get("/wallet/balance")
    r.raise_for_status()
    return r.json()                  # -> {"currency":"BDT","available":"4250.00","as_of":"2026-06-21T09:14:05+06:00"}

def mini_statement(limit=10):
    r = session.get("/wallet/mini-statement", params={"count": limit})
    r.raise_for_status()
    return [
        {
          "txn_id": e["ref"],
          "type": e["kind"],         # send / cashout / billpay / recharge / remittance
          "amount": e["amt"],
          "counterparty": e.get("party"),
          "ts": e["time"],
        }
        for e in r.json()["entries"]
    ]

# USSD *259# fallback returns the same shape, fewer fields, when the app build shifts

Bangladesh Bank rules and the consent we work under

mCash operates under Bangladesh Bank's Mobile Financial Services Regulations of 2022, issued by the Payment Systems Department, which replaced the 2018 rules and mandate PIN-plus-second-factor authentication on transaction-grade actions. There is no consumer data-sharing mandate equivalent to PSD2 or Open Finance Brasil, so the dependable basis for any read is the account holder's own consent — not a regulatory feed. The Data Protection Act, 2023 is the privacy frame Bangladesh is moving toward; legal commentary still treats parts of it as in flux, so we operate to its stated principles — purpose limitation, access and erasure rights — without leaning on any single unsettled clause. In practice that means authorized, logged, data-minimized access, consent records kept per account, and an NDA where your use calls for one. We read only the fields a job needs.

Where teams put an mCash feed

• A Dhaka SME accounting tool that pulls each linked mCash wallet's mini-statement nightly and reconciles merchant and bill payments against its books.
• A nano-lender that reads a consenting borrower's balance and inflow history (salary, remittance, cash-in) to size a facility, with consent recorded.
• A payroll platform confirming that salary disbursements to staff mCash wallets actually landed, by matching its payout file to inbound transfer records.

Screens this mapping drew on

Public Play Store screenshots we reviewed while mapping the wallet surfaces. Select to enlarge.

The wider MFS field around mCash

mCash is one of more than a dozen Bangladesh Bank-approved mobile financial services. A team integrating one wallet usually wants several normalized to one schema; these are the neighbours, named for context only.

• bKash — the market-leading wallet, the largest pool of P2P, bill and merchant records in the country.
• Nagad — the Bangladesh Post Office-linked MFS, broad consumer transaction and cash-in/out data.
• Rocket — Dutch-Bangla Bank's MFS, wallet activity tied closely to DBBL bank accounts.
• Upay — UCB Fintech's wallet, transfers, bills and merchant payments.
• MYCash — Mercantile Bank's MFS, a bank-linked wallet ledger.
• Trust Axiata Pay (tap) — a newer wallet with P2P and merchant flows.
• FirstCash — First Security Islami Bank's Shariah-compliant MFS, a close peer to mCash.
• OK Wallet — One Bank's MFS, transfers and bill-pay records.
• Tallykhata — a ledger-and-payments app that shared the Binimoy launch cohort, small-merchant bookkeeping data.

How this brief came together

Mapped in June 2026 from Islami Bank's own mCash pages, the Play Store listing, Bangladesh Bank's MFS regulatory documents, and reporting on Bangladesh's inter-MFS interoperability. Primary sources we opened:

• Islami Bank — mCash service page
• Bangladesh Bank — Guidelines on Mobile Financial Services (PDF)
• The Daily Star — inter-MFS transfer via Binimoy
• Google Play — Islami Bank mCash listing

Mapped by the OpenBanking Studio integration desk, June 2026.

Questions integrators ask about mCash

Can mCash data be read through the *259# USSD menu as well as the app?

Yes. Balance and mini-statement come back over both channels: the *259# USSD menu (English-only) returns a stripped figure and the last few entries, while the app session carries richer history and counterparty detail. We map both and let the reader fall back from one to the other.

Which Bangladesh regulator sits over an mCash integration?

Bangladesh Bank, through its Payment Systems Department and the Mobile Financial Services Regulations of 2022. Every action is authenticated by the account holder's four-digit PIN with a second factor, so we build the session handling around a consenting account, arranged with you during onboarding.

Do Binimoy or the new NPSB interoperability rails hand us a customer's statement?

No. Binimoy and the October 2025 NPSB interoperability move money between wallets and banks; they are settlement rails, not a record of one customer's ledger. We read the balance and statement from the wallet itself through authorized interface integration.

How current is the balance figure we read from mCash?

The balance is the live figure at the moment of the read, the same value the *259# check returns. The mini-statement is the last N entries; for a full ledger we page the in-app history and normalize each row to amount, type, counterparty and timestamp in BDT.