Integrating HBL Mobile's accounts, cards and Raast transfers

Behind a single login, HBL Mobile concentrates current and savings accounts, downloadable HBL CreditCard statements, loan details, mutual-fund and term-deposit holdings, and five distinct money-movement rails for Habib Bank's retail base. That breadth is the reason an integrator wants in: one consented session reaches balances, line-level history, card state and transfer records that would otherwise sit across several portals. Our job is to turn that authenticated surface into a clean feed you can query.

What follows is concrete. The data the app actually holds, the authorized way we reach it under the account holder's consent, the source and spec we hand over, and the engineering quirks specific to HBL that we plan around. The route matters more than any single endpoint, so we name the one we would take and why.

What HBL Mobile holds behind login

Every row below maps to a surface the app exposes to its own users, named the way HBL names it where possible.

Reaching that data: the authorized routes

Three routes genuinely apply to HBL Mobile. Each runs under the account holder's authorization, and the access and onboarding for each is something we arrange with you as the project starts.

Consented session integration

We analyse the app's authenticated traffic against a consenting account and rebuild the calls as a stable client. This reaches the full set of surfaces the app shows — accounts, statements, history, cards, loans, transfers. Effort is moderate; durability depends on app updates, which we cover in maintenance. We set up the capture environment with you during onboarding.

Native statement export

HBL Mobile already lets a user download account and HBL CreditCard statements. Where a project only needs statement documents, we parse those downloads into structured records. Low effort, high durability, since it rides a user-facing feature that rarely changes.

Consent-based open banking, as it matures

The State Bank of Pakistan has been moving toward standardized APIs and consent-based data sharing. As that channel firms up, it becomes a regulated, durable feed for account information and payment initiation. We track the framework and design the consent model so a project can switch onto it without a rebuild.

For most HBL Mobile work we begin from the consented session integration, because it is the only route that reaches every surface a customer can see in the app. When a brief is narrower — say nightly statement capture for a single business — the in-app download is cheaper and we parse it instead. The open-banking channel is what we build toward where a client wants the regulated, long-lived feed.

What you receive

Deliverables are tied to the HBL surfaces in your scope, not a generic package.

• OpenAPI / Swagger spec covering the surfaces you want — accounts, statements, transactions, transfer status.
• Protocol & auth-flow report: the login chain through OTP and optional biometric, the session-token lifecycle, request signing, and the Raast ID linking flow.
• Runnable source in Python or Node.js for the key endpoints: authenticate and refresh, list accounts, fetch a statement, page transaction history, check transfer status.
• Automated tests against a consenting account or captured fixtures, so a future app update fails loudly instead of silently.
• Interface documentation mapping each call to the screen a user would recognise.
• Compliance and data-retention guidance: consent records, data minimization, retention windows, NDA where you need one.

A statement pull, sketched

Illustrative shape of the calls behind a statement fetch. Field names are confirmed during the build against a consenting account, not guessed.

# Illustrative — confirmed during the build, not a published contract
POST /hblmobile/auth/session
  { "username": "...", "deviceId": "...", "otp": "123456" }
-> 200 { "sessionToken": "…", "expiresIn": 900 }

GET /hblmobile/accounts
  Authorization: Bearer <sessionToken>
-> 200 [ { "accountId":"…", "iban":"PK…", "type":"current",
           "balance": { "amount": 0.0, "currency": "PKR" } } ]

GET /hblmobile/accounts/{accountId}/statement?from=2026-01-01&to=2026-03-31
-> 200 { "lines": [
     { "date":"2026-01-04", "desc":"…", "amount":-1500.00,
       "channel":"RAAST", "balance": 0.0 } ] }

# session is short-lived (~15 min); the client re-authenticates
# before each batch and backs off on a 401 rather than hammering login
      

Transfer records carry a channel so a Raast payment and a 1LINK transfer land in the same normalized shape. Errors get handled the boring way: retry with backoff on transient failures, fail the batch on an auth break and re-consent.

Where this gets used

• A bookkeeping tool that pulls a Pakistani SME's HBL account and credit-card statements each night and posts them to its ledger.
• A treasury view reconciling Raast and IBFT payouts across HBL and other 1LINK member banks under one consented account set.
• A lender reading consented HBL transaction history and loan details to gauge affordability before approving a facility.

Consent and the SBP picture

Pakistan's banking regulator is the State Bank of Pakistan. SBP runs Raast, the country's instant payment rail, and published a Licensing and Regulatory Framework for Digital Banks in January 2022 (per SBP). Reporting since then points to a steady push toward standardized APIs, shared e-KYC and consent-based data sharing. A fully in-force consumer open-banking data mandate comparable to the UK or EU is still emerging, so we do not lean on one. The dependable basis for our work is the account holder's own authorization: the customer consents, the access is scoped to what they agreed to, and it can be revoked.

