Reaching consolidated SET holdings behind the wiset login

One SET Member sign-in puts a Thai investor's whole position on screen — equities, bonds, and tax-benefit funds, drawn together under the Service tab's My Wealth view, with shareholder records and dividend history a tab away through TSD e-Service. SET describes this consolidated, multi-asset holdings view as a first for the Thai market. That single login is exactly what makes wiset worth integrating: the data already sits behind one authenticated account, normalized by SET, instead of scattered across a handful of broker apps. The job is to read it back out, with the account holder's consent, in a shape your own systems can use.

The route we would actually run here is authorized analysis of the SET Member session on a consenting account — driving the same authenticated calls the app makes and recording their shapes — because the holdings and shareholder surfaces are personal, per-account, and gated by login rather than offered as any shared feed. TSD's native report exports cover the audit-grade fallback. Below: what the app holds, how each route behaves, and what lands in your repo.

What the app actually holds

wiset organizes itself into five tabs — Me, Market, Service, Watch, More. The data worth integrating clusters in three of them. Mapped to where it originates:

The valuable, defensible part is the first three rows. Market and calendar data are useful but broadly published by SET; the holdings and shareholder records are the per-account material that justifies an integration in the first place.

Authorized routes to the data

Three routes apply to wiset. Each is described by what it reaches, how much work it is, how long it lasts, and what we set up to run it.

Session analysis on a consenting SET Member account

We sign in as the consenting account holder, observe the authenticated calls the app makes for My Wealth and the Market tab, and rebuild them as documented requests with the right headers, token handling, and response parsing. Reaches every holdings and market surface the account can see in-app. Effort is moderate and front-loaded into the mapping. Durability is good between app releases, with a re-check when SET ships a new client. Onboarding — which accounts, what consent record — is arranged with you; the build runs against a sandbox or a consenting account you nominate.

TSD Investor Portal authorization

The shareholder records sit behind TSD e-Service, which layers its own authorization over the SET Member login, in some flows through NDID identity verification. We treat it as a second handshake in the same job, so a holdings pull and a dividend-certificate pull can complete in one run. Reaches holder information, securities balances, statements, and benefit history. Effort is higher because of the extra identity step; durability is strong because the portal is a stable institutional service.

Native TSD report export

The Investor Portal already issues downloadable reports — statements of securities holding, withholding-tax certificates. Where a workflow only needs periodic records rather than live reads, we wire the export and parse it. Lowest effort, highest durability, coarser timing. It also doubles as a reconciliation check against the session route.

For most teams the session route on a consenting account is the one to build first, because it returns the live consolidated holdings that the other two only partly cover; we pair it with the TSD export as the reconciliation backstop and add the Investor Portal handshake when shareholder-level records are in scope.

What lands in your repo

Concrete artifacts, tied to wiset's own surfaces:

• An OpenAPI specification covering the My Wealth holdings read, the Market and calendar feeds, and the TSD shareholder and dividend endpoints as we map them.
• A protocol and auth-flow report: the SET Member token exchange and refresh, the TSD Investor Portal handshake, and any NDID step, with the cookie and bearer chain written down.
• Runnable source for the key endpoints in Python or Node.js — sign-in, holdings pull, calendar fetch, shareholder-benefit query — with retry and token-refresh handling.
• Automated tests against recorded fixtures, so a SET client update that shifts a response is caught before it reaches production.
• A normalized schema that flattens equities, bonds, and funds into one position model, plus interface documentation.
• Consent-capture and data-retention guidance written against Thailand's PDPA.

Hosted instead of source? The same endpoints run on our infrastructure and you call them, paying per call.

A sketch of the authenticated session

Illustrative shapes — exact paths and field names are confirmed against a consenting account during the build, not published by SET:

# 1) SET Member sign-in -> short-lived bearer + refresh
POST /auth/setmember/token
  { "grant": "refresh", "refresh_token": "..." }
  -> { "access_token": "...", "expires_in": 900 }

# 2) Consolidated portfolio, one row per position
GET /mywealth/holdings
  Authorization: Bearer <access_token>
  -> { "as_of": "2026-06-25",
       "positions": [
         { "symbol": "PTT",   "asset": "equity", "units": 1200,   "mkt_value_thb": 41400 },
         { "symbol": "...RMF", "asset": "fund",   "units": 850.21, "nav_thb": 18.42 },
         { "isin": "TH...",   "asset": "bond",   "face_thb": 100000 } ] }

# 3) Shareholder records ride a second authorization (TSD Investor Portal)
GET /tsd/holder/benefits?year=2025
  -> dividend rows + withholding-tax certificate references

# Error handling: 401 -> refresh once, then re-auth; back off on portal throttling.

The point of the sketch is the join: a position from My Wealth and a benefit row from TSD describe the same security under two different authorizations. Reconciling them on the symbol/isin key is where most of the build's care goes.

Consent and Thailand's PDPA

