Reaching CellFin’s wallet and linked-account data

One CellFin login fans out to a lot of money. The wallet keeps its own balance, but the same session also reaches a linked Islami Bank CBS account, a Khidmah credit card, a prepaid card, an agent-banking line and an mCash account — the app links all of them to a single Digital Wallet, per its own feature list. That is the integration prize here: not a single balance, but a consolidated view across a bank core, cards and a mobile-money account, reachable through one authenticated app. A third party that wants to read those balances, pull transfer history, or reconcile a payment that left through NPSB does not need six connections. It needs one, modelled correctly.

Data the wallet keeps behind login

Each row below is a surface the app actually shows a signed-in user. Where CellFin names a thing a certain way, that is the name in the table.

Authorized routes to that ledger

Bangladesh does not yet hand you a regulated consent rail to plug into, so the route work is honest about what carries the data and what only carries money.

Protocol analysis of the consented session

The app talks to Islami Bank’s backend over a token-authenticated session after device binding and an OTP step. We observe that traffic with the account holder’s authorization, document the login and refresh chain, and rebuild the balance, history and transfer calls as a clean client. This reaches everything the app shows. Effort is moderate; durability is good as long as we plan for app updates. This is the route we would build on for CellFin, because the multi-account view only exists inside that session and nothing else exposes it.

User-consented credential access

For an aggregation product where the end user is present, the same session can be driven under their explicit consent, with credentials held by the consenting party rather than by us. Good for read-heavy balance and statement use; it inherits whatever step-up the bank applies, which we map.

NPSB as a payment rail, not a data feed

CellFin settles interbank and MFS transfers through the National Payment Switch. Since November 2025 that switch carries direct bank-to-wallet legs to bKash, Nagad and others, per Bangladesh Bank’s rollout. It is useful context for reconciling where a transfer went, but it moves value, not account data, so it supports the integration rather than replacing it.

What lands in your repo

The handover is built around CellFin’s real surfaces, not a template:

• An OpenAPI description of the normalized endpoints — consolidated balances, wallet ledger, transfer status, card state — so the multi-account fan-out reads as one tidy contract.
• A protocol and auth-flow report: device binding, OTP, the token issue-and-refresh chain, and how the signed-in session is held across the balance and Send Money calls.
• Runnable source for the core endpoints in Python or Node.js, whichever your stack uses, with the transfer-status poller included.
• Automated tests against recorded fixtures, plus a replay harness so a CellFin app update can be re-checked without a live account each time.
• Interface documentation an in-house team can maintain, and a data-retention note covering what is logged and minimized.

A balance-and-transfer call, sketched

Illustrative shape only — exact field names and the token chain are confirmed during the build against a consenting account, not guessed from the outside.

POST /cellfin/session/refresh
  Authorization: Bearer <short-lived access token>
  X-Device-Id: <bound device fingerprint>
  -> 200 { "access": "...", "expires_in": 600 }

GET /cellfin/accounts            # the consolidated fan-out
  -> 200 {
       "wallet":  { "id": "cf-***", "balance": "...", "ccy": "BDT" },
       "linked": [
         { "type": "CBS",   "masked": "***4821", "balance": "..." },
         { "type": "MCASH", "masked": "***0190", "balance": "..." },
         { "type": "CARD",  "scheme": "KHIDMAH", "available": "..." }
       ]
     }

GET /cellfin/transfers?since=2026-06-01
  -> 200 [ { "ref": "...", "rail": "NPSB", "to": "bank:***",
             "amount": "...", "state": "SETTLED" },
           { "ref": "...", "rail": "MFS",  "to": "nagad:***",
             "amount": "...", "state": "PENDING" } ]

# error path we handle explicitly
401 SESSION_EXPIRED  -> re-run refresh, then retry once
423 STEP_UP_REQUIRED -> surface OTP challenge to the consenting user

Bangladesh Bank rules and the consent we work under

CellFin operates under Bangladesh Bank’s Payment Systems Department and the Mobile Financial Services Regulations of 2022. There is no statutory account-information-services regime to ride; the interoperable Binimoy platform that pointed in that direction was suspended in 2025 over contract issues, which is exactly why we anchor on the account holder’s own authorization rather than a consent API. On the privacy side, Bangladesh approved a Personal Data Protection Ordinance in 2025 that makes the individual the owner of their data and requires explicit consent for collection, with parts phased in after gazette publication. We work to that posture now: consent is recorded, access is logged, the data set is minimized to what the integration needs, and we sign an NDA where a client wants one. Cross-border handling matters here because the app is used from abroad, so remittance and overseas-session data stay inside the agreed scope.

What we plan around on CellFin

Two things shape the build, and we handle both as part of the work:

