You Spend the Weekend on the Filings. The Funds Finished Trading Them Friday Afternoon — The Alpha Left for Retail Sits Where Machines Cannot Read

Saturday morning. You make coffee, open the laptop, pull the quarterly numbers that dropped Friday afternoon, and start the work you take pride in — figures into Excel, P/E computed, ROE against history, D/E checked for debt creep, support lines drawn on the chart.

Here is what happened to that exact same set of numbers while you were still asleep.

The second those statements hit the system on Friday afternoon, they were vacuumed into institutional models through an API, automatically. The numbers became features, got benchmarked against consensus, surprise was computed, and orders went out on a clock measured in milliseconds. By the time you finish the first cell in your spreadsheet, the price you are about to make a decision on has already digested that data.

This is not about diligence or intelligence. You may read a filing better than the new graduate at the fund. But you are playing a game where the rules are settled by speed, and in a speed game the side with an API and a server wins every time. No exceptions.

So the question is not "how do I read filings faster". It is "which battlefield is left, where speed is not what decides".

There is one. It has been open and free the whole time.

1. Only one definition of alpha survives contact: data not yet in the price

The problem with the data retail uses every day is that everyone holds the identical set. Price, volume, financial ratios, historical statements — bought from the same vendors, sitting in spreadsheets that look the same, processed by people trained the same way. Data everyone holds equally gets absorbed into the price very fast. What is left for you is the commission, not alpha.

That last row is this entire article compressed into one line: what keeps a dataset valuable is not its secrecy, it is the cost of reading it — and in Thailand that cost is high enough to lock almost the whole market out.

Read this sentence. I did not write it. It is live text from the Form 56-1 (One Report) of a Thai listed company.

VARO · FY2025: "Customer concentration risk: The Company has five major customers accounting for approximately 60% of total sales."

