Moving Nagad DSO wallet and settlement data into your back office

A Nagad DSO wallet sits one rung above the Uddokta agents it supplies, holding the e-money float those agents draw down for Cash-In and the B2B settlement traffic that flows up to Nagad's central Mother Wallet. A distributor running several DSO wallets ends up reading all of that off a phone screen and re-keying it into a spreadsheet at day's end. The integration work here is about getting the same float, settlement and statement records into a system you actually run — on a schedule, normalized, and reconcilable against your own books.

What a DSO wallet actually holds

Strip away the dashboard and the DSO app is really a handful of record sets, each described the way the app frames it.

Authorized routes into the DSO ledger

Three authorized paths reach those records. Which one fits comes down to how fresh the feed must be and how hands-off you want it.

Authorized interface integration / protocol analysis

We capture the DSO app's authenticated session against a consenting account and map the JSON calls behind balance, B2B transfer and statement views. This is the route that gives near-live float and full settlement detail. Access to a consenting DSO or distributor account is arranged with you during onboarding; the build runs against that account or a sponsor sandbox.

User-consented account operation

For an ongoing feed, we run scheduled pulls under a DSO login the distributor consents to and controls, with the session and scope held to the data you asked for. Durable as long as the login holds; it re-validates when the app ships a new build.

Native statement export

The daily statement is itself structured per-line, so where a lighter touch is enough we lift that export and normalize it for accounting. Lower effort, day-grained rather than real-time.

For a distributor that wants its float and settlements in its own ledger now, the first route is the one we would build on — it reaches every record set at the freshness reconciliation needs. The statement export stands on its own where the only goal is a clean nightly close. The national open-banking rail Bangladesh Bank is standing up will be the cleaner long-run path once it is issued, and we design so the move onto it is a swap of the data source, not a rebuild.

A balance-and-statement call, sketched

The shapes below are illustrative; exact paths and field names are confirmed during the build, and every call runs only against a consenting DSO or distributor account.

# 1) Establish a session with the login PIN (the transaction PIN is never used for reads)
POST /dso/v1/session
  { "msisdn": "8801XXXXXXXXX", "login_pin": "******" }
  -> 200 { "access_token": "...", "expires_in": 900, "dso_wallet_id": "..." }

# 2) Read current float
GET /dso/v1/wallet/balance
  Authorization: Bearer <access_token>
  -> 200 { "wallet_id": "...", "available": "152340.50",
           "currency": "BDT", "as_of": "2026-06-20T09:05:00+06:00" }

# 3) Pull the B2B settlement statement for a date range
GET /dso/v1/statement?from=2026-06-01&to=2026-06-20&type=b2b
  Authorization: Bearer <access_token>
  -> 200 { "lines": [
             { "ts": "...", "amount": "-25000.00", "counterparty": "mother_wallet",
               "ref": "...", "status": "SUCCESS" }, ... ],
           "page": 1, "has_more": true }

# Error handling we wire in:
#   401 -> token expired, re-establish session and retry once
#   429 -> back off and respect throttling; page with has_more, never hammer

What lands when the build is done

At hand-off you get a working integration, not a slide deck. For the DSO surfaces above that means:

• An OpenAPI / Swagger spec covering the session, balance, B2B-transfer and statement calls.
• A protocol and auth-flow report documenting the PIN login to session-token chain and how reads stay clear of the transaction-PIN step.
• Runnable source for the key endpoints in Python or Node.js — the float read and the statement pull, ready to schedule.
• Automated tests against the consenting account or sandbox, including token-expiry and pagination paths.
• Interface documentation mapping each statement line to its fields, plus a normalized JSON/CSV schema.
• Data-retention and consent guidance fitted to BFIU expectations and the PDPO 2025 consent rules.

What we account for in the build

A few things specific to this app shape how we put it together.

• Nagad uses PIN in two phases — one for login, one for each transaction (as Nagad describes its consumer flow). We model the session so reads ride the login leg only and never trip a transaction confirmation, which keeps live float untouched.
• The DSO is a middle layer in a three-app hierarchy. We map the DSO-to-Mother-Wallet B2B leg separately from the DSO-to-Uddokta balance transfers, so a settlement and an agent top-up are never merged in the normalized output.
• The app updates periodically (version 1.0.32.01, refreshed April 2025 per its AppBrain listing). When a new build ships we re-run the capture and patch the field maps as part of maintenance, so the feed does not quietly break.
• We keep pulls consent-scoped and logged and hold the data to the balance and statement fields, which is the posture BFIU AML/CFT and KYC supervision expects of anyone handling MFS records.

Consent, BFIU rules and Bangladesh's data law