Holdings, dividends, and shareholder records are personal data under Thailand's Personal Data Protection Act (PDPA, B.E. 2562). The dependable lawful basis here is the account holder's own consent — recorded, scoped to the fields you genuinely need, and revocable — not any blanket authority. Where the TSD Investor Portal routes identity through NDID, that consented digital-identity check is part of the same chain rather than a side channel.

How we operate it: consent captured and logged before any read; retained fields minimized to what the use case requires; the access path documented end to end; an NDA in place where the engagement touches account holders' records. That posture is how the studio works, and it keeps the integration reviewable.

Engineering notes we account for

Two specifics about wiset that shape the build, handled on our side:

• Two authorizations, one job. My Wealth answers to the SET Member session; TSD e-Service answers to the Investor Portal (and sometimes NDID). We design the run so the second handshake refreshes on its own clock and a portal timeout never silently drops the shareholder half of a sync.
• Mixed asset shapes under one view. My Wealth folds equities, bonds, and tax-benefit funds into a single screen, but each carries different fields — units and market value for equities, NAV for funds, face value and ISIN for bonds. We model them as one position type with asset-specific branches so a downstream consumer reads a consistent record.
• Client-release drift. When SET ships a new wiset build the response shapes can move; we keep the mapping under fixture-backed tests and fold a re-check into maintenance so a quiet field rename is caught early.

Where teams put this to work

• A Thai wealth-advisory tool that imports a consenting client's full SET position instead of asking them to read it off four broker apps.
• A tax-prep workflow that pulls withholding-tax certificate rows and dividend history straight from TSD e-Service at filing time.
• A back-office reconciliation that matches registered shareholdings against a custody ledger ahead of a corporate action, using the securities calendar for timing.

Screens we worked from

How this was checked, and where

Worked from the app's own store listings and SET's published service pages in June 2026: the five-tab structure and the My Wealth / TSD e-Service descriptions from the Play Store entry and SET's launch announcement, the shareholder-service detail from SET's TSD Investor Portal page, and the PDPA framing from current Thai data-protection guidance. Endpoint paths above are illustrative until confirmed against a consenting account.

• wiset on Google Play (th.or.set.application.wiset)
• SET — TSD e-Service (Investor Portal)
• SET launches wiset, Thailand's first all-in-one investor app
• Thailand PDPA consent and notification guidance (Tilleke & Gibbins)

Mapped by the OpenBanking Studio integration desk · June 2026.

Apps in the same orbit

Other Thai investing apps that hold account-level data a unified integration might fold in. Listed as ecosystem context, not ranked.

• Streaming (Settrade) — multi-market trading app holding per-brokerage order history and real-time positions.
• AomWise (Settrade) — stocks, mutual funds, and DR/DRx in one account, holding consolidated fund and equity positions.
• Streaming Fund+ — mutual-fund focused, holding fund holdings and transaction history.
• TDX (Thai Digital Assets Exchange) — SET-group digital-token exchange holding token balances and trade history.
• Streaming Click2Win — trading-simulation app holding simulated order and watch data.
• Interactive Brokers — global broker available to Thai investors, holding cross-market positions and statements.
• SaxoInvestor (Saxo) — long-horizon platform holding stock, ETF, bond, and fund positions.
• Liberator — Thai trading app holding equity positions and order records.
• Bualuang Securities — brokerage app holding Thai equity and derivatives accounts.
• Kasikorn Securities (Streaming) — broker front end on Streaming, holding per-account Thai stock positions.

Questions integrators ask

Which surfaces hold the consolidated My Wealth holdings, and can they be read per account?

The Service tab's My Wealth view aggregates equities, bonds and tax-benefit funds for the signed-in SET Member. It is a per-account, server-rendered surface, so the integration reads one consenting account at a time through that account's own authenticated session; there is no shared bulk feed and we do not treat it as one.

Does the TSD e-Service shareholder data ride the same login as the SET Member session?

No. The shareholder records — holder information, securities balance, statements and withholding-tax certificates — sit behind the TSD Investor Portal, which carries its own authorization on top of the SET Member sign-in, in some flows via NDID. We map both handshakes so a holdings call and a shareholder-benefit call can run in one job.

How does Thailand's PDPA shape what we can pull from a consenting wiset account?

Holdings, dividends and shareholder records are personal data under Thailand's PDPA, so the lawful basis is the account holder's recorded consent, scoped to the fields you actually need and revocable. We log consent, minimize retained fields, and keep the access path documented so it stands up to review.

We already hold SET Member access for our own corporate accounts — what changes the build?

It shortens it. With a consenting account we can confirm the My Wealth and TSD response shapes directly during the build rather than inferring them, which firms up the schema and the test fixtures. Access is arranged with you during onboarding; the app name and what you want from its data are the only things we need to begin.

Runnable source for these wiset endpoints starts at $300, paid after delivery once you are satisfied with what works — the My Wealth pull, the TSD shareholder calls, the market feed, with tests and docs. Prefer not to host it yourself? The same integration runs on our infrastructure as a pay-per-call API with no upfront fee. Either way the turnaround is one to two weeks, and you only ever hand over the app name and what you want from its data — access, consent records and compliance are arranged with you as part of the work. Tell us what you need at /contact.html and we will scope it.