Reaching NBP Digital balances, statements and transfer history

National Bank of Pakistan moved a large chunk of its retail relationship into one app, and that app is where the data lives: a customer logs in with an MPIN or biometrics and sees live balances across one or more linked accounts, statements for the last 30, 60 or 90 days, and a transfer ledger spanning IBFT, IBAN and CNIC payments. For a fintech building account aggregation, a lending underwriter pulling a cash-flow history, or a finance product that wants a verified balance, that authenticated view is the target. This brief sets out what is reachable inside NBP Digital, the authorized way to reach it, and what we hand over.

The short version: Pakistan now has a published open banking framework and an SBP sandbox, and NBP has invested in an API layer of its own, so consent-based access is the route the work is built against — with protocol analysis of the app's own traffic as the dependable way to cover any scope a licensed channel does not yet expose. We recommend treating the SBP-aligned consent path as the channel you put in front of customers, and the traffic-analysis build as how we make the same balance and statement scopes work end to end while that channel matures. That choice is explained below, not asserted.

What sits behind the login

The surfaces below map to features the app itself advertises. Granularity reflects what a real session exposes; field-level detail is confirmed during the build against a consenting account or sandbox.

Authorized routes to the data

Three routes apply to NBP Digital. They are not mutually exclusive — most builds run one as the customer-facing channel and lean on another to cover the gaps.

Consent-based account access (SBP-aligned)

The State Bank of Pakistan has published an open banking framework and operates a regulatory sandbox, and NBP has built API infrastructure as part of its modernization. Where a consent-based channel is available for the scope you need, this is the cleanest path: explicit customer consent, scoped access to balances and statements, an audit trail the regulator expects. Durability is high because it tracks the regime. We handle the sandbox onboarding and consent wiring with you during the engagement.

Protocol analysis of the authenticated app

For any scope a licensed channel does not yet cover, we map the app's own authenticated traffic — the login and OTP/device-binding handshake, the token it carries, and the request shapes behind balance, statement and transfer screens — and reimplement those calls under your authorization. This reaches everything the app itself can see. It needs a re-validation pass when NBP ships a front-end change, which we account for in maintenance.

User-consented credential access and native export

The app emails statements and exports the 30/60/90-day window. With a consenting account holder, that export is a low-effort fallback for one-off statement pulls or for backfilling history before a live sync goes in. It is narrow, but it is reliable and needs no reverse engineering.

What we hand over

Every deliverable is tied to NBP Digital's real surfaces, not a generic banking template.

• OpenAPI/Swagger spec covering the endpoints we implement — login/session, balance, statement query by window, transfer history, beneficiaries — with request and response schemas.
• Protocol & auth-flow report documenting the MPIN/biometric login, the OTP and device-binding step the app uses for security, and the token/cookie chain that authorizes each call.
• Runnable source for the key endpoints in Python and Node.js — a working client that logs in, pulls a statement window, and returns normalized records.
• Normalized schema that folds IBFT, IBAN, CNIC and Raast transfer lines into one record shape so NBP data reconciles against other banks.
• Automated tests against captured fixtures, plus interface documentation and data-retention guidance aligned to SBP expectations.

A statement pull, sketched

Illustrative only — field names and the exact auth chain are confirmed during the build against a consenting account.

POST /digital/session/login
  { cnic, account_iban, mpin, device_id }   # device-binding + OTP per app security
  -> 200 { session_token, accounts: [{ iban, type: "conventional|islamic" }] }

GET /digital/statement?iban=PK..&window=90
  Authorization: Bearer <session_token>
  -> 200 {
       account_iban, window_days: 90,
       lines: [
         { posted, description, amount, dr_cr,
           channel: "IBFT|IBAN|CNIC|RAAST|BILL",
           counterparty_iban, counterparty_bank, ref }
       ]
     }

# normalize: map channel + ref so a Raast credit here reconciles
# against the same payment seen from the sending bank
on 401 -> refresh_session(); on 423 -> device re-bind required

Consent, the SBP, and how access is handled

The governing regime is the State Bank of Pakistan's open banking framework, backed by its regulatory sandbox — the consumer's explicit consent is the dependable basis for any access, scoped to the data set in use and revocable. We build to that: consent is recorded, access is scoped to the agreed domains, and we minimize what is pulled to what the use case needs. Where reverse engineering of the app's interface is used to cover a scope, it runs under your written authorization, the work is logged, and an NDA covers anything sensitive. Pakistan's data-protection rules are still maturing, so we default to data minimization and short retention rather than holding raw statement data longer than the use case requires.

