Connecting to the account data behind Meezan Mobile App

Meezan Bank runs Pakistan's largest Islamic banking network, and the current Mobile App (package invo8.meezan.mb, per its Play Store listing) is where a single customer's whole relationship sits: linked current and savings accounts, full transaction history, fund transfers across the Raast rail, debit-card controls, Al Meezan mutual-fund holdings, and Payoneer-linked global payments converted to PKR. For a fintech, an accounting product, or a freelancer-payout tool, that is a dense, per-user record set — and reaching it for a third party is exactly the work this brief scopes.

The bottom line: the data worth syncing lives behind an authenticated session, not in any file the user can casually export. The route we would actually run is user-consented interface integration of the app's own traffic, with the State Bank's open-banking direction layered in as it firms up. Raast activity is not a separate problem — it lands in the same transaction stream we read.

What the app holds, surface by surface

Each row below is a real surface in the app as Meezan describes it, mapped to where it originates and what an integrator does with it.

Authorized routes to that data

Account-holder consented interface integration

The customer authorizes access; we analyse the app's authenticated traffic and implement the session, token and request flow that reproduces what the app shows. This reaches everything in the table above, because it reads the same surfaces the user reads. Durability is good day to day, with re-validation needed when Meezan ships a front-end change. We arrange the consenting test account and the authorization paperwork with the client during onboarding — that setup is our step, not a hoop to clear first.

SBP open-banking rail (emerging)

The State Bank of Pakistan published an open-banking framework in 2022, and Karandaaz has backed standardised-API and third-party-provider work. Where a bank-side consented API surface is reachable, it is the cleanest long-run path for balances and statements. It does not yet cover the full app surface, so we treat it as a complement, not the whole answer.

Native export as a fallback

Where the app or net-banking side can emit a statement file, that covers historical transactions for low-frequency needs. It misses real-time Raast events and card state, so it backs the consented route rather than replacing it.

For most buyers the consented interface route is the one we recommend, because it is the only path that returns Raast activity, card controls and Payoneer credits in one consistent feed rather than a partial slice. The SBP rail is where we shift the balance-and-statement portion as it becomes generally available.

What lands in your hands

• OpenAPI specification describing a normalised Meezan surface — accounts, transactions, Raast events, card state — so your side codes against one contract.
• Protocol & auth-flow report covering the login, token/session lifecycle and the biometric-plus-fallback ladder as it behaves during the build.
• Runnable source for the key endpoints (Python or Node.js) — authenticate, list accounts, page statements, capture Raast transfers.
• Automated tests against the consenting account, including the lockout-window behaviour.
• Interface documentation plus data-retention and consent-logging guidance fit for an SBP-regulated bank's customer data.

A worked example: paging the statement feed

Illustrative shape of the consented flow, confirmed against the live surfaces during the build — field names settle once the session is mapped.

# 1. Establish the consented session (auth ladder mapped during build)
session = meezan.authenticate(
    device_binding=DEVICE_ID,
    factor="biometric",            # fallback: national_id + live_capture
)
# Honour the post-sensitive-event cooling window before re-auth
if session.locked_until:
    schedule_after(session.locked_until)

# 2. Enumerate linked accounts
accounts = session.get("/accounts")        # -> [{id, iban, type, balance, currency:"PKR"}]

# 3. Page the unified statement feed (Raast rail tagged inline)
for acct in accounts:
    cursor = None
    while True:
        page = session.get(f"/accounts/{acct['id']}/transactions",
                           params={"after": cursor, "limit": 100})
        for tx in page["items"]:
            # tx.rail in {"raast_p2p","raast_p2m","ibft","meezan_internal"}
            emit(normalise(tx))
        cursor = page.get("next")
        if not cursor:
            break
      

Consent and the Pakistani regulator

The supervising authority is the State Bank of Pakistan; Raast itself is the SBP's instant-payment rail, managed operationally with Karandaaz. Because a mandated account-information regime is still forming rather than fully in force, the dependable basis for access is the account holder's own consent, captured and logged. We scope consent to the specific domains a project needs, honour revocation, and minimise stored fields to what the use case requires. Pakistan's data-protection regime is still maturing through draft legislation, so we operate to bank-grade posture by default — authorized access only, access logs, NDA where the engagement calls for it, and retention windows agreed up front.

