Pulling statements and balances out of Nagad

Every Nagad balance, Send Money line and monthly statement lives behind a four-digit PIN and a server-side account tied to the holder's national ID. None of it crosses to another wallet on its own. Customer transactions across Bangladesh's mobile-money services topped Tk 17 lakh crore in 2024 by Bangladesh Bank's MFS figures, yet a single Nagad ledger still cannot be read by an outside system without a deliberate integration. That gap is the work this page is about.

Nagad runs as the Digital Financial Service of the Bangladesh Post Office. For a finance team, a remittance partner, or a lender doing affordability checks, the value sits in the account record: who paid whom, when, how much, and the running balance. We get that record out under the account holder's authorization and hand back something you can run.

The bottom line: most of what an integrator wants is in the Statement view and the balance check, both behind the login. We would read those through a consented interface integration, normalize the fields, and keep the periodic statement export on hand as a cross-check. The detail follows.

What sits behind the Nagad PIN

These are the surfaces the app actually exposes to a logged-in user, named the way Nagad names them. Each maps to a data domain a third party would want to read.

Reaching it with authorization

Three routes genuinely apply to Nagad. We arrange the access each one needs together with you during onboarding; none of it is something you have to assemble before we begin.

Consented interface integration

We analyze the app's own traffic under the account holder's authorization, map the PIN login and token chain, and read the statement, balance and history endpoints the way the app does. Reach is wide: anything the user can see, we can return. Effort is medium because the auth flow and field shapes have to be worked out against a live, consenting account. Durability is good with light upkeep when the app front end changes. This is the route we lean on for reading an account.

Native statement export

Nagad produces account statements, both in-app and as downloadable records. We parse those into structured rows. Effort is low and it needs nothing fancy. The trade-off is freshness: an export is a batch snapshot, not a live feed, so we treat it as a reconciliation check against the interface read rather than the primary source.

Binimoy / IDTP participation

Binimoy, the country's interoperable digital transaction platform, settles real-time movement between participating banks, MFS and PSPs. Where your project actually needs to move money rather than read it, an authorized participant integration on this rail is the durable path, and we handle the participant onboarding with you. It does not read someone else's statement, so it complements the interface route rather than replacing it.

For a team that wants Nagad's account history and balance, the consented interface route is the one that returns it, checked against the statement export; Binimoy only earns its place once live money movement is in scope. We would tell you which of the three fits before any code is written.

What lands at handover

The deliverable is a working integration for Nagad's surfaces, not a slide deck. A typical package:

• An OpenAPI/Swagger specification covering the balance, statement and history calls as a clean, documented contract.
• A protocol and auth-flow report: the PIN login, token issue and refresh, and session handling, written up so your team can maintain it.
• Runnable source for the key endpoints in Python or Node.js — statement pull, balance read, Send Money history — with the Bangla-to-canonical normalization built in.
• Automated tests against recorded responses so a Nagad app update that shifts a field is caught early.
• Interface documentation, plus data-retention and consent-logging guidance fitted to Bangladesh Bank's MFS conduct rules.

A statement read, sketched

Illustrative only. Endpoint paths and field names are confirmed against a live, authorized account during the build; this shows the shape of the read, not a fixed contract.

# Consented Nagad statement pull. The PIN is entered by the
# account holder during the consent flow and never stored by us.
import requests
session = requests.Session()
BASE = "https://app.nagad.example"        # resolved during traffic analysis

def login(msisdn, device_id):
    r = session.post(f"{BASE}/auth/login", json={
        "mobileNumber": msisdn,
        "deviceId": device_id,
    })
    r.raise_for_status()
    # ... PIN challenge exchanged inside the consent flow ...
    return r.json()["accessToken"]

def statement(token, frm, to):
    r = session.get(f"{BASE}/account/statement",
        headers={
            "Authorization": f"Bearer {token}",
            "Accept-Language": "en",        # force English-keyed fields
        },
        params={"from": frm, "to": to})
    r.raise_for_status()
    for tx in r.json()["transactions"]:
        yield {
            "ts":      tx["transactionDate"],
            "type":    tx["serviceType"],       # SEND_MONEY, ADD_MONEY, BILL_PAY ...
            "amount":  to_decimal(tx["amount"]),     # Bangla numerals normalized
            "counter": tx.get("counterPartyNumber"),
            "ref":     tx["transactionRefId"],
            "balance": to_decimal(tx["availableBalance"]),
        }

Where teams use this

• A digital lender reads three months of statement and Send Money history, with consent, to score a thin-file borrower who banks only on Nagad.
• A remittance house reconciles its payouts against the recipient's Add Money and remittance-receipt records to confirm funds landed.
• An SME bookkeeping tool imports a merchant's QR-payment and bill-pay lines so the owner stops keying them by hand.
• An employer running stipend or salary disbursement matches its outbound batch to recipients' incoming records and flags failures.