• The multi-account fan-out is the hard part, not the easy part. A CBS account, an mCash account, an agent-banking line and several card types each report differently. We design one normalized account model up front, with a per-source adapter, so adding a linked type later does not mean re-plumbing the client.
• Device binding and OTP step-up are session-level, not one-time. CellFin binds to a device and challenges sensitive actions. We build the refresh-and-retry loop around that, and design the sync so a step-up surfaces to the consenting user cleanly instead of stalling a batch.
• The front end changes. Islami Bank ships app updates regularly — APKMirror lists releases in the 3.5.x line during 2025. We include a replay harness and a maintenance check that re-runs the recorded calls, so a changed endpoint is caught before it breaks your pipeline.

Access to a sandbox or a consenting account is arranged with you during onboarding; the build runs against whichever you provide, and we do that setup together rather than handing you a checklist.

Where integrators put this

• A personal-finance app pulling consolidated CellFin balances and ledger so a user sees bank, card and wallet money in one place.
• An accounting or payroll tool reconciling foreign-remittance credits as they land, since CellFin receives them 24/7.
• A merchant or marketplace confirming that an NPSB or MFS payout actually settled, by polling transfer state rather than waiting on a statement.

Pricing and how we hand it over

The source code lands in your repository when it runs and you have checked it — the build starts from $300 and you pay only after delivery, once you are satisfied with what it does against a CellFin account. If you would rather not host anything, we run the integration and you call our endpoints, paying per call with no upfront fee. A working cycle runs one to two weeks depending on how many linked-account types you need covered. Tell us the app name and what you want out of its data, and we take the access and compliance arrangements from there. Start the conversation at /contact.html.

Screens we mapped

Store screenshots we reviewed while tracing the surfaces above. Tap to enlarge.

What we checked

We read Islami Bank’s own CellFin page and the Google Play listing for the feature set and the linked-account model, the Bangladesh Bank Payment Systems pages for NPSB’s role, a Business Standard report on the November 2025 bank-to-wallet expansion, and The Daily Star’s summary of the 2025 Personal Data Protection Ordinance. Sources opened while writing this:

• Islami Bank — CellFin product page
• Bangladesh Bank — Payment Systems
• The Business Standard — NPSB bank-to-MFS transfers
• The Daily Star — Personal Data Protection Ordinance 2025

Mapped by the OpenBanking Studio integration desk, 17 June 2026.

Other wallets riding the same rails

Same category, same NPSB and MFS plumbing — named here because a unified integration often spans several of them, not to rank one over another.

• bKash — the largest MFS wallet in the country; holds P2P transfers, merchant payments, savings and cash-out history per account.
• Nagad — Post Office–backed wallet with digital KYC; keeps send-money, bill and top-up records behind login.
• Rocket — Dutch-Bangla Bank’s MFS, tied into DBBL accounts, with transaction and bill-pay ledgers.
• Upay — United Commercial Bank’s wallet; balances, transfers and merchant payments per user.
• Tap — Trust Axiata’s MFS; wallet ledger, transfers and bill payments.
• mCash — Islami Bank’s own MFS, which CellFin already links; account balance and transaction history.
• Dmoney — a PSP-side wallet handling P2P and merchant settlement records.
• TallyPay — a newer MFS holding wallet balances and transfer history per account.

Questions integrators ask about CellFin

Can a third party read CellFin balances across the linked Islami Bank account and the wallet at once?

Yes. CellFin exposes Bank, mCash and CellFin balances inside one signed-in session, and the linked CBS account, Khidmah card and agent-banking line sit behind the same login. We model that fan-out as a single normalized account list so an integrator gets one call instead of chasing each surface separately.

How do you handle CellFin transfers that fan out to bKash, Nagad and the NPSB rails?

The Send Money flow carries a rail tag — EFT and NPSB for bank legs, MFS for bKash, Nagad and mCash. We capture that tag, the counterparty and the settlement state per transaction, then expose status polling so your system can reconcile a transfer end to end rather than guess from a balance change.

Which regulator covers CellFin, and does Bangladesh have a formal consent rail like Open Banking?

CellFin runs under Bangladesh Bank’s Payment Systems Department and the Mobile Financial Services Regulations of 2022. There is no statutory account-information-services consent regime today; the interoperable Binimoy platform that aimed at that role was suspended in 2025. So the dependable basis is the account holder’s own authorization, with NPSB used as a payment rail rather than a data-consent rail.

Does CellFin’s overseas mode change the integration?

It can. Islami Bank describes CellFin working from 26 countries for Bangladeshi citizens, and the remittance-receipt surface behaves differently from a domestic session. We account for the geo-gated paths and the foreign-remittance ledger so the integration does not break when the consenting account is used from abroad.