Account, card and transfer data behind UBL Digital - Safe Banking

UBL Digital opens a Smart Account from a CNIC and a biometric check, no branch visit, which means a freshly onboarded user has server-side balances, a debit card and a transaction ledger within minutes. That is the data an integrator wants: per-account records sitting behind an authenticated session at United Bank Limited, not a static brochure. The app caps a single peer transfer at PKR 50,000 and roughly PKR 1,000,000 a day, per coverage of its P2P limits, and it lets a customer raise card and banking limits up to Rs. 10 million from inside the app, as the listing describes it. Those numbers tell you the backend holds real, mutable financial state.

Our read on this app: the richest target is the authenticated statement and transfer ledger, reached through a consented session rather than any public feed. Pakistan's open-banking plumbing is still young, so the working basis is the account holder's authorization, and the build is shaped around UBL's biometric and OTP login. The rest of this brief maps what is reachable and how we deliver it.

Data behind the login

Each row below is a surface the app actually exposes to a logged-in user, named the way UBL presents it where possible.

Routes to the data

Three routes apply to UBL Digital. We arrange the access each needs with you during onboarding rather than asking you to clear it first.

Consented interface integration and protocol analysis

We observe the traffic the app exchanges after a consenting account logs in, document the request and response shapes for balance, statement, transfer and card surfaces, and rebuild those calls as a clean client. Reachable: nearly everything a user sees in-app. Effort is moderate and front-loaded into capture and mapping. Durability is good between app releases and is kept honest with a re-validation pass. This is the route we would run as the main one here, because it gives the full ledger with the least dependence on any external scheme maturing.

User-consented credential session

For a single business or account holder, the integration drives the customer's own authenticated session, biometric unlock and OTP included, on a schedule they consent to. Reachable: the same data, scoped to that one account. Light to set up, and the cleanest consent story for a single-tenant pull. The trade-off is per-account scaling.

Native statement export

The app already produces downloadable statements. We parse those into structured records as a fallback, so a field change in the live session does not stop the data flowing. Narrow on its own, dependable as a safety path beside the first route.

What lands on delivery

Everything is tied to the surfaces above, not a generic kit.

• An OpenAPI/Swagger specification covering the account, statement, transfer and card endpoints we mapped.
• A protocol and auth-flow report: the token or cookie chain UBL establishes after biometric login and OTP, and how the refresh path behaves.
• Runnable source for the key calls in Python or Node.js, your choice, with the statement and transfer pulls working end to end.
• Automated tests, including contract checks that fail loudly when a field or endpoint moves.
• Interface documentation a maintainer can act on, plus guidance on consent logging and data retention for Pakistani accounts.

A statement call, sketched

Illustrative shape only, with field names confirmed during a build rather than copied from any document. It shows the session reuse and the per-entry structure we normalize toward.

# Consented session already established (biometric unlock + OTP on device)
# Token captured and refreshed against the account holder's session.

GET /digital/accounts/{account_id}/statement?from=2026-05-01&to=2026-05-31
Authorization: Bearer <session_token>
X-Device-Binding: <device_id>

# Normalized response we emit downstream:
{
  "account_id": "****4821",
  "currency": "PKR",
  "opening_balance": 184230.55,
  "entries": [
    {
      "posted_at": "2026-05-14T09:21:00+05:00",
      "amount": -50000.00,
      "rail": "RAAST_P2P",          # CNIC / mobile / QR alias send
      "counterparty_alias": "0300-*****12",
      "narrative": "P2P transfer",
      "status": "POSTED"
    },
    {
      "posted_at": "2026-05-15T11:02:00+05:00",
      "amount": 75000.00,
      "rail": "IBFT",
      "narrative": "Inbound remittance partner credit",
      "status": "POSTED"
    }
  ]
}

# On token expiry -> run the consented refresh, retry once, then alert.
# Backstop: parse the app's downloadable statement for the same window.
      

Where this gets used

• An accounting tool pulling a UBL business account's statement nightly to auto-categorize utility, fee and zakat payments.
• A treasury dashboard tracking Raast and IBFT cashflow across several UBL accounts in one view.
• A lender confirming inbound remittance credits against an applicant's stated income, with the applicant's consent.
• A personal-finance app folding UBL balances and IPS fixed-income holdings into a wider net-worth picture.

Consent and the Pakistani rulebook

