Reaching Futu NiuNiu positions, orders and statements through an authorized integration

A single Futu NiuNiu login spans Hong Kong, US, A-share, Japanese and Singapore positions, plus options, futures, ETFs, bonds, funds and leveraged forex — and the order history, fills, statements and watchlists layered on top of them. That breadth is the integration problem. The records you want for a third-party portfolio tool, a tax export, or a compliance feed sit behind a consented session and the account's own market-data entitlements, not in a tidy file you can request once. The authorized way in is protocol analysis of the consenting user's session, backed by the app's own statement export and, where a formal route is needed, a data-access request under Hong Kong's privacy ordinance. This brief maps what is reachable and what we hand over.

Bottom line: for an account you or your client control, the practical build is a consented-session capture reconciled against the in-app statement export, with the PDPO request kept ready for personal data an export does not surface. Real-time LV2 depth stays inside the user's own exchange subscription. We build the rest into a clean, documented interface.

What sits behind a Futu NiuNiu login

The app names its own surfaces clearly, which makes mapping them straightforward. Each row below is something an integrator would actually consume.

Routes that fit a multi-market broker app

Three routes apply here, and they layer rather than compete.

Protocol analysis of a consented session

We capture the client-to-server traffic of a consenting account, document the auth chain (session token plus a device-binding cookie set at login), and rebuild the calls behind positions, orders, statements and watchlists as a clean interface. This reaches the most, including the live order book and account state. Durability is moderate — Futu ships frequent app updates, so the client contract drifts and we account for re-capture. Onboarding and the consenting test account are arranged with you at the start of the build.

Native statement export

Futu surfaces transaction statements in-app (Trade > Statements) and as a downloadable CSV from the desktop History tab, with monthly PDFs emailed and password-protected. This is the low-effort, durable path for historical fills and balances. We wrap the export, decrypt and parse the PDF, and normalize it so it is machine-readable. It does not carry live state, which is why it pairs with the session route.

PDPO data-access request

Where a formal basis is needed for the personal data Futu Securities holds, section 18 and Data Protection Principle 6 of Hong Kong's Personal Data (Privacy) Ordinance give the account holder a right of access, made on the PCPD's data-access request form. Slower and broader, it is the route of record when an in-app export is not sufficient. We prepare and track the request as part of the engagement.

For most clients the session capture reconciled against the statement export is what we would actually build first; it covers live and historical data with the least fragility. The PDPO request stays in reserve for personal data those two do not reach, and we keep real-time exchange depth inside the account's own subscription rather than redistributing it.

A worked example: the transaction statement

The snippet below mirrors the in-app statement / "export transaction flow" view. Endpoint paths and field names are confirmed per account during the build, not published constants; the auth here is the consenting user's own Futu session, never a bypass.

# Illustrative. Authorized session = the consenting user's own login.
import requests

class FutuSession:
    def __init__(self, base, session_token, device_cookie):
        self.s = requests.Session()
        self.base = base
        self.s.headers["Authorization"] = f"Bearer {session_token}"
        self.s.cookies.update(device_cookie)   # device-binding cookie from consented login

    def transaction_flow(self, acc_id, market, begin, end, page=1):
        # Trade > Statements / "export transaction flow"
        r = self.s.get(f"{self.base}/trade/v1/statements", params={
            "accountId": acc_id,
            "market": market,            # HK | US | SG | JP | CN
            "begin": begin, "end": end,
            "pageNo": page, "pageSize": 200,
        }, timeout=15)
        if r.status_code == 401:
            raise SessionExpired("re-run consented login; session tokens are short-lived")
        r.raise_for_status()
        rows = r.json().get("data", {}).get("list", [])
        return [normalize_fill(x) for x in rows]

def normalize_fill(x):
    # collapse HK board lots and US shares into one shape; currency kept per row
    return {
        "trade_date": x["tradeTime"],
        "symbol":     x["stockCode"],
        "market":     x["market"],
        "side":       x["trdSide"],      # BUY / SELL
        "qty":        x["qty"],
        "price":      x["price"],
        "currency":   x["currency"],     # HKD / USD / SGD / JPY / CNH
        "fee":        x.get("totalFee"),
    }

What you receive

Every engagement ends in a repository you can run, not a slide deck. For Futu NiuNiu that means:

• An OpenAPI/Swagger specification covering the statement, positions, order-history and watchlist calls we rebuild.
• A protocol and auth-flow report: the login token exchange, the device-binding cookie, session lifetime, and the pagination behaviour of the statement endpoint.
• Runnable source for the key endpoints in Python or Node.js, including the PDF-statement decryptor and the multi-market normalizer.
• Automated tests against recorded fixtures, so a Futu app release that moves a field fails loudly instead of silently.
• Interface documentation plus data-retention and consent-logging guidance keyed to the PDPO.

Normalizing HK, US and SG into one shape

A position from a HK sub-account and one from a US sub-account arrive with different lot conventions and currencies. We collapse them so downstream code never special-cases a market.

{
  "position": {
    "symbol": "00700.HK",
    "market": "HK",
    "name": "Tencent Holdings",
    "qty": 100,                       // one HK board lot
    "avg_cost":     { "amount": 312.40,   "currency": "HKD" },
    "market_value": { "amount": 38900.00, "currency": "HKD" },
    "source": "futu.positions",
    "as_of": "2026-06-15T08:00:00+08:00"
  }
}
      

