Reaching Pubali Bank account data behind the PI Banking login

Behind a PI Banking login sits a Pubali Bank core-banking account: real-time statements, interbank transfer history across three different rails, utility and credit-card bill records, cheque status, and card management. The app is the mobile financial service of Pubali Bank PLC, and the transactional state a partner would want to query lives on the bank's side, not on the handset. Our job is to turn that authenticated surface into something a system can call.

The route we would actually run here is account-holder-consented session integration: we work from a consenting customer's own access, observe how the app authenticates and how it requests statements and transfer history, and rebuild those calls as a clean, documented interface. It does not depend on a national open-banking standard being live, and it slots onto one when Bangladesh Bank publishes it.

What PI Banking actually holds

Each row below is a surface the app exposes to its own user. Granularity reflects what the screens and the listing describe, not a guess at the core-banking schema.

Session and statement call, as we rebuild it

This is illustrative — the exact field names and auth handshake are confirmed during the build against a consenting account, not asserted here. The pattern is a token-bound session followed by a statement query, with the transfer rail carried through so downstream code can reconcile it.

POST /pi/session            # establish consented session
  body: { device_id, credential_ref }
  -> 200 { session_token, otp_required: true }

POST /pi/session/verify     # OTP step, as the app prompts
  body: { session_token, otp }
  -> 200 { access_token, expires_in }     # short-lived; we re-auth, not retry blind

GET  /pi/account/statement?from=2026-05-01&to=2026-05-31
  headers: { Authorization: Bearer  }
  -> 200 {
       account: "****1234",
       entries: [
         { ts, amount, dr_cr, balance, channel, rail }   # rail: NPSB | BEFTN | RTGS | INTERNAL
       ]
     }

# error handling we wire in:
#  401 -> token expired mid-pull -> silent re-auth, resume cursor
#  429 -> back off; statements are paged by date window, not offset

What lands on delivery

For PI Banking the package is built around the statement and transfer surfaces above:

• An OpenAPI/Swagger spec describing the session, statement, transfer-history and bill-pay calls as a clean interface.
• A protocol and auth-flow report — the token/OTP session chain as it actually behaves, including expiry handling.
• Runnable source for the key endpoints in Python or Node.js, with the NPSB/BEFTN/RTGS rail field normalized.
• Automated tests against a consenting account or a sandbox, covering the re-auth and paging cases.
• Interface documentation plus data-retention and consent-logging guidance fit for Bangladesh Bank's posture.

If you only need the data, not the code, the same surfaces are exposed as a hosted endpoint you call.

Reaching the data — the routes that fit

Account-holder-consented session integration

Working from a consenting customer's own access, we map how PI Banking signs in and how it pulls statements and transfers, then rebuild those as a stable interface. Reachable: everything the user sees. Effort: moderate, mostly in the OTP/token lifecycle. Durability: good, with a parser check for front-end changes. We arrange the consenting test account with you during onboarding.

Protocol analysis of the app's traffic

Where a screen does something the consented session does not cleanly expose — the QR and Cash-by-QR payloads, for instance — we analyze the documented traffic under your authorization to specify that flow precisely. This pairs with route one rather than replacing it.

Native statement view as fallback

PI Banking shows real-time statements and a configurable recent-transaction list on the device. Where a structured pull is constrained, that view is a backstop for low-frequency reconciliation.

For most partners the consented session is the one to build on: it covers the statement and three-rail transfer history that the business case usually turns on, and it is the surface that carries forward onto Bangladesh Bank's open-banking standard when that arrives. Protocol analysis is the targeted add-on for the QR flows.

Consent and the Bangladesh regulatory frame

Bangladesh does not yet operate a live consumer open-banking standard. Bangladesh Bank, the central bank and regulator, runs the payment rails PI Banking rides — NPSB, BEFTN and BD-RTGS — and has publicly signalled Open Banking Guidelines and a standardized API protocol, reported around 2026 with a working committee to follow. We treat that as the direction of travel, not as current law. The dependable basis today is the account holder's own consent to access their data, recorded and time-bound.

