Integrating the account behind Meezan's Roshan Digital Account app

A logged-in Roshan Digital Account holds more than a balance. There are current and savings accounts in PKR, USD, GBP and EUR; a Naya Pakistan Certificate ledger with its tenors and maturities; cross-bank transfers over IBFT and Raast; and, for holders who opened a Central Depository Company sub-account, Shariah-compliant equity on the Pakistan Stock Exchange. Meezan Digital Account Opening — package com.roshandigital on Google Play — is the app overseas Pakistanis use to open and run that account. This page maps what it carries and the authorized way to reach it.

The short version: nearly everything worth integrating lives behind one authenticated session, and most of it is structured per-currency and per-instrument rather than dumped as a single number. The route we would actually build runs on the account holder's own consent against that session — described in full below — with the regulated interface kept in view for when its standards land.

What an integrator can pull, surface by surface

Each row is a surface the app actually presents to a signed-in RDA holder, named the way the app and the bank name it where possible.

Authorized ways into the account

Three routes apply to this app. For each: what it reaches, the effort, how durable it is, and what we set up to run it.

Consented interface integration

We analyze the app's own traffic and rebuild the calls behind it, running against an account whose holder has authorized access. This reaches the whole logged-in surface — balances across currencies, the certificate ledger, PSX positions, transfers. Medium effort; durability tracks the app's release cycle, so it needs occasional maintenance. Access to a consenting account on a registered device is arranged with you during onboarding.

Regulated account information (AIS)

The State Bank of Pakistan's open-banking framework puts account information and payment services in scope. The technical standards under it are still being finalized, so this is the route we keep the design ready for rather than the one available to ship today. Once the standards are in force, durability is high because access no longer depends on the app's front end.

Native statement export

Where Meezan internet or mobile banking exposes a statement or transaction download, we fold it in as a low-effort baseline for history and backfill. It carries less than the live session does, so it complements rather than replaces the interface route.

For most teams the consent-based interface route is the one to build now: it reaches everything behind the login and does not wait on standards that are not finished, and where a statement download exists we use it as a cheap history backfill. The regulated route is the one we keep the build portable toward — not the one to block on.

A login-and-balance call, sketched

Illustrative only — header names and field shapes are confirmed during the build, not lifted from any Meezan document. It shows the device-bound, OTP-gated login the app uses and a multi-currency balance read.

POST /rda/auth/login
  { "cnic_nicop": "...", "device_id": "<registered-device>", "channel": "app" }
  -> 200 { "txn_ref": "...", "otp_required": true }

POST /rda/auth/otp
  { "txn_ref": "...", "otp": "######", "device_id": "<registered-device>" }
  -> 200 { "access_token": "<jwt>", "expires_in": 600 }

GET /rda/accounts?include=balances
  Authorization: Bearer <access_token>
  -> 200 { "accounts": [
       { "iban": "...", "currency": "PKR", "type": "savings",
         "available": 184250.00, "ledger": 184250.00 },
       { "iban": "...", "currency": "USD", "type": "current",
         "available": 5200.00 } ] }

# client side: refresh on expiry, keep the device binding, fail loud on OTP timeout
def balances(session):
    try:
        r = session.get("/rda/accounts", params={"include": "balances"})
        if r.status_code == 401:        # token aged out
            session.reauth()            # re-run OTP step inside the same consent
            r = session.get("/rda/accounts", params={"include": "balances"})
        r.raise_for_status()
        return [normalize(a) for a in r.json()["accounts"]]
    except OtpTimeout:
        raise IntegrationError("OTP step expired; surface to the holder, do not retry blind")

What you receive at handover

The deliverables map onto the surfaces above, not a generic checklist:

• An OpenAPI/Swagger spec covering the RDA calls we implement — auth, accounts, transactions, certificates, equity.
• An auth-flow report tracing the login → OTP → device-bound token → refresh chain as it behaves on this app.
• Runnable source in Python or Node.js for the key reads: login, the cross-currency balance pull, transaction history, NPC holdings, PSX positions.
• A normalized schema that maps Meezan's fields to a clean model, with currencies and instruments kept separate.
• Automated tests run against a consenting account or sandbox, plus interface documentation and data-retention guidance.

Consent, and where the State Bank's rules stand

Two things govern how this data is reached. The first is the account holder's own consent: an overseas Pakistani who opened the RDA can authorize access to their own balances, transfers and holdings, and that authorization — logged, scoped, revocable — is what the integration runs on today. The second is the State Bank of Pakistan's open-banking framework, published in 2022 with account information and payment services in scope; the technical standards under it are still being finalized, and the State Bank has been running an open-banking theme through its regulatory sandbox. We build to the consent-based route now and keep the design close enough to the framework that moving onto the regulated interface, once its standards are in force, is a swap rather than a rebuild. Access stays authorized and documented, we minimize what we pull to what the use case needs, hold consent records, and work under NDA where the engagement calls for it.