— verbatim from the risk factors section of the Form 56-1, page 4 · original at the SEC (Thailand's Securities and Exchange Commission)

Five customers, roughly 60% of sales. That is a quantitative fact with enormous consequence for valuation — it tells you about bargaining power, revenue volatility and tail risk that no financial ratio anywhere will tell you. And that 60% figure exists in nobody's price feed. It sits in one paragraph of a PDF.

2. Why quant funds turned to alternative data — and why nobody has mined Thailand's

Institutions abroad worked this out ten years ago. When the edge in reported numbers ran dry, they moved to alternative data — satellite images counting cars in parking lots, credit card data, web footprints, and the text in the documents companies file themselves.

In Thailand the best alternative data is the Form 56-1 / MD&A, and three things have kept it unmined. All three are the moat.

1. It is not data. It is a PDF — the Thai Form 56-1 is built for a human to open one file at a time. No API, no schema, Thai mixed with English, some files scanned images. Getting text out clean enough to process is pure engineering work that nobody wants to do.

2. Same word, different meaning / different words, same meaning — one company writes "ความเสี่ยงจากการกระจุกตัวของลูกค้า" [the customer book is narrow enough that they had to put it in writing]. Another writes "รายได้ส่วนใหญ่มาจากลูกค้าภาครัฐและรัฐวิสาหกิจ" [the top line rides the state budget cycle and nothing else]. A third writes "คำสั่งซื้อจากลูกค้ารายใหญ่ลดลง" [the anchor accounts are already cutting orders]. All three are the same story. Hit Ctrl+F with "กระจุกตัว" [the textbook word for concentration, and the only one a literal search will catch] and you find the first one only. Keyword search matches characters. It does not match meaning. I laid the two side by side in detail in semantic search versus keyword search.

3. Ninety percent of it is ritual language — most MD&A is sentences every company writes identically ("บริษัทมีการบริหารสภาพคล่องอย่างระมัดระวัง" [we have a treasury desk and nothing detonated this year]). Count raw word frequency and all you get is noise. What has value is the sentence that breaks the ritual, which is rare. That is the signal.

Together these three build an access cost high enough to keep most people out — which, in investment language, is the definition of a data moat. All that remains is for someone to pay that cost on your behalf.

3. Step one is not "search". It is "turn prose into a table"

The most common failure in this field is thinking the problem is solved by "a smarter search box". It is not. As long as the answer is still "30 relevant paragraphs", you sit and read them yourself, and you will never backtest anything, because the data has no axes.

What has to change is the unit of the answer, from "a chunk of text" to a structured finding — one row per fact, with columns, a time axis, a source, and every row backed by the original document rather than a summary the AI composed itself. How I force that, I wrote up in the three gates I use to keep fabricated numbers from getting out.

Here is what one row actually looks like in the system today. Pulled straight out, unedited.

{
  "id": "th:risk:EXT-PDG-FY2025-006-v1",
  "ticker": "PDG",
  "fy": 2025,
  "domain": "risk",
  "theme": "market-risk",
  "severity_score": 4,
  "is_distress_signal": true,
  "snippet_verbatim": "However, sales to major customers in the bottled water segment continued to decline, due to those customers having installed their own bottle-blowing machines in their production lines.",
  "source_url": "https://market.sec.or.th/public/idisc/en/FinancialReport/ALL-0000008325/20240101-20271231?symbol=PDG",
  "page_ref": 1,
  "audit_id": "EXT-PDG-FY2025-006-v1"
}

Once it looks like this, what was prose a moment ago becomes a panel dataset — a company axis (ticker), a time axis (fy), a topic axis (domain / theme) and rankable variables (severity_score, is_distress_signal), which is the minimum condition for doing anything that deserves the word quant.

And the part that matters most to someone who does model validation for a living: every row is required to carry snippet_verbatim (the original text management wrote, not an AI rewrite) + source_url + page_ref. If a signal starts distorting your model, you get back to the source line in one click. A tool that summarizes brilliantly but cannot point at the source does not make it to the investment committee table. (Same principle regulators enforce on AI inside financial institutions — the Bank of Thailand's ban on black-box AI.)

The index serving live today covers 916 listed Thai companies, both SET and mai, as 479,663 finding rows (read live from the index at the moment this page was built), split into 3 domains open for search on the Terminal — financials, risk and auditor (from the auditor's report) — spread across 26 sub-themes, from liquidity-risk, concentration-risk, credit-risk through to margin, revenue and key_audit_matters.

4. The case that explains all of it: PDG and the sentence that will never appear on a chart

Enough theory.

PDG (Prodigy) is not a company I picked in advance. I had never heard of it. It surfaced by itself from a single query run across the whole market, and following it down the time axis produced this entire arc in a few minutes. Here is the shape of it:

PDG (Prodigy) · one story told across four fiscal years — every line is management's own

  FY2022      Costs start to bite
              COGS/revenue = 84.65%   ← crude oil pushed raw material prices up
                  │
  FY2023      ⚠️ Cannot pass it through — the single most important line in the arc
              COGS/revenue = 89.46%
              "couldn't pass the burden of being increased costs to customers at all"
              ⇒ pricing power = zero
                  │
  FY2024      Profit rebounds +74.98% YoY
              ⇒ read this one year alone and you conclude "the bottom is in"
                  │
  FY2025      🚩 Customers moved production in-house (insourcing)
              "...customers having installed their own bottle-blowing machines..."
              ⇒ not cyclical, not seasonal = demand gone for good, no way back

  P/E · ROE · price charts tell you only "how much revenue disappeared"
  One sentence in the Form 56-1 tells you "it is not coming back"

Now the verbatim record. Every box links out to the original.

FY2022 — costs start to bite

"The cost of goods sold increased 34.633 million baht or 28.93 % compare with the same period 2021 but the cost of goods sold compared to sales revenue as 84.65%, it rose because the rising of raw material price that impacted from the rising in crude oil price."

— original page 1 (quarter ended 31 Mar 2022)

FY2023 — the squeeze continues, and this is the sentence that matters most

"The cost of goods sold decreased 8.796 million baht or 5.70 % compare with the same period 2022 but the cost of goods sold compared to sales revenue as 89.46%..."

"The company couldn't pass the burden of being increased costs to customers at all."

"The part of sale revenue decreased due to reducing in orders of major customers."

— original pages 1–2

Stop here and look properly. The system files that middle sentence as risk/strategic-risk · severity_score: 5 · is_distress_signal: true

That sentence is the most direct confession about pricing power the management of a listed company is capable of writing. And it appears as no line in the financial statements. You see only its effect — gross margin contracting — never the structural cause. And you have no way of knowing whether the problem is temporary or permanent until you read it. COGS to revenue in the same quarter moved from 84.65% to 89.46% in one year.

FY2024 — recovery

"As ended of the third quarter of 2024, the company generated a net profit to THB 13.673 million increasing of THB 5.859 million or 74.98% which compared with the net profit of THB 7.814 million in the third quarter of 2023"

— original page 1

I include this one because it matters — the method is not built to find bad news only. It catches turning points too. Read FY2023 alone and conclude the company is finished, and you miss half the story. Read FY2024 alone and you miss the other half, which is worse.

FY2025 — and this is what I call real alpha

"However, sales to major customers in the bottled water segment continued to decline, due to those customers having installed their own bottle-blowing machines in their production lines."

— original page 1

Read it slower: the major customers bought bottle-blowing machines and installed them in their own production lines.

That is not a cycle, not a season, not a soft economy — it is the customer insourcing production, a permanent and irreversible loss of demand. No financial ratio tells you how the lost revenue was lost. It tells you only how much. One sentence in one paragraph of a Form 56-1 tells you it is not coming back.

And this is the whole point of the article: however well you read a filing, however skilled you are with a chart, however early you get up — the dataset you use has no field for this fact in the first place. It is not a speed problem. You are reading a different document from the people who actually know.

5. The four-step workflow I actually run

Step 1 — write the hypothesis in the language management "would write", not in keywords

This is the step people get wrong most often, and it is free.

Do not type "customer concentration". Type the sentence you think management would actually write when forced to explain the thing — for example "บริษัทพึ่งพารายได้จากลูกค้ารายใหญ่เพียงไม่กี่ราย" [the top line hangs on a handful of accounts and they had to put it in writing]. The system compares the meaning of your sentence with the meaning of the paragraphs in the documents. The closer your sentence is to the language management actually uses, the tighter the hit.

I ran that query across the whole market. It came back in 47 milliseconds. Top three:

VARO · FY2025 · risk/concentration-risk: "Customer concentration risk: The Company has five major customers accounting for approximately 60% of total sales." — original page 4

AIT · FY2023 · risk/concentration-risk: "The majority of the Company's revenue recognized in 2023 comes from government and state enterprises customers." — original page 1

JDF · FY2024 · risk/strategic-risk: "The proportion of sales from products produced for customers to sell under their own brand and products that the company manufactures on behalf of customers was 92%, while the sales of products under the company's own brand accounted for 8% of total revenue." — original page 4

Note that not one result contains "พึ่งพา" [the word a filing uses when it concedes dependence] or "รายใหญ่เพียงไม่กี่ราย" [the phrase for a customer base of a handful], which is what I typed. JDF does not even use the word for concentration. It writes OEM 92% / own brand 8%, which is the same fact in substance. This is what Ctrl+F will never do, ever.

Step 2 — sweep the whole market cross-section first, do not drill a single name yet

Once you have the right query, the next move is to read it as a cross-section, not as a stock list. The question you are answering is not "which stock should I buy" but "how is this problem distributed across the market".

If 40 companies say the same thing, it is a macro theme (raw materials, wages, interest rates) — the price has probably taken some of it in. But if 3 companies say it and the other 37 in the same industry are silent, the silence is the data. You have just found a difference nobody has priced. (A full cross-section on the wage and interest-rate themes, 23 companies verbatim, is in the piece on labor and funding costs.)

Step 3 — read across time, because the signal is in the change, not the level

This step is the core, and it is the entire reason every row needs a fy axis. The PDG case in the previous section is this step, start to finish.

The level of risk is rarely worth much, because every company writes about risk the same way. What is worth something is how the same company's language changed year over year — I wrote up how to read this way in reading MD&A across time.

And the point people skip: PDG is a small company with no analyst coverage. If a system covers only part of the market, companies like this are the first to fall through the mesh — because what disappears first is always the tail, never the head. The grid today is the entire market. A PDG-shaped story is no longer something you have to get lucky to find.

Step 4 — narrow the funnel with filters, not with your eyes

Once you can read, the next problem is scale. You cannot eyeball hundreds of thousands of finding rows. You narrow the funnel. These are real numbers from the index build of 10 Aug 2026.

 384,568 rows   Full index (all fiscal years · 921 companies)
      │
      │  ↓ keep only the 6-year window searchable on the Terminal (FY2021–FY2026)
      ▼
 340,323 rows   (915 companies)
      │
      │  ↓ + flagged is_distress_signal
      ▼
  99,876 rows   (903 companies)  ⚠️ nearly the whole market — this flag alone is "not" a signal
      │
      │  ↓ + severity_score = 5 alongside the flag
      ▼
   5,513 rows   (722 companies)  ✅ a count an analyst team can actually read through

Look hard at the numbers in parentheses and you will see the most important trap in this dataset. The is_distress_signal flag alone catches 903 of 915 companies — nearly the whole market. And severity_score = 5 alone casts a net just as wide (70,907 rows across 903 companies). Which means neither of these two filters is a signal on its own — what actually narrows the funnel is using them together and putting the weight on the theme. So the 5,513 figure is the condition "flagged and severity 5", not one or the other. I put this here because if you are a quant you will find it yourself on day one, and I would rather you heard it from me first.

Note on the numbers: the figures in this funnel (and in the per-fiscal-year table at the end) are frozen at the 10 Aug 2026 build, because they have to add up as a set. The company and row counts shown in section 3 are read live from the serving index, so they run higher and move whenever new documents land — different because they are measured at different times, not because they are different systems.

6. From signal to factor: pulling the full dataset out to backtest

Everything above is still hand research. To make it a real factor you need the whole dataset, not the top 10 search results — and that is an entirely different engineering problem.

So I split it out into a separate REST endpoint built for quants specifically: GET /v1/quant/findings, which is not a search. It is a scan of every row matching the filter, in a fixed order (ticker, fy, id), paged with a cursor.

• Filter by tickers / fy_start · fy_end / theme / domain / distress_only
• Every page returns total_matched (full post-filter set size) + next_cursor + has_more — walk it to the end of the set with no rows lost or duplicated at the page seams
• Every row carries provenance as part of the contract, not as a courtesy: audit_id, source_url, page_ref, extraction_version
• since_updated_at for delta-sync — the first pass pulls everything, subsequent passes pull only what changed (new filings). No reloading history.
• Token-bucket rate limit at 300 calls/minute (burst 600), answering 429 with Retry-After and X-RateLimit-* so your script can pace itself

Entitlements are enforced at the backend, not in the frontend. I fired a GAMMA-tier key at it (the highest package sold). This is what actually came back.

HTTP 403
{"error":"quant_api_required","tier":"max","upsell_tier":"quant_api",
 "note":"Bulk & time-series access is the Quant API (B2B) package."}

Note on naming: the "tier":"max" value in the response above is an internal system key, not the name of the package being sold — when the packages were renamed to the "The Greeks" set (1 Aug 2026) I deliberately left the original keys alone (pro → DELTA · max → GAMMA), because those keys are bound to the subscription row and the entitlement token of people who have already paid. Changing a key to make a name look neat orphans an existing customer's entitlement and buys nothing back. I am reproducing the raw response unedited, because if you wire up the API you will see this key.

The Quant API package is ฿5,999/month (6 years deep, no cap on calls per day). It is not on the website yet — I am opening it one user at a time, direct, because I want to know what you will actually do with it before I lock a contract. If you are at a fund or an asset manager, or you run systematic strategies and want this dataset to test, email contact@boomleverage.com.

7. And if you do not want to write Python — you do not have to

Everything in the previous section is what institutional-grade alternative data looks like: cursor pagination, delta-sync, provenance in the API contract, a token-bucket rate limit.

And if you are retail and you got this far thinking "good stuff, but I do not code" — that gap is exactly why this dataset has always belonged to institutions. Not because the documents are closed, but because between the document and the reader sits a layer of engineering an ordinary person has no way across.

So I took that same block of data — same rows, same store, same sources — and wired it to a plain Thai search screen on the Boom Leverage Terminal. You type the sentence you think management would write. The system returns the actual paragraph with a link to the Form 56-1 so you can check it. Done.

Plainly: the two answer different questions. The API side answers "did this factor make money over the past 6 years". The screen side answers "what did management write about the stock I hold that I have never read". The second question is in no way the lesser one. It is just answerable in ten seconds instead of ten weeks.

8. Four traps to clear before this dataset goes into a model

This is the section I most want you to read, and the section data vendors do not normally write. I do model validation for a living. My job is to find where a model breaks — so I will tell you where my own dataset will break yours.

1. Look-ahead bias — the trap that will kill your backtest

fy is not the date this data became available. It is the fiscal year the content refers to. The Form 56-1 and the MD&A are filed with the SEC weeks to months after that.

Line a FY2023 signal up against returns from the start of 2023 and you are trading on information nobody in the real world could read yet. The Sharpe will be beautiful and entirely fake.

The correct alignment uses the filing date as the point the data enters your dataset. Plainly: the system does not yet stamp a filing date at row level — updated_at today is index-build-cycle resolution, not document resolution (row-level stamping is queued and has to be fixed at the extractor; the API contract already reserves the field). Until then, you have to pull the filing date from the source file at the SEC itself — which is doable, because every row already carries source_url.

I am willing to write this paragraph even though it makes my own product look worse, because if you are a real quant this is your first question, and I want the answer in front of you before you have to ask it.

2. Survivorship bias — the most valuable samples are the ones already gone

Today's index is built from companies still listed, which means the companies that already failed are absent from the sample — and that is the most valuable sample of all if you want to build an early-warning model. Train on survivors only and your model learns that "danger signals usually lead nowhere", which is a false conclusion.

This is explicitly on my roadmap — collect historical Form 56-1 filings from delisted, merged and renamed companies, then run them back to find the language patterns that appear before a crisis. But as of writing, it is not done. So I say it here, rather than writing it up as a feature on a sales page. (The fundamentals of reading warning signals out of text I covered in the piece on NLP early-warning systems inside banks, which is work I actually built on the credit risk side.)

3. Ritual language will swallow your signal

Once more because it matters: the is_distress_signal flag hits 903 of 915 companies over the 6-year window. Use it as a standalone variable and you get a factor with almost no discriminating power. severity_score = 5 behaves the same way (the same 903 companies). Full market coverage does not make this problem go away. It makes it more visible — the more complete the sample, the wider a coarse filter casts.

And here is something important I have to say, because if I do not, you will read the numbers wrong: these two fields do not mean the same thing in every domain. That is by design.

• is_distress_signal is reserved for the risk domain only. In the financials domain it is always false by design — not because there is nothing worrying in the financial statements, but because a "distress flag" is a risk-side question, not a numbers-side one.
• severity_score in the financials domain measures materiality, not danger. A highly material item is therefore entirely normal, not a warning. In the risk domain the same value reads far more literally as severity.

So do not compare severity_score across domains directly. You would be adding importance to danger, which are different units. The 5,513 rows in the funnel above are therefore the condition "flagged and severity 5" — which, by the definition of the flag, already restricts to the risk side on its own. That is why it actually narrows the funnel, and it is not a coincidence.

The way that works is to treat it as a first-pass filter and put the real signal in the difference — company against itself in the prior year (which themes are new, which themes moved up in severity), and company against the median of its own industry in the same year. PDG's "couldn't pass the burden of being increased costs to customers at all" is valuable because it is not a ritual sentence, not because it carries a flag.

4. The grid is full — but "full" does not mean "unbiased"

If you are running a panel regression or an event study you need to know the shape of your grid. These are the company counts with data by fiscal year (10 Aug 2026 build), and they matter more than the total.

These numbers equal the number of companies that actually filed in each fiscal year. Put another way, the mapping of the whole market is finished — every volume that reached us has been extracted and indexed. The remaining ceiling is not the system's processing capacity, it is the number of documents that exist in the world. The empty cells are documents nobody has filed yet, not documents we could not get to.

But here is the part a career in model validation makes me flag: a full grid is not a neutral grid. Three biases survive, and you handle them yourself.

One — FY2026 is not finished. Most of the 815 companies in the bottom row come from quarterly filings, not full annual reports. Compare the latest year against complete years directly and you are comparing different units. Drop the running year, or compare quarter against quarter only.

Two — depth per company is uneven. Large companies write longer, more detailed MD&A and therefore produce several times more rows per year than small ones. Count "number of findings" as a raw variable and you are measuring document length, not business risk. Always normalize to that company's row count before comparing across companies.

Three — non-standard fiscal years. A number of Thai companies do not close on 31 Dec, so the fy axis is not the same calendar axis on every row. If your strategy is sensitive at quarterly resolution, align on the actual filing date from source_url, not on the fy number (this ties straight back to trap 1).

The minimum standard is therefore unchanged: set a rule for how many years of data a company needs to enter the sample, and always report how many companies the rule dropped. The only difference is that today that rule drops very few, because almost every company has all 6 years.

9. "And what if you disappear?" — the last question the institutional side always asks

Putting a dataset into an investment process means taking on vendor risk. If my answer were "do not worry, I am not going anywhere", that is not an answer. Here is the actual structure that keeps this system from being tied to one person.

Layer 1 — a fleet of AI agents running the line themselves. Downloading documents from the SEC, splitting, OCR, extracting findings, verifying verbatim citations, all the way through to rebuilding the index, runs as automated lanes 24 hours a day, with a controller dispatching work, catching failures and re-running them. What the humans do is set the rules and check the output. They do not walk the line.

Layer 2 — no dependency on a single AI vendor. The extraction system is designed to swap model providers without touching the pipeline. Several layers of cross-vendor fallback are in place today, because the lesson from model risk work is that single-vendor dependence is systemic risk, not a pricing question.

Layer 3 — a human team that is not just me. Development and operations run on an outsourced team and a working network of developers, not a structure where all the knowledge sits in one head.

Layer 4 — and this one matters most: the dataset is verifiable without going through me. Every row always carries snippet_verbatim + source_url + page_ref + audit_id, and every source is a public document the SEC publishes free. Which means that if one day you want to prove out every row I ever sent you, you can do the whole set yourself, without asking me for anything.

That last point is the real answer to key person risk in a data business — not because a contract says we will be here forever, but because what we hand you proves itself on a day we are not.

10. Stop fighting in a game where everyone carries the same weapon

Alpha is not in a more complicated model, and it is not in reading filings faster than before — it is in the dataset nobody else reaches because converting it is too much work. In Thai equities, that dataset has been sitting free on the SEC website the whole time. It is just in a shape machines cannot read.

If you are still fighting with P/E · ROE · charts, you are fighting on a battlefield where your opponent holds the identical weapon and fires it a million times faster. On the battlefield where management's words decide, speed is worth nothing — the advantage goes to whoever asks the right question. The data is open to everyone equally. The questions are not.

Try it yourself tonight — for this launch window I am giving everyone who logs into the Terminal the full DELTA package free until 30 Sep 2026 (4 years deep · 150 credits/day), no card required, because billing is switched off entirely for the promotion. When it ends the entitlement reverts to the free package on its own. Nothing charges automatically. (why I am giving it away, and the full terms)

Go to terminal.boomleverage.com and do step 1 of this article: type your hypothesis as a sentence management would write, and see which companies are saying that thing without your knowing — starting with the stocks in your portfolio right now.

If you are on the institutional side and want the full dataset through the API to backtest, email contact@boomleverage.com. I handle every conversation myself.

This tool provides information and educational analysis with citations to the source documents. It is not investment advice. The company names raised in this article are purely methodological examples, to demonstrate how to read text out of public disclosure documents — not a signal to buy or sell any security. Every quotation is verbatim from a publicly disclosed Form 56-1, with a link to the original at every point. Investment decisions are the user's own responsibility.