Authorization, the PDPO and the SFC posture

Futu Securities International (Hong Kong) is licensed by the Securities and Futures Commission, holding the Type 1 dealing licence among others, which it uplifted in July 2024 to cover virtual-asset dealing (per Futu Holdings' investor-relations announcement). That regulated standing is why we keep every pull tied to the account holder's authorization. The governing data-rights instrument is the Personal Data (Privacy) Ordinance: section 18 and Data Protection Principle 6 give the data subject a right of access to personal data Futu holds, enforced by the Office of the Privacy Commissioner for Personal Data. Consent here is the dependable basis — not a speculative open-data scheme. We record the consent scope, honour revocation, minimize captured fields to what the integration needs, and operate under NDA where the client requires it. Real-time exchange feeds carry their own licensing, which we respect by leaving live depth inside the user's market-data subscription.

Engineering realities we plan around

Two things about this specific app shape the build, and we handle both rather than push them onto you.

Market-data entitlements. The real-time tiers the app sells — NASDAQ TotalView, NYSE OpenBook, US Composite, HK LV2, the Singapore feeds — are exchange-licensed and gated per account. We scope the quote layer to exactly what the consenting account is entitled to and keep real-time depth behind that subscription, so the integration never becomes an unlicensed redistribution of exchange data.

Password-protected, multi-currency statements. Statements arrive as encrypted PDFs by email and a desktop-only CSV, with HKD board lots settling differently from US shares. We parse the protected PDF, reconcile it line-for-line against the CSV, and normalize currency, lot size and corporate-action fields so a headless pull does not depend on a person opening an email. Because Futu releases app builds often, we also budget a re-capture step when a release moves fields, scheduled into maintenance rather than discovered in production.

Screens we worked from

Store screenshots used while mapping the surfaces above. Select to enlarge.

Cost and how the build runs

A source-code build for Futu NiuNiu starts at $300, billed only after we deliver and you have run it against your own account and are satisfied. The alternative skips owning code: call our hosted endpoints for Futu data and pay per call, with nothing upfront. Both run on a one-to-two-week cycle, and access — the consenting account, any sandbox, the consent paperwork — is arranged with you while the build proceeds. Tell us the data you need from Futu NiuNiu and we will route the rest. Start a Futu integration on the contact page.

Where Futu sits among trading apps

The same integration approach maps onto the apps a Futu user often runs in parallel. Plain ecosystem context, not a ranking.

• moomoo — Futu's international product on the same backend; surfaces near-identical positions and statements for non-HK accounts.
• Tiger Brokers (Tiger Trade) — multi-market broker with HK, US and Australian access; holdings and order history behind a login.
• Webull — US-centric broker app with portfolio, order and watchlist data per account.
• Longbridge — HK and US trading app holding positions, statements and quote data.
• Snowball / Xueqiu — investment community plus brokerage, strong on social signals and watchlists.
• Tonghuashun (10jqka) — A-share-focused quotes and analytics with account linkage.
• AAStocks — Hong Kong quotes and technical data, lighter on account state.
• Interactive Brokers — global multi-asset broker with deep statement and position records per account.
• Valuabull — HK and US trading app positioned on low-cost, simple execution.

Questions integrators ask about Futu NiuNiu

Can you reach Futu's LV2 depth and the 60-level US order book, or only the account's own data?

Real-time exchange depth — NASDAQ TotalView, NYSE OpenBook, US Composite, the HK LV2 feed — is exchange-licensed and tied to the account's own market-data subscription, so we keep that behind the user's entitlement rather than redistributing it. The reliable, portable surfaces are the consenting account's positions, order and fill history, statements and watchlists, plus reference and end-of-day data. We scope the quote feed to what the account is actually entitled to.

Which markets and instruments does a Futu NiuNiu integration actually cover?

As the app describes its coverage, a single login spans Hong Kong, US, A-share, Japanese and Singapore stocks, plus options, futures, ETFs, bonds, funds and leveraged forex. We normalize symbols, currency, lot size and corporate-action fields across those markets into one schema so a HK board lot and a US share reconcile in the same ledger.

How does the Hong Kong PDPO data-access route differ from reading the app's own export?

The app's own statement export (in-app Trade > Statements, or the desktop History CSV) is the fast path for an account you control. A PDPO data-access request under section 18 and Data Protection Principle 6, made to Futu Securities as the data user, is the formal legal route to the personal data held on file when an export is not enough. We use whichever the engagement authorizes and document the consent trail either way.

We already pull moomoo statements in-house — can you match that for Futu NiuNiu HK accounts?

Yes. moomoo and Futu NiuNiu share Futu's backend, but the HK product surfaces statements as password-protected PDFs by email plus a desktop CSV, with HKD board lots and different settlement than a US account. We parse the protected PDF, reconcile it against the CSV, and hand back the same normalized records you already store, so the HK accounts land in your existing pipeline.

How this mapping was put together

Surfaces were checked in June 2026 against Futu's own help material and Hong Kong's privacy regulator: Futu's guide to exporting the transaction flow, the FUTU HK statement help page, the PCPD's Personal Data (Privacy) Ordinance overview, and the Futu Holdings SFC Type 1 licence announcement. Endpoint and field details are verified per account during the build, not asserted from these public pages.

Mapped by the OpenBanking Studio integration desk · June 2026.