Reaching the float ledger and cash flows inside Nagad Uddokta

Nagad runs cash through more than 300,000 Uddokta agent points, per the company's published agent-network figures, and every one of them keeps a running float balance that the agent app reconciles as money moves. That float, plus the per-transaction record sitting behind it, is the thing a distributor house, a reconciliation team, or an agent-management platform actually wants in its own system. The Uddokta app is where an agent takes cash in, pays cash out, registers a new customer, settles with a Distribution Sales Officer, and runs bill payments and recharges. All of it lands as server-side state under one agent login.

The route we would actually take is protocol analysis of the agent app's own session, run against an Uddokta account whose holder has authorized the work. That mirrors what the agent already sees on screen, so the data maps cleanly, and it does not depend on any one settlement rail being exposed. Native statement export is a fallback when an auditor wants the same numbers as a download. Below is the data, the routes, what we hand over, and how the engagement runs.

What the Uddokta app keeps server-side

Each row below is a surface the agent app genuinely exposes to its logged-in user. Field names follow how the app presents them where we could confirm it.

Authorized ways into the agent data

Three routes apply here. Access and onboarding are arranged with you during the engagement; none of this is something you need to have lined up before we start.

Consented agent-account access

We operate against a live Uddokta account whose holder consents to the work. This is the cleanest path for an agent or distributor who simply wants its own float and transaction history flowing into a back office, because the data we read is the data that account already owns. Effort is moderate; durability is good as long as the login and session model hold.

Protocol analysis of the app session

We map the agent login challenge, the bearer-token refresh, and the transaction-history and balance calls the app makes. This produces the schema and the auth flow the integration runs on, and it is what keeps field names stable when Nagad ships a new build. We set up the capture environment and the authorized test account as part of onboarding.

Native statement reconciliation

Where the app or the agent portal offers a downloadable statement, we wire that as a periodic export so your auditors can match the synced numbers against a paper trail. Lower fidelity than the live ledger, but it earns its place when a compliance team wants both.

If you run a distributor network and want every agent's float and transaction history in one place, we would build the consented-account route first because it reflects exactly what an agent already sees, then lean on the protocol map to keep the field mapping intact across app releases. The statement export only goes in when an audit needs the same figures in downloadable form.

Inside one agent-ledger call

Illustrative shape of the work, not a published contract. The exact paths and field names are confirmed against a consenting Uddokta session during the build.

# Field names below are confirmed during protocol mapping, not from any spec.
import requests

BASE = "https://api.example-agent-host"   # real host resolved while mapping the session

def agent_session(msisdn, pin, device_id):
    # Agent login is a multi-step challenge: device check, PIN/OTP,
    # then a short-lived bearer token.
    r = requests.post(f"{BASE}/agent/v1/login",
                      json={"msisdn": msisdn, "pin": pin, "deviceId": device_id})
    r.raise_for_status()
    return r.json()["accessToken"]

def ledger(token, frm, to, cursor=None):
    r = requests.get(f"{BASE}/agent/v1/txn/history",
                     headers={"Authorization": f"Bearer {token}"},
                     params={"from": frm, "to": to, "cursor": cursor})
    r.raise_for_status()
    page = r.json()
    for txn in page["transactions"]:
        # type: CASH_IN | CASH_OUT | DSO_TRANSFER | BILL_PAY | RECHARGE
        yield {
            "id": txn["txnId"],
            "type": txn["type"],
            "amount_bdt": txn["amount"],
            "fee_bdt": txn.get("fee", 0),
            "counterparty": txn.get("customerMsisdn") or txn.get("dsoMsisdn"),
            "balance_after": txn["agentBalanceAfter"],
            "at": txn["timestamp"],
        }
    if page.get("nextCursor"):            # history is capped per request, so we page
        yield from ledger(token, frm, to, page["nextCursor"])
      

Two things shape the real implementation: the token is short-lived, so a long backfill re-authenticates mid-run, and history is returned in capped pages, so the ledger is walked with a cursor rather than a single pull.

What lands in your repository

• An OpenAPI / Swagger spec for the agent endpoints we map — login, balance, transaction history, registration status, DSO transfer.
• A protocol and auth-flow report covering the login challenge, the bearer-token refresh, device binding, and the paging model.
• Runnable source for the key endpoints in Python or Node.js, including the float reconciliation and ledger-walk shown above.
• Automated tests against recorded responses, so a Nagad app update that changes a field is caught by a failing test, not by a silent gap in your data.
• Interface documentation a developer who has never seen the app can build against.
• Data-retention and consent-handling guidance written for an MFS agent context, including how the STR/SAR surface is kept out of scope by default.

Typical jobs this feeds

• A distributor house pulling every agent's daily float, commission and cash movements into its own ERP each night.
• A reconciliation routine matching cash-out records against the bank settlement leg where the payout clears over NPSB.
• An onboarding dashboard tracking customer-registration volume and KYC status per agent, so a DSO can see where sign-ups stall.

The rulebook this sits inside

Nagad operates under Bangladesh Bank. Mobile financial services in Bangladesh are governed by the Bangladesh Bank Mobile Financial Services Regulations of 2022, and Nagad has since received the country's first full-fledged digital-bank licence (reported June 2024) as it moves toward Nagad Digital Bank PLC. There is no single enacted general data-protection statute in Bangladesh as of this writing, so the controls that matter here are sectoral: Bangladesh Bank's MFS and ICT-security rules, and the AML/CFT obligations the BFIU enforces.