So consent scope is defined per engagement: which surfaces, for how long, revocable by the customer. We operate authorized, documented or user-consented access only, log consent and access, minimize what is pulled to the agreed fields, and work under NDA where the client needs it. PI Banking states it uses a Sectigo certificate to protect transmitted data; our integration respects that transport security rather than working around it.

Engineering judgment specific to this app

A few things about PI Banking shape how we build, and we handle each as part of the work:

• The three transfer rails do not behave alike. NPSB settles in real time around the clock; BEFTN is batch, settling on working-day cut-offs and rolling to the next working day after Friday or a holiday; RTGS is instant and irrevocable for high-value amounts. We model each rail's status and settlement timing separately so a unified ledger does not mark a pending BEFTN batch as failed.
• The session is OTP-bound and short-lived. We design the sync around that token lifetime so a long statement pull re-authenticates cleanly and resumes from its cursor, instead of expiring mid-range.
• The app requests optional contacts and camera permissions for top-ups, profile photos and QR/Cash-by-QR. We scope the integration to the account data you actually need and leave those device-side permission surfaces out unless the QR flow is explicitly in scope.
• Front ends change. We add a check that flags when PI Banking's screens or payloads shift, so the parser is updated before the data quietly drifts.

Interface evidence

App screens we referenced while mapping the surfaces above. Select to enlarge.

Comparable apps in the same banking estate

Partners rarely want one bank in isolation, so the same consented-session method extends across Bangladesh's banking and MFS apps. These are named for context, not ranked:

• Citytouch — City Bank's internet banking app; account, card and transfer data behind a login.
• Nexus Pay — Dutch-Bangla Bank's cardless app; accounts, cards and NPSB transfers.
• Cellfin — Islami Bank Bangladesh's app; accounts and wallet-style flows.
• bKash — large MFS wallet; balances, send-money and merchant payment history.
• Nagad — MFS wallet; wallet balance and transaction records.
• Rocket — Dutch-Bangla Bank's MFS; wallet and bill-pay history.
• Upay — UCB's MFS app; wallet ledger and payments.
• EBL Skybanking — Eastern Bank's app; account and card data.
• OK Wallet — ONE Bank's wallet, already interoperable with PI Banking for fund transfer.

How this was checked

I worked from PI Banking's own store listing and feature copy, the OK Wallet–Pubali Bank interoperability page, and Bangladesh Bank's payment-systems material plus reporting on its open-banking plans, on 19 June 2026. The transfer-rail behaviour (NPSB real-time, BEFTN batch, RTGS high-value) is drawn from Bangladesh Bank's published payment-system sources, not from inside the app.

• PI Banking — Google Play listing
• Bangladesh Bank — Payment Systems
• The Business Standard — Bangladesh's open-banking plans
• OK Wallet × Pubali Bank interoperability

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask

Which transfer rails does PI Banking touch, and do they come back the same way?

Three, and no. PI Banking moves money over NPSB (real-time interbank, round the clock), BEFTN (batch, settled on working-day cut-offs) and RTGS (high-value, instant and irrevocable). Each returns a different settlement timing and status shape, so the unified ledger we build reconciles them separately rather than treating a transfer as one event.

Can you reach statement and transaction data while Bangladesh has no live open-banking standard yet?

Yes. The dependable basis today is the account holder's own consented access to their PI Banking session, not a published scheme. Bangladesh Bank has signalled Open Banking Guidelines and a standard API around 2026, and we design the integration so it can move onto that scheme when it lands, but the work does not wait on it.

What about the QR and Cash by QR surfaces — are those in scope?

They can be. PI Banking includes merchant QR payment and a Cash by QR feature in card management, which the app describes as using optional camera permission. We map those as their own flow because the payloads and the card-side state differ from a plain account transfer.

The build runs on a one-to-two-week cycle. Two delivery shapes: we hand over runnable API source plus documentation for the surfaces above starting at $300, which you pay after delivery once you are satisfied; or you skip the build and call our hosted endpoints, paying only per call with nothing upfront. Tell us the app and what you need from its data — give us the requirement at /contact.html and we map the rest, including access and the consenting test account.