Engineering notes we plan around

• Device binding and OTP. The app binds to a device and gates login with an OTP, so a client that re-authenticates from a new context triggers a re-bind. We design the session layer to hold and refresh the bound token cleanly rather than re-binding on every run.
• Conventional vs Islamic accounts. NBP Digital serves both conventional and Aitemaad Islamic account holders, and statement and profit lines read differently. We tag account type at extraction so a Mudaraba-based Islamic account is not flattened into a conventional model.
• Multi-account linkage. A single user can add multiple accounts. We key every record to its IBAN so balances and statements stay separated per account instead of being summed blindly.
• Raast/IBFT reference mapping. Transfers carry rail-specific references. We map them into one reconciliation key so a payment is matchable from both ends, which is the part most off-the-shelf parsers get wrong.

Where this gets used

• An aggregator showing a customer's NBP balance alongside other Pakistani banks in one view.
• A lender pulling a 90-day NBP statement to underwrite cash flow instead of asking for a PDF.
• A merchant platform confirming a Raast or IBFT payout landed, by reading the transfer record directly.
• A bookkeeping tool syncing categorized NBP transactions nightly into its ledger.

How we engage

Delivery on NBP Digital runs in a 1–2 week cycle once the target scope is set. You can take it two ways. Under source-code delivery, priced from $300, we build the integration and hand over the runnable client, the OpenAPI spec, tests and the protocol report — and you pay after delivery, once you have confirmed it does what you need. Under the pay-per-call model, you skip the build entirely and call our hosted endpoints, paying only for the calls you make, with no upfront fee. Tell us the app and what you want out of its data and we scope it — start the conversation here. Access, sandbox onboarding and any authorization paperwork are arranged with you as part of the work.

App screens

What was checked

Surfaces were read from the app's own Play and App Store listings and NBP's digital product pages; the regulatory picture from the State Bank of Pakistan and the open banking tracker; the payment-rail detail from SBP's Raast page and 1LINK's API catalogue; and NBP's own API work from Google Cloud's case study. Checked June 2026 against these primary sources:

• NBP Digital product details (nbp.com.pk)
• State Bank of Pakistan — Raast instant payment system
• How APIs help NBP modernize banking (Google Cloud)
• 1LINK Open API Gateway — sandbox product catalogue

Mapped June 2026 by the OpenBanking Studio integration desk.

Other Pakistani banking apps in the same picture

Useful context for anyone building one integration across the market. Named neutrally; each holds comparable account data behind its own login.

• HBL Mobile — Habib Bank's app; balances, bill payments and transfers for a large retail base.
• UBL Digital — United Bank's app; accounts, cards and online payments.
• Meezan Bank — Shariah-compliant banking app; Islamic account statements and transfers.
• Bank Alfalah (Alfa) — accounts, transfers and a wallet layer in one app.
• JazzCash — mobile wallet with bank-account, CNIC and bill flows.
• Easypaisa — wallet-turned-digital-bank with a wide payments footprint.
• Raqami — licensed Islamic digital bank with current, savings and term products.
• Mashreq — digital-first bank operating in the same consent regime.

Questions integrators ask

Which NBP Digital surfaces actually hold queryable data?

The authenticated account view: live balance for one or more linked NBP accounts, the 30/60/90-day statement, the beneficiary list, debit card status and the transfer history behind IBFT, IBAN and CNIC payments. These are the surfaces an aggregator or a finance tool would sync.

Does the State Bank of Pakistan open banking framework cover a transfer like this?

The SBP published an open banking framework and runs a regulatory sandbox, and NBP itself has built out an API layer, so consent-based account access is the regime the integration is designed against. Where a sandbox or licensed channel is not yet open for a given data set, the same scopes are reached by protocol analysis of the app's own authenticated traffic under your authorization.

How do Raast and IBFT identifiers show up in the data we get?

Transfers in NBP Digital route over IBFT (1LINK) and Raast (SBP), so a statement or transfer record carries IBAN, the counterparty bank, and Raast/IBFT reference fields. We normalize those into one schema so a payment in NBP reconciles against the same record seen from another bank.

Can you separate conventional and Islamic (Aitemaad) account data?

Yes. NBP Digital registers both conventional and Islamic account holders, and the product type changes how profit and statement lines read. We tag account type during extraction so downstream logic treats a Mudaraba-based Islamic account correctly rather than flattening it into a conventional model.