Reaching the data inside Konnect by HBL

HBL markets Konnect as a branchless account tagged to your mobile number, and that number effectively becomes the account number — that is how HBL's own Konnect pages describe the product. So the public identifier for a Konnect customer is a phone number, not an IBAN you can read off a card. That single design choice shapes nearly every integration decision below.

The bottom line: Konnect carries the full spread of retail wallet data behind a device-bound login, and the practical way to it is mapping the app's own authenticated traffic with the accountholder's consent. We treat the SBP framework and Raast as the regulatory context, not as a live third-party rail you can call today. Where the app already exports a file — statements, tax certificates — we lean on that as the cheaper path.

What Konnect holds, per user

Each row below is a surface the app actually exposes to a logged-in user, named the way Konnect names it.

Getting to it: the authorized paths

Authorized interface integration / protocol analysis

This is the path that reaches everything in the table. We map the Konnect mobile app's authenticated traffic against a consenting account, document the request/response shapes and the auth chain, and rebuild the calls as clean, typed source. It reaches balance, statements, transfers, bills and cards. Effort is moderate; durability depends on how often HBL reshapes the app, which we account for in maintenance. Access is arranged with you during onboarding — the build runs against a consenting Konnect account you control.

Native export (statements, tax certificates)

Konnect already lets a user download statements and annual tax certificates. For those two surfaces, automating the in-app download and parsing the files is cheaper and steadier than reconstructing a feed. Narrow, but reliable.

Consented account aggregation, as it matures

The SBP open banking framework points toward regulated, consent-based data sharing in Pakistan. It is not yet a generally available third-party rail, so we do not build on it as today's spine — but where a sponsor or sandbox arrangement is available, we wire to it and keep the protocol path as the working route underneath.

For most buyers the call is straightforward: run the authorized interface integration as the live data path for balances, transfers and cards, and fold in the native statement and tax-certificate exports for those documents because parsing HBL's own files is steadier than reconstructing them. We name the trade-offs in writing before any code is cut.

What lands in your repo

Concrete artifacts, all tied to Konnect's real surfaces:

• An OpenAPI/Swagger spec for the endpoints we map — session refresh, balance, statement query, transfer history, card status.
• A protocol and auth-flow report: the device-binding, T-PIN and biometric/OTP chain, and how short-lived tokens refresh.
• Runnable source for the key calls in Python and Node.js, including the alias→IBAN resolution and rail tagging.
• Automated tests against recorded fixtures, so a future app update that shifts a field is caught early.
• Interface documentation a new engineer can follow without a walkthrough.
• Compliance and data-retention guidance: consent records, logging, data minimization, NDA where you need one.

A statement pull, sketched

Endpoint names and field shapes here are illustrative and get confirmed during the build; the auth pattern reflects what Konnect's device-bound login looks like in practice.

# 1) Refresh the short-lived session token (device-bound)
POST /konnect/v1/session/refresh
Headers: X-Device-Id, X-App-Version, Authorization: Bearer <refresh_token>
Body:    { "tpin_hash": "...", "biometric_assert": "<optional>" }
-> 200   { "access_token": "...", "expires_in": 900 }
-> 401   { "code": "TPIN_LOCKED", "attempts_left": 0 }   # back off, surface re-auth

# 2) Read a statement window for the alias (= registered mobile number)
GET /konnect/v1/accounts/{alias}/statement?from=2026-05-01&to=2026-05-31
Headers: Authorization: Bearer <access_token>
-> 200 {
     "alias": "03XXXXXXXXX",          # Konnect alias, resolved to IBAN internally
     "currency": "PKR",
     "opening_balance": "...",         # amounts kept as strings, never floats
     "entries": [
       { "ts": "2026-05-04T11:02:00+05:00", "rail": "RAAST", "type": "TRANSFER",
         "amount": "-2500.00", "ref": "RST..." },
       { "ts": "2026-05-09T09:40:00+05:00", "rail": "IBFT",  "type": "TRANSFER",
         "amount": "+18000.00", "ref": "1L..." },
       { "ts": "2026-05-12T18:15:00+05:00", "rail": "BILL",  "type": "UTILITY",
         "amount": "-1340.00", "ref": "KE..." }
     ]
   }
      

Where integrators put this

• A personal-finance app showing a user's Konnect wallet next to their other Pakistani accounts in one balance view.
• A lender pulling consented Konnect statements for cash-flow underwriting before approving a small loan.
• An SME accounting tool auto-importing Konnect bill payments and transfers so books stay current.
• A disbursement platform pushing and reconciling Raast payouts to Konnect aliases.

