Sonali e-Wallet account records, reached by consent

Sonali Bank PLC runs Sonali e-Wallet as the consumer front end to what the app's own description calls the largest state-owned commercial bank in Bangladesh. Behind the screens, every Add Money move, BEFTN transfer, airtime recharge and bill payment becomes a server-side record tied to one wallet account. That record set — not the buttons in the app — is what an integrator actually wants, and there is an authorized way to reach it.

The bottom line is plain. The app shows the holder a full picture of their wallet and the bank account behind it, gated by a PIN and, for any transfer, an OTP. We rebuild that authenticated view as a clean interface you can call, working from an account that consents to the project. The transfer-confirmation question is handled against Bangladesh's own rails rather than guessed at.

Account records the wallet keeps on file

Open the app and the data falls into a handful of buckets. Each maps to a surface a holder already sees, which is exactly what makes it reachable under their authorization.

Authorized routes into the wallet

Three authorized paths reach this data; which one you build depends on what you actually need back.

Consented interface integration

We replay the app's own authenticated traffic — the PIN login, the session token, the OTP step for transfers — from an account that consents to the work. This is the only route that hands back the holder's entire view in one consistent shape, balances through DPS schedules. Effort is moderate, mostly in the auth handshake and session handling; durability tracks the app's build versions, which we manage with a re-check step. Access to a consenting account or test credentials is arranged with you when the project opens.

Rails-level transfer status (BEFTN / NPSB)

When the narrow question is "did this transfer settle", we model status against Bangladesh's clearing semantics instead of polling a screen. BEFTN runs in batches; NPSB moves interbank retail transfers in real time around the clock. Reachable scope is transfer state, not the wider record set. Durability here is high because the behavior is regulator-defined.

On-device notification capture

The app fires a notification on every activity, and also reports over SMS and Messenger. A consented device-side capture turns those into a low-effort event feed. Low effort, medium durability, narrow to transaction events.

For most buyers the consented interface integration is the one to build first, because it is the only path that returns the complete account picture the holder already has. We pair it with notification capture so a recharge or transfer surfaces the instant the app receives it, and we fall back on the BEFTN/NPSB status model for the cases where settlement confirmation is the whole job.

A history pull, sketched in code

Here is the rough shape of a read against the wallet's mobile backend. Field names are illustrative — the exact contract is confirmed during the build against a consenting account. The read side needs only the session; the write side takes the second factor.

# Illustrative. Sonali e-Wallet gates login with a PIN and asks for an OTP on every transfer.

POST /m/auth/login
  { "msisdn": "+8801XXXXXXXXX", "pin": "····", "device_id": "<bound-device>" }
  -> 200 { "session": "<token>", "wallet_no": "01XX…", "otp_required_for": ["transfer"] }

# Balance and history return on the session token alone.
GET /m/account/balance            Authorization: Bearer <token>
  -> 200 { "wallet_balance": "…", "linked_account_balance": "…", "ccy": "BDT" }

GET /m/account/txns?from=2026-05-01&to=2026-05-31
  -> 200 { "items": [ { "ts": "…", "type": "RECHARGE|BEFTN|ADD_MONEY|BILL",
                        "counterparty": "…", "amount": "…", "status": "…" } ] }

# A BEFTN transfer needs the OTP alongside the PIN:
POST /m/transfer/beftn
  { "to_account": "…", "amount": "…", "pin": "····", "otp": "······" }
  -> 202 { "ref": "…", "rail": "BEFTN", "status": "PENDING_BATCH" }
      

Note the last status. A BEFTN transfer sits in a batch before it clears, so "pending" is normal, not a failure — the integration has to read it that way.

What lands in your repository

Everything we hand over is tied to the surfaces above, not a generic template.

• An OpenAPI/Swagger spec for the normalized endpoints — balance, transaction history, transfer status — with the wallet's own field meanings carried through.
• A protocol and auth-flow report covering the two-step PIN session, the OTP step, and token lifetime as they behave for this app.
• Runnable source for the key endpoints in Python or Node.js, the login-and-read path working end to end.
• Automated tests against recorded responses, including the BEFTN pending-then-cleared transition.
• Interface documentation a second engineer can pick up without us.
• Compliance and retention guidance: what consent record to keep, what to log, what not to store.

Bangladesh Bank's rules, and the basis for access

Sonali e-Wallet answers to Bangladesh Bank through its Payment Systems Department, the licensing and oversight body for mobile financial services under the MFS Regulations 2022. The Payment and Settlement Systems Act 2024, passed in July 2024, sits over the wallet, gateway and switch layers it touches. A Personal Data Protection Ordinance only reached the gazette in early 2026, per reporting, so that regime is new and still settling. Because of that, the dependable legal basis for this work is not a data-sharing mandate — it is the account holder's own documented consent. We operate authorized and logged, keep the consent record, minimize what we pull to what the brief needs, and sign an NDA where the client wants one.