We operate compliance-first. Access is authorized and documented, every pull is logged against a consent record, we minimize what is collected to the fields a project actually uses, and we sign an NDA where the engagement needs one. Where the SBP open-banking channel becomes available, consent expiry and revocation move into that regulated flow and we wire the integration to honour it.

Engineering details we plan around

Three things about HBL specifically shape how we build, and we handle each as part of the work.

• Five transfer rails, three identifier types. HBL-to-HBL, 1LINK, M-net, IBFT and Raast use account numbers, IBANs and Raast IDs interchangeably. We map them to one payment model so a Raast-ID payment and a 1LINK account transfer reconcile against the same ledger instead of looking like unrelated events.
• OTP and biometric session expiry. Login chains through an OTP step and optional biometric, and the session is short-lived. We design the token refresh around that window so a long sync re-authenticates cleanly rather than stalling mid-batch, and credential handling stays consent-scoped and logged.
• Separate Islamic build. HBL also ships HBL Islamic as a separate package. We scope which app surface you need up front so Shariah-compliant product fields are not mixed into a conventional-account feed by accident.
• A front end that moves. When HBL releases a new build and the request format shifts, our maintenance step re-checks the captured flows against a consenting account and patches the client before the sync breaks.

Screens we worked from

HBL Mobile listing screenshots, as published on the store. Tap to enlarge.

What we checked

We read HBL's own HBL Mobile and Raast pages for the feature and transfer-rail detail, the Play Store listing for the package and current feature set, the State Bank of Pakistan digital-banking framework for the regulatory direction, and contemporary reporting on Pakistan's open-banking move. Sources opened:

• HBL Mobile — Habib Bank product page
• HBL — Raast (ID linking and transfers)
• State Bank of Pakistan — Licensing and Regulatory Framework for Digital Banks
• The Express Tribune — Pakistan and open banking

Mapped by OpenBanking Studio's integration desk — checked 2026-06-24.

Other Pakistani bank and wallet apps in the same picture

These hold comparable account or wallet data and come up when a project wants one feed across several institutions. Listed for context, not ranked.

• Meezan Mobile — Meezan Bank's Shariah-compliant accounts, cards and transfers.
• Alfa — Bank Alfalah's app, covering accounts, cards and bill payments.
• UBL Digital — United Bank's retail banking, statements and transfers.
• SC Mobile Pakistan — Standard Chartered's local accounts and card data.
• NBP Digital — National Bank of Pakistan's mobile banking surface.
• Easypaisa — Telenor Microfinance wallet with balances, payments and bill records.
• JazzCash — mobile wallet holding transfer and bill-payment history for a large user base.
• SadaPay — digital-first account with card and spend records.
• Konnect by HBL — HBL's own branchless wallet, distinct from the HBL Mobile core app.

Questions integrators ask about HBL Mobile

Can you keep HBL CreditCard statements separate from current-account statements in the feed?

Yes. The app exposes account statements and HBL CreditCard statements as separate downloadable documents, so we model them as distinct sources with their own identifiers and let you query or merge them on your side rather than flattening both into one stream.

Does Raast ID linking change how a transfer shows up in the integration?

It changes the identifier, not the record. A Raast payment carries a Raast ID where a 1LINK or IBFT transfer carries an account number or IBAN. We normalize all of HBL Mobile's transfer rails — HBL-to-HBL, 1LINK, M-net, IBFT and Raast — onto one payment model so they reconcile against the same ledger.

What happens to the integration when HBL ships a new app version or changes its login flow?

When the request format or the OTP and biometric login chain shifts in a new build, our maintenance step re-checks the captured flows against a consenting account and patches the client before the sync breaks. We treat HBL Mobile's front end as something that moves and plan the upkeep around that.

If we only need HBL balances and transaction history, what is the cheapest way to run it?

For balances and history alone, the hosted pay-per-call API is usually cheaper because you pay only for the calls you make and carry no infrastructure. If you want the code in your own environment, the source-code build covers the same surfaces and you run it yourself.

Working with us

Give us the app name — HBL Mobile — and what you need out of it; access and any compliance paperwork are arranged with you as the project runs. Delivery sits in a one-to-two-week cycle. A source-code build starts at $300: you get the runnable client, the OpenAPI spec, tests and docs, and you pay only after delivery once it satisfies you. Prefer to call an endpoint instead of host one? The pay-per-call hosted API has no upfront fee — you call ours and pay per call. Tell us which surfaces matter and we will scope it — start a conversation on the contact page.