Pulling balances, statements and card data out of MCB Live

MCB Bank Limited runs MCB Live as its flagship retail banking app, and behind that login sit per-user records — balances, statements, card controls, transfer history — that an aggregator or fintech in Pakistan typically reaches today only through authorized, consent-based integration. MCB is among the country's larger commercial banks, fourth by assets and second by branch network per public bank-sector summaries, with a customer base reported in the millions. That scale is the point: a single MCB Live connection covers a lot of accounts.

Bottom line: the data is rich and the surfaces are well-defined, but Pakistan does not yet have a live national consent rail to ride. The route we would actually run is a user-consented protocol integration against a genuine MCB Live session, normalized into a clean API on our side. The rest of this page maps the surfaces, the route, and what lands at the end.

Account surfaces MCB Live keeps server-side

These are the surfaces the app names itself, mapped to where they come from and what an integrator does with each. Granularity reflects what the app exposes to a logged-in user, not an assumption about the bank core.

Consent, and where Pakistan's open-banking rules actually stand

The regulator here is the State Bank of Pakistan. SBP published an open-banking framework in 2022 covering API-based account information and payment access, and it ran an open-banking theme in the regulatory sandbox whose guidelines came in 2025, with shortlisted participants testing in a live but controlled environment. The technical API standards behind that framework are still being developed rather than finalized, per SBP and open-banking trade coverage. So the page does not pretend there is a standard consent endpoint to call today.

What that means in practice: the dependable legal basis is the account holder's own authorization. The customer who owns the MCB Live login consents, the integration acts within that consent, and every pull is logged. On the privacy side, Pakistan's Personal Data Protection Bill 2023 is still a draft awaiting passage, so we operate to data-minimization and retention norms by default — collect only the fields the use case needs, keep consent records, and work under NDA where the engagement calls for it. As the SBP framework matures and the sandbox graduates participants, the same integration can move onto a standardized rail without changing the data contract you depend on.

Routes we would actually take into MCB Live

Three approaches fit this app. They are not equal, and the recommendation is plain.

User-consented protocol integration

The account holder authorizes; we analyze the app's authenticated traffic and build against the real session. This reaches everything in the surfaces table — balances, statement, cards, transfers. Effort is moderate, durability depends on app-version churn, and we set up the consenting test account with you during onboarding. This is the one we would run as the working integration for MCB Live, because it is the only route that reaches the full surface set today and rests on a basis that holds regardless of where SBP's framework lands.

Standardized SBP open-banking consent

The forward path. Once SBP's technical standards and sandbox graduate to production access, account information and payment initiation move onto a regulated consent flow. We track it and design the data contract so a later switch is a back-end swap, not a rebuild. It is not something to wait on for a project that needs data now.

Native in-app exports

Where MCB Live already produces an artefact — an e-Statement subscription, a downloadable withholding-tax certificate — we parse those as a low-effort supplement for documents that are awkward to derive from live calls. Useful as a complement, not a substitute for the live route.

What you get back

The deliverable is a working integration for MCB Live's surfaces, not a report. Concretely:

• An OpenAPI / Swagger specification covering the account, statement, card and transfer endpoints we map.
• A protocol and auth-flow report: the login and token handshake, refresh behaviour, and exactly how the OTP step gates financial actions.
• Runnable source for the key calls in Python or Node.js — balance read, statement pull, transfer initiation with the OTP hand-off.
• Automated tests against captured fixtures, so a future app build that shifts a field is caught early.
• Interface documentation plus consent and data-retention guidance written for Pakistan's current rule context.

Each piece ties to a real MCB Live surface. The statement code returns the same fields the Account Statement screen shows; the transfer code follows the Quick Transfer and Raast flow rather than a generic stub.

A statement pull, sketched

Illustrative shape only — field names are confirmed during the build, not lifted from a published spec. It shows the session, the multi-account read, the capped statement, and the OTP-gated transfer.

# Auth: device-bound login returns a short-lived bearer + refresh
POST /auth/session
  { userId, deviceId, pin }  ->  { accessToken, refreshToken, expiresIn }

# The "Multiple Accounts" dashboard
GET /accounts
  Authorization: Bearer <accessToken>
  ->  [ { accountId, iban, currency: "PKR", availableBalance, ledgerBalance } ]

# Account Statement is capped (~10 on screen); page for more
GET /accounts/{id}/statement?count=10&cursor=<next>
  ->  { items: [ { postedAt, amount, currency, type, narrative, balanceAfter } ],
        nextCursor }