The dependable basis for our work is the agent account holder's own authorization to access the data their account already holds. Consent scope is set to the specific surfaces a job needs — float and ledger, say, not the STR/SAR flow — and is bounded by the session model, which expires and can be withdrawn. We minimize: NID-linked registration data and any suspicious-transaction material are excluded unless deliberately scoped in. Access is logged, records are kept, and we sign an NDA where the work touches customer identity data. That is how we operate, not a checklist you have to satisfy before we begin.

Edge cases we plan around

• The DSO-to-agent-to-customer hierarchy is easy to mis-count: a balance received from a Distribution Sales Officer is a float top-up, not a customer cash-in. We tag transaction types explicitly so float, commission and customer movements never collapse into one number.
• The agent session token is short-lived. We design the nightly float-and-ledger sync to re-authenticate cleanly mid-run so it does not silently stop part way through a backfill.
• STR and SAR submissions are reportable AML material headed for the BFIU. We hold that surface read-only and out of any default export, and gate it behind an explicit compliance decision with access logging.
• Transaction limits and rates move — the per-day agent cash-in and cash-out ceilings were adjusted in early 2025 — so we treat limit and fee values as data to read, never as constants baked into the code.

What moves, and how we keep up

Two forces change this app from underneath an integration. Nagad ships new app builds, which can rename fields or alter the login steps; and Bangladesh Bank has been moving all MFS providers onto the interoperable Bangla QR standard, with deadlines and penalties attached, which shifts the QR payloads the app reads and writes. We keep a re-validation check that compares live responses against the mapped schema and flags drift before a sync breaks, and the protocol map means re-pointing the integration is a small job rather than a rebuild.

How a build is priced

Runnable source for the agent-ledger and cash-flow endpoints lands in your repository from $300, billed only after delivery once you have run it and you are satisfied — that is the source-code model, and it is yours to host. If you would rather not run anything, the second model is a hosted API: you call our endpoints for Nagad Uddokta and pay per call, with no upfront fee. A typical build runs one to two weeks. Tell us the app name and what you want out of its data, and we arrange access, the test account and any compliance paperwork with you. Start the conversation on the contact page.

Screens we worked from

What we checked

This mapping was put together on 2026-06-26 from the app's own Play Store listing and description, Bangladesh Bank's MFS regulation, press coverage of Nagad's digital-bank licence, the central bank's Bangla QR directive, and the BFIU's suspicious-transaction reporting guidance. Sources we opened:

• Nagad Uddokta on Google Play
• Bangladesh Bank — Mobile Financial Services Regulations, 2022 (PDF)
• The Daily Star — banks and MFS providers must adopt Bangla QR
• BFIU / Bangladesh Bank — Guidance on Reporting Suspicious Transactions (PDF)

OpenBanking Studio · agent-app mapping, June 2026.

Other Bangladeshi wallets in the same picture

An agent or distributor rarely runs only one wallet, so a unified back office usually has to read several of these. Listed for ecosystem context, not ranked.

• bKash — the largest MFS in Bangladesh; holds customer wallet balances, send-money and merchant-payment history.
• bKash Agent — the agent-side counterpart, with the same float and cash-in/cash-out ledger shape we map for Uddokta.
• Rocket — Dutch-Bangla Bank's mobile banking service, holding wallet and bank-linked transfer records.
• Upay — UCB-backed MFS with wallet balances, bill pay and merchant transactions.
• NexusPay — Dutch-Bangla Bank's cardless app spanning bank cards and Rocket accounts.
• GPAY — Grameenphone's payment app for recharges, bills and ticketing.
• iPay — an online payment service with send-money, withdrawal and bill-payment records.
• tap — Trust Axiata's MFS, holding wallet and transfer history.
• Dmoney — a payment platform with wallet and settlement data.

Questions integrators ask about Uddokta

Can you keep agent commission and DSO float movements separate from customer cash-in/cash-out records?

Yes. We model the DSO-to-agent-to-customer hierarchy explicitly so a balance received from a Distribution Sales Officer is tagged as a float top-up, not counted as a customer cash-in. Each ledger row carries its transaction type, counterparty MSISDN and the agent balance after, so commission, float and customer movements stay reconcilable.

Does the data line up with the Bangla QR and NPSB rails the Uddokta app touches?

Where a cash-out or merchant payment settles over the National Payment Switch Bangladesh or a Bangla QR acceptance, we map the reference fields the app records so your records can be matched against the interoperable settlement leg. Bangladesh Bank has been pushing all MFS providers onto Bangla QR, so we keep the QR payload parsing under a check for when the format shifts.

The Uddokta app can file STR and SAR reports. Is that data in scope?

We treat the suspicious-transaction surface as read-only and minimized. STR and SAR material is reportable AML data filed to the BFIU through goAML, so we keep it out of any export unless your compliance team scopes it in deliberately, and access to it is logged.

Nagad now holds a digital-bank licence. Does a back-end change break the integration?

It can. Nagad received Bangladesh's first full-fledged digital-bank licence in 2024 and is moving toward Nagad Digital Bank PLC, which means endpoints and auth steps may be re-platformed over time. The protocol map we hand over is what lets us re-point the integration quickly rather than rebuild it, and a re-validation check flags drift before a sync breaks.