What we plan around on this build

Device binding and OTP. The app ties a session to a registered device and gates login with a one-time code — the listing mentions auto-fetched OTPs. We design the integration to live inside that, running against a registered, consenting device and treating the OTP and device token as steps in the flow, so sessions stay valid instead of tripping the bank's fraud controls.

No two RDAs look alike. One holder has a single PKR savings account; another has PKR plus USD, GBP and EUR, Naya Pakistan Certificates, and a CDC-linked PSX sub-account. We scope the schema so an absent module reads as absent rather than as an error, and so an account that later adds an equity sub-account does not break the feed that was already running.

Two transfer rails, one shape. Outgoing payments move over IBFT and over Raast, and the two carry different reference and status semantics. We normalize them into a single transaction shape with the rail recorded, so downstream reconciliation never has to special-case which network a payment took. When Meezan re-skins a screen in a release, that parsing is maintenance we keep in scope and re-test against the live flow.

Where an RDA feed gets used

• A wealth view for overseas Pakistanis that shows RDA balances across currencies next to NPC maturity dates, in one place.
• A bookkeeping tool that ingests RDA transfers and bill payments and matches them against invoices for a remitter or a small business.
• A portfolio tracker that pulls CDC-linked PSX holdings into a wider investment picture spanning other markets.

Working with us, and what it costs

A finished Meezan RDA integration leaves you with code that runs and the spec that explains it, not a slide deck. One path is source-code delivery: we build the runnable endpoints, the OpenAPI description, the auth-flow report and the tests, hand them over, and you pay from $300 only after delivery, once it does what you asked. The other is our hosted API — you call our endpoints and pay per call, with nothing upfront. Either way the cycle runs one to two weeks once access to a consenting account is arranged. Tell us the app and what you want from its data on the contact page and we will scope it.

The screens we worked from

Store screenshots of the Meezan Digital Account Opening app. Select one to enlarge.

Sources, and how this was checked

This brief was put together on 25 June 2026 from the app's own store listing and primary sources on the Roshan Digital Account scheme and Pakistan's open-banking status. We read the bank's RDA pages for account types and currencies, the State Bank's RDA material and an open-finance status tracker for the regulatory picture, and the Pakistan Stock Exchange's Roshan Equity page for the investment surface. Specific pages opened:

• Meezan Bank — Roshan Digital Account
• State Bank of Pakistan — Roshan Digital Account
• Open finance status tracker — Pakistan (SBP framework, Raast)
• Pakistan Stock Exchange — RDA Roshan Equity Investment

Mapped and reviewed by the OpenBanking Studio integration desk — 25 June 2026.

Other Pakistani banking apps in the same orbit

Same-category apps an aggregator or finance product would integrate alongside the Meezan RDA app. Listed for context, not ranked.

• HBL Mobile — HBL's app for balances, transfers, bill pay and digital account opening; the same per-user banking records a unified feed would carry.
• UBL Digital — UBL's app with Raast payments and the Asaan digital account, a close cousin in account and transaction shape.
• Alfa (Bank Alfalah) — Bank Alfalah's app spanning accounts, cards and payments.
• MCB Live — MCB's mobile banking for accounts, transfers and bills.
• Faysal Digibank — Faysal Bank's app, with an Islamic banking side comparable to Meezan's.
• Dubai Islamic Bank Pakistan — also a Roshan Digital Account provider, so its data shape overlaps closely with Meezan's RDA.
• Allied Bank (myABL) — ABL's app, and another Roshan Equity provider for PSX investment.
• Easypaisa — wallet and branchless banking; balances and payment history rather than a full multi-currency account.
• JazzCash — a mobile wallet for payments and transfers across Pakistan.

Questions we get about the Meezan RDA app

Does an RDA's multi-currency side come through as separate balances?

Yes. PKR, USD, GBP and EUR accounts are distinct records inside the same login, and we model each as its own balance with its own currency code rather than collapsing them into one figure.

Can you reach Naya Pakistan Certificate and PSX holdings, or only the cash account?

Both, when the account holder has them. The certificate ledger and any CDC-linked equity positions sit behind the same session as the cash account, so a single consented integration can carry maturities, tenors and holdings alongside the running balance.

Pakistan's open-banking rules are still being written. Does that hold the work up?

No. The State Bank published its open-banking framework in 2022, but the technical standards under it are still being finalized, so we build today on the account holder's own consent and the app's own traffic, then move to the regulated interface once those standards are in force.

How do you deal with the OTP and device binding at login?

We treat them as part of the auth flow, not something to get around. The build runs against a consenting account on a registered device, records the OTP step and the device-bound token in the auth report, and keeps session refresh inside the consent the holder gave.