# Quick Transfer is OTP-gated: surface the challenge, capture the result
POST /transfers/quick   { fromAccount, toIban, amount }  ->  { transferId, status: "OTP_REQUIRED", otpRef }
POST /transfers/{id}/otp  { otpRef, otp }                ->  { status: "EXECUTED", raastRef }

What we plan around in an MCB Live build

A few specifics about this app shape the engineering. We handle them; none of them is something you have to clear first.

• OTP-gated actions. Transactions confirm by one-time passcode. We design the flow so the integration drives a real consenting session and presents the OTP challenge to the account holder, capturing the outcome — financial actions stay under the user's control by design.
• The short statement window. The app surfaces only a small slice of recent transactions on screen. For deeper history we page and stitch periodic pulls into a continuous ledger our side, and cross-check against e-Statement output so nothing is dropped at the seams.
• App-version churn. MCB Live is an actively maintained flagship, so field names and the token handshake can shift between releases. Our maintenance includes a periodic check that re-confirms the captured surfaces still match and patches the parser before data goes stale.
• Raast transfer identity. A bank account links to one Raast ID at a time, per SBP, so we model transfer identity per account rather than assuming one global handle, and carry the Raast reference through to your schema.

Where teams put this data to work

• An accounting product syncs a customer's MCB balances and statement lines into PKR-normalized books each night.
• A treasury tool initiates Quick Transfer payouts and tracks each one to its Raast reference.
• A personal-finance app aggregates MCB alongside other Pakistani bank accounts into one consented view.
• A lender pulls a consenting applicant's recent statement window to verify income before a decision.
• A back office collects withholding-tax certificates across many MCB accounts at filing time.

Screens behind this mapping

Public store screenshots we worked from while mapping the surfaces above. Select to enlarge.

Other Pakistani banking apps worth aggregating alongside

A unified view in Pakistan usually spans several of these. Each holds comparable per-user account data, and the same consent-based method applies.

• HBL Mobile — Habib Bank's app; balances, transfers, bill pay and digital account opening across a very large customer base.
• Meezan Bank — Islamic banking app with Shariah-compliant account and transaction records.
• UBL Digital — United Bank's app covering accounts, cards and a broad transfer set.
• SC Mobile Pakistan — Standard Chartered's app for account management and payments.
• Faysal Digibank — Faysal Bank's digital banking with full account control.
• Easypaisa — wallet and branchless-banking platform holding balances and payment history.
• JazzCash — mobile-account wallet with transfers, bills and a large transaction ledger.
• Askari Bank — Askari's digital app for accounts and card services.
• Bank of Punjab (BOP) — provincial bank app with accounts and transfers.
• Dubai Islamic Bank Pakistan — Islamic-compliant accounts and payments.

Questions integrators ask about MCB Live

Can you reach transaction history beyond the ten entries MCB Live shows on screen?

Yes. The on-screen statement is capped at roughly ten recent transactions, as the app's own listing describes it, but the integration pages and stitches periodic pulls into a continuous ledger on our side, and reconciles it against the app's e-Statement output for longer windows.

Does Pakistan's SBP open-banking framework mean this data is available through a standard consent API today?

Not yet. The State Bank of Pakistan published an open-banking framework in 2022 and ran an open-banking theme in its 2025 regulatory sandbox, but the technical API standards are still being developed. So the dependable basis today is the account holder's own authorization, not a live national consent rail.

How do MCB Live's OTP-gated transfers affect an integration?

Financial actions like Quick Transfer are confirmed by a one-time passcode. The integration drives a genuine consenting session and surfaces that OTP challenge to the account holder, then captures the result. It does not attempt to sit behind the OTP step.

Can you return amounts normalized to PKR with the Raast reference on each transfer?

Yes. We normalize balances and transactions to PKR with consistent timestamps, and where a transfer clears over Raast we carry its reference through to the delivered schema so your records reconcile against the bank side.

How this mapping was put together

Checked in June 2026 against MCB Live's public store listing and MCB Bank's own site for the feature set, and against State Bank of Pakistan material plus open-banking trade coverage for the regulatory picture. The surfaces above come from what the app describes to its users; the regulatory status reflects published framework and sandbox material, not a private roadmap. Primary sources:

• MCB Live on Google Play
• State Bank of Pakistan — Raast instant payments
• Pakistan open-finance status tracker
• SBP regulatory sandbox first cohort (Open Banking Expo)

Mapping compiled by the OpenBanking Studio integration desk, June 2026.

Most MCB Live builds we scope land inside one to two weeks. You can take the runnable source and documentation for a fixed fee starting at $300, paid only after delivery once the integration works to your satisfaction; or we host the endpoints and you pay per call with nothing upfront. Tell us the app and what you want out of its data, and we arrange access and the consenting test account with you as part of the work. Start the conversation here.