Reaching HBL Islamic account and Raast records through an authorized integration

Per HBL's own banking pages, the bank is Pakistan's largest, and its Islamic arm surfaces the same statement, transfer and Raast records in this app that an integrator would want to sync. The records are real account state behind an authenticated session: downloadable statements, dated transaction lines, beneficiary lists, scheduled instructions, and a live connection to Raast, the instant payment rail operated by the State Bank of Pakistan. That is a worthwhile integration target. The wrinkle is the route, not the data — Pakistan's open-banking regime is still being built, so the practical path is authorized analysis of the app's own session rather than a waiting consumer data-sharing mandate.

Our recommendation for HBL Islamic is to anchor the build on authorized interface analysis of the app's session traffic, with user-consented access where an end user is in the loop and native statement export as a low-effort fallback. Raast and the SBP regulatory sandbox become the regulated spine for any integrator that operates payment-initiation flows and can join those schemes. The rest of this brief is specific about each.

What the app holds, account by account

The map below follows the feature names HBL Islamic uses in its own listing and release notes, so an integrator can line each surface up against what they need.

The Qiblah locator and Tasbih counter are local utilities with no server-side record, so they sit outside any integration. Everything else above is account state worth syncing.

Getting to the data: the routes that actually work here

Four routes apply to HBL Islamic. They differ in reach, effort and how long they hold up when the app changes.

Authorized interface analysis of the app session

The app authenticates a user, then exchanges structured calls for statements, history, transfers and bill payments. We analyse that session under the client's written authorization, document the auth and token chain, and rebuild the calls as a clean interface. Reach is the widest of the four — anything the app itself can show. Durability is medium: the app front end shifts (recent notes added dormant-account activation and freelancer onboarding), so we keep a re-validation step in maintenance. Access for the build is arranged with the client during onboarding, against a consenting account.

User-consented access

Where an end user is present, they consent and the integration acts within their own session and limits. Reach matches what that user can see. This is the natural route for budgeting, accounting and aggregation products with a live user.

Native statement export

The app already exports account statements. For a reconciliation or bookkeeping use case that only needs periodic statements, parsing that export is the lowest-effort, most durable option, and we wire the parser and schedule for it.

SBP regulatory sandbox and Raast participation

For an integrator running payment-initiation or aggregation as a business, the State Bank of Pakistan's regulatory sandbox and the Raast rail are the regulated spine. We help structure the integration to fit those programmes; eligibility there belongs to the integrator's own licensing, and we build around it. We would not lead a single-tenant data sync here, but we would for anyone scaling payment flows.

For most briefs the first route carries the build and the third backs it up; the fourth is the path when the work is a regulated payments product rather than a point integration.

Where SBP rules and Pakistan's data law stand

Pakistan does not yet run a mandated consumer open-banking scheme. The State Bank of Pakistan issued regulatory-sandbox guidelines in 2025, and per Open Banking Expo it later shortlisted a first cohort that included Open Banking applicants — Neem Exponential, Digi Khata and Switch Retail. That is sandbox-stage, not a broad data-sharing right, so this brief does not quote fixed data-window or threshold figures as settled law, because they are not yet settled. Raast, by contrast, is live and operated by the SBP, with API-based connectivity for banks and fintechs developing around it.

On privacy, the Personal Data Protection Bill 2023 was approved by the Federal Cabinet but, as reported, remains pending before Parliament — it is not yet in force. In the meantime the SBP enforces financial-sector data and cybersecurity standards through existing instruments, including the Payment Systems and Electronic Fund Transfers Act 2007 and the SBP regulations for security of internet banking. We run every engagement on authorized, documented or user-consented access, with consent records and access logs kept, data minimised to what the use case needs, and an NDA in place where the client wants one. Consent scope, expiry and revocation are built into the integration rather than bolted on.

What you receive at the end

The deliverable is the working integration for the HBL Islamic surfaces you name, not a report about them. Concretely:

• An OpenAPI/Swagger specification covering the statement, transaction-history, transfer and bill-payment surfaces in scope.
• A protocol and auth-flow report: the login, device-verification handshake, token issuance and refresh, and the T-PIN step as it applies to transfers.
• Runnable source for the key endpoints in Python or Node.js — session establishment, statement pull, transaction history, payment initiation and Raast status.
• Automated tests against the documented responses, including the asynchronous Raast confirmation path.
• Interface documentation a developer can hand to a teammate, plus compliance and data-retention guidance scoped to Pakistan.

Each piece maps to a real surface in the table above — nothing generic is shipped to pad the set.

A statement pull, in practice

Illustrative — field names and the device-bound session are confirmed during the build, not asserted here as the bank's published contract.

POST /islamic/auth/session
  device_id, registered during onboarding handshake
  credentials -> short-lived access token + refresh token
  (transfers later require the 4-digit T-PIN, kept out of any log)

GET /islamic/accounts/{accountId}/statement
  query: fromDate, toDate, format=json|pdf
  headers: Authorization: Bearer <token>

200 OK
{
  "accountId": "…",
  "productType": "islamic-current",     # Shariah label, not "interest"
  "currency": "PKR",
  "openingBalance": "…",
  "closingBalance": "…",
  "lines": [
    { "postedDate": "2026-04-02",
      "valueDate": "2026-04-02",
      "amount": "-…",
      "channel": "RAAST",
      "counterparty": "…",
      "ref": "…" }
  ]
}