Mobile money in Bangladesh runs under a defined set of rules, and the integration is built to fit them rather than around them. Bangladesh Bank's MFS Regulations govern the service itself; BFIU circulars set the AML/CFT, KYC and data-security expectations that anyone touching agent and distributor records has to honour. The Personal Data Protection Ordinance 2025 — approved in October 2025 and gazetted in November 2025, with full enforcement expected around 2027 per The Daily Star — makes explicit, specific, informed consent the basis for processing personal data, with a right to withdraw. We work from a consent record the distributor controls, scope the pull to the fields agreed, log access, and sign an NDA where the engagement needs one. A national open-banking API protocol is still being stood up by Bangladesh Bank, so it is not something to depend on today; the dependable basis is the distributor's own authorization, and we design the consent flow so it can map onto the open-banking rail later without re-papering.

Where distributors put this data

Distributors tend to want this feed for a few concrete jobs:

• Nightly float reconciliation — close each DSO wallet against the day's B2B settlements automatically, no manual statement reading.
• Liquidity alerting — watch float against agent Cash-In demand and warn before a wallet runs short.
• Settlement assurance — match every Mother Wallet transfer to an expected amount and flag the gaps same-day.
• Agent roll-up — aggregate Uddokta balance transfers into one performance view across a territory.

Screens we worked from

The app screens below are what the DSO flows look like in practice. Tap to enlarge.

Other MFS apps in the same settlement web

Bangladesh's mobile-money market is crowded, and the DSO layer touches several neighbours a unified integration would cover together. Names are listed for context, not ranked.

• bKash — the largest MFS wallet in the country; holds consumer balances and send-money, cash-in and cash-out records.
• bKash Agent — the agent-facing companion app; holds agent float and per-transaction logs.
• Rocket — Dutch-Bangla Bank's MFS, one of the oldest; carries wallet balances and bank-linked transfers.
• Upay — United Commercial Bank's MFS, with wallet balances, bill pay and merchant flows.
• SureCash — used for disbursements and education-fee collection; holds account ledgers.
• tap (Trust Axiata Pay) — MFS wallet with P2P and merchant payment records.
• Islami Bank mCash — a bank-operated MFS with wallet balances and transfers.
• Nagad Uddokta — Nagad's agent app for cash in/out and customer onboarding; the layer the DSO supplies.
• Nagad Distributor — Nagad's distributor app for the upstream B2B leg with DSO wallets.

What we checked, and where

We worked from primary sources, dated below. The app's role and record sets come from its Play Store and AppBrain listings; the regulatory picture from Bangladesh Bank's own MFS guideline, contemporary reporting on the open-banking timeline, and coverage of the Personal Data Protection Ordinance 2025. Checked June 2026.

• Nagad DSO listing (AppBrain) — package, version, functions
• Bangladesh Bank — Guidelines on Mobile Financial Services (PDF)
• The Business Standard — Bangladesh's open-banking plans
• The Daily Star — Personal Data Protection Ordinance 2025 takeaways

Field notes from the OpenBanking Studio integration desk · June 2026.

Questions distributors ask

Can a DSO wallet's float and B2B settlements be read without touching live cash-in operations?

Yes. Reads are scoped to the balance and statement endpoints and run on a consenting DSO or distributor account using the login session only, so no transaction-PIN action fires and the live float is left as-is.

How is the DSO layer's data different from the Nagad Uddokta and Distributor apps?

The DSO sits between the distributor and the Uddokta agents it supplies. Its wallet records B2B transfers with the central Mother Wallet and balance transfers down to Uddoktas, whereas the Uddokta app holds customer cash-in and cash-out and the Distributor app holds the upstream B2B leg. We model the three layers separately so a B2B settlement is never conflated with an agent top-up.

Which Bangladeshi regulator and rules apply to this kind of integration?

Mobile financial services sit under Bangladesh Bank's MFS Regulations and BFIU AML and CFT and KYC circulars, with the Personal Data Protection Ordinance 2025 setting consent rules as it phases in. A national open-banking API is still being stood up, so the dependable basis today is the distributor's own authorization, logged and data-minimized.

Does the daily statement come out structured enough to reconcile automatically?

The statement is line-itemized by timestamp, amount, counterparty and status, which is enough to normalize into JSON or CSV and post against your own ledger. We hand back the field map and a runnable pull so nightly reconciliation runs without re-keying from the phone.

Delivery runs a one-to-two-week cycle. Source-code delivery starts at $300, billed only after the integration is in your hands and working to your satisfaction; or skip the build fee entirely and call our hosted DSO endpoints, paying only for the calls you make. Tell us the app name and what you need from its data on our contact page and we'll scope it.