Getting the weekly major-shareholder series out of 籌碼大股東

Every week, the Taiwan Depository & Clearing Corporation freezes a snapshot of who holds what — counts of shareholders at each shareholding tier, taken on the last business day of the week. 籌碼大股東 takes that snapshot and turns it into a per-stock trend line for roughly 1,700 listed and OTC names, according to its store listing. The integration question here is not "where does the base data live" — it is public, under the Open Government Data License v1.0. It is how to reach the layer the app computes on top, and how to keep it in step with a clock that ticks once a week.

What sits behind the chip charts

Five surfaces matter to anyone syncing this app. Two are public; the rest are the app's own product.

The weekly clock, and what moves it

This app has one heartbeat. The custody balance is read on the last business day of the week and the dispersion table is published weekly, so every figure downstream — the ranking, the flow series, the major-versus-minority split — advances once per week and never intraday. Two things shift that clock in practice. A public holiday on the usual release boundary pushes the snapshot date, and the app's derived series can lag the raw TDCC release by a refresh cycle. We pin the sync to the published snapshot date rather than wall-clock time, and we reconcile the derived series against the raw layer so a missed or delayed week shows up as a gap, not as a flat line that looks like real data.

Honest ways in

Three routes apply to this app. They are not equal.

Open-data base layer

The dispersion table is published as Taiwan government open data and exposed through TDCC's OpenAPI (OAS 3.0). Reachable: the full weekly holder-count-by-tier table per stock. Effort: low. Durability: high — it is a licensed public feed. We set this up as the reproducible foundation, keyed by ticker and snapshot week, under OGDL v1.0 attribution.

Authorized protocol analysis of the app backend

The major-shareholder ranking, the flow-trend chart and the price overlay are computed by nStock and served to the mobile client. Reaching them means analysing the app's own traffic — the login and token-refresh chain, then the chip-trend endpoints — under your authorization, framed as reverse engineering for interoperability. Effort: medium. Durability: moderate, because client endpoints can change; we cover that in maintenance. This is the route that delivers the part you cannot get from the open dataset.

User-consented watchlist access

The self-selected list is bound to a user or device. With a consenting account it can be mirrored as its own surface and refreshed on the same weekly cadence. Effort: low once access is arranged with you during onboarding. Durability: tied to the account.

What we would actually build: the open-data layer as the dependable spine, the protocol-analysis layer bolted on for the derived analytics that give the app its value, and the watchlist only if a customer needs their own universe synced. Recommending the open-data layer alone would hand you a thinner product than the app itself.

What lands in your repo

Concrete artefacts, tied to the surfaces above:

• An OpenAPI/Swagger specification covering the weekly dispersion query, the major-shareholder ranking, the flow-trend series and the watchlist read.
• A protocol and auth-flow report for the app backend: the login, token issue and refresh chain, request signing, and the error and rate behaviour observed during the build.
• Runnable source for the key endpoints in Python and Node.js — the TDCC open-data pull plus the derived-layer client, with the weekly reconciliation step included.
• Automated tests, including a contract test that fails loudly if nStock changes an endpoint before your pipeline serves stale numbers.
• Interface documentation and a short data-retention note covering the PDPA-relevant watchlist surface and OGDL v1.0 attribution for the public layer.

A request, end to end

Both layers in one picture. Field names and the app host are illustrative and confirmed during the build, not taken from any vendor document.

# Base layer — TDCC weekly dispersion (Open Government Data License v1.0)
GET https://openapi.tdcc.com.tw/v1/opendata/qryStock?stockNo=2330
Accept: application/json
# -> [ { "資料日期":"20260515", "持股分級":"15",
#        "人數":4123, "股數":812340000, "占集保庫存數比例":3.71 }, ... ]

# Derived layer — 籌碼大股東 app backend (mobile client traffic;
# host / path / token shape confirmed during the build, not from a vendor doc)
POST {app-host}/v2/chip/holderTrend
  Authorization: Bearer <device-scoped token from the login/refresh chain>
  { "stockNo":"2330", "weeks":52, "tier":"byCapital" }
# -> { "stockNo":"2330",
#      "series":[ { "week":"2026-05-15", "majorPct":71.4, "minorPct":28.6,
#                   "majorHolders":312, "close":1015 }, ... ] }

# 401 -> run the refresh chain, retry once
# 429 -> respect the weekly cadence; do not poll intraday

One normalized record per ticker, per week

We collapse both layers into a single weekly record so the public base and the app's math reconcile against each other:

{
  "ticker": "2330.TW",
  "asOfWeek": "2026-05-15",
  "source": "tdcc-dispersion + nstock-derived",
  "dispersion": [ { "tier":15, "holders":4123,
                     "shares":812340000, "pctOfCustody":3.71 } ],
  "majorShareholders": { "countRule":"by-share-capital-tier",
                          "count":312, "pct":71.4 },
  "minorShareholders": { "pct":28.6 },
  "priceOverlay": { "close":1015, "currency":"TWD" }
}

{ "watchlist": { "owner":"consented-account",
                 "tickers":["2330.TW","2317.TW"], "refresh":"weekly" } }

PDPA, and where the public-data line sits