Consent and the SBP backdrop

Banking data in Pakistan sits under the State Bank of Pakistan. SBP published an open banking framework in 2022 and operates Raast, including the Person-to-Merchant scheme — both real, both cited below. What does not yet exist is a broad, generally available AISP-style consent rail a third party can call for any customer. Pakistan also has no comprehensive data-protection statute in force; the Personal Data Protection Bill has stayed in draft, so confidentiality obligations rest on SBP rules and the customer relationship rather than a single privacy act.

Given that, the dependable basis for a build today is the accountholder's own authorization. We work against a consenting account, keep consent and access records, minimize what we store to the fields your use case needs, and sign an NDA where the engagement calls for one. If and when a regulated consent rail opens for Konnect, the same mapped endpoints move onto it with little rework.

Engineering details we plan around

• Alias, not IBAN. The user-facing identifier is a mobile number tagged to a CNIC. We normalize the alias↔IBAN mapping and keep a stable internal account key, so a customer changing their number does not orphan their history downstream.
• Device binding and short tokens. Konnect ties sessions to a registered device behind T-PIN and biometric checks, with short-lived tokens. We design the sync around that bind-and-refresh window so it does not silently expire, and run re-auth through the consenting account rather than around any control.
• Two transfer rails. Entries arrive over Raast and over 1Link IBFT with different reference formats. We tag each line by rail so reconciliation lines up against the right scheme instead of guessing.
• App churn. HBL ships Konnect updates regularly. We keep a periodic re-check in the maintenance window for when an update moves a field or a screen, and the recorded-fixture tests flag it fast.

Freshness and how we drive it

Balances read live on an active session. Statement and transfer lines appear as transactions post, so we drive freshness with scheduled pulls and a polite backoff rather than hammering the interface. Amounts stay as strings end to end to keep PKR values exact. Tax certificates change once a year, so those run on an annual cadence, not a polling loop.

Screens we mapped

The store screenshots we reviewed while scoping this brief — tap to enlarge.

Sources and review

For this brief we read HBL's own Konnect product pages for the account model and feature set, the SBP digital-finance pages for Raast and the open banking context, the app's store listings for the package and platform facts, and Open Banking Tracker's Pakistan page for the regulatory state. Checked June 2026.

• HBL — Konnect Mobile App (product page)
• State Bank of Pakistan — Raast Person-to-Merchant
• Open Banking Tracker — Pakistan
• Konnect by HBL — Apple App Store (PK)

Mapped by the OpenBanking Studio integration desk, June 2026.

Other Pakistani wallets and bank apps

Useful context if you are aggregating across the market — neutral notes on what each holds:

• JazzCash — telco-backed wallet with balances, transfers, bill payments and a merchant network.
• Easypaisa — now a digital bank, holding wallet and account balances, transfers and bill data.
• UBL Omni — UBL's branchless banking wallet, the closest peer to Konnect's model.
• SadaPay — EMI-issued account and card with transaction history and IBAN.
• NayaPay — wallet and card data, transfers and merchant payments.
• HBL Mobile — HBL's flagship retail app, holding full branch-account statements and cards.
• myABL (Allied Bank) — retail accounts, statements and Raast transfers.
• Meezan Bank app — Islamic-banking accounts, balances and transaction history.

A unified integration would normalize alias-keyed wallets like Konnect against IBAN-keyed bank accounts so a single schema covers the lot. Pull what you need from Konnect, line up the engagement, and route any questions through our contact page — source-code delivery starts at $300, billed only after delivery once you are satisfied, or run our hosted endpoints and pay per call with nothing upfront. Either way the cycle is one to two weeks.

Questions integrators ask about Konnect

Can you separate Raast transfers from 1Link IBFT in the statement feed?

Yes. Each entry carries rail metadata, so we tag Raast (the SBP instant rail) separately from 1Link IBFT and bill or top-up lines, which keeps reconciliation matched to the right reference scheme.

How does the mobile-number alias map to a real account number?

Konnect tags the account to your PTA-registered mobile number, so the number is the public alias per HBL's Konnect pages. We resolve that alias to the underlying IBAN and keep a stable internal key, so a number change does not break downstream joins.

Does Pakistan have a live open-banking consent rail we would use for Konnect?

Not as a broad, generally available third-party rail yet. SBP published an open banking framework and runs Raast, but consented access for a build today rests on the accountholder's own authorization, which is what we run the integration against.

Can tax certificates and account statements be pulled as files?

Yes. The app surfaces account statements and annual tax certificates as downloadable documents; we automate retrieval and parse them into structured records alongside the live balance and transaction feed.