Pulling portfolio, orders and PSX live data out of MMK Trade-Flair

Munir Khanani Securities runs MMK Trade-Flair as the customer-only terminal sitting on top of its PSX trading desk. Everything an integrator cares about — positions, the order ticket, the day's trades, balance — is per-account and behind the broker login. There is no neutral public surface for it. Either you talk to the broker backend that drives this terminal with the customer's authorization, or you do not see the data.

The right route on this one is interface integration with the broker backend, scoped to the customer accounts you have written authorization for, with PSX Data Services Vending (or an authorized vendor such as Capital Stake) layered on cleanly if you also want to redistribute market quotes. We have done this shape of build for other PSX brokers and it is what we would deliver here.

The customer surfaces in detail

What is actually behind the screen, named the way the terminal names it where possible:

Routes to the data

1. Interface integration with the broker backend

This is the spine. The terminal talks to Munir Khanani's order-routing stack — which, like most PSX brokers, traces back to KiTS as an order-management layer — over an authenticated session. We map the session handshake, the order endpoints, and the portfolio read endpoints from the live traffic of the customer's own terminal, under the customer's written instruction and with the broker informed. What is reachable: every per-account surface the terminal can render. Effort sits in the auth and the keep-alive; durability is good as long as we re-validate after broker-side terminal updates.

2. User-consented credential access via the broker session

Where the integrator is a customer themselves and only needs a private feed, the deliverable can wrap the broker session as a thin headless client rather than reverse-engineering it into a separate service. Smaller scope, faster to ship, and it keeps the credential trail with the consenting customer. We tend to recommend this for individual-trader integrators and small advisory firms.

3. PSX Data Services Vending for market data

For anything that is PSX market data rather than account-specific — quotes, depth, end-of-day summaries, indices — the licensed path is PSX Data Services Vending (Level 1, Level 2 with tick-by-tick, or EOD), per the PSX product page. We can wire the integration so the terminal-mediated quote is replaced by a directly-licensed feed where the downstream use requires that.

4. Native statement export