Most of this payload carries no personal element — aggregate holder counts per shareholding tier are market statistics, not data about an identifiable person. The personal surface is narrow and specific: the self-selected watchlist and the device or account identifier it binds to. That falls under Taiwan's Personal Data Protection Act, whose 2023 amendment raised penalties for inadequate security measures and created a dedicated data-protection authority. Our posture: the public dispersion layer is integrated under the Open Government Data License with attribution; the watchlist is treated as a separately consented surface with a documented retention window, kept minimal and revocable, and access to any account-bound state is arranged with you and logged. Where a customer's own portfolio universe is involved we work under NDA. Compliance here is how the integration is built, not a gate the data sits behind.

Judgment calls we make for you

Two engineering decisions are specific to this app and we own them, so they do not surface as surprises later.

• Variable major-shareholder count. 籌碼大股東 does not show a flat top-N; it scales the number of "major shareholders" to each stock's share-capital tier, so a large-cap and a small-cap stock expose different cut-offs. We encode that tiering rule in the normalized schema so the exported ranking matches the on-screen number, and we hold it consistent against the raw TDCC tiers.
• Two layers that can drift apart. The public dispersion table and the app's derived series do not always advance on the same beat. We make the snapshot week the join key for both, run a weekly reconciliation that flags any week where the derived layer disagrees with the recomputed base, and keep the contract test green so an endpoint change is caught in the maintenance window rather than in your data.

Access to the app backend and to any consenting account is set up with you during onboarding — it is part of the work, handled as a step in the project, not something to clear beforehand.

Cost and how it runs

A working pull of the weekly dispersion base layer plus the app's derived major-shareholder ranking and flow series is a one-to-two-week build. After that, you choose how to take it. We can deliver the runnable source, the OpenAPI spec, the protocol report and tests as a package starting at $300, billed only after delivery once you have checked it does what this brief says. Or we host the integration and you call our endpoints, paying per call with nothing upfront. Same data either way; the difference is whether you run the code or we do. Tell us the tickers you care about and what you want out of the chip data on the contact page and we will scope it back to you.

Screens we worked from

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

Where this sits among Taiwan chip tools

Same category, useful for scoping a unified chip-analytics feed. Names are listed for context, not ranked.

• 股市籌碼K線 (CMoney) — chip K-line app combining major-investor positioning with technical lines; a parallel read on accumulation.
• 股市籌碼K線大股東-跟著大股東買股票 (CMoney) — a major-shareholder follow product over a similar dispersion base, useful for cross-checking derived rankings.
• 三竹股市 (Mitake) — broad Taiwan/US/Japan quotes with a chip overview and broker branch entry/exit data.
• 三竹智選股 (Mitake) — screening and stock-health tooling that consumes similar institutional and chip signals.
• Mr. Yuanta (Yuanta Securities) — broker app pairing screening with quotes and trading; holds account-bound state alongside market data.
• 行動股市 (Dayna) — a general Taiwan watching/quotes app whose watchlist surface maps onto the same sync model.
• Goodinfo! 台灣股市資訊網 — a web reference for shareholding structure and fundamentals, often used to verify dispersion-derived figures.
• 籌碼K線 — another chip-line product investors compare against the major-shareholder view.

Questions integrators actually ask us

The numbers come from the TDCC dispersion table — why not just read that open dataset ourselves?

You can, and we will set that base layer up cleanly for you. But the raw 集保戶股權分散表 is one weekly table of holder counts per shareholding tier. What makes 籌碼大股東 useful is the layer on top: a major-shareholder count scaled to each stock's share capital, a 52-week flow series, the major-versus-minority split, and the price overlay. That derived layer is the part we reverse-engineer for interoperability; the open dataset alone does not give it to you.

How fresh is what we would receive — does the chip data move during the trading day?

No. The TDCC custody snapshot is taken on the last business day of each week and published weekly, so the dispersion figures and the app's derived trend advance once a week, not intraday. We design the sync to that cadence and add a guard for holiday-shifted releases so a delayed week is detected rather than silently skipped.

Does 籌碼大股東 hold anything personal we would need consent for?

Most of the payload is public market data with no personal element. The personal surface is the self-selected watchlist and the device or account identifier it is bound to, which fall under Taiwan's Personal Data Protection Act. We treat that watchlist as its own consented surface, keep it separable from the public market layer, and minimize what is retained.

The app shows a different number of major shareholders per stock — does your output preserve that?

Yes. 籌碼大股東 scales the major-shareholder count to each stock's share-capital size rather than using a flat top-N. We encode that tiering rule in the normalized schema so the exported ranking matches what a user sees on screen, and we reconcile it against the raw TDCC tiers so the two layers stay consistent.

What we checked

Mapped on 2026-05-17 against the app's Google Play listing, the TDCC dispersion-table documentation and open-data portal, Taiwan's national open-data dataset entry, and the Personal Data Protection Act text. Sources opened:

• 籌碼大股東 on Google Play
• TDCC — Table for Spread of Shareholdings under TDCC Custody
• Shareholder Ownership Dispersion Table (data.gov.tw dataset 11452, OGDL v1.0)
• Taiwan Personal Data Protection Act (English text)

OpenBanking Studio · integration desk mapping, 2026-05-17.