Khanani Securities routes its PSX order flow through MMK Trade-Flair, which means the data an integrator usually wants — live positions, working orders, intraday quotes, the cash-and-margin line — sits on the broker's back-office terminal and on the authenticated session the handset opens. The integration described here treats that traffic as the surface, ingests it on the broker side under the customer's authorization, and pipes it into whatever downstream system needs the feed: a portfolio reconciler, a risk dashboard, a tax book, a research desk.
What sits behind the login
Reading the app's own description, the Play Store listing and the broker's site, the surfaces a third party would want to read are reasonably clear. The granularity is the broker's, not ours — we map what the app already shows.
| Data domain | Where in MMK Trade-Flair | Granularity | What an integrator does with it |
|---|---|---|---|
| Position book | Portfolio screen | Per-scrip, with average cost and mark-to-market | Reconcile holdings; feed an intraday risk view |
| Working orders | Orders → live | Per-order: state, side, qty, price, TTL, fills-so-far | Replicate the order ladder; alert on partials |
| Trade history | Orders → history | Per-execution, time-stamped to the second | P&L attribution, tax book, audit trail |
| Live quotes | Watchlist / scrip card | Tick during session; last-trade after hours | Drive price grids, triggers, calculations |
| Cash & margin | Account screen | Aggregated in PKR; margin used, margin available | Risk gating; pre-trade exposure caps |
| Investment exposure | Exposure view (as the app describes it) | Per-scrip share of book and sector tilt | Concentration analysis; rebalancing prompts |
| Corporate actions | Notifications, joined to CDC | Per-scrip, dated | Book entitlements and ex-dates; reconcile drops |
Three routes that fit a PSX broker terminal
Pakistan does not yet run a national open-banking or open-finance scheme for brokerage data, the way the UK runs OB or Brazil runs Open Finance, so the dependable basis is the customer's own authorization. Three shapes work here.
Route 1 — authorized broker-side ingestion
Khanani's terminal sits on the PSX plumbing (NTT and KITS, per PSX's published trading services). Reading the data on the broker side, under a letter of authority signed with Khanani Securities, is the most durable shape: a single integration sees every client account the broker authorizes, the order log is the authoritative one, and a mobile-app rewrite does not break it. We arrange this access with the broker as part of onboarding.
Route 2 — user-consented session against the mobile endpoints
For a single customer or a fast first build, the simpler path is to hold the same authenticated session the MMK Trade-Flair handset opens, in a controlled environment, with the account holder's written consent. The integration speaks to the same endpoints the app does; it stands up in days. It will survive until the broker rotates auth, at which point we re-pin during maintenance.
Route 3 — CDC Access as a depository cross-check
Authoritative depository balances and corporate-action entitlements live at Central Depository Company, reachable for the customer through CDC Access (web, mobile and SMS). Pulling this in parallel gives a second source for holdings, so the broker view does not silently drift from the depository book. CDC Access does not carry order flow, so it is a complement to routes 1 and 2, never a substitute.
In practice we lead with route 1 where the customer plans to scale across many client accounts, and with route 2 where one account holder wants their own data in their own system tomorrow. Route 3 rides alongside either.
An illustrative call against the position book
The exact field names, auth chain and error envelope are pinned during the build by replaying the actual traffic with the customer's consent — what follows is the shape, not a contract.
POST /broker/session
Authorization: HMAC(client_id, signed_nonce)
body { client_code, terminal: "MMK-FLAIR", channel: "mobile" }
→ 200 { token, expires_in, session_id,
market_state: "open" | "pre" | "closed" }
GET /portfolio/positions?session=<session_id>
→ {
as_of: "2026-05-27T09:46:12+05:00",
cash_pkr: <decimal>,
margin_used: <decimal>,
positions: [
{ scrip: "OGDC", qty: 1000, avg_cost: 142.50, ltp: 144.20, mtm: 1700.00 },
{ scrip: "LUCK", qty: 50, avg_cost: 815.30, ltp: 820.10, mtm: 240.00 }
]
}
GET /orders?session=<session_id>&state=working
→ { orders: [
{ id, scrip, side: "BUY" | "SELL", qty, px,
ttl: "DAY", filled, state: "WORKING" | "PARTIAL" | "FILLED" }
] }
# fills push (broker-side route 1)
POST /your-webhook/mmk/fills
body { order_id, exec_id, scrip, side, qty, px,
ts: "2026-05-27T10:12:04+05:00" }
Idempotency key is (broker_id, order_id, exec_id) so re-runs do not double-count fills; tick-size rounding rides off PSX's published price bands.
Source, OpenAPI spec, and the runnable client
We lead with what runs on your side, not a slide deck. The drop for MMK Trade-Flair looks like this:
- Runnable Python or Node.js client that holds the session, refreshes the token, and pulls positions / orders / quotes on a schedule you control. Ships with an example reconciliation loop wired to your downstream store.
- Webhook handler scaffolding for fill notifications, so an execution inside MMK Trade-Flair lands in your system within seconds, not at the next poll.
- Automated test rig against a captured response set, so the integration does not silently break when the broker rotates a field name. Tests run on your CI.
- Idempotent ingestion design — (broker_id, order_id, exec_id) as the natural key — so a replayed run produces the same end state, never doubled fills.
- Batch-vs-realtime split: tick stream during the PSX session, scheduled reconcile after the close; the client picks the mode from the session's market_state.
- OpenAPI / Swagger spec for the surface we hit, kept in lock-step with the client code (one source of truth, not two).
- Protocol and auth-flow report — the HMAC and cookie chain as it actually runs in MMK Trade-Flair — written so a future engineer can extend it without rebuilding our knowledge.
- Interface documentation plus a short retention and data-minimization note for the customer's own compliance file.
SECP, CDC, and consent in Pakistan equities
The dependable legal basis on this page is the customer's own authorization — the account holder authorizing us to act on their session, or Khanani Securities authorizing us to read on the customer's behalf on the broker side. A national consent layer for brokerage data is not yet in place in Pakistan; this is the honest read of the equities market today.
SECP's Securities Brokers (Licensing and Operations) Regulations 2016 (updated April 2024, per SECP) require brokers to maintain real-time order and transaction logs for at least five years. The integration is designed to read those logs and never write to them; we also keep our own append-only call log on the integration side so the customer has an independent, retrievable trail of every read. Depository balances ride on CDC's investor account services rather than the broker terminal, so for holding confirms we cross-check against the CDC Access feed.
Consent is scoped per engagement: which accounts, which surfaces, for how long, with revocation in one place. NDAs and the letter of authority with Khanani are arranged with the customer during onboarding rather than asked for upfront; they are a project step, not a gate.
Engineering notes that bite on this app
Three concrete pieces we account for so the customer does not run into them six weeks in.
Session window vs poll cadence
The PSX session is short — roughly 09:30 to 15:30 Pakistan time on weekdays, with a Friday prayer break (per PSX's published trading hours). The client we ship knows this. During the session it holds a live socket or long-poll for ticks; outside the session it drops to a slower portfolio-and-orders refresh that only touches cash and holding endpoints. That keeps the feed honest during the day and stops it from generating noise overnight.
Scrip code and corporate-action joins
PSX scrips can be renamed, split or merged through corporate actions; an order placed two years ago on a now-renamed symbol still needs to resolve in your book. The integration carries a mapping table the build refreshes from PSX's published scrip list and CDC corporate-action notices, so historical orders join cleanly to current positions. We treat that as part of the project, not a homework item for the customer.
PKR rounding and tick-size bands
PSX uses tick-size bands by price tier, so a naive round-to-paisa generates rejected orders. The shipped client carries the band table and applies the right increment per scrip before sending, so order-replication code does not lose round-trips at the broker.
Freshness around the PSX session
For a feed that derives from a five-hour market, freshness is a configuration, not a constant. The reconciler should accept that positions, orders and ticks during 09:30–15:30 PKT come in at sub-second cadence, that the cash and margin line is computed at session-close, and that authoritative holdings catch up at the CDC end after settlement. The client exposes the market_state from the session response, so a downstream consumer can render "settled" vs "intraday" without guessing.
Questions PSX integrators bring us
How do you keep up with PSX session ticks without hammering the broker terminal?
The client we ship is session-aware. Inside PSX hours it holds a long-lived authenticated socket against the broker side and pushes ticks into your queue; outside session hours it shifts to a slower portfolio-and-orders poll that only touches the cash and holding endpoints. That keeps the data fresh during the day and quiet overnight, and avoids the rate-limit footprint you would get from a naive cron.
Does the ingestion sit on the broker side or speak to the same endpoints the mobile app uses?
Either. The durable shape is broker-side ingestion under a letter of authority from Khanani Securities — that survives mobile-app rewrites and gives us the raw order log. The faster shape is replaying the same authenticated calls the MMK Trade-Flair handset makes, with the customer's account; we use this when the customer needs a working feed in days rather than weeks, and migrate to broker-side later if the volume justifies it.
Where do depository balances come from — the broker terminal or CDC?
Working positions and intraday P&L come from the broker side: MMK Trade-Flair is where they are first computed. Authoritative depository balances and corporate-action entitlements sit at Central Depository Company, reachable through CDC Access for the customer. The integration cross-checks the two so a stale broker view does not silently drift from the depository book.
What does SECP's five-year retention rule mean for what we build?
Per the Securities Brokers (Licensing and Operations) Regulations 2016, the broker — not the integrator — owns the five-year order and transaction log. We read that log, we do not write into it. The integration carries its own append-only call log so the customer has an independent, retrievable trail of every read; we hand over the retention and data-minimization note that goes with it.
How this mapping was put together
This page draws on the app's own listings on Play and the App Store, Munir Khanani Securities' site, PSX's published trading services and hours, SECP's broker licensing pages, and CDC's investor-services pages. The Play Store listing carries a "10,000+ downloads" badge and an update date in mid-2025; the iOS twin is published as MMK Trade-iFlair. Specific calls, error envelopes and field names are not asserted here — those are pinned in the build, against a consented session.
Sources opened during this mapping:
- Munir Khanani Securities — Mobile Trading
- Pakistan Stock Exchange — Trading Services (NTT / KITS / JTT)
- SECP — Brokers & Agents Licensing
- Central Depository Company — CDC Access
OpenFinance Lab integration desk — mapping reviewed 2026-05-27.
App profile (factual recap)
Name. MMK Trade-Flair (Android, package com.microlinks.Munirkhanani); the iOS twin is published as MMK Trade-iFlair.
Publisher. Muhammad Munir Muhammad Ahmed Khanani Securities Limited — a Karachi-based PSX TREC-holder brokerage. Per the firm's site, it offers equity brokerage services to retail and corporate clients and runs a research portal alongside the trading app.
Function. Place orders during the live PSX session and monitor portfolio holdings during and after market hours, per the app's own description.
Distribution. Free on Google Play and the App Store; the Play listing shows 10,000+ Android downloads as of writing, with an update in mid-2025.
Sister terminal. MMK NxG — a newer iOS-side terminal from the same broker, listed on the App Store.
Interface evidence
Screenshots as the broker publishes them on Google Play; click for a full view.
If you want this on your stack
On delivery, the simplest fit for MMK Trade-Flair is the source-code drop: a Python or Node.js client built against the surface the app actually uses, with the OpenAPI spec, automated tests and the interface docs alongside, for from $300 and paid once you have it running on your side. If you would rather not host anything, the same surface is reachable through our pay-per-call hosted API — no upfront cost, you only pay for the calls you make. A first build is usually 1–2 weeks from kickoff. Send the app name and what you want pulled to contact and we will scope it back.