# Raast transfers settle asynchronously:
#   submit -> { "status": "PENDING", "raastRef": "…" }
#   poll   -> GET /islamic/raast/{raastRef}  until SETTLED | RETURNED
# On 401 the refresh token is replayed once, then re-auth;
# a stale device_id returns a re-registration challenge, handled in the client.

What we plan for on this build

Three things about HBL Islamic specifically shape how we engineer the integration.

Device binding and the T-PIN step

HBL's recent release notes describe device management to verify internet-banking devices and a 4-digit numeric T-PIN for transfers. We model the device-registration handshake so the integration is treated as a known device rather than tripping a re-verification on every run, and we keep the T-PIN out of any logged or persisted path.

Real-time Raast settlement

Raast transfers confirm in real time and asynchronously. We design the sync to wait on a Raast status before marking a payment final, so a transfer that is still pending is not counted, retried or reported as settled by mistake.

Shariah product fields

Islamic accounts carry profit-sharing terms and Shariah product names rather than conventional interest fields. We map that product schema explicitly so a downstream ledger does not mislabel an Islamic account, and so reporting stays correct for a customer who runs both Islamic and conventional books.

Where integrators take this

• An SME accounting tool that pulls HBL Islamic statements and transaction history nightly and posts them into its ledger.
• A personal-finance app that aggregates a consenting user's HBL Islamic balances and spend alongside other Pakistani accounts.
• A treasury or payouts platform that initiates and reconciles Raast and interbank transfers, tracking each through to settlement.
• A Zakat or donation platform that reconciles inbound payments made through the app's donation and bill-payment flows.

Working with us, and what it costs

The build runs on a 1–2 week cycle and lands as runnable source for the HBL Islamic surfaces you name. You can take it as a source-code delivery — the runnable API code plus the OpenAPI spec, automated tests and interface docs, from $300, invoiced only after it is delivered and you have confirmed it works. Or skip running anything yourself and call our hosted endpoints on a pay-per-call basis, with nothing paid up front. You give us the app name and what you want out of its data; access, consent and any compliance paperwork are arranged with you as part of the engagement, not asked of you before it starts. To scope a build or get a quote, contact OpenBanking Studio.

Screens from the app

Public store screenshots, shown for interface reference.

What was checked, and when

This brief was built from HBL's own description of the app's features and recent release notes, the State Bank of Pakistan's Raast pages, reporting on the SBP regulatory-sandbox cohort, and the public store listing. Primary sources opened: HBL Islamic banking mobile app, SBP — Raast instant payment system, SBP regulatory-sandbox first cohort, and the Google Play listing. Mapped by the OpenBanking Studio integration desk, May 2026.

Other Pakistani banking apps in the same picture

An integrator rarely needs only one bank. These same-market apps hold comparable account and payment state, and a unified integration usually has to normalise across several of them.

• Meezan Mobile — Pakistan's largest dedicated Islamic bank; Shariah accounts, transfers, Raast, Zakat and donation flows.
• BankIslami — the second-largest Islamic bank; retail accounts plus home and auto financing records.
• UBL Ameen — UBL's Islamic window; account, transfer and bill-payment data inside a large conventional bank's stack.
• Faysal DigiBank — Faysal Bank's app after its move to full Islamic banking; multi-account view, transfers and bill payments.
• Al Baraka Islamic Bank — Shariah retail and consumer banking with its own digital channel.
• HBL Mobile — HBL's conventional sibling app; the same bank's non-Islamic account and payment records.
• Easypaisa — large mobile wallet and digital bank; QR payments, bill pay and balance state.
• JazzCash — wallet with a wide retail network and online-shopping payment records.
• SadaPay — fintech with free interbank transfers and virtual-card transaction data.

Questions integrators ask about HBL Islamic

Does HBL Islamic's Shariah product structure change what an integration can pull versus a conventional HBL account?

The records are the same shape — balances, statements, transaction lines, transfers — but Islamic accounts label them differently. Profit-sharing terms stand in for interest, and account types carry Shariah product names. We map that product schema explicitly so a downstream ledger does not file an Islamic account as a conventional interest-bearing one.

Can the integration cover Raast instant transfers, or only standard interbank ones?

Both. The app initiates HBL-to-HBL, normal interbank and Raast instant or P2M transfers. Raast confirmations are real-time and asynchronous, so we build the sync to wait on a Raast status rather than assume the transfer settled the moment it was submitted, which keeps pending payments from being counted twice.

How does the integration deal with the device verification and T-PIN HBL added?

HBL's recent release notes describe device management to verify internet-banking devices and a 4-digit numeric T-PIN for transfers. We model the device-registration handshake so the integration runs as a recognised device, and the T-PIN path is kept out of any logged or stored trace.

Pakistan's open-banking rules are still at sandbox stage — does that hold the integration up?

No. The State Bank of Pakistan's open-banking work is at regulatory-sandbox stage, so a broad consumer data-sharing mandate is not yet in force. The integration does not depend on it: it runs through authorized interface analysis of the app's own session and user-consented access, with the sandbox or Raast route used where an integrator qualifies for it.