UBL is regulated by the State Bank of Pakistan, and its transfers ride Raast, the SBP's instant payment system. Pakistan does not yet run a mature open-banking or account-aggregation scheme that a third party can call for consent, so we do not pretend one exists. The dependable basis is the account holder's own authorization. Pakistan's Personal Data Protection Bill is still in draft and defines consent as a freely given, specific and informed indication that can be withdrawn; we operate to that standard ahead of enactment. Concretely, that means scoped consent records, an honored revocation path, data minimization so only the requested fields are stored, encrypted handling, and an NDA where the engagement needs one. Access is authorized, logged, and limited to what the integration requires.

Engineering notes for UBL

Two things we account for on this app specifically:

• Biometric and OTP login is built around the consenting account, not worked past. We trace the token chain produced after that gate and design the refresh so the integration re-authenticates on schedule; the OTP step stays with the account holder, and we plan the cadence so a session does not silently expire mid-run.
• UBL ships frequent app updates and runs several regional builds (Pakistan, Qatar, UK) on different backends. We pin the integration to the Pakistan app.com.brd build, version the captured contract, and wire a re-validation pass into maintenance so a moved endpoint shows up as a failing test rather than corrupt data. Transfer limits and card-limit ceilings are read live rather than hard-coded, since the app lets a user change them.

Screens we worked from

Store screenshots used while mapping the app's surfaces. Click to enlarge.

Other Pakistani banking apps

Same category, often the same integration ask across more than one institution. Named for context, not ranked.

• HBL Mobile — Habib Bank's app; balances, transfers, bill pay and digital account opening.
• Meezan Bank App — Shariah-compliant retail banking with the same account and statement surfaces.
• Alfa — Bank Alfalah's app, covering accounts, cards and payments.
• myABL — Allied Bank's personal and business banking app.
• SC Mobile — Standard Chartered Pakistan, with cross-border banking features.
• Easypaisa — wallet and QR payments, bill pay and mobile top-ups.
• JazzCash — mobile wallet with a wide retail and online-shopping footprint.
• SadaPay — free IBFT transfers and virtual cards.
• NayaPay — social payments, free transfers and a linked debit card.

A unified integration normalizes balances and transactions across several of these so a downstream tool reads one schema instead of nine.

What we checked

We reviewed the UBL Digital store listings for its feature set and limits, the State Bank of Pakistan's Raast pages for the payment rail behind its transfers, an open-banking tracker for Pakistan's regime status, and a current data-protection guide for the consent standard. Sources below open in a new tab.

• State Bank of Pakistan — Raast instant payment system
• Open Banking Tracker — Pakistan status
• ICLG — Pakistan data protection 2025–2026
• UBL Digital - Safe Banking on the App Store

Mapped by the OpenBanking Studio integration desk · 2026-06-18.

Questions integrators ask

Can you reach Raast and IBFT transfer records, or only balances?

Both. The same authenticated session that returns a balance also returns posted transfers, including Raast P2P sends keyed to a CNIC, mobile number or QR alias and standard IBFT entries. We map each as its own record type with amount, counterparty alias, channel and timestamp rather than treating the statement as one flat blob.

Does Pakistan's framework let a third party pull UBL account data today?

Pakistan's formal open-banking and account-aggregation regime is still early-stage, so there is no mature consent API to call. The dependable basis is the account holder's own authorization: a consenting customer or business authorizes the pull, and we build the integration against that session, logging consent and minimizing what is stored.

How do you handle UBL's biometric and OTP login during the build?

Biometric unlock is a device-local gate; the network session it produces is what matters. We trace the token or cookie chain the app establishes after login and the OTP step, then drive a refresh path with the consenting account so the integration can re-authenticate without a person tapping through every run. The OTP handling is designed around the account holder, not bypassed.

What happens to the integration when UBL ships a new app version?

Front-end and endpoint shifts are expected on a bank app that updates often. We version the captured contract and include a re-validation pass in maintenance so a changed field or moved endpoint surfaces as a failing check rather than silent bad data. Statement exports are kept as a fallback parse path for the same reason.

Getting started is light: tell us it's UBL Digital and what you want out of its data, and we arrange access and any compliance paperwork with you from there. Delivery runs one to two weeks. Source-code delivery starts at $300: you receive the runnable API source and documentation, and you pay only after delivery once the integration satisfies you. The alternative is a pay-per-call hosted API, where we host the endpoints and you pay for the calls you make, with no upfront fee. Either way, start at our contact page with the app name and your requirement.