For periodic, low-frequency needs, the simplest route is the statement export the terminal itself offers (and what is mirrored at CDC's investor portal). This is brittle for live use but a clean fallback for end-of-month bookkeeping.

If we had to pick one for a first build: route 1 with route 3 attached as the market-data layer. Route 2 if you are integrating only for yourself. Route 4 is a finisher, not a foundation.

What you receive

• OpenAPI 3.1 specification for the per-account surfaces we mapped — auth, portfolio, orders (read and write), trade history, ledger — with normalized field names so the contract is stable even if the broker renames fields.
• Protocol and auth-flow report covering the login handshake, session-token lifetime, refresh, and how the terminal keeps the session warm. Short, exact, and what an on-call engineer can read at 2am.
• Runnable source for the key endpoints in Python and Node.js. One client, both languages, with pluggable credential storage.
• Automated tests against a consenting account (recorded fixtures for the read paths; a separate live-only suite for the order path, never run in CI without the broker's go-ahead).
• Interface documentation aimed at the team that will run it after we hand it over — error model, retry semantics, what breaks first when the broker side changes.
• Compliance and data-retention notes calibrated to SECP broker rules and the bank-secrecy regime, with a record of what each pull is for.

One endpoint, walked through

Illustrative shape — the exact endpoint paths, header names and payload keys are confirmed against the live terminal during the build. The point of showing it here is the model, not the strings.

# Per-account read for MMK Trade-Flair.
# Auth via the broker session that drives the customer terminal.
import requests, time

class MMKClient:
    BASE = "https://terminal.munirkhanani.example"   # resolved during analysis

    def __init__(self, user_id, password, device_id):
        self.s = requests.Session()
        r = self.s.post(f"{self.BASE}/auth/login", json={
            "userId":   user_id,
            "password": password,
            "deviceId": device_id,
        }, timeout=10)
        r.raise_for_status()
        body = r.json()
        self.token   = body["sessionToken"]
        self.expires = time.time() + body.get("ttl", 600)

    def _hdr(self):
        if time.time() > self.expires - 30:
            self._refresh()
        return {"Authorization": f"Bearer {self.token}"}

    def portfolio(self):
        r = self.s.get(f"{self.BASE}/portfolio/holdings",
                       headers=self._hdr(), timeout=10)
        r.raise_for_status()
        # normalized: symbol, qty, avg_cost, last_price, mkt_value, unreal_pnl
        return r.json()["holdings"]

    def orders(self, day=None):
        r = self.s.get(f"{self.BASE}/orders",
                       headers=self._hdr(),
                       params={"date": day} if day else {},
                       timeout=10)
        r.raise_for_status()
        return r.json()["orders"]

    def place_order(self, symbol, side, qty, price=None):
        payload = {"symbol": symbol, "side": side, "qty": qty}
        if price is not None:
            payload["price"] = price
            payload["type"]  = "LIMIT"
        else:
            payload["type"]  = "MARKET"
        r = self.s.post(f"{self.BASE}/orders",
                        headers=self._hdr(), json=payload, timeout=10)
        # Order writes only execute under written customer authorization
        # and the broker's own pre-trade controls; never run without both.
        r.raise_for_status()
        return r.json()

Freshness and reliability

Order events arrive within the terminal's own latency budget — sub-second once the session is open. Portfolio and ledger lag the trade event by the broker's settlement cycle: cash settles via NCCPL on the published T+1/T+2 path for the instrument; share custody reflects through CDC on the same cycle. MMK has been at the top of the CDC RAAST settlement rankings recently, which an integrator should read as "the broker-side latency on cash movements is on the better end of the street", not as an SLA. We wire the build to surface both an in-flight and a settled view of the same record so downstream code does not silently treat unsettled cash as available.

Pakistani regulation, in scope

The lawful basis here is the customer's own authorization to act on their account, layered onto a broker that is itself licensed by SECP under the Securities Brokers (Licensing and Operations) Regulations, 2016. The brokerage-side secrecy obligations sit under the long-standing Banking Companies Ordinance, 1962 framework and the Payment Systems and Electronic Funds Transfers Act, 2007 — the position to take is that any per-customer surface is confidential and only moves on a written instruction. Pakistan's Personal Data Protection Bill, 2023 is still in draft, so the brief does not assume a statutory data-rights right of access; the basis is consent and instruction, not a regulatory open-finance regime.

Compliance-side, the build comes with NDA on request, a per-pull purpose log, data minimization (we only fetch the fields you asked for), and an export of the consent record alongside the source.

Engineering calls for this terminal

• Auth and session keep-alive are the fragile part. The terminal logs in against the broker backend with a session token; lifetime is short by design, and the terminal keeps it warm. We map the refresh and idle behaviour during onboarding so the deliverable does not break the first time it sits open over a long weekend.
• Per-account material and market data are separated cleanly. Per-account surfaces ride the broker auth and stay on the per-account contract. PSX quotes seen on the screen are licensed feed; if the downstream system re-emits them we route that through a PSX Data Services Vending or authorized-vendor licence rather than republishing what was rendered. The two stay in different code paths so a future market-data licence change doesn't tangle the broker integration.
• Settlement reconciliation is wired in. Position state can oscillate within the settlement window if you trust each event blindly. We add a settlement-vs-trade reconciler so positions converge to the end-of-day NCCPL/CDC picture rather than flickering between intraday and settled values.
• Broker-side updates are planned for, not patched after. The broker pushes terminal updates; field names and an occasional endpoint shape can move. The handover includes a small re-validation test set so a maintenance pass after a broker release is a contained job, not an incident.

Screens we mapped

Public Play Store screenshots, kept here as the interface-evidence index. Each one corresponds to one or more of the surfaces in the table above.

How we checked

The corporate site and the Play Store listing for the operator and the app; the PSX product pages for the trading-system and data-vending layers; and the SECP brokers-and-agents page for the licensing posture. Cross-checked against industry reporting on the Pakistani broker roster. Per-customer behaviour described above is from public terminal documentation and from the way comparable PSX-broker terminals behave; the exact endpoint strings come from the live mapping pass during the build, not from this page.

• Munir Khanani Securities — Mobile Trading page
• MMK Trade-Flair on Google Play
• PSX online trading / KiTS
• SECP — Brokers & Agents licensing

OpenBanking Studio · integration desk · reviewed 2026-05-29.

Adjacent PSX terminals

For context — other apps an integrator working in the Pakistani broker space tends to be asked about. Each holds broadly the same shape of per-customer data (portfolio, orders, ledger) on top of PSX, so a unified integration across two or three of them is a small extra pass rather than a separate project. Listed for ecosystem context, not ranking.

• MMK NxG — same firm's newer terminal; same broker backend, slightly different surfaces.
• AKD Trade — AKD Securities' customer terminal; one of the consistently top-ranked PSX brokers by active accounts.
• KTrade — KTrade Securities' app; one of the larger digital-first onboarding flows.
• JS Global — JS Global Capital's terminal; PSX connectivity comparable to MMK's.
• AHL Tradecast — Arif Habib Limited's customer app; AHL is among the firms most cited for research output.
• Topline TopTrade — Topline Securities' terminal.
• Next Online — Next Capital's customer terminal.
• Investify — independent PSX market-data and watchlist app, licensed for live data.
• PSXON — independent PSX market-following app, market data and news only.

Questions integrators ask about this one

Does this cover the order ticket as well, or are we limited to portfolio reads?

Both. The terminal places orders during live market and reads back fills, so an integration can post a new order, poll its status through the order book surface, and reconcile it against executed-trade history. Write paths are scoped to what the broker authorizes for the calling account.

How do you handle the PSX live feed that shows on the screen?

Per-account material (positions, orders, ledger) rides the broker session and is delivered with the build. Market quotes shown on the terminal are PSX-vended; if you want to re-emit them downstream they go through a separate PSX Data Services Vending or authorized-vendor licence, not the broker auth. We wire the build so the two paths stay clearly distinct.

Are the positions we see real-time or end-of-day, given CDC and NCCPL settlement?

Trade events are real-time; settled position state at CDC and cash at NCCPL update on the broker's settlement cycle, and MMK's RAAST flow has been one of the faster ones on the street. We add a reconciler so the dataset you receive does not flip between in-flight and settled values during the cash-settlement window.

What changes if we point this at MMK NxG instead of MMK Trade-Flair?

NxG is the same firm's newer terminal — the broker backend is largely shared, but auth and some surface names differ. The build is scoped per terminal; pointing the same integration at both means a second short pass to map NxG's auth and any surface renames, not a redo.

Source-code delivery for an MMK Trade-Flair integration starts at $300 and is paid after the build is in your hand and verified against a consenting account. The hosted-API option carries no upfront fee — calls only. Either route runs end-to-end in 1–2 weeks. Tell us the surfaces you need at /contact.html.

Mapping reviewed 2026-05-29.