Details we plan the build around

A few things about this specific app shape how the integration is built. None of them are yours to clear first — they are ours to handle.

• The two-phase PIN and the per-transfer OTP are part of the contract, so the session handler is built to complete sensitive calls exactly as the app does. OTP delivery is arranged with the consenting account holder during onboarding.
• The app states it works from anywhere but for domestic transactions only, so we scope the integration to BDT domestic flows and do not model cross-border rails that are not there.
• BEFTN is batch and NPSB is real time, so transfer-status polling is designed against both — a batched transfer stays "pending" rather than reading as failed, while NPSB confirmations resolve in the same session.
• The Android build moves over time — APKMirror lists it at version 2.4.0.0 as of writing. When Sonali Bank ships a new release, the captured contract gets re-checked before the next sync, and that re-check is part of how we maintain the integration.

Working with us, and the price

Source-code delivery starts at $300, and you pay only after the integration is in your hands and doing what this brief described. The other model skips the build on your side entirely: we host the endpoints, you call them, and you pay per call with nothing upfront. Either way the working cycle runs one to two weeks from the point we have a consenting account to test against. Tell us the app — Sonali e-Wallet — and what you want out of it; we handle the rest. Start a conversation and we will scope it back to you.

Staying current as the app changes

Freshness depends on the route. Notification capture is close to live — an event lands as the app receives it. Balances and history are pulled on demand against the session, so they are as current as the moment of the call. Transfer status carries BEFTN's batch latency by design; we surface that honestly rather than report a settled state early.

Screens from Sonali e-Wallet

These are the app's own Play Store screens, useful for confirming which surfaces a build needs to cover. Tap to enlarge.

How this mapping was checked

This brief was put together on 2026-06-20 from the app's store listing and its stated feature set, the Bangladesh Bank payment-systems material on BEFTN and NPSB, and current reporting on the country's payment-law and data-protection changes. Primary references:

• Sonali e-Wallet on Google Play — feature list, operators, security model.
• Bangladesh Bank — BEFTN operating rules — batch clearing behavior.
• The Business Standard — bank-to-MFS transfers via NPSB — interoperability from November 2025.
• VDB Loi — Payment and Settlement Systems Act 2024 — licensing and oversight scope.

Mapped by the OpenBanking Studio integration desk, 2026-06-20.

Other Bangladeshi wallets in the same picture

Sonali e-Wallet shares its market with a crowded field of wallets and bank apps. A buyer aggregating Bangladeshi accounts usually wants several of these under one interface. Listed for context, not ranked.

• bKash — the market-leading MFS wallet, holding P2P transfers, payments and top-up history for a very large user base.
• Nagad — the Bangladesh Post-linked wallet, with money transfers, bill payments and mobile recharge records.
• Rocket — Dutch-Bangla Bank's mobile money service, an early entrant carrying transfer and bill-pay data.
• Upay — United Commercial Bank's wallet, covering transfers, payments and merchant transactions.
• CellFin — Islamic Bank Bangladesh's wallet, holding account-linked transfers and remittance receipts.
• Sonali eSheba — Sonali Bank's sibling app for account opening and government fee payments, a related record source.
• TallyPay — a wallet aimed at everyday transfers and merchant payments.
• Dmoney — a payment service carrying transfer and bill-payment activity.

Questions integrators ask first

If a transfer leaves over BEFTN instead of NPSB, can you still tell me whether it settled?

Yes. BEFTN settles in batch windows while NPSB moves in real time, so we model the two differently — a BEFTN transfer reads as pending until its batch clears rather than failed, and NPSB confirmations come back the same session. The integration reports a single normalized status either way.

Login wants a PIN and every transfer wants an OTP. Does that stop you building against the app?

No. We rebuild the two-step PIN session and the per-transfer OTP step exactly as the app performs them, using an account that consents to the work. OTP delivery is set up with that account holder when the project starts.

Who regulates this, and what is the legal basis for reading the account data?

Sonali e-Wallet sits under Bangladesh Bank's Payment Systems Department and the Mobile Financial Services Regulations. A Personal Data Protection Ordinance only reached the gazette in early 2026, so that framework is still settling; the dependable basis we rely on is the account holder's own documented consent, backed by logging, data minimization and an NDA where needed.

We only care about domestic BDT wallet activity — is that the whole scope?

That matches the app, whose own description limits it to domestic transactions. We scope the build to BDT domestic flows — balances, transfers, recharges, bills and DPS installments — and leave out cross-border rails the app does not carry.