Engineering points we account for

• The app applies a two-hour temporary lockout after sensitive events. We design the sync and re-auth schedule around that cooling-off window so automation rides with it instead of triggering it.
• Login is biometric with a fallback to National ID verification plus live-picture capture. We map the full auth ladder, so the integration handles the fallback path and is not brittle to a single factor.
• Accounts can be added or removed inside the app. We model that link lifecycle so a de-linked account degrades cleanly rather than breaking a running sync.
• Per-channel limits (ATM, POS, eCommerce, transfer) are user-set state, not constants. We read them as live values so spend-control views stay truthful.

Interface evidence

App screens from the store listing, for surface reference.

Where this gets used

• A freelancer-finance tool reconciling Payoneer-to-PKR credits against invoices, pulling the inbound credits as they land in the Meezan account.
• An SME accounting product syncing daily statements and inter-bank transfers so the books match the bank without manual entry.
• A merchant dashboard reading Raast P2M settlements for a near-live view of QR takings.
• A personal-finance app surfacing Al Meezan fund positions alongside cash balances for one combined picture.

How this was checked

Surfaces taken from Meezan's own app description and its mobile-banking page; the Payoneer linkage from the Payoneer–Meezan partnership announcement; the regulatory picture from the State Bank of Pakistan's digital-financial-services and Raast materials. Checked June 2026.

• Meezan Bank — mobile banking
• Payoneer × Meezan Bank partnership
• State Bank of Pakistan — digital financial services
• State Bank of Pakistan — Raast P2M

OpenBanking Studio integration desk · mapping notes, June 2026.

Nearby apps in the same data space

Same Pakistani banking-and-wallet space; we name them for ecosystem reach, not ranking.

• HBL Mobile — Habib Bank's app, holding balances, transfers, bill pay and card controls.
• UBL Digital — United Bank's app with account, transfer and payment data.
• Alfa by Bank Alfalah — accounts, transfers and card management for Bank Alfalah customers.
• Easypaisa — wallet and branchless-banking ledger with bill pay and transfers.
• JazzCash — mobile wallet holding balances, transfers and merchant payments.
• NayaPay — social-payments wallet with free bank transfers and a linked card.
• SadaPay — wallet with free IBFT transfers and virtual cards.
• Zindigi — JS Bank's digital app with account and payment data.
• Al Meezan Investments — Meezan's asset-management app for Shariah-compliant fund holdings.

Questions an integrator asks

Does the SBP Open Banking Framework already give a regulated feed into Meezan accounts?

Not yet as a turnkey route. The State Bank of Pakistan published an open banking framework in 2022 and Karandaaz has supported standardised-API work, but a mature, mandated account-information rail comparable to UK Open Banking is still forming. For now the dependable basis is the account holder's own consent; we build against that and fold in the regulated rail as it lands.

Can the integration pull Raast P2M and P2P transactions, not just balances?

Yes. Raast transfers (Meezan-to-Meezan, inter-bank P2P and merchant P2M QR) surface in the app's transaction history, so they map into the same statement feed we extract, tagged by rail and counterparty alias where the app exposes it.

How do you handle the two-hour lockout the app applies after sensitive events?

We model that cooling-off window in the session logic so automated re-auth and sync schedule around it instead of tripping it. The auth ladder, including the National ID and live-picture fallback when biometrics fail, is mapped during the build.

What does a Payoneer-linked withdrawal look like to the integration?

The Payoneer link surfaces as global-payment credits converted to PKR inside the account, per the Payoneer and Meezan Bank partnership. We capture those as inbound transactions with their source attribution so freelancer-payout reconciliation works end to end.

To start, you give us the app name and what you want out of its data; access and the consenting test account are arranged with you. Two delivery shapes follow. We can hand over runnable source plus documentation for the Meezan surfaces from $300, billed only after delivery once you have the working code in hand — or you can call our hosted endpoints and pay per call with nothing upfront. Either way the cycle is one to two weeks. Tell us which fits and we will scope it: start a project.