Consent and the Bangladesh Bank rulebook

Nagad operates under Bangladesh Bank, which licenses and supervises mobile financial services through the MFS Regulations of 2022, with payment-system licensing now resting on the Payment and Settlement Systems Act, 2024. There is no consumer-facing open-banking mandate that forces an account-data API here, and Bangladesh has no comprehensive data-protection statute in force yet — a Personal Data Protection Act has been under draft. So the dependable basis for a read is the account holder's own written authorization, alongside Bangladesh Bank's conduct rules on customer data.

We work to that basis. Access is authorized and logged, consent records are kept, scope is limited to the fields a project actually needs, and an NDA covers the engagement where you want one. Consent is revocable, and we wire revocation into the sync so a withdrawn authorization stops the feed.

What we plan around on Nagad

A few specifics shape the build, all of which we handle rather than hand back to you:

• Nagad demands a PIN at login and again on every money-moving action. We keep the statement sync strictly read-only so it uses the login session alone and never touches the transaction PIN, and we manage the session-refresh window so a long-running feed does not quietly expire.
• The app is bilingual and statements render in Bangla or English. We normalize Bangla numerals, date formats and biller strings into one English-keyed schema, so a downstream system never has to branch on language.
• Nagad Islamic is a separate Shariah interface selected inside the app. We detect which interface an account uses and map both to the same schema, so an integrator gets one shape instead of two.
• Limits and visible fields differ by DKYC tier, since onboarding via NID and selfie sets the account level. We scope the integration per tier so a partially verified account's missing fields are handled, not assumed present.

Screens we mapped against

The published app screens, for reference on the surfaces named above. Select one to enlarge.

How this brief came together

Checked in June 2026 against the Play Store listing for com.konasl.nagad, Nagad's own limits-and-charges page, Bangladesh Bank's MFS regulation, and reporting on the Binimoy interoperability rail. Where a detail is not public — the live endpoint paths, exact field names — the page says so and the build confirms them against an authorized account. Sources:

• Nagad — overview, Bangladesh Post Office, DKYC and remittance partners
• Bangladesh Bank — Mobile Financial Services Regulations, 2022
• The Daily Star — launch of the Binimoy interoperable transaction platform
• Nagad — limits and charges

Mapped by the OpenBanking Studio integration desk · June 2026.

Other wallets on the same rails

Same market, comparable account records — useful if you need one integration spanning several Bangladeshi wallets rather than Nagad alone.

• bKash — the largest MFS provider in the country; holds the same balance, Send Money and statement records at scale.
• Rocket — Dutch-Bangla Bank's mobile money service, with cash-in/out and transfer history tied to a bank.
• Upay — United Commercial Bank's wallet, covering transfers, bill pay and merchant payments.
• Tap (Trust Axiata pay) — operated by Trust Axiata Digital; wallet balances and transaction logs.
• mCash — Islami Bank's Shariah-based MFS, serving account-linked transfers and bill pay.
• OK Wallet — One Bank's MFS brand for transfers, top-ups and payments.
• SureCash — an open mobile-payment platform used for disbursements and bill collection.
• TallyKhata — a wallet and bookkeeping app participating in the IDTP interoperability rail.

Questions integrators ask about Nagad

Can you pull a full Nagad statement, or just the current balance?

Both. The consented interface route returns the same per-transaction statement and monthly summary the Statement screen shows, plus the one-tap balance, normalized to a clean schema. You are not limited to a single figure.

Nagad asks for a PIN on every transaction. How does that affect a read-only sync?

A statement read uses the login session, not the per-transaction PIN, which only guards money movement. We build the sync read-only so it never initiates a transfer, and we handle session refresh so the feed keeps running instead of dropping silently.

Statements render in Bangla or English depending on app language. Which do we get?

One canonical, English-keyed schema. We normalize Bangla numerals, date formats and biller names so a downstream system gets consistent fields no matter which language the account holder reads the app in.

Does Binimoy or IDTP let us reach a Nagad account through one cross-wallet endpoint?

Binimoy is an interoperable settlement rail for moving money between participating banks, MFS and PSPs, not a read interface for another person's statement. For reading an account's history and balance, the consented interface route is what returns it.

Starting a Nagad build

You give us the app name — Nagad — and what you need from its data. We do the rest: route choice, access arranged with you, and the build itself, on a one-to-two-week cycle. Source-code delivery starts at $300; you get runnable source plus docs and pay only after delivery, once it works as described. Prefer not to host it? Call our endpoints and pay per call, with nothing upfront. Tell us what you are after on the